2 replies to this topic

[foxmarks]

We found an interesting issue today that may be more process than a bug but not sure how it happened. For quite a while we had a localized version, de-DE, which we've been using for quite a while. Recently, when downloading the latest strings, we've been getting a de translation set as well as a de-DE, which with our scripting, has been ignored. Unfortunately, the "de" version is the one that is actively being translated, so new strings haven't been coming though. After looking out our translation list in WTS, sure enough there is a "de" but not a "de-DE".

Did this somehow get re-assigned automatically or how did this come about?

Cheers,

Will
Xmarks

[Goofy]

We found an interesting issue today that may be more process than a bug but not sure how it happened. For quite a while we had a localized version, de-DE, which we've been using for quite a while. Recently, when downloading the latest strings, we've been getting a de translation set as well as a de-DE, which with our scripting, has been ignored. Unfortunately, the "de" version is the one that is actively being translated, so new strings haven't been coming though. After looking out our translation list in WTS, sure enough there is a "de" but not a "de-DE".

Did this somehow get re-assigned automatically or how did this come about?

Cheers,

Will
Xmarks

yes it is a deliberate process we are slowly indulging in since some months, we wish to stick more closely to Mozilla "officially supported" langcodes as can be seen here http://l10n.mozilla.org/webdashboard/
It is pretty long to migrate everything so here are the 2-letter languages on the WTS currently

de
fr
nl
pl

(probably more to come)
Of course developers should modify their chrome.manifest declarations accordingly.

Soory for the annoyance.

[foxmarks]

Ahh, that makes sense.

Cheers,

Will
Xmarks