On Tue, Oct 14, 2003 at 12:39:43PM -0400, Joey Hess wrote:
> Martin Quinson wrote:
> > /etc/po-sysv/<lang-code>/po-sysv.po
> > translation provided by this package, extracted by the scripts of
> > w.d.o/intl/l10n and translated as usual (main way of translation)
>
> You seem to be proposing a centralized repository of translations for
> these strings, as well as bloating /etc with files that were designed to
> go in source packages. I think both are very bad ideas.
About the bloating po /etc, I agree, it should be placed elsewhere.
About the centralized translation DB, my point is that each package would
have at the *very* most 20 strings. This leads to:
- i18ning the init scripts is a rather simple task, needing at the very
most one full time week to get implemented.
- Extracting all possible strings and translating them all to your native
language does neither need more than a few days (including reviews from
peers).
- Repporting every piece of translation as bug report, getting it fixed in
the package, and the package uploaded (pesting the maintainer not willing
to integrate them, isolating MIA maintainer to get someone NMU the
package to integrate them) ;
Checking that the translation was not broken in the process (ie, encoding
of data preserved, for example) ;
Checking wheather the translation of the package is modified to update your
translation, and go through the integration process again...
...takes more time than the translation itself when the size of the data
to translate becomes small enough.
I also guess that this situation would be annoying for maintainers.
Change one letter in your init output, and you'll get 2-10 bug repports,
some of them even proposing further improvement to the strings, inducing
yet more translation update...
This is why I plan to provide a way to centralize the translations in
po-sysv. But my plan is not to keep this like that for ages.
When a translation is integrated into the package (which have to be in a
perfect world), it will be no need to put it into the centralized DB.
Likewise, when we come up with a working translation center for Debian,
easing the interaction between maintainer and translators without relying on
bug game, this system can be ripped out.
Moreover, this centralized translation schema is not intended to be extended
to other source of material. The specificity of po-sysv is the small size of
each <package>.po file, allowing (IMHO) to some shortcuts in the design to
ease the logistics.
> > /etc/po-sysv/<lang-code>/user.po
> > The user may want to overide the translations.
>
> That smells of overdesign. If users really want to override
> translations, standard gettext could be modified to support it without
> adding a confusing and debian-specific directory to /etc that we have no
> evidence that anyone would ever use.
Mmm. You may be right, I'm not sure about that. The need of that file is
indeed not proved yet.
> > /usr/share/locale/.../po-sysv.mo
> > The messages of the binaries in that package, if needed.
>
> ?
There is 2 binaries in po-sysv. If they have to output messages under some
conditions, I'd like to have them i18n'ed also.
> > /etc/sysv-i18n/sysv-i18n.bashrc
> > every bash-based init script should source it prepare the i18n of messages.
>
> You seem to be calling for throwing out a lot of effort to let shells
> other than bash be used during bootup (some POSIX complient shells other
> than bash run about 10x as fast). I don't think that's a good idea,
> there are other ways to get i18n in POSIX shell than relying on
> bashisms.
No, this time it was simply underdesigned ;) We have to come up with a
sysv-i18n.pm (placed somewhere under /usr/lib/perl) and a
/etc/sysv-i18n/sysv-i18n.sh which use the ECHO="gettext -n" trick. That way,
each maintainer is free to choose the scripting language he wants for init
scripts.
Thanks for your time, Mt.
--
The tragedy of modern man is not that he knows less and less about the
meaning of his own life, but that it bothers him less and less.
--- Vaclav Havel
Attachment:
pgpFiJYo07xtr.pgp
Description: PGP signature