Bug 83276 - Norwegian locale in the distro
Norwegian locale in the distro
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-01 06:31 EST by Kjartan Maraas
Modified: 2016-11-24 11:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-05 13:25:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kjartan Maraas 2003-02-01 06:31:16 EST
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 09:57:22 EST
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-03 21:43:14 EST
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 11:34:24 EST
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 11:38:03 EST
So, why is the norwegian localization moving to something that is just an alias?
Comment 5 Kjartan Maraas 2003-02-04 13:56:20 EST
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 18:04:18 EDT
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 08:53:24 EDT
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 07:35:40 EDT
Making this visible for others.
Comment 9 Kjartan Maraas 2003-08-20 07:39:27 EDT
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 08:26:23 EDT
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 07:17:49 EDT
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 14:55:33 EDT
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 19:32:16 EDT
Why not use ISO-8859-15 to get the € euro symbol as well?
Comment 14 Petter Reinholdtsen 2003-09-01 19:18:04 EDT
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 19:21:00 EDT
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 02:51:01 EDT
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 04:29:51 EDT
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 14:12:01 EDT
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 13:10:49 EDT
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 10:03:26 EDT
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 17:09:35 EDT
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 03:20:14 EST
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 11:30:25 EST
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 13:25:48 EST
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 11:31:12 EST
Is there a point in filing a request to keep the no_NO locale as a
full locale to get a transition period?

Note You need to log in before you can comment on or make changes to this bug.