Re: LANGUAGE variable set by D-I (was: Re: Bug#356997: apt: internationalization of yes/no answers does not accept displayed answers)
On Fri, Mar 17, 2006 at 09:19:40PM +0100, Denis Barbier wrote:
> On Fri, Mar 17, 2006 at 08:37:19AM +0100, Jens Seidel wrote:
> > There is nothing wrong with fr_FR:fr, right?
> >
> > Also we should consider possible dialects for *one* language such as de_DE,
> > de_AT, de_BE, de_CH, de_LU for German. I remember that there exist some
> > translations only in one dialect, just because the translator is not willing or
> > unfamiliar with de_DE. Nevertheless they are more useful than the C fallback
> > locale.
>
> Your examples does not work, try
> $ LANGUAGE=de_AT:de_BE:de_CH:de_LU:de strace -e open ls --usage 2>&1 > /dev/null |
> grep /usr/share/locale
> open("/usr/share/locale/locale.alias", O_RDONLY) = 3
> open("/usr/share/locale/de_AT/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/de/LC_MESSAGES/libc.mo", O_RDONLY) = 3
> open("/usr/share/locale/de_AT/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale/de/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
> As you can see, message catalogs from de_BE, de_CH and de_LU are never
> looked at.
> This example also shows that setting LANGUAGE=fr_FR:fr does nothing more
> than LANGUAGE=fr_FR.
Right, because there exists only one dialect for French: French as
spoken in France (fr_FR).
But nevertheless LANGUAGE=de_AT:de_BE:de_CH:de_LU:de is exactly what I
want (but I'm not sure about the order, de_DE should of course be the
first entry followed by ????). Your example just demonstrates that libc
tries xx if xx_YY is not found and this is good. If there is no de_AT
file but a general de one it uses this.
But now consider the case that there exists no de file:
# mkdir -p /usr/share/locale/de_LU/LC_MESSAGES/
# mv -i /usr/share/locale/de/LC_MESSAGES/coreutils.mo /usr/share/locale/de_LU/LC_MESSAGES/
$ LANGUAGE=de_AT:de_BE:de_CH:de_LU:de strace -e open ls --usage 2>&1 > /dev/null | grep /usr/share/locale
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/de_AT/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de/LC_MESSAGES/libc.mo", O_RDONLY) = 3
open("/usr/share/locale/de_AT/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de_BE/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de_CH/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de_LU/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
Now de_LU is used which is just a little bit different from de_DE (I
think) but much better than C.
This problem would not occur if German translations are always
installed in de/. But does this happen? It seems that de_DE files are
really installed there and not in de_DE (this doesn't exists on my system).
How about a program which has a de_AT and de_LU translation. Are we sure
that one is installed in de/ (which one?).
Exists a policy about this?
Jens
Reply to: