In attachement, a new version of my proposal, hopefully addressing all remarks done so far. please, please, bug it if you feel it should be bugged. Thanks for your time, Mt.
GOALS: internationalizing the output of init scripts under /etc/init.d
----
- It should work
- Modification to init scripts should keep minimal
- Unneeded load on packager and translators should be avoided when possible
OVERVIEW and RATIONAL:
---------------------
I just tried to restart a service on the computer of a friend of mine using
redhat, and the messages came 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. That is why I propose to implement a
package called po-sysv offering the needed infrastructure for that.
It will be a bit more complicated under Debian since we cannot relly on a
centralized database, even for such translation. So, we have to come up with
a system allowing the package to put string in the common pot at
installation. This would be very similar to the /etc/bash_completion.d/ or
/etc/logrotate.d/.
On the other hand, putting those translation in the relevant source package
only is a bit cumbersome since those translations are so small. Requesting
each packager to deal with a bug repport per language each time the init
script change is too much burden on their shoulders.
So, we have to come up with a system using the translation from the packages
as primary source of information (since it is How It Should Be Done (TM)),
but providing a backup source of translations, which would be centralized,
and hopefully managed directly by translators (since it is easier).
This design implyies that all possible strings from Debian may end in the
centralized DB, which is a bloat (since even strings of not installed
packages would be installed). That is why this approach is not possible for
other translatable material (debconf templates comes to mind). But one
specificity of the messages in init is that there are very few such strings.
So, the bloat is small enough to allow this trick to ease the logistic.
Moreover, this is a hack doomed to disappear when we have a proper solution
to ease interaction between packagers and translators without the extra load
of the bug handling game.
FILES:
------
Source of translation:
/usr/share/po-sysv/<lang-code>/po-sysv.po
the centralized DB, as installed by the po-sysv package.
/usr/share/po-sysv/<lang-code>/<package>.po
the translation provided by each package (content overrides po-sysv.po)
Translation used:
/lib/locale/<lang-code>/LC_MESSAGES/po-sysv-scripts.mo
Concatenation of all available translation for init scripts
This cannot be at the usual /usr/share/locale since this dir is not
mounted when the first init script run.
Translation configuration:
/etc/environment
the definition of the LANGuage to use (this is standard, isn't it?).
Files needed to let the init scripts use this i18n:
/usr/share/po-sysv/bash.rc
to be sourced by bash scripts (3 such scripts on my box)
Use the $"bashism" to get translations (faster possibility)
/usr/share/po-sysv/sh.rc
to be sourced by /bin/sh scripts (84 such scripts on my box)
/usr/share/po-sysv/po-sysv.pm
to be used by perl scripts (no such scripts on my box. Drop it?)
Binaries:
/usr/sbin/update-po-sysv
Rebuilds the mo files from concatenation of po files.
/usr/bin/po-sysv-install <init script>
(help maintainers to add translation in there package)
- find out wheter the init script is perl- or bash- or sh- based
- extract the strings from it (using standard tools for the two first
possibility, something else for sh based scripts)
- get the translation contained in the package (at the same place than
the po-debconf ones?)
- build the needed /usr/share/po-sysv/<lang-code>/<package>.po in the
package binary archive
REMAINING PROBLEM:
------------------
- /usr/bin/po-sysv-install should be integrated both with po-debconf, so
that each source package can have only one DB for both kind of material,
and with debhelper so that this mecanism can be integrated seamlessly to
Debian.
- Both binaries (update-po-sysv and po-sysv-install) 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' when the second depends on 'superfluous'
packages to make implementor life easier.
- Did I edit my /etc/environment or is the definition of LANG in it
standard?
- Is /lib the best location for the mo file (containing the translations in
binary format) ?
- Would the console at the primary steps of the setup be able to display
exotic caracters (ie, non ASCII) ? If not, it there a possibility to give
it this feature ? If not is this idea doomed to death?
POSSIBLE ROADMAP:
----------------
- Implement this infrastructure
- Find a packager responsible of a package installing init script willing to
collaborate with me (should be easy) to debug the infrastructure.
- Announce the existence of this system, proposing to the packager to source
the relevant rc file to use it.
- Modify the w.d.o/intl/l10n/ scripts to extract all strings, even from
packages not sourcing the rc file.
- Get the centralized DB populated for 2-10 languages.
- Announce again this system, encouraging the packager not doing it yet to
source the relevant rc file and integrate the translation in their
package (if they want to).
- Bug the packages not sourcing the rc file.
- Get this system enforced in the policy.
- Bug the packages not containing their translation (?).
- Get rid of the centralized DB when/if it becomes useless.
CHANGELOG:
----------
20031015: Fixed (?) the design leak revealed on debian-i18n
Switched to verbose mode to explain what was not clear in the draft
Remove the borken idea of user.po
20031014: First draft
Attachment:
pgpKHG9hEqZ25.pgp
Description: PGP signature