Gente portuguesa propoñendo un método de internacionalización dos scripts de
inicio de Debian, por si a alguén lle interesa enterarse do asunto para
facelo en galego máis adiante:

[ - -]

---------- Forwarded message ----------
Date: Mon, 12 Jul 1999 18:11:11 -0300
From: Lalo Martins <>
Subject: Translation of init scripts
Resent-Date: 12 Jul 1999 21:17:53 -0000
Resent-cc: recipient list not shown: ;

This weekend I sat over gettext thinking of translated initscript messages.
This is a proposal for some practical solution, so I'm mailing
-devel-announce, but please followup on -devel [and send me CC, since I
-don't plan to subscribe to devel again]. Also, please leave
-user-portuguese out of followups; I'm doing this CC to there because I
promised to :-)

The gettext package comes with a standalone "gettext" util, wich can act as
an "echo" replacement. With this, and a "" file in the
correct locale dir, we can get translated messages. I wonder why we didn't
start this before; with debian-jp etc, and the number of -de|-es|-fr
developers, I think it's an important feature.


There are four layers to the problem.

1: the selection of the language

2: the display of the messages, retaining compatibility with
existing versions

3: the packages and dependencies involved

4: the translations themselves

Layer 1: selecting the language

The language is selected by the LANG, LC_ALL or LC_MESSAGES environment
variable. Most sites set one of these globally in /etc/environment or
/etc/profile, with the option of individual users setting something else in
their shell load scripts (for example on sites that offer telnet/ssh

However, I'm not very sure about sourcing /etc/environment in the init
scripts. It may set some other potentially nasty things. Also, you may want
to keep the system's default language as C (English) but have the boot in
your language, since you're the only one who's going to see it. So I think
perhaps the best solution would be either of:

a: /etc/defaults/language, to be sourced by the "parent" init scripts
   (/etc/init.d/rc, for example - all scripts started by init, not by some
   other scripts)
b: hack init itself to set one of the variables, reading the value from
   inittab or even a boot parameter (/proc/cmdline)

These have the added value that the "init" language isn't necessarily the
same as the "system default" language; so if your site is hosted in Hungary
but has telnet/ssh accounts available, you may set the "init" language to hr
and get "LANG=C; export LANG" in /etc/environment.

Then if you do `/etc/init.d/something reload' the messages will come out in
the "system default" language. Magic :-)

Layer 2: displaying the messages

All "echo" commands in the scripts must somehow call something
internationalized - "gettext -s" or something debian-specific. Se layers 3
and 4 for the pros and cons of each.

The way I did it for my weekend test was editing all scripts which produced
output in /etc/init.d and /etc/rc.boot; before they output anything, add:

if [ -f $SETLANG ]; then
  echo='echo -e'

This isn't the best way IMHO, as I said in layer 1, but it's good enought
for now. Of course I later realized I could source
$SETLANG only in the "parent" scripts.

The script currently just does:

. /etc/default/language
export TEXTDOMAIN=debian-init-scripts
echo="/usr/bin/gettext -s -e"

And then I replaced all "echo" for "$echo". Wow, it works.

The rationale for /etc/init.d/ is that it could come with the
"gettext" package; so, if "gettext" isn't installed, things proceed as

A second approach is to split the standalone "gettext" program into its own
package and promote it to base/required. Then change all "echo" for "gettext
-s" - isn't much more trouble than changing them for "$echo".

A third approach is to come up with a "printf"-like internationalized
program and package it in base/required. The "whys" are in layer 4.

Layer 3: packages and dependencies

This is what I was just talking about; there should be some minimal backward
compatibility. Each of the three approachs above have its own problems and

First approach ($echo) already solves its own problem. If gettext is not
installed, it is not used. This is somewhat similar to the way Debian is
used to doing things, IMHO.

Second and third approachs put the necessary packages in "base" section and
flag them "required" priority. But the priority only works if dpkg knows
about the package! So perhaps, for a while, updated packages should
"pre-depend" on the new package.

And just because I'm sure someone will ask: as long as the program exists,
it will work just fine if it doesn't find translated messages. It just
displays them in English.

Layer 4: translating the messages

This poses a problem. Of course our language teams and even users would
quickly volunteer, but we should do our best to make the job easier - after
all, there must be a LOT of scripts to translate. If people must translate
all of

"Starting foo bar server: foo"
"Stopping foo bar server: foo"
"Starting time waster: twt"
"Stopping time waster: twt"

the work is a lot bigger than if we just ask them to translate

"foo bar server"
"time waster"


Most packages (according to current policy) have something like:
"Starting my_description: my_daemon" (later) "."
"Stopping my_description: my_daemon" (later) "."
"Restarting my_description: my_daemon" (later) "."
"Reloading my_description configuration files" (later) "."

For gettext to have more hints about it, we would have to spell
the first part of these (the period stays as is) like:
"Starting" "my_description:" "my_daemon"
"Stopping" "my_description:" "my_daemon"
"Restarting" "my_description:" "my_daemon"
"Reloading" "my_description" "configuration files"

Old packages have instead:

"Starting my_description... " (later) "done."

It would have to become:

"Starting" "my_description... " (later) "done."

but of course if someone's going to edit the script, it might just as well
be updated to the new policy.

But this imposes major hacks on us, because of two situations:

Situation 1: the colon, ellipsis etc

As you may see in the example above, the translator would need to translate
both "my_description" and "my_description:". This sucks. Not because it's
more work - actually it will be a matter of copy-paste most times - but
because it's a waste of space, and hackers don't like things like this.

The kludge I made looks like:

"Starting" "my_description" "\b: my_daemon"

but then I either have to change "$echo" for "$echo -e" or set it to
`echo="echo -e"' without gettext and `echo="gettext -s -e"' with it. Also,
of course, it's ugly.

Situation 2: the "Reloading configuration files" messages

When you do "/etc/something reload", the new policy says it should print
something like

"Reloading my_description configuration files" (later) "."

which would become

"Reloading" "my_description" "configuration files"

for gettext. The problem is that this fixes a sentence order; in many
languages, there's no way to make this sentence make sense. Portuguese (my
language) is one of them.

In C we would do something like

printf("Reloading %s configuration files", description);

and then the translation could do anything to that, like

msgid "Reloading %s configuration files"
msgstr "Reloading configuration files for %s"

or in Portuguese

msgstr "Recarregando arquivos de configuração de %s"

and this works.


Situation 1 could be solved by an "echo" replacement that didn't insert
spaces between its parameters; so the string would become

"Starting" " " "my_description" ": my_daemon"

but this does nothing for situation 2.

A printf-like echo replacement would work for both, but would be a pain to
implement and yet another thing for maintainers to learn/worry about.

So I don't have an answer :-)

The potfiles

Either way, I suggest that all the messages be kept in a single Debian-wide
potfile, to be named "".

The compiled, translated files ("*.mo") should, IMVHO, go in the
"locales-XX" packages ("locales-de", "locales-es" etc), since they already
exist. This saves space for users - they only get the language(s) they need.

I can send you the .pot file with all the few messages I already have
(collected from my home, 150M-installation Debian scripts). But I'd rather
leave it for later when we come up with a decision.

Oh... and finally, I think each language-team and locales-XX-maintainer
should come to a decision regarding the maintenance of the translations.
Some will want to send diffs to the maintainer, others will prefer CVS,
perhaps even use the lists. Whatever, I don't care.

      I am Lalo of deB-org. You will be freed.
                 Resistance is futile.
                 pgp key in the web page

Debian GNU/Linux       --

Para sair desta lista, manda un mail a
poniendo "unsubscribe" na mesaxe

Responderlle a