|Summary:||Norwegian locale in the distro|
|Product:||[Retired] Red Hat Linux||Reporter:||Kjartan Maraas <kmaraas>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED UPSTREAM||QA Contact:||Brian Brock <bbrock>|
|Version:||9||CC:||fweimer, jakub, notting, pcormier, pere|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-11-05 18:25:48 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Kjartan Maraas 2003-02-01 11:31:16 UTC
Description of problem: Not sure this is the right place for this, but I can't think of any other place to put it. The norwegian localisation is transitioning to use of nb_NO from no_NO and for a period of time both need to be supported on equal basis. As it is now all the KDE translations use nb_NO and the GNOME ones and a lot of others use no_NO. Would it be possible to have apps look in nb if they don't find localisations in the no dir? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Kjartan Maraas 2003-02-02 14:57:22 UTC
I tested some more today and wanted to see if using the LANGUAGE environment variable would help here. You can set multiple languages like this: LANGUAGE=sv:da:no and that makes gettext look for message catalogs in all three of these languages' directories in that order. The problem here is that KDE doesn't seem to respect LANGUAGE at all for some weird reason, and AbiWord doesn't use gettext so that won't be "fixed" by this trick either. Should I file a bug against KDE somewhere for not respecting LANGUAGE?
Comment 2 Bill Nottingham 2003-02-04 02:43:14 UTC
Probably, yes. Jakub, is glibc changing locale to use nb for norwegian? (Currently, glibc does not ship a nb locale).
Comment 3 Jakub Jelinek 2003-02-04 16:34:24 UTC
But nb_NO and nb_NO.ISO-8859-1 are aliases for no_NO. I can add nb_NO.UTF-8 -> no_NO.UTF-8 alias if needed.
Comment 4 Bill Nottingham 2003-02-04 16:38:03 UTC
So, why is the norwegian localization moving to something that is just an alias?
Comment 5 Kjartan Maraas 2003-02-04 18:56:20 UTC
Previously we had: no@nynorsk -> Norwegian (nynorsk dialect) no_NO -> Norwegian (bokmÃ¥l dialect) This has moved to: nn_NO -> nynorsk nb_NO -> bokmÃ¥l In the later ISO standards. Eventually the no@nynorsk and no_NO stuff should just be removed. But checking that all legacy apps support the new stuff etc will take some time I guess. Will the alias from nb_NO-UTF.8 -> no_NO-UTF.8 take care of AbiWord and KDE? If that's the case I'm all for it. Then I'll personally start moving GNOME and RH translations to using nb.po for the bokmÃ¥l translation after the release. Cheers Kjartan
Comment 6 Kjartan Maraas 2003-05-13 22:04:18 UTC
How would I go about renaming all the files in CVS? Apply for a new team handling nb and just commit the same files with nb.po as the name? Or better, get someone to run a script that renames everything and changes ALL_LINGUAS in configure.in?
Comment 7 Kjartan Maraas 2003-06-06 12:53:24 UTC
Anyone know how this could best be handled? Should no_NO be renamed to nb_NO or should one run with both for a while to see if anything breaks when removing no_NO? I need help from someone to rename the files in CVS though. It would be nice to get consistency between KDE and GNOME but I'm not sure how many other apps use no_NO still. I see kdbg.mo in no_NY. That should really be fixed since no_NY is an invalid locale name. I've taken a look in /usr/share/locale/no/LC_MESSAGES and it seems most apps other than KDE still use no instead of nb. I think moving GNOME stuff and RH specific apps to nb_NO and then seeing what's still left is the way to go.
Comment 8 Kjartan Maraas 2003-08-20 11:35:40 UTC
Making this visible for others.
Comment 9 Kjartan Maraas 2003-08-20 11:39:27 UTC
Please look at this reference for glibc: libc/2981 This is a request to change to having nb_NO and nn_NO as the norwegian locales. The no_NO one is to be phased out as soon as we can manage to rename all the translations in the apps.
Comment 10 Petter Reinholdtsen 2003-08-20 12:26:23 UTC
A patch to add nb_NO as a real locale, and removing the alias is available from <URL: http://sources.redhat.com/ml/libc-alpha/2003-06/msg00133.html >. I believe this is the best solution, to make it easier to convert programs already using no_NO for bokmÃ¥l translations.
Comment 11 Kjartan Maraas 2003-08-31 11:17:49 UTC
Is this going to happen for the next release, or do we have to wait for the next one?
Comment 12 Petter Reinholdtsen 2003-08-31 18:55:33 UTC
Adding an alias nb_NO.UTF-8 -> no_NO.UTF-8 will not solve the problem at hand, which is that gettext do not accept translation files correctly named nb.po, and the fact that different program use different language codes for Norwegian BokmÃ¥l. The solution to both these problem is to remove the alias nb_NO, and create the nb_NO locale as a real locale (Using ISO-8859-1 like the current no_NO), and modify all programs to use the same language code in accordance with RFC 3066 and ISO 15897, which is nb. The locale would then be nb_NO, not no_NO.
Comment 13 Kjartan Maraas 2003-08-31 23:32:16 UTC
Why not use ISO-8859-15 to get the â¬ euro symbol as well?
Comment 14 Petter Reinholdtsen 2003-09-01 23:18:04 UTC
The commonly used charset in Norway is at the moment is ISO-8859-1, as far as I know. I see the argument of making sure the new locale handle the currency symbol of the neigbouring countries. For this reason, it might be a good idea to use ISO-8859-15 instead. I have no strong opinion on which of these are the best. I do have strong objections regarding UTF-8, because it give lots of problems when communicating with other systems. Most of these are not prepared to handle UTF-8 yet.
Comment 15 Petter Reinholdtsen 2003-09-01 23:21:00 UTC
A good argument for using ISO-8859-1 as the charcet of the new locale, is to make sure that the new locale is compatible with the old alias, to avoid surprising the users.
Comment 16 Kjartan Maraas 2003-09-02 06:51:01 UTC
Petter, I think it's bad if the default character encoding for *one* language in the distro is different than the others. If there are problems communicating with other systems that can't be configured around please file bugs against Red Hat Linux to get them fixed. The switch to UTF-8 was done to "force" the issue if I remember correctly and I think it's way too late to reverse that decision. But getting the new locale in place so we can start moving the existing translations would be a nice thing indeed. Jakub?
Comment 17 Petter Reinholdtsen 2003-09-02 08:29:51 UTC
OK. There are two issues here. One is the charset to be used in the upstream glibc source. I believe it should use ISO-8859-1. Another is the charset used in RedHat. Perhaps it should be UTF-8. RedHat seem willing to take the pain with getting UTF-8 to work, and I have no problem with that, as long as I can switch back to ISO-8859-1 on my machines. The problem I've seen with UTF-8 is ssh from RedHat 9 to for example Solaris, where the norwegian characters are garbled because Solaris is expecting ISO-8859-1, while the terminal on RedHat is generating UTF-8. These are unsolvable as long as the protocol do not specify character set info. My solution is to switch RedHat to use the same charset as the rest of the installations.
Comment 18 Kjartan Maraas 2003-09-02 18:12:01 UTC
I agree. I was thinking of the Red Hat side of things here. Though, it's not necessary to switch the encoding for the distro to get around the problem for ssh AFAIK. Just run ssh with LC_ALL=no_NO? I'm sure this has been discussed during the first development cycle using UTF-8.
Comment 19 Kjartan Maraas 2003-09-22 17:10:49 UTC
Is there any chance of getting a comment from anyone here? We need to get this fixed soon...
Comment 20 Owen Taylor 2003-10-03 14:03:26 UTC
The default charset really doesn't matter at the Red Hat level. If it's something other than UTF-8, we'll use 'nb_NO.UTF-8".
Comment 21 Kjartan Maraas 2003-10-18 21:09:35 UTC
Is there really no chance of getting this in before the localisation freeze? It would be very nice to be able to start moving translations over to the right locale during the next cycle.
Comment 22 Petter Reinholdtsen 2003-10-31 08:20:14 UTC
The nb_NO locale is now available in Debian/unstable, and will end up in the next stable release. I hope RedHat can add it as well.
Comment 23 Kjartan Maraas 2003-11-04 16:30:25 UTC
So, it looks like the locale was added to glibc which is very nice. Since it was added as a new locale and the old (no_NO) was deprecated and made an alias of the new one (nb_NO) we won't have a transition period where both work, since gettext doesn't handle locales that are aliases IIRC. Consider this a request to keep the no_NO locale around for a period of time until we have moved the translations over to nb_NO. This could take some time since it affects most the software in the distro.
Comment 24 Ulrich Drepper 2003-11-05 18:25:48 UTC
None of this effect any existing release. The locale will appear in FC2. So I'm closing the bug with UPSTREAM.
Comment 25 Kjartan Maraas 2003-11-06 16:31:12 UTC
Is there a point in filing a request to keep the no_NO locale as a full locale to get a transition period?