Bug 83276

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?

Probably, yes.

Jakub, is glibc changing locale to use nb for norwegian?

(Currently, glibc does not ship a nb locale).

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.

So, why is the norwegian localization moving to something that is just an alias?

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

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?

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.

Making this visible for others.

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.

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.

Is this going to happen for the next release, or do we have to wait for the next
one?

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.

Why not use ISO-8859-15 to get the ⬠euro symbol as well?

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.

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.

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?

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.

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.

Is there any chance of getting a comment from anyone here? We need to get this
fixed soon...

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".

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.

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.

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.

None of this effect any existing release.  The locale will appear in
FC2.  So I'm closing the bug with UPSTREAM.

Is there a point in filing a request to keep the no_NO locale as a
full locale to get a transition period?