289481 - [website] Add note to release notes that Norwegian language code [no vs. nb] issue is fixed in Tiger

Status: VERIFIED FIXED

(Camino Graveyard :: Product Site, defect)

Description

[Leif Halvard Silli]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: 2005033112 (v0.8.3Int)

Multilingual Camino 0.8.3 comes in both Norwegian (Nynorsk) and Norwegian
(Bokmål). Fine. But the language codes used for the two .lproj folders are
wrong. They _use_  [no] for Bokmål and [nn] for Nynorsk. It should have been
[nb] for Bokmål, and [no] should not have been used. Alternatively they should
use [nn_NO] and [nb_NO]. 

Why? Because [NO] is a reference to _both_ Nynorsk and Bokmål. Thus, when a web
page, or an application comes in two _separate_ Nynorsk and Bokmål version, [no]
should not be used as it can't be used to discern between the two. 

Reproducible: Always

Steps to Reproduce:
1. Install 0.8.3 and choose Show File Info (command + I) to see the languages it
comes with
2. Notice that there is one 'nn' and one 'no' version.
3. Make 'no' the preferred language and launch to check the content
Actual Results:  
Results: it shows that Camino uses  'no' to refer to 'Norwegian(bokmål).

Expected Results:  
The package names should be clear an tell us which language they referred to. I
should not need to a) check whether there also was a [nn] alternative before
beginning to guess what was hidden under [no]. I should not need to launch
Camino to see if [no] referred to Nynorsk or Bokmål. 

Check bug 288776 also. This bug concluded that Camino takes its langugage values
from the International panel of OS X, and that Mozilla won't give Camino an
interface for selecting language preference. That conclusion means that Camino
must begin to implement the things we are waiting on from Apple:

Many has reported to Apple that they must discern between Norwegian Nynorsk and
Norwegian Bokmål. I can only refer to my recent bug report to Apple,  check
[e-mail] referencing Bug ID# 4079316. 

Apple currently offers «Norwegian» as _one_ choice the International control
panel. This means that _really_ they doesn't offer us to prefer the one or the
other language at the moment.

I am informed that the translators of the Norwegian Nynorsk and Bokmål versions
many times requested that [nn_NO] and [nb_NO] be used.

For the sake of Norwegian users, it is better to use [nn_NO] and [nb_NO] than
[nn] and [nb], as the _NO clearly shows that it is the Norwegian vesion. Because
[nb]  is a code that we don't use ourselves, in Norwegian, We hardly use [nn]
either -- these are english shortenings. (I wish one could write this in
Norwegian insted.)

A consequense of fixing this bug will be that, until Apple enables the language
codes nn/nn_NO and nb/nb_NO in OS X, Camino may not open in Norwegian
"clothings" unles the user opens Show File Info and disables all other languages
than his preferred variant of Norwegian. But someone must take the first step.
And using nn_NO and nb_NO _is_ in accordance with Apple's spesifications. See
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Concepts/LanguageDesignations.html>

But then again, either way, this is an Apple bug. And Mozilla should do the
right thing.

Comment 1

[Ludovic Hirlimann [:Usul]]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Where you using Camino when you reported the bug ?

> Multilingual Camino 0.8.3 comes in both Norwegian (Nynorsk) and Norwegian
> (Bokmål). Fine. But the language codes used for the two .lproj folders are
> wrong. They _use_  [no] for Bokmål and [nn] for Nynorsk. It should have been
> [nb] for Bokmål, and [no] should not have been used. Alternatively they should
> use [nn_NO] and [nb_NO]. 

shouldn't it be No_nn and No_nb like we have Fr_fr and Fr_be and fr_ca ?
 

> Check bug 288776 also. This bug concluded that Camino takes its langugage values

This is totally different. This bug covered how web pages should be displayed
and not how application should be displayed.

> Norwegian Bokmål. I can only refer to my recent bug report to Apple,  check
> [e-mail] referencing Bug ID# 4079316. 

I can only see my bugs.

> Apple currently offers «Norwegian» as _one_ choice the International control
> panel. This means that _really_ they doesn't offer us to prefer the one or the
> other language at the moment.

The "Norwegian" Apple is offering is NN I supose ?
 
> For the sake of Norwegian users, it is better to use [nn_NO] and [nb_NO] than
> [nn] and [nb], as the _NO clearly shows that it is the Norwegian vesion. Because
> [nb]  is a code that we don't use ourselves, in Norwegian, We hardly use [nn]
> either -- these are english shortenings. (I wish one could write this in
> Norwegian insted.)
> 
> A consequense of fixing this bug will be that, until Apple enables the language
> codes nn/nn_NO and nb/nb_NO in OS X, Camino may not open in Norwegian
> "clothings" unles the user opens Show File Info and disables all other languages
> than his preferred variant of Norwegian. But someone must take the first step.
> And using nn_NO and nb_NO _is_ in accordance with Apple's spesifications. See
>
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Concepts/LanguageDesignations.html>
> 
> But then again, either way, this is an Apple bug. And Mozilla should do the
> right thing.

Sure What about adding the correct way of enabling your langauge of choice in
the release note ?

Comment 2

[Marcello Testi]

My questions.
Does the actual situation allow to use at least Bokmål "out of the box", by
using the system settings?
Aside from being more formally correct, using nb_NO and nn_NO would
significantly change the way things WORK?

Comment 3

[Leif Halvard Silli]

(In reply to comment #2)
> Does the actual situation allow to use at least Bokmål "out of the box", by
> using the system settings?

When Norwegian is the preferred language in OS X, the application will currently
open with the content of the no.lproj file, whether it contains Norwegian Bokmål
or Norwegian Nynorsk.

Actually, OS X currently system recognizes both 'Norwegian.lproj' and 'no.lproj'
when it comes to "out of the box" functionality. It will prefer 'no.lproj' over
'Norwegian.lproj'.

> Aside from being more formally correct, using nb_NO and nn_NO would
> significantly change the way things WORK?

Yes, it will. But not before Apple fixes their bug. When Apple fixes their bug,
then we that use Mac OS X in Norwegian, will have to choose which language is
their preferred language variant. Then, if I prefer Norwgian Nynorsk, Camino
will also open with the same interface -- as long as the codes are right.

(In reply to comment #1)
> (In reply to comment #0)
> Where you using Camino when you reported the bug ?

I tested with Camino and reported with FIrefox since it contained the bugzilla
password ...

> >   [.. ] they should  use [nn_NO] and [nb_NO]. 
> 
> shouldn't it be No_nn and No_nb like we have Fr_fr and Fr_be and fr_ca ?

I understand why you ask. ;-) To be pedant, your codes are actually fr_FR and
fr_BE.  You use the same language in two different locales. We, on the contrary,
use two different languages (nb and nn) in the same locale (NO). 
 
> > Check bug 288776 also. This bug concluded that Camino takes its langugage values
> 
> This is totally different. This bug covered how web pages should be displayed
> and not how application should be displayed.

You are correct in one sense: if Apple had offered both Norwegian Nynorsk and
Norwegian Bokmål, then it would have been possible to surf the web with a
Norwegian Bokmål localized Camino and yet prefer Norwegian Nynorsk web pages.

However, the Apple bug that governs that Camino can(not) discern between Nynorsk
and Bokmål web pages, also govern that Camino cannot discern between Nynorsk and
Bokmål user interfaces. It is due to the same Apple bug that Camino only knows
about [no] web pages and [no] .lproj folders. 

> > Norwegian Bokmål. I can only refer to my recent bug report to Apple,  check
> > [e-mail] referencing Bug ID# 4079316. 
> 
> I can only see my bugs.

Ok -- I don't know Apple's bug interface very well ... In my bug I ask that when
someone prefers Norwegian Nynorsk in the Internatinal panel, then all resources
(web pages, .lproj files, spelling services etc) that uses the [nn] or [nn_NO]
code be available and preferred. If such resources doesn't exist then I ask that
[no] and [no_NO] be automatically chosen. Likewise for Bokmål users [nb],
[nb_NO] should be preferred with [no] and [no_NO] as secound preferences.

> > Apple currently offers «Norwegian» as _one_ choice the International control
> > panel. This means that _really_ they doesn't offer us to prefer the one or the
> > other language at the moment.
> 
> The "Norwegian" Apple is offering is NN I supose ?

There are only one Mac OS X, where everything is supposed to exist. Apple Norway
may not have recognized that we now have changed to the (more multilingual) Mac
OS X.

<http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Concepts/LanguageDesignations.html>
> > 
> > But then again, either way, this is an Apple bug. And Mozilla should do the
> > right thing.
> 
> Sure What about adding the correct way of enabling your langauge of choice in
> the release note ?

As a temporary solution, right?

Perhaps the most simple temporary solution would to use [no.lproj] for Bokmål
and [Norwegian.lproj] for Nynorsk (se not above). Disabling [no.lproj] will then
make [Norwegian.lproj] the preferred lproj-folder (as long as Norwegian is
selected in the International panel).

A note should be included -- perhaps under the Help menu about the special
Norwegian _temporary_ solution.

A second note could be included about how to add [nn] _and_ [nb] to
AppleLanguages in <~/Library/Preferences/.GlobalPreferences.plist>. Entering 

open ~/Library/Preferences/.GlobalPreferences.plist

in Terminal will open that file in Property List Editor for editing.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

What's the status of this bug?  Has Apple fixed the issue in 10.4?

It sounds to me like the best way to "fix" the two problems (wrong/ambiguous
accept-language and UI language) from Camino's end is to use either nn and nb or
nn_NO and nn_NO for the .lproj and then provide a release note that indicates
the users need to add these to their AppleLanguages section of the
global....plist and then order them in the International prefPane to control
Camino's UI preference and accept-language priority.

This allows Camino to avoid the "ambiguous" no and Norwegian designations yet
still fit in with the standard OS and internet architecture.  Someone could even
write an AppleScript to do the "defaults write AppleLanguages" command so that
users would never have to touch the Terminal or PropertyList Editor at all.

If one set one's International preferences (in order) to nb, nn, no/Norwegian,
Camino would prefer the nb UI and tell webservers one wanted nb first, if
available, then nn, then "generic" Norwegian if neither specific language were
available, and the OS would fall back to displaying generic "Norwegian" because
it doesn't have localizations for nb and nn.  Right?  And all Norwegian Camino
users would rejoice?

Comment 5

[Daniel Aleksandersen]

Apple now corectly indicates Norwegian bokmål as NB in Tiger.


(In reply to comment #4)
> What's the status of this bug?  Has Apple fixed the issue in 10.4?
> 
> It sounds to me like the best way to "fix" the two problems (wrong/ambiguous
> accept-language and UI language) from Camino's end is to use either nn and nb or
> nn_NO and nn_NO for the .lproj and then provide a release note that indicates
> the users need to add these to their AppleLanguages section of the
> global....plist and then order them in the International prefPane to control
> Camino's UI preference and accept-language priority.
> 
> This allows Camino to avoid the "ambiguous" no and Norwegian designations yet
> still fit in with the standard OS and internet architecture.  Someone could even
> write an AppleScript to do the "defaults write AppleLanguages" command so that
> users would never have to touch the Terminal or PropertyList Editor at all.
> 
> If one set one's International preferences (in order) to nb, nn, no/Norwegian,
> Camino would prefer the nb UI and tell webservers one wanted nb first, if
> available, then nn, then "generic" Norwegian if neither specific language were
> available, and the OS would fall back to displaying generic "Norwegian" because
> it doesn't have localizations for nb and nn.  Right?  And all Norwegian Camino
> users would rejoice?

Comment 6

[Ludovic Hirlimann [:Usul]]

a Note in some release note should be enough for nearlier systems.

Comment 7

[Samuel Sidler (old account; do not CC)]

Confirming as a website/release not bug.

CCing Mike so he knows this needs to be in our release notes.

Comment 8

[Samuel Sidler (old account; do not CC)]

What exactly do you want the release note to say? I'm not completely sure. Can
someone iron out the wording?

Comment 9

[Daniel Aleksandersen]

Norwegian = NO
Norwegian Bokmål = NB
Norwegian Nynorsk = NN

Most Norwegians speak NB, and some NN. NO means both NB and NN.

Comment 10

[Samuel Sidler (old account; do not CC)]

(In reply to comment #9)
> Norwegian = NO
> Norwegian Bokm�l = NB
> Norwegian Nynorsk = NN
> 
> Most Norwegians speak NB, and some NN. NO means both NB and NN.

Yes, I knew that. I'm saying, what should our release notes say to let people
know this is fixed in 10.4?

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The release note is really directed at 10.2.x and 10.3.x users, as things will
work correctly out-of-the-box on 10.4.x (or so I understand from the comments in
this bug).

"Due to a bug in Mac OS X 10.2.x and 10.3.x, Norwegian users of the Camino
MultiLang edition will need to manually select their desired user interface
language and manually set their 'accept-language' string.  To make Camino
MultiLang run in Nynorsk or Bokmål, select Camino MultiLang in the Finder and
choose "Get Info" from the File menu.  In the resulting window, click the
triangle next to "Languages:" and uncheck every language except the one desired
as Camino's UI language.

To set the accept-language string, add the string
user_pref("camino.accept_languages", "nb,nn,no,en"); to your user.js file [here
link to the Hidden Prefs page of the website, which explains the whole user.js
thing, where to find it, etc.], where the languages are listed in the order in
which you'd prefer them if a server can send content in multiple languages.  (In
this example, you want Bokmål first, then Nynorsk, then generic Norwegian, then
English if none of the other three languages are available.)  You may now launch
Camino.  

Apple fixed this bug in Mac OS X 10.4, so no work-arounds are necessary."

Something like that?

Calling it accept-lang is too technical, but I don't know a layman's term that
won't take a paragraph.  The accept-lang instructions paragraph definitely needs
some cleaning up of its English, too....  It's a first stab, at least.

Comment 12

[Samuel Sidler (old account; do not CC)]

(In reply to comment #11)
> To set the accept-language string, add the string
> user_pref("camino.accept_languages", "nb,nn,no,en"); to your user.js file [here
> link to the Hidden Prefs page of the website, which explains the whole user.js
> thing, where to find it, etc.], where the languages are listed in the order in
> which you'd prefer them if a server can send content in multiple languages.

Would it be easier/better to have them edit this in about:config now that it
works? Does it work to change the entry in about:config while Camino is running
after having changed Languages in the info panel prior to Camino running?

Also, we have to call it "accept-language" I think. It's a shame, but there's
not much we can do about it.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #12)
> Would it be easier/better to have them edit this in about:config now that it
> works? 

Perhaps, if one were able to do that.  camino.accept_languages is a pref that
doesn't exist by default (basically, it overrides the automatic accept-lang
detection), and that part of about:config is still broken in Camino (bug 306613).

Also, we might want add a line to the last pgh saying "If you upgrade to 10.4,
you can remove the user_pref("camino.accept.... line from your user.js and prefs.js"

I also noticed that this is a rather long release note in comparison to the
rest.  Perhaps we should just include the first sentence of the first paragraph
in the release notes themselves and then add a link to somewhere on cb.o where
the entire work-around process is described?

Comment 14

[Samuel Sidler (old account; do not CC)]

Smokey, should this be added to the relnotes for Camino 1.0 *after* the multi-lingual version is out? And, if it applies to 084, should I be adding it to those relnotes as well?

I'll get this for 1.0.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The first part (UI lang) only applies to MultiLang, but the second part (accept-lang) applies to any Norwegian users running 10.2 or 10.3 and the UniLang version.  For that reason, and for general housekeeping, I'd include it in the release notes for 1.0 from the get-go.

Both parts apply to 0.8.4 as well.