Enterprise: Locale: incorrect time patterns

Created on 25 Apr 2019  路  12Comments  路  Source: infor-design/enterprise

According to locale definitions here https://github.com/moment/moment/tree/develop/locale
And I have also checked in C#, time pattern for e.g. sl-SI it should be using ':' and not '.'

Raising a question whether there's more mismatch in the locale definitions.

At least these have wrong time pattern
da-DK
pl-PL
pt-BR
sl-SI

[2] high type

All 12 comments

Our source for this is the CLDR I'm seeing the version i had has some differences on the latest https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/sl/ca-gregorian.json#L323

So will update based on that as a source. I am seeing for example sl-SI has changed but da-DK has not so that one is probably correct. Will check them all against the latest CLDR

How does that play with csharps CultureInfo?
E.g. I see that in CultureInfo nb-NO short date pattern looks like following "dd.MM.yyyy"
But in CLDR it looks like following "dd.MM.y"
https://github.com/unicode-cldr/cldr-dates-full/blob/1af902b749bef761f07281f80241250053b4313d/main/nb/ca-gregorian.json#L314

They say MS uses CLDR http://cldr.unicode.org/#TOC-Who-uses-CLDR- but we did one exception with CLDR and made all years four digit pattern. (Usually) But seems the nb-NO case isnt how i expect https://github.com/infor-design/enterprise/blob/master/src/components/locale/cultures/nb-NO.js#L18 so i would update that one.

I think that actually a single y in CLDR means a four digit year as well but not in our code, needs to be yyyy

Further question on nb-NO definition, https://github.com/unicode-cldr/cldr-dates-full/blob/1af902b749bef761f07281f80241250053b4313d/main/nb/ca-gregorian.json#L324
nb-NO has a short-alt-variant, which sl-SI does not have. Are you taking that into consideration?

I noticed that on the computer I use, it would recognize the first pattern which is HH:mm but not HH.mm. So my guess when you update locales, you should priorities short pattern and not the short-alt-variant

Yeah i would agree that we would take the short pattern from these when i go through it all again.

@guoliang i synced this up have a look at https://github.com/infor-design/enterprise/pull/2114

da-DK -> not changed https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/da/ca-gregorian.json#L320
pl-PL -> changed some
pt-BR -> changed some
sl-SI -> changed

Others corrected.

Keeping this ticket in Ready for QA and retest it during Smoke testing.

That issue you noted is unrelated and is fact a separate issue: https://github.com/infor-design/enterprise/issues/2021 i think this info should go on that ticket instead

Hi, @brianjuan The only way to test this ticket is by conducting regression on
the datepicker and time picker and then try a few locales to change like can spot check on http://localhost:4000/components/datepicker/example-timeformat.html?locale=bg-BG

As discussed i have a fix in for the IE issues https://github.com/infor-design/enterprise/pull/2186

This issue is now resolved.

Was this page helpful?
0 / 5 - 0 ratings