When I visit http://www.iro.umontreal.ca/contrib/po/maint/tar/ I do not see a listing for no.po (Norwegian), even though http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?domain=tar says that a 'no' translation is available in http://www.iro.umontreal.ca/contrib/po/teams/PO/no/tar-1.13.19.no.po. This translation, however, is byte-for-byte identical to the nb translation http://www.iro.umontreal.ca/contrib/po/teams/PO/nb/tar-1.13.19.nb.po.
In my private copy of GNU tar I am currently using an automated procedure that grabs all translations from http://www.iro.umontreal.ca/contrib/po/maint/tar/. Hence I'm getting 'nb' but not 'no'. Is this the desired behavior? That is, should I advise Norwegian users to set their locale to 'nb' rather than to 'no'?
lør, 05.07.2003 kl. 22.55 skrev Paul Eggert:
When I visit http://www.iro.umontreal.ca/contrib/po/maint/tar/ I do not see a listing for no.po (Norwegian), even though http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?domain=tar says that a 'no' translation is available in http://www.iro.umontreal.ca/contrib/po/teams/PO/no/tar-1.13.19.no.po. This translation, however, is byte-for-byte identical to the nb translation http://www.iro.umontreal.ca/contrib/po/teams/PO/nb/tar-1.13.19.nb.po.
In my private copy of GNU tar I am currently using an automated procedure that grabs all translations from http://www.iro.umontreal.ca/contrib/po/maint/tar/. Hence I'm getting 'nb' but not 'no'. Is this the desired behavior? That is, should I advise Norwegian users to set their locale to 'nb' rather than to 'no'?
no is deprecated, but it's going to take a coordinated move to get stuff over to nb I think. I've already filed a bug with Red Hat since I do the translations for that distro, but I want to switch GNOME and the Red Hat translations at the same time to make sure everything works when it's done. KDE is already using nb_NO.
I think we should start bugging the distro makers to get the default locale switched over to nb there, and start moving existing translations as soon as possible.
Cheers Kjartan
Kjartan Maraas kmaraas@online.no writes:
lør, 05.07.2003 kl. 22.55 skrev Paul Eggert:
When I visit http://www.iro.umontreal.ca/contrib/po/maint/tar/ I do not see a listing for no.po (Norwegian), even though http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?domain=tar
[...]
In my private copy of GNU tar I am currently using an automated procedure that grabs all translations from http://www.iro.umontreal.ca/contrib/po/maint/tar/. Hence I'm getting 'nb' but not 'no'. Is this the desired behavior?
At UMontreal, we already copied all no files to nb (and no@nynorsk files to nn); perhaps the expire script did not remove the last remaining no file of every text domain.
I think we should start bugging the distro makers to get the default locale switched over to nb there, and start moving existing translations as soon as possible.
I'll file a bug report at http://bugzilla.suse.de; it is password protected, but if one of you in intrested in a account drop me a line.
[Kjartan Maraas]
no is deprecated, but it's going to take a coordinated move to get stuff over to nb I think. I've already filed a bug with Red Hat since I do the translations for that distro, but I want to switch GNOME and the Red Hat translations at the same time to make sure everything works when it's done. KDE is already using nb_NO.
I think we should start bugging the distro makers to get the default locale switched over to nb there, and start moving existing translations as soon as possible.
The first thing to fix is the locale in glibc. When nb_NO is an alias for no_NO as it is now, there is no way to get gettext to use the nb.po files. I've filed a bug, URL:http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=glibc&pr=2981, but is still waiting for a resolution. I've since asked for a new nb_NO locale instead of renaming no_NO, URL:http://sources.redhat.com/ml/libc-alpha/2003-06/msg00133.html. I hope one of these solutions will be accepted by the glibc maintainers soon.
The next thing is to update XFree86 to use the same locale name. Then all the other packages should be fairly easy to fix.