國語 - RangeError: Invalid language tag: zh_CN

[1u]

We run into a problem when selecting Chinese Languages:

Openki/Openki#667
I couldn't figure where the problem lies. @sbalmer will check on it in two weeks.
@gadicc If you'd directly see what the problem might be, this would save us some work. :)

cheers

(ex. on dev and staging - switch to 國語 (zh_TW) or 中文 (zh_CN) and reload page)

User is greg and its pwd as well. Tanslations under /translate.
Zurich-German (de_ZH) is not a problem

[gadicc]

Hey @1u :)

Did @sbalmer already start on this? I can only see zh_TW on the language list. There also seems to be a weird loop when changing languages (any language). In any event, with zh_TW, I see from your own debugging code:

Date formatting set to zh-tw because zh_TW not available

and on reload:

  RangeError: Invalid language tag: zh_TW
    at new NumberFormat (native)
    at $$compiler$$Compiler.compileMessageText (https://dev.openki.net/packages/msgfmt_core.js?hash=70750e8c258ebdcf91ef38a9eb04d66c9fb7a13c:154:43)

(which is part of packages/msgfmt_core/upstream/intl-messageformat/dist/intl-messageformat-with-locales.js)

It looks like the case isn't the problem but how the language tag is done. I traditionally went with the POSIX / ISO 15897 locale standard which uses an underscore ("_") to separate the region (e.g. zh_TW), but Intl uses BCP 47 language tags, which uses a dash ("-") to separate all kinds of subtags (case insensitive, but uppercase is recommend for the region), e.g. (zh-TW, zh-tw, zh-nan-TW, etc).

I don't recall offhand what steps I took to decode the language, or if we do at all. I think your simplest thing to try first would be to back everything up and rename all region instances to use dashes instead of underscores, and see if that solves the issue. It seems like moment also prefers it that way.

I'm a bit baffled though why de_ZH still works though 🤔 I guess because of Date formatting set to de because de_ZH not available.

[1u]

hey. thanks for the reply. @sbalmer will be back next week. Let's see.. as there is no Chinese/Taiwanese regions it's not urgent.

[sbalmer]

@gadicc thanks for your input! I didn't realize NumberFormat was the complaining party here. I think changing the language ID to use BCP 47 will be the sensible thing to do, thanks for your suggestion.

Presumably, the reason de_ZH does not trigger this error is because it has no translations involving {NUM} where (that's the assumption) NumberFormat will be used.

This issue can be closed. What meteor-messageformat could do here is tracking these errors and giving feed back in the sense of "hey one of your translation strings tries to format a number but your language code is invalid." I think there is a similar problem with malformed translation strings.