Re: Debian Debconf Translation: Compromise (was: Debian Debconf Translation proposal ( again ))
* Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> [040109 13:05]:
> If we could agree on the following other points raised here and in
> other people's mails, that would already be a major step forward:
>
> 1. A more formal system to be put in place on alioth, where you can
> more easily give write access to your translations to the
> translation teams.
> 2. Encourage more people to move their code to alioth. I guess this
> is a pretty good idea in general, that pretty much everybody
> already agrees on.
> 3. Try to put some sort of system in place to automatically warn
> translators about changed strings.
> 4. The good old string freeze. I don't personnally understand
> Wouter's "Ha !" comment, but I'm sure he'll be willing to expand
> upon this ?
I don't know if it is a so good idea to tie it to closely to alioth,
but I think some general mechanism for maintainers to give tasks
would really be a good idea. It does not help when the debconf-templates
are translated, but the program itself misses anything than three
languages.
And even when packages would all be in some central[1] cvs-archive, it
would still be hard to have everything there in a form making it easy
to say what should be described.
I as maintainer would most like some form of some place, where I can
submit several documents of different formats to be translated, together
with background information (and be it only links to the package
description and the upstream webpage[2]). Some formalism to describe
formats would be nice together with some way to share them[3].
This way I as maintainer, that know what is where in the package can
search all the important parts, I will hopefully know what will be
changed in the near future and even coordinate with upstream[4] about
a string-freeze in the upstream version and supply all the strings
and texts some weeks before I even start packaging that new version[5].
Last but not least for such a system to work there has to be some
easy and direct way for the maintainers and other intrested parties
to see the translated things. Getting upstream and its main testers
write some translations is not that easy, getting them reviewing some
is much easier, especially as they fear to read those in their mother
language when they also use Debian...
Hopefully looking into the future,
Bernhard R. Link
[1] I always shudder over the word "central", perhaps I think to much
about "central point of failure".
[2] As most of the ugliest and most bad translations around are totaly
valid translations but only quite out of context. German readers
may think about "Kein Weltraum links von Gerät".
[3] So that only one Person has to write some "This type is hand-written
manpage, format can be found <bla>, never translate .SH NAME"
[4] I guess the Packages from Gnome and KDE are still a minority, and
most little upstreams would benefit much from it. (As we Debian
Package Maintainers are also often the ones helping upstream with
strange architectures and strangenesses in their build-systems, it
is only logical to get in touch with that thing, too).
[5] For this it might be very useful, if the system made it possible to
have multiple versions of some dokuments[6], as the current old version
may get a upload in some days and then perhaps be a year in stable,
while the new version may be released by upstream then within the
freeze.
[6] Optimally with some way to mark them as lower priority, as some
priority system would be gernerally nice to perhaps first get the
programm than important dokumentation, and only when nothing else is
to do longer parts of dokumentation and tutorials...
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: