On Wed, Oct 15, 2003 at 01:08:05PM +0100, amck@utvinternet.com wrote:
> Ok, Comments:
>
> (1) Keep it simple.
>
> Put the po files in /lib. RedHat, Mandrake keep them in
> /usr/share; I don't know how they handle unmounted /usr offhand.
>
> Don't ship the po files in packages, or merge, etc; they are
> source. Do something like
> # in /etc/init.d/file
> DOMAIN=foo # ie pkg uses /lib/locale/$lang/foo.mo
>
> . /etc/init.d/functions
> # This supplies $ECHO, as shown in previous mails.
> # then,
>
> $ECHO "Starting up..."
>
> , and thats all the changes required to the _script_.
That's where we disagree. I want to come up with a system making it simple
for the packager to use it in their scripts, ie inducing as less change to
their existing script as possible. Ie, I want to make it simple for them,
not for me.
> Later, /etc/init.d/functions can be changed/experimented with
> to provide green OK / graphical icons, etc.
It should also set LOCALEDIR or whatever it is called, to search the po
files in an already mounted directory, but that's not important.
> (2) Don't merge the po/mo files.
> Provide 1 .po file per package (providing n translated .mo files, of course).
>
> You cannot automatically merge .po files and expect it to work.
> A string may be context sensitive, and one source string have
> several translations, or be translated slightly differently
> by several translators; how does that work? if two packages
> both supply the string "Shutting down." but supply slightly
> different translations of that string, the merge won't work
> automatically. If this is kept within a package, the maintainer
> can resolve the issue. Don't worry too much about the small
> size of the po files; correctness is more important.
The section 9.4 of the policy does not give very much liberty to those
scripts. For example, "Shutting down" is disencouraged:
| When you stop or restart a daemon, you should issue a message identical
| to the startup message, except that Starting is replaced with Stopping or
| Restarting respectively.
|
| For example, stopping the printer daemon will like like this:
|
| Stopping printer spooler: lpd.
The error messages format is not specified by this section, but as it states
that each script is only allowed to output a single line, I guess that they
are forbiden. Again, this is a "should" and not a "must", though.
I greped around in the init files installed on my box, looking for evidence
that such string collision was impossible. My conclusion is that I
overestimated a lot the amount of stuff to translate. Most scripts use only
those constructions:
Starting $DESC: $NAME.
Stopping $DESC: $NAME.
Restarting $DESC: $NAME.
Reloading $DESC... done.
Saving $DESC... done.
(failed $REASON).
$DOING_ACTION... done.
Some scripts clearly don't respect the policy (lirc outputs more than 5
lines when the package is not configured), some other scripts provide more
command than the policy requieres (fetchmail debug-run) and thus have more
variating outputs.
My feeling is that all this could benefit of a more rigid tool to do the
output in order to gain in homogeneity. I am thinking about a tool to
remplace the echo command, and which could be i18ned to do what I previouly
thought.
The following would then be ok IMHO:
sysv-output <command> <arguments>
mimicking the outputs I gave above:
sysv-output start "$DESC" "$NAME"
sysv-output multi-start "$DESC" "$NAME" # for starting several daemon
sysv-output stop "$DESC" "$NAME"
sysv-output action "$DESC"
sysv-output failed "$reason"
sysv-output done
In order to display the green stuff in all case, a session oriented stuff
could be needed. The script chunk sourced by all init scripts to use that
system could fork a mini-daemon in charge of counting how many chars where
displayed so far to put the [OK] on the right column.
To i18n those strings, I don't think it's reasonable to ask each package to
provide a mo under /lib/locale or /usr/share/locale (depending on if they
are to be run before or after the mount) containing only one string (the
DESC) in most cases, and at most 5. It would really be better to include all
strings found within Debian in the package providing this service, with a
system for packages not included in the distribution to add their
translations. Yes, I mean po concatenation ;)
The benefits of such approach is that:
- All output gain in homogeneity
- It is simple to i18n and l10n
- It is possible to have other form of outputs (logging to syslog; green [OK])
> The setting of LANG is not our problem; its in /etc/environment,
> which init will source early on. Remember, some of these
> scripts will be run at other times, when LANG may be
> different; the standard mechanism suffices.
Sure, I just wanted to make sure that relying on the fact that LANG was set
by other mean was ok.
> (3) Don't use bashisms like $"hello" in init scripts. The
> shell is guaranteed _not_ to be bash in many cases.
I disagree. If the packager wrote #! /bin/bash as first line, I'm willing to
allow him to use the power of bash. Even if that was not clear in my first
version, I won't impose the use of bash, though. Note that if a sysv-tool
proves to be the way to go, this discusion is mot.
> (4) Don't conflate the problem with debconf. Debconf is a very nice tool, but
> not needed or used here.
You still don't get my point here. The use of the strings will be completely
different. Even in the binary package, the strings will be put in different
files, but I do think that putting the source of translation in the same
file for both po-debconf and init script is a good idea. This would make the
translator life easier, leading to an easier life for packager.
> (5) Additional tools, eg update-po-sysv, etc. are not needed,
> and will conflict with e.g. localepurge. Just place the
> compiled .mo files into, eg /lib/locale/<lang>/<foo>.mo
If the packagers want to i18n their package without this infrastructure,
they are both free to do so and very welcomed. I just want to i18n those
messages. I don't care how, but I propose a solution for those who care even
less than me ;)
> (6) Available console: A font with non-ASCII chars is needed.
> Currently the font is set quite late, in S48console-chars.sh,
> and a non-ASCII font is not set by default. This could be changed, though; consolechars
> is in /usr/bin; moving it
> to /bin would help. Non-ASCII fonts are shipped in
> console-data, but setting one by default will break
> VESA modes the user has chosen at boot-time. I can't currently
> figure out how to detect what mode the user has the machine
> in; I might set a debconf question in console-data , defaulting
> to "yes", low priority, telling the user do they want
> a non-ASCII font (default latarcyrheb-sun16, for
> complete-ish coverage).
Thanks for this precious advice. I guess this is still a bit early to think
about those problems, but knowing where the problem comes from, and that a
solution exists is a very important information.
Thanks again for your time, Mt.
--
Source is provided to this software because we believe users have the right
to know exactly what a program is going to do before they run it.
Attachment:
pgpXqjFRe_piL.pgp
Description: PGP signature