Code

Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#11068 closed (fixed)

Wrong language code for Norwegian (Bokmål)

Reported by: nfg Owned by: jezdez
Component: Internationalization Version: master
Severity: Keywords: language_code norwegian
Cc: jon@… Triage Stage: Fixed on a branch
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

According to the The GNU gettext manual the language code for Norwegian bokmål have changed from 'no' to 'nb'. In Django the language code used is 'no'. This should be renamed to 'nb', if there is not a very good reason not to.

As a intermediate measure it is perhaps a good idea to set LANGUAGE_CODE = 'nb:no' in settings.py if you use Norwegian, then both language codes would be searched for translations. Perhaps this should be mentioned in the Internationalization documentation somewhere? Perhaps a section about language codes? I can make a documentation patch for it.

Attachments (0)

Change History (11)

comment:1 Changed 5 years ago by nfg

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Version changed from 1.0 to SVN

comment:2 Changed 5 years ago by garcia_marc

  • Cc jon@… added
  • Owner changed from nobody to garcia_marc

I don't know much about Norwegian languages, but it looks like Norwegian (no) and Norwegian-Bokmal (nb) are different languages. So now, translations in django/conf/locale/no/LC_MESSAGES are for Norwegian-Bokmal, that is incorrect, right?

So the solution would be just renaming the directory from no to nb, so you'll have translations to Norwegian-Bokmal but not Norwegian. Is it ok?

I'm CC the last translator to Norwegian, to validate that there is a mistake on it.

comment:3 Changed 5 years ago by jonklo

The reporter is correct. Norwegian (no) is commonly used when describing Norwegian-Bokmal (nb), as it is the main language used in Norway. The translation that is currently residing in Django is a Norwegian-Bokmal (nb) translation. The right thing to do would be to rename the current translation to nb.

comment:4 Changed 5 years ago by garcia_marc

  • Resolution set to fixed
  • Status changed from new to closed

(In [11402]) [soc2009/i18n] Fixed #11068. Norwegian Bokmal code fixed

comment:5 Changed 5 years ago by garcia_marc

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Fixed on a branch

comment:6 Changed 4 years ago by jezdez

  • Owner changed from garcia_marc to jezdez
  • Status changed from reopened to new

comment:7 Changed 4 years ago by jezdez

  • Status changed from new to assigned

So what would be a sane way to handle this and maintain backwards compatibility?

comment:8 Changed 4 years ago by garcia_marc

Probably, if we copy the translation to 'nb', without removing the one in 'no'.

That way, it would work ok when the language is set correctly, but it will go on working for projects that already has set the 'no' language.

Does it sound ok, or am I missing something?

comment:9 Changed 4 years ago by russellm

  • milestone set to 1.2

If the language code has changed, we should update our code. After discussing with jezdez on IRC, we will

  • copy no->nb
  • put a note in the no translation file that nb should be updated, not no
  • Modify django.utils.translation to raise a warning if the no translation is requested
  • Update the deprecation notes and release notes to indicate the change.

comment:10 Changed 4 years ago by jezdez

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [13047]) Fixed #11068 - Introduced new language code "nb" for Norwegian Bokmål as a replacement of the current "no".

comment:11 Changed 3 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.