>
>
>Hello,
>
>I just tried to restart a service on the computer of a friend of mine using
>redhat, and the messages come in french. Now, I'm jalous and I want the same
>functionnality under Debian. I've checked the bug pages of sysvinit and
>general, and saw nothing like that.
>
>As usual, it will be more complicated under Debian than under other
>distributions because we have no centralized authority and some maintainers
>won't accept to see parts of "their" packages out of their hands.
>
>
>Here is the design I propose for that, introducing a new package called
>"po-sysv". It seems pretty simple and I may implement it soon, if nobody
>comes up with major objections.
>
>FILES:
>------
>
>/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)
>/usr/lib/po-sysv/<lang-code>/<package>.po
> If the package maintainer wants to override the content of the previous
> database, or simply to integrate those translations in their package.
>/etc/po-sysv/<lang-code>/user.po
> The user may want to overide the translations.
>
>/usr/share/locale/.../po-sysv-scripts.mo
> The result of the concatenation of both databases, to be used by the init
> scripts
>/usr/share/locale/.../po-sysv.mo
> The messages of the binaries in that package, if needed.
>
>/etc/sysv-i18n/sysv-i18n.bashrc
> every bash-based init script should source it prepare the i18n of message>s.
>
Please avoid using /etc for the data files; under the LSB
its reserved for configuration information, and even that is
being transitioned out.
Also, for /etc services remember that /usr may not be mounted
at the time, so /usr/share/locale (the 'best' place), is also
out.
Instead, put 'core' stuff, eg for base, in something like
/lib/locale/<lang>/<package.po>
>/etc/environment
> the definition of the LANGuage to use (this is standard, isn't it?).
>
>BINARIES:
>---------
>
>/usr/sbin/update-po-sysv
> Rebuilds the mo files from concatenation of po files.
> Rebuild the user.po, so that user can edit them.
>
>/usr/bin/po-sysv-install <init script>
> - finds out wheter the init script is perl- or bash- based
> - extract the strings from it (using standard tools)
> - create the /usr/lib/po-sysv/<lang-code>/<package>.po if needed
>
>PO CONCATENATION POLICY:
>------------------------
>The strings are taken in that order (ie, last overides first).
> - Fully translated strings provided by po-sysv.
> - Fully translated strings provided by each package.
> - Fully translated strings provided by the user.
>
>The user have the last word, but a given string is overrided only if the new
>one is fully translated (fuzzy discarded), of course.
>
>
>REMAINING PROBLEM:
>------------------
>
>/usr/bin/po-sysv-install should be integrated both with po-debconf, so that
>each package can have only one DB for both kind of material, and with
>debhelp so that this mecanism can be integrated seamlessly to debian.
>
>Both binaries could be placed in two packages (po-sysv and po-sysv-dev) so
>that the first one gets a chance to be of priority 'standard'.
>
>Did I edit my /etc/environment or is the definition of LANG in it standard?
>
>It is possible with this design to have string collision between packages.
>But I think that this is rather unlikely.
>
>This design also introduce a little mo bloat since all strings are
>translated, even for the uninstalled packages. But who cares about 10k? [*]
>
Why po-debconf ? gettext also supports shell, etc. (which is
how redhat, etc. do it). Some /etc/init.d files , such as
pcmcia, etc are shared across plaforms, which we would want,
and they use GETTEXT. Why not just use gettext, placing the
po files in the same place as redhat /mandrake, etc?
(Obviously use po-debconf for debconf stuff, but boot and
/etc/init.d services would use
if [ -e /bin/gettext ]
GETTEXT="getttext --domain $SERVICE "
else
GETTEXT="echo -n"
$GETTEXT "Starting service..."
etc.
>
>Any comment?
>Thanks, Mt.
>
>[*] This argument can be answered by the fact that this situation is "of
>course" only a hack for now. A proper solution involves a central server
>containing all translations. With this, each package could contain
>uptodate translations without imposing an extra burden on maintainer
>shoulder to handle l10n bugs like we do now for debconf. More on this later.
>
>--
>Though a program be but three lines long, someday it will have to be
>maintained.
> -- The Tao of programming
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQE/jAtDIiC/MeFF8zQRAk9VAKCYcebJnz21z4yawvOsoNwNLjmHUwCg0Vqf
>VuwnlxDclu3NQC2pgQrUsWM=
>=c64Z
>-----END PGP SIGNATURE-----
>
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
