Enterprise: SOHO-3124: 4.0 Locale unable to indicate locale for parseNumber() or formatNumber()

[clepore]

Please add the ability to indicate the locale for parseNumber() and formatNumber() and translate()

Landmark used Globalize.cultures["default"] (en-US) to parse and format numbers for the Landmark storage formats for numbers. Locale.parseNumber() and .formatNumber() uses the current culture; if the current culture is not en-US, there is not a way to parse or format a number for en-US or for any other culture for that matter.
This issue is formerly SOHO-3124

• [x] Include option to pass a non current locale to parseNumber() or formatNumber() and translate
• [x] Include option to pass a non current locale to datepicker/timepicker/monthview and calendar
• [x] Additionally, would also like the ability to indicate to not use grouping. This was possible with

Locale.formatNumber(1234567.1234, { group: '' }); // Equals 1234567,123

[karinpb]

I would take this a step further and say that we need to be able to set a locale "en-US" for the language and one for formatting "sv-SE" and it applies to dates and numbers.

[tmcconechy]

@karinpb Can you elaborate on what you mean there. I was thinking we do this by allowing a third option to each of the functions so you can just call them with any locale other than the currently set one.

[karinpb]

The scenario I'm facing is the following. Ming.le is sending us two parameters, one for language and one for format. We have the requirement to separate Language and Locale. Widget developers have created inline widgets using the IDS controls, in many cases without passing in a format in order to support different locales.

I don't want them to have to do code changes. I want to be able to set language and format-locale on the Locale, like Locale.set("en-US","sv-SE") where the first parameter is the language and the second the format(locale-location). It should then apply as the default format in the same way as Locale.set("sv-SE") would use Swedish and Swedish formatting.

It's not really an option to change and temporarily use Locate.set("sv-SE") to then get the format and manually use that format. I'm hesitant to changing that global object and it would mean that the widget developers need to change their code in order to support this separation of language and format. On the other hand if this was build into IDS components then it would be business as usual, no code changes needed.

Looking at a locale file, the formatting section is 3 KB (unminified) or 1 KB minified. The language part is 31KB unminified and 28KB minified. So the translation is a substantial part of that code. It might be OK to load the translations, but we don't need them, only the formatting information, so I would rather not load that information.

[tmcconechy]

For format is that both number and date format in one? It might make sense to separate all three things. Maybe

Locale.set('sv-Se');

// And/Or
Locale.setNumberFormat('en-US');
Locale.setDateFormat('sv-SE');
Locale.setTranslationLang('sv-SE');

I think we could split the files but would result in 3 separate downloads. One way around this is to set the locales once in the head so they are only downloaded initially.

[tmcconechy]

Relates to https://github.com/infor-design/enterprise/issues/463

[brianjuan]

https://4170-beta0-enterprise.demo.design.infor.com/components/monthview/test-specific-locale.html
https://4170-beta0-enterprise.demo.design.infor.com/components/calendar/test-specific-locale.html
https://4170-beta0-enterprise.demo.design.infor.com/components/datepicker/test-two-locales-same-page.html
https://4170-beta0-enterprise.demo.design.infor.com/components/timepicker/test-specific-locale.html
https://4170-beta0-enterprise.demo.design.infor.com/components/monthview/example-index.html
https://4170-beta0-enterprise.demo.design.infor.com/components/calendar/example-index.html
https://4170-beta0-enterprise.demo.design.infor.com/components/datepicker/example-index.html
Passed QA testing on all browsers, moving to Done.