Add localization to DisplayUnitSystem and pull localized strings from Culture object#71
Add localization to DisplayUnitSystem and pull localized strings from Culture object#71UliPlabst wants to merge 2 commits into
Conversation
Would it be better to pull this from CLDR, using CLDR-JS? What do you think? |
Yeah that makes sense. I didn't know about CLDR. If I understood correctly CLDR-JS is just a library that grants easy access to CLDR Data. Would be the appropriate way to extract the relevant decimalFormat data from CLDR and put it in globalize/globalize.cultures.ts? If my work is welcome I can do that. |
|
It could be the solution. If you download the CLDR release, you can find all the languages definitions inside /common/main/. Inside every xml named with language only (ex Anyway, your job seems great. I botched italian localization into my project and this implementation would be so nice. |
I did a Pull Request with the CLDR unicode adjusting the Localized strings, solving issue#36. I have tested it here, and by all means, it's working clean. The iteresting is that there is no method changes, so, even old visuals can upgrade to this, without any change. By the way, I must say it is my first Pull Request and the Build check failed, because package.json is out of sync with the lock one. I had changed the file package at the branch and not the lock one. How to fix it? Is there a way to give a "NPM Install" from here? Or should I create a Pull Request for the lock file? |
|
Will @jrussi1301 's pull request be merged so that #36 is resolved or should I gather the decimal format strings from CLDR into my pull request? |
This pull request aims to support localization of the DisplayUnitSystem discussed in #36 .
I changed the signature of the describe function in valueFormatter.ts@localizationOptions from
to
to support giving out different objects based on the configured culture of the formatter.
Further on I extended the culture type to contain an optional localizedStrings property. In the default describe function I try to pull the format and title value from the localizedStrings property of the culture object, otherwise I default back to valueFormatter.ts@localizationOptions.
Also every instance of DisplayUnitSystem now has a assigned culture object that it retrieves in it's constructor. Therefore it does no longer make sense to cache units in the static property since different instances of DisplayUnitSystem can have different cultures and therefore need different unit objects. A cache could be implemented nontheless but is not necessary in my opinion.
I aimed for minimal modifications under the constraint that the localization information should be supplied through the culture object defined in globalize/globalize.cultures.ts. I also added localizationStrings for the german language culture object. Unfortunately I do not have the resources to add the appropriate localizedStrings object for other languages.