translation files are renamed for a few languages

[Olivier Tilloy]

There’s code in nav/index.html that does a curious mapping of certain language names¹:

  ast-ES → a1
  en-GB → e1
  en-AU → e2
  zh-CN → z1
  zh-TW → z2

For all other languages, it uses navigator.language.substring(0, 2).

This looks ugly, error-prone and not future-proof. And it obfuscates the translation process for contributors.

Let’s see if this can be reworked to not require this curious mapping, and use proper language codes for all supported languages.

¹ https://bazaar.launchpad.net/~unav-devs/unav/trunk/view/head:/nav/index.html#L155

[costales (costales)]

I think to remember, the library for translating the HTML:
https://github.com/coderifous/jquery-localize

only accepted 2 characters. I found my issue:
https://github.com/coderifous/jquery-localize/issues/50

Because of that, I fixed changing the codes. Yes, I'm agree it is a bad fix, but I didn't find a better :)

[costales (costales)]

Reviewing the issue...

Forzing the locale to zh_CN or zh-CN:

locale = zh-CN and nav/locales/po/messages-zh-CN.json works.
locale = zh_CN and nav/locales/po/messages-zh_CN.json doesn't work.
locale = es-AST and nav/locales/po/messages-es-AST.json doesn't work.

Then, the po files should have the "-" and the Asturian can't work either.

[Olivier Tilloy (osomon)]

I’ve had a look at the code for jquery-localize¹ and I can confirm that it doesn’t handle language codes with more than two letters (i.e. it assumes ISO 639-1 codes).
However navigator.language may return 3-letter codes².
In its current implementation, jquery-localize would trim "ast" to "as", thus loading translations for Assamese instead of Asturian.
What we really need to do here is fix jquery-localize instead of working around the issue.

The issue with Chinese is different³: jquery-localize tries to load a generic language file (zh.json) first, and if it fails to do so it won’t load the culture-specific one (zh-CN.json). Again this should be fixed in jquery-localize.

Finally, it appears jquery-localize doesn’t handle language variant codes at all (e.g. ca-ES-valencia), even though we might have specific translations for those (launchpad would export <email address hidden>).

¹ https://github.com/coderifous/jquery-localize/blob/master/dist/jquery.localize.js
² https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage/language
³ https://github.com/coderifous/jquery-localize/issues/47

[Olivier Tilloy (osomon)]

I filed https://github.com/coderifous/jquery-localize/issues/86 to track the lack of support for language variant codes in jquery-localize.

[costales (costales)]

So good research Olivier :)) Great work!!

I would avoid to fix jquery-localize, if we try to fix any library it will
crazy (openmarkers has a few issues with uNav too).

It's not a big deal for me to rename ES_ast as a1 in each release
(Valencian is not in the phone yet, but I could parse it too), and
everything works. And when that bug will be fixed in jquery-localize,
update the library :)

What do you think?
A hug.

--
--
Sent using Dekko from my Ubuntu device

[Olivier Tilloy (osomon)]

Well I suggest we try to fix those issue upstream. But the project hasn’t seen *any* activity in almost a year, that’s not a very good sign. In any case if we are to fix the version that’s embedded in unav, we should definitely forward our patches upstream.

[Olivier Tilloy (osomon)]

I’ve submitted a fix for https://github.com/coderifous/jquery-localize/issues/50 upstream: https://github.com/coderifous/jquery-localize/pull/87.

Let’s see if the upstream author is interested in it.

[Olivier Tilloy (osomon)]

Two of the three issues in jquery-localize have been fixed upstream:
  https://github.com/coderifous/jquery-localize/issues/50
  https://github.com/coderifous/jquery-localize/issues/47

The last remaining issue is:
  https://github.com/coderifous/jquery-localize/issues/86