Hello Ben, On Thu, Aug 07, 2008 at 11:24:55PM +0100, Ben Hutchings wrote: > -------- Forwarded Message -------- > From: Simon Tatham <[EMAIL PROTECTED]> > To: Ben Hutchings <[EMAIL PROTECTED]> > Subject: Re: Bug#483665: Po4a is ready, should I start? > Date: Thu, 07 Aug 2008 11:08:11 +0100 > > Ben Hutchings <[EMAIL PROTECTED]> wrote: > > > I think it would be better to get your translations upstream, if they > > will be accepted. As I said before, document translations should not be > > so difficult to deal with in a portable way as string translations seem > > to be. I'm cc'ing Simon so he can comment on this. > > Hmm. Certainly I agree that translations of the Puzzles manual would > be much easier to manage than translations of the strings scattered > throughout the source code.
Translations, be it program or manual or ... are only work once for
the developer: He has to denote the translatable material and update
the build system (actually, for documentation you can use po4a, where
only the build system needs an update). Once this is present, upstream
can usually ignore l10n issues, only accept updates by the translation
teams when they arrive. E.g. for gnome, upstream simply pulls all
translations available at release time from their SVN repository,
where the localization teams routinely update the translations.
If upstream / the Debian maintainer is nice, then he can get
statistics once he finishes updating the strings and request (one
command!) more and updated translations before he releases (or do
another point release once a certain amount of translations has
arrived). But this is optional (though certainly liked by l10n teams).
> The thing that always concerns me about keeping translations of the
> manual in my repository is that I don't have the skills to keep them
> up to date myself. So where I'd normally make checkins to my
You don't have to. This is the job of the l10n teams. As long as only
a (small) part is translated, *always* the English version is used.
You can setup what you consider small, I think the default for po is
80%. Once a translation passes this stage (usually counted per
programm / per manual page) the translation is used *where current*,
while remaining paragraphs are intermixed in English. So if you update
a certain paragraph, then this will appear in English in all
translations until the relevant teams update their translation.
> repository which atomically update the code and documentation so
> that everything remains in sync and self-consistent, I would now
> have to make checkins which left the various docs versions out of
> sync with each other and with the code (or else, unacceptably, have
> a potentially unbounded set of translators be on my critical path
> for all docs-affecting checkins).
No, l10n requests are nice but not necessary. And as stated above, the
user would always get current information, just some part might not be
in his/her native language but in English instead. The only "overhead"
would be if you are kind to translators, to do a "point" release
(maybe fixing minor bugs along) with updated translations, but this
could also be done by, e.g., the Debian maintainer until you do
release the next version.
> So it would seem more sensible for me to have docs (and other)
> translations kept somewhere separate from my core code, with an
> indication of which core source revision they were accurate as of.
This is detected automatically. Basically when you build your
programms and docs the l10n system (e.g. po4a, or plain gettext) check
for which strings they can get a translation. The l10n teams do a dry
run (or simply take the last run of yours) and add translations for all
missing strings (simply by downloading a certain file, updating it,
and then sending it back to you / commiting them). So having them
separatly is of course possible, but probably increase the workload,
because there would need to be a mechanism to connect both locations.
I, for example, maintain translations where upstream does not want to,
but this places the burden on me to get upstreams work, see whats
missing, getting the updates (because translators might not know that
a "downstream" maintains them) and so on. Technically possible, but
sub optimal.
> I'm willing to have that "somewhere" be a subdirectory of my own
> repository, if necessary, but it would seem to me more convenient if
> it were somewhere the translators could directly commit changes to.
For this I leave it to your workflow. Usually it is sufficient for
l10n teams to have *read* access to your repository, so they can
always grab the latest version of your files when working on their
translation. They would then send the update to you so you can check
them in. Of course, as I said, you could provide a certain repository
which you sync with regularly, where you could give write access as
well to l10n teams. I think this just has to fit your personal work
flow, l10n teams are usually rather flexible, especially when they see
that their work is actually integreated. So simply *tell* us your
favorite way of work (or, if it is complicated, a script automating
it would be nice as well).
I hope I could clarify the issues at hand. If you like, I can go into
more technical terms[1], but atm I think the actually implementation is
not at question, but rather the general issues.
Greetings
Helge
[1] Well, as so far that it works. At least I have enough pointers to
man pages so that all questions should be answered, and
i18n.debian.org could probably cover those corner cases forgotten
in the man pages (or special to your case).
--
Dr. Helge Kreutzmann [EMAIL PROTECTED]
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: Digital signature
