Hello Ian,
full quote, as i acidentially dropped the list.
On Mon, Oct 08, 2018 at 06:07:51PM +0100, Ian Jackson wrote:
> Helge Kreutzmann writes ("Re: advice on po/pot/po4a layout etc. [and 1 more messages]"):
> > Hello Ian,
> > > This is now done. The updated README is here:
> > > https://browse.dgit.debian.org/dgit.git/tree/po/README
> >
> > Thanks. Reading it as a translator, I like it, as it gives me a good
> > introduction where to start and what are the relations and priorties.
>
> Thanks. I really appreciate your feedback (both positive and
> negative). It is very helpful to have guidance from people who know
> the area better.
>
> (Was there a reason you dropped the list? If not, please do post your
> response there, as I think it's likely to be helpful to others, given
> the questions I am about to ask...)
No, it happened by chance.
> > I'm only missing a paragraph about minimum translation, i.e. how much
> > of the messages / man pages need to be translated, before the
> > translation is used. Is this the common 80% rule or did you change it?
>
> This is an interesting question. I noticed while working on the po4a
> machinery that there was this -t option. But I didn't have much of an
> idea on what basis I ought to be setting the value.
>
> After thinking about it a bit I set it to 50%. I would have gone
> lower, but I wasn't sure if there was a good reason not to set it to
> (say) 10%.
>
> Is it very jarring or difficult for the reader, to provide a
> partially-translated document ? Obviously a fully-translated document
> is better. But ISTM that a partially-translated one is likely to be
> better than a completely untranslated one.
As you give good guidenance like providing the original term alongside
the translated one, i completely agree in your case. This eases the
burden for translators also, as they know the result can be seen /
used earlier. (Translation resources are scarce, especially if a
review is added).
> This is particularly true for documents like mine, which are very
> "sectional" if you see what I mean.
Yes, I understand.
> As for the messages, I'm not wrong in thinking that any translation at
> all is better than none, so the po message translation machinery has
> no threshold ? I mean, I just use msgmerge with no special options.
>
> > (And you might want to run a spellchecker over it, as there a several
> > typos).
>
> Thanks for that suggestion. I will do that.
>
> > Start small, develop I'd say. From a translators view, who likes to
> > work on the repositories directly, I just would like to have a little
> > hassel as possible, as I know the basic git commands, but having
> > complex instructions for merging I would avoid, so if the machinery is
> > completely on the salsa side, I would not mind (sorry that I cannot
> > figure that out from your mail, in my use case I simply "push" the
> > updated file and then the maintainer does the rest).
>
> Err, yes.
>
> > You may want to add a paragraph in README about commiting the translation
> > as well (or a pointer to where this is covered).
>
> Right now there is no translation git repository. Nor even a tree on
> salsa. The git history is provided on the dgit git server (ie, you
> `dgit clone'). I think I should probably start by providing my own
> tree on salsa.
>
> I will add something to the README about committing the translation
> and using salsa to send a MR.
That would be verfy helpful.
> My thinking in my earlier mail was that maybe we should have a team on
> salsa that has automatically-updated repos for every translatable
> package and where a translator can just send a merge request.
>
> Presumably some robot would keep these trees updated, transform merge
> requests into BTS emails, and so on.
This is in principle a very interesting idea. Before starting, I would
like to point out three issues:
a) Translations are not 1:1, even within a domain like "computer
science" or "free software". Let alone that sometime you do
translate a term (let's say, the option is a filename, then
"filename" would be translated), and sometimes you don't (when
filename is the key, where an option is assigned to, oviously then
"filename" shall not be translate).
b) It is a huge tasks, requiring infrastruture, cooperation, etc. If
bubulle is still around, you might contact him, as he
(unsuccesfully, despite his *very* huge investement), tried this.
c) Only "native" packages or packages with no upstream translation
machinery could join, otherwise duplicated work would occur (e.g.
KDE, GNOME, libreoffice etc. have their own teams, there are
spanning efforts for multiple packages (cross distro)).
So yes, if it would work, it would be very welocmed, but maybe dgit
first?
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature