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:
-- [http://ceu.fi.udc.es/gpul - f...@debian.org - http://humbolt.geo.uu.nl/eulug] ---------- Forwarded message ---------- List-Post: proxecto@trasno.net Date: Mon, 12 Jul 1999 18:11:11 -0300 From: Lalo Martins <l...@webcom.com> Reply-To: debian-de...@lists.debian.org, l...@webcom.com To: debian-devel-annou...@lists.debian.org Cc: debian-user-portugu...@lists.debian.org Subject: Translation of init scripts Resent-Date: 12 Jul 1999 21:17:53 -0000 Resent-From: debian-devel-annou...@lists.debian.org Resent-cc: recipient list not shown: ; Followup-To: debian-de...@lists.debian.org, l...@webcom.com 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 "debian-init-script.mo" 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. HOW ******* 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 accounts). 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: SETLANG=/etc/init.d/setlang.sh if [ -f $SETLANG ]; then . $SETLANG else echo='echo -e' fi 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 setlang.sh 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/setlang.sh is that it could come with the "gettext" package; so, if "gettext" isn't installed, things proceed as usual. 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 sollutions. 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 "Starting" "Stopping" "foo bar server" "time waster" right? 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. Sollutions ---------- 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 "debian-init-scripts.mo". 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. []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:l...@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org -- Para sair desta lista, manda un mail a gpul-traduccion-requ...@ceu.fi.udc.es poniendo "unsubscribe" na mesaxe
