About locale 'zh-Hant-TW' about formatjs HOT 32 CLOSED

zh and zh-TW map to different scripts. Similarly, you may find issues with the following.

• az maps to Latn script, but az-IR maps to Arab script and az-RU maps to Cyrl script.
• ha maps to Latn script, but ha-CM or ha-SD maps to Arab script.
• kk maps to Cyrl script, but kk-AF, and kk-CN, and kk-IR, and kk-MN map to Arab script.
• mn maps to Cyrl script, but mn-CN maps to Mong script.
• pa maps to Guru script, but pa-PK maps to Arab script.
• sr maps to Cyrl script, but sr-ME, and sr-RO, and sr-RU, and sr-TR map to Latn script.
• ug maps to Arab script, but ug-KZ and ug-MN map to Cyrl script.
• zh maps to Hans script (as pointed out), but zh-AU, and zh-BN, and zh-GB, and zh-GF, and zh-HK, and zh-ID, and zh-MO, and zh-MY, and zh-PA, and zh-PF, and zh-PH, and zh-SR, and zh-TH, and zh-TW (as pointed out), and zh-US, and zh-VN map to Hant script.

PS: I'm ignoring languages that you don't distribute.

from formatjs.

@ericf @tom76kimo Looks like zh-Hant-TW is still missing. Looks like that was the original question is about. I am currently blocked by this. Any plans to add Taiwanese?

from formatjs.

When you use the root locale zh is the output not what you're expecting? Our locale data extraction process only creates locale data for the root language to de-duplicate the data.

If you're programmatically adding one of React Intl's locale data packs to the page we use this approach:

var localeDataFile = 'react-intl/dist/locales/' + locale.split('-')[0] + '.js';

Where "zh-Hant-TW" would result to:

"react-intl/dist/locales/zh.js

Let us know if the output you get when using zh for zh-Hant-TW is not what you expect.

from formatjs.

zh maps to simplified Chinese and zh-Hant-TW maps to traditional Chinese.
I expected the traditional one and got simplified instead. 😢

from formatjs.

So as an example, in English "3 minutes ago", you'd expect this?

• zh: "3分钟前"
• zh-Hant: "3 分鐘前"

Note: The CLDR data has a space between after the number in the zh-Hant version.

from formatjs.

Yes, I expect the "3 分鐘前" zh-hant one.
The space is OK, the point is that I need the 鐘 not 钟.

from formatjs.

Okay, good to know. We have access to this data so we'll discuss how to handle this since it likely will apply to other languages as well. We were hoping the root locale would be good enough, so it's good for us to know that it's not in this important case for very popular languages.

from formatjs.

Thanks for your quick response. I am appreciated.

from formatjs.

Dear Ericf

We are working on Yahoo Frontpage for TW/HK mobile. Could you give a favor to put a high priority to support zh-Hant-TWand zh-Hant-HK ? The external bucket date is by the end of March.

Thanks.

Young

from formatjs.

@imyoungyang yeah, the fastest thing I can do is generate the data files for you guys to use and include in your app's source code. Once we figure a solution for Chinese and any other locales that whose root language rules for relative time formatting differ from its other variations we'll update the package to include that data.

I'll provide these data files sometime tomorrow, EST timezone.

from formatjs.

@ericf I think we may need to change this line also https://github.com/yahoo/intl-relativeformat/blob/master/src/core.js#L69

I verified this on ember-intl when I IntlRelativeTime.__addLocaleData for both zh and zh-hant-tw. It always used the zh relativeTime.

from formatjs.

@jasonmit yeah, good call, there are a few things that will need to be adjusted to in IRF to support this.

from formatjs.

WoW!! big thinks to ericf@ and jasonmit@.

Once you have done this feature, please send us related info and source[1]. If you need any zh-Hant-TW improvement, we are willing to help.

thanks for your quickly response.

[1] yahoo email:
[email protected]
[email protected]

from formatjs.

yeah, I knew this was going to be problematic since we are forcing to use the root locale across the board to minimize the amount of data we load. The real questions here is: do we want to continue producing the "*-with-locales.js" file? Maybe we should keep producing that one with all root locales (which covers probably 99% of the cases, even if it is not 100% accurate, people in all those regions will understand it), and then produce all individual files from CLDR in such a way that they can use explicit locales, or rely on the fallback mechanism. Essentially, provide a path for them to use the exact rules for a particular locale, or rely on the fallback mechanism to use the root locale per region.

from formatjs.

The real questions here is: do we want to continue producing the "*-with-locales.js" file? Maybe we should keep producing that one with all root locales (which covers probably 99% of the cases, even if it is not 100% accurate, people in all those regions will understand it)

I feel that we need to produce it at least through v1.x, and we can revisit its removal in v2. As for covering 99%, that's more nuanced, because the popularity of a language (especially Chinese) needs to factor in.

@tom76kimo @imyoungyang could you guys elaborate on the significance of simplified vs. traditional Chinese? I'm curious how people would feel when they see simplified Chinese and why you guys want the output in traditional Chinese — I'm ignorant on this issue.

The pluralization rules in CLDR are only for the root locales. What we should do is gather more data by [programmatically] surveying all of the locale variations to check whether the fields data for relative time matches the the root locale's values. Doing this check will expose differences like zh vs. zh-Hant and possibly more. Armed this with data we should be able to make a better decision as to how to layout the data files at the Intl RelativeFormat and integration lib levels.

from formatjs.

We've discussed this issue further and realized that we need to make code changes to the intl-relativeformat package for this to work. We've opened formatjs/intl-relativeformat#25 and the set of tasks is listed here: formatjs/intl-relativeformat#25 (comment)

Once we resolve these lower-level issues, this package should Just Work™

from formatjs.

The pluralization rules in CLDR are only for the root locales.

For most, but not for all. For example, Brazilian Portuguese (pt) has different plural rules from Portuguese from Portugal (pt-PT).

from formatjs.

One thing is clear now, we need to provide locale data for every locale that has custom rules, and we can continue providing the bundle with root locales for now (e.g.: react-intl-with-locales.min.js) and eventually deprecate it in the next big revision.

from formatjs.

@ericf Simplified Chinese literally means it is a been-simplified language, Taiwan and Hong Kong don't use it.

from formatjs.

@rxaviers, initial experimentation shows that there are only few offender locales that are different from their respective root locale (based on our current cldr provider package):

bs-cyrl
en-au
en-hk
es-419
es-mx
fr-ca
ne-in
pa-arab
shi-latn
sr-latn
sv-fi
uz-cyrl
yo-bj
zh-hans-hk
zh-hans-mo
zh-hans-sg
zh-hant
zh-hant-hk

the rest the locales can be folded into one of its parent locales.

from formatjs.

I've created formatjs-extract-cldr-data which extracts and de-dups data from the CLDR in a way that correctly respects the locale hierarchy. I am not working on updating FormatJS' lower-level intl-* packages to use the updated data, and then React Intl will get those updates as well.

from formatjs.

Thanks @ericf for the updates!!

from formatjs.

This is fixed in PR formatjs/intl-relativeformat#28

from formatjs.

Is the plan to create separate locale data files all the valid combinations? Loading in browser (non-bundled), a consumer will likely not know whether to request the non-region specific locale data file or a region specific data file.

from formatjs.

@dbatiste there will still be a single zh.js file, but it will look like this:
https://github.com/yahoo/intl-relativeformat/blob/master/dist/locale-data/zh.js

Note: That file gzips to: 636 bytes

from formatjs.

Ah I see. Awesome!

from formatjs.

Yeah this way it's backwards compatible and the locale data is bundled per top-level language with the details for each language's locales encapsulated.

Also we broke out the CLDR locale data extraction into its own package in case people want to bundle up locale data differently:
https://github.com/yahoo/formatjs-extract-cldr-data

from formatjs.

PR #94 fixes zh-Hant-* and locales that were incorrectly handled.

from formatjs.

Thanks! Nice work! Looking forward to the new release!

from formatjs.

React Intl v1.2.0 correctly supports zh-Hant locales.

from formatjs.

Yeah, I'm having same problem of using zh-hant-tw

from formatjs.

I can use zh-Hant-TW, what's the issue you bumped into?

from formatjs.