ubuntu-translations-coordinators team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

Public bug reported:

Currently the code to detect the user's language preference to load the
translations for webapps is the following (in common/utils.js):

    var lang = unsafeWindow.navigator.language; //TODO: came up with a
better approach

    if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
        return dict[lang][strid];
    } else {
        return strid;
    }

'dict' is a variable containing a JSON string that is populated at build
time with the contents of the translations in .po files in the source
tree. It includes the locale code as read from the .po (or LINGUAS)
files, which is a gettext-style locale code.

The problem is that the 'lang' variable as returned from the browser in
some cases won't match the user's locale. This is mainly due to the fact
that Firefox uses IETF-style language codes, whereas the system uses
gettext-style language codes. That means for some languages there won't
be a match, and thus translations won't be loaded. Here's an example for
Simplified Chinese:

- Gettext locale code: zh_CN
- Firefox locale code: zh-cn

So there must be a translation gettext -> Firefox (and Chromium, if it
returns locales in a different format) at build time, so that locale
names from the system and from the browser can match and translations
can be loaded.

Also notice that in some cases either the country code in the locale
code might be present in the system locale but not in the browser, and
viceversa, so it might be an idea to ignore the country code apart from
some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a few)

** Affects: ubuntu-translations
     Importance: High
         Status: Triaged

** Affects: webapps-applications
     Importance: Undecided
         Status: New

** Affects: webapps-applications (Ubuntu)
     Importance: Undecided
         Status: New

** Visibility changed to: Public

** Also affects: ubuntu-translations
   Importance: Undecided
       Status: New

** Also affects: webapps-applications (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: ubuntu-translations
       Status: New => Triaged

** Changed in: ubuntu-translations
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Translations Coordinators, which is subscribed to Ubuntu Translations.
Matching subscriptions: Ubuntu Translations bug mail
https://bugs.launchpad.net/bugs/1065422

Title:
  Language detection code will not work for all languages

Status in Ubuntu Translations:
  Triaged
Status in WebApps: Initial set of Apps:
  New
Status in “webapps-applications” package in Ubuntu:
  New

Bug description:
  Currently the code to detect the user's language preference to load
  the translations for webapps is the following (in common/utils.js):

      var lang = unsafeWindow.navigator.language; //TODO: came up with a
  better approach

      if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
          return dict[lang][strid];
      } else {
          return strid;
      }

  'dict' is a variable containing a JSON string that is populated at
  build time with the contents of the translations in .po files in the
  source tree. It includes the locale code as read from the .po (or
  LINGUAS) files, which is a gettext-style locale code.

  The problem is that the 'lang' variable as returned from the browser
  in some cases won't match the user's locale. This is mainly due to the
  fact that Firefox uses IETF-style language codes, whereas the system
  uses gettext-style language codes. That means for some languages there
  won't be a match, and thus translations won't be loaded. Here's an
  example for Simplified Chinese:

  - Gettext locale code: zh_CN
  - Firefox locale code: zh-cn

  So there must be a translation gettext -> Firefox (and Chromium, if it
  returns locales in a different format) at build time, so that locale
  names from the system and from the browser can match and translations
  can be loaded.

  Also notice that in some cases either the country code in the locale
  code might be present in the system locale but not in the browser, and
  viceversa, so it might be an idea to ignore the country code apart
  from some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a
  few)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-translations/+bug/1065422/+subscriptions