Skip to content
This repository has been archived by the owner on Jul 10, 2019. It is now read-only.

RelativeFormat.__localeData__ needs the full locale name, instead we just take the root locale #25

Closed
jasonmit opened this issue Feb 13, 2015 · 5 comments · Fixed by #28
Closed

RelativeFormat.__localeData__ needs the full locale name, instead we just take the root locale #25

jasonmit opened this issue Feb 13, 2015 · 5 comments · Fixed by #28
Assignees
@ericf
Labels
bug

Comments

@jasonmit
Copy link
Contributor

https://github.com/yahoo/intl-relativeformat/blob/master/src/core.js#L69

I believe is going to cause an issue as well for formatjs/formatjs#78

Steps:

  • Load both parsed CLDR objects into IntlRelativeTime.__addLocaleData
  • The following will output the same:
    • new IntlRelativeFormat('zh-hant-tw').format(new Date(new Date() - 3 * 60000));
    • new IntlRelativeFormat('zh').format(new Date(new Date() - 3 * 60000));
@jasonmit jasonmit added the bug label Feb 13, 2015
@jasonmit jasonmit changed the title RelativeFormat.__localeData__ needs the full locale name, instead we split on - and take the head RelativeFormat.__localeData__ needs the full locale name, instead we just take the root locale Feb 13, 2015
@ericf
Copy link
Collaborator

ericf commented Feb 13, 2015

This will force the issue of actually implementing a correct locale matcher instead of the simple poor-man's one we're using now. We should be able to look to the Intl.js polyfill for the details of the implementation.

@caridy
Copy link
Collaborator

caridy commented Feb 13, 2015

... or we can use the implementation from content negotiation used by express (https://github.com/jshttp/negotiator/#accept-language-negotiation). In any case, this should probably be an abstraction.

@ericf
Copy link
Collaborator

ericf commented Feb 13, 2015

@caridy We can start by writing the algorithm directly in this package since it's the only thing that will need it. Later we can decide if we want to pull it out into its own package.

@ericf
Copy link
Collaborator

ericf commented Feb 13, 2015

Tasks

I see the following being the set of things we need to do address this issue:

  • Evaluate the CLDR data to determine which locales have different field values than the data for their corresponding root locale. We know Chinese is one, let's programmatically determine if there's others. This evaluation should start with just the data this package uses from CLDR.
    Created formatjs-extract-cldr-data project
  • Based on the evaluation above, we need to make a decision whether Chinese is an exception, or if other languages have the difference across their sub-locales.
    Chinese is not the only exception
  • Update grunt-extract-locale-data to extract the field data for all unique locales, not just the root locales. We'll also need to reconcile this with the intl-messageformat data since that only applies to the root locales. The data for this package needs to include the plural functions + field data. (This may push us to making the locale resolution algorithm its own package since we'll likely need to run a similar process during the CLDR data extraction.)
    [email protected]
  • Update this package to work with more than just root locales — both when __addLocaleData() is called and when new instances are created.
    PR Fix locale data and improve locale resolving #28
  • Implement correct locale resolution algorithm to find the best fit locale for the data we have; e.g. if the developer only loaded zh but is creating a new instance with zh-Hant-TW, should we fallback to zh? (Again we should follow how the built-in Intl libs handle this or the Intl.js polyfill, and we may want this to be its own package.)
    PR Fix locale data and improve locale resolving #28

@ericf ericf mentioned this issue Feb 13, 2015
Closed
@jasonmit jasonmit mentioned this issue Feb 13, 2015
Closed
@ericf ericf self-assigned this Mar 6, 2015
ericf added a commit to ericf/intl-relativeformat that referenced this issue Mar 10, 2015
@ericf
Fix locale data and improve locale resolving
3f19bd3 
This upgrades to `[email protected]` and
`[email protected]` which vastly improves the locale data
in the following ways:

* Added locale data for all leaf locales which differ from their root
  locale's data; e.g. "zh-Hant-TW" is not the same as "zh".

* Properly de-duplicate data for all CLDR locales by correctly
  traversing a locale's hierarchy of ancestor locales.

* Added data for the following languages:
  aa, agq, bas, bh, ckb, dav, dje, dsb, dua, dv, dyo, ebu, ewo, guw,
  guz, hsb, ia, in, iu, iw, jbo, ji, jv, jw, kaj, kam, kcg, khq, ki,
  kln, kok, ksf, ku, lb, lu, luo, luy, mer, mfe, mgh, mo, mua, nah,
  nmg, no, nqo, nus, ny, pap, prg, qu, rn, rw, sbp, sh, sma, smi, smj,
  smn, sms, swc, syr, tk, tl, twq, vai, wa, wo, yav, yi, zgh

----

These changes also include improvements for how locales are resolved.
Here are some details of these changes:

* If no extra locale data is loaded, the locale will _always_ resolved
  to `en`.

* If locale data is missing for a leaf locale like `fr-FR`, but there
  _is_ data for the root, `fr` in this case, then its root will be
  used.

* If there's data for the specified locale, then that locale will be
  resolved; i.e.,

    var rf = new IntlRelativeFormat('en-US');
    assert(rf.resolvedOptions().locale === 'en-US'); // true

* The resolved locales are now normalized; e.g., `en-us` will resolve
  to: `en-US`.

Fixes formatjs#25
ericf added a commit to ericf/intl-relativeformat that referenced this issue Mar 10, 2015
@ericf
Fix locale data and improve locale resolving
288fcd0 
This upgrades to `[email protected]` and
`[email protected]` which vastly improves the locale data
in the following ways:

* Added locale data for all leaf locales which differ from their root
  locale's data; e.g. "zh-Hant-TW" is not the same as "zh".

* Properly de-duplicate data for all CLDR locales by correctly
  traversing a locale's hierarchy of ancestor locales.

* Added data for the following languages:
  aa, agq, bas, bh, ckb, dav, dje, dsb, dua, dv, dyo, ebu, ewo, guw,
  guz, hsb, ia, in, iu, iw, jbo, ji, jv, jw, kaj, kam, kcg, khq, ki,
  kln, kok, ksf, ku, lb, lu, luo, luy, mer, mfe, mgh, mo, mua, nah,
  nmg, no, nqo, nus, ny, pap, prg, qu, rn, rw, sbp, sh, sma, smi, smj,
  smn, sms, swc, syr, tk, tl, twq, vai, wa, wo, yav, yi, zgh

----

These changes also include improvements for how locales are resolved.
Here are some details of these changes:

* If no extra locale data is loaded, the locale will _always_ resolved
  to `en`.

* If locale data is missing for a leaf locale like `fr-FR`, but there
  _is_ data for the root, `fr` in this case, then its root will be
  used.

* If there's data for the specified locale, then that locale will be
  resolved; i.e.,

    var rf = new IntlRelativeFormat('en-US');
    assert(rf.resolvedOptions().locale === 'en-US'); // true

* The resolved locales are now normalized; e.g., `en-us` will resolve
  to: `en-US`.

Fixes formatjs#25
@ericf ericf mentioned this issue Mar 10, 2015
Merged
@ericf
Copy link
Collaborator

ericf commented Mar 10, 2015

With PR #28 all of the above tasks are completed.

@ericf ericf closed this as completed in #28 Mar 10, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@ericf ericf

Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix locale data and improve locale resolving ericf/intl-relativeformat
3 participants
@ericf @caridy @jasonmit