Format dates, times with window.navigator.language instead of UI i18n locale #354

Merged

floatingghost merged 2 commits from smitten/akkoma-fe:date-locale-fix-cherrypick into develop

2023-12-15 11:53:00 +00:00

smitten commented

2023-10-31 04:03:42 +00:00

Contributor

Dates are formatted with the currently configured i18n locale code, but those locales discard the country code from the language. So both en-US and en-GB in the browser settings are mapped to en in the i18n messages.

This results in dates being formatted in USian MM/DD/YYYY format instead of DD/MM/YYYY format as expected. See post from 0w0.is.

This PR does not affect the i18n mapping but updates internalToBrowserLocale so it checks what is set on window.navigator before falling back to the i18n value.

Dates are formatted with the currently configured i18n locale code, but those locales discard the country code from the language. So both `en-US` and `en-GB` in the browser settings are mapped to `en` in the i18n messages. This results in dates being formatted in USian MM/DD/YYYY format instead of DD/MM/YYYY format as expected. See [post from 0w0.is](https://0w0.is/objects/3a1b0edc-adc5-45e2-9d96-c7c4ee126b13). This PR does not affect the i18n mapping but updates `internalToBrowserLocale` so it checks what is set on window.navigator before falling back to the i18n value.

smitten added 1 commit 2023-10-31 04:03:43 +00:00

ci/woodpecker/pr/woodpecker Pipeline was successful Details

c9dc8f00f9

Use window.navigator.language before interface i18n language

Oneric commented

2023-11-01 22:55:57 +00:00

Member

Not an Akkoma maintainer, so don't take my suggestion as having any weight.

Getting rid of the forced US format for English is good, but I feel like the current approach creates a new problem.
It will entirely discard the interface language selected in the frontend settings in favour of the primary browser locale. But those two might intentionally differ resulting in e.g. dates being formatted in a way not matching any variant of the FE language.

Imho it would be better to use the browser languages to select the highest prio entry matching the FE language. If there’s no matching browser language, we’ll still have to fallback to the regionless FE language, but in that case it seems fair to assume the user doesn't care about the particular variant (or there might be no regional variants. Anyway they can easily fix it by adding an entry to their browser’s languages).

I.e. updating the patch to something like this:

diff --git a/src/services/locale/locale.service.js b/src/services/locale/locale.service.js
index c4f8ce21..55c46543 100644
--- a/src/services/locale/locale.service.js
+++ b/src/services/locale/locale.service.js
@@ -8,7 +8,18 @@ const specialLanguageCodes = {
   'zh': 'zh-Hans'
 }
 
-const internalToBrowserLocale = fallbackCode => specialLanguageCodes[fallbackCode] || window.navigator.language || fallbackCode
+const browserRegion = genericLang => {
+  for (const blang of window.navigator.languages) {
+    if (genericLang === blang.split('-')[0])
+      return blang;
+  }
+  return null;
+}
+
+const internalToBrowserLocale = fallbackCode => {
+  const lang = specialLanguageCodes[fallbackCode] || fallbackCode;
+  return browserRegion(lang) || lang;
+};
 
 const internalToBackendLocale = code => internalToBrowserLocale(code).replace('_', '-')

Note: on page load internalToBackendLocale is called once for all existing localisations and after that only for the configured FE language, but apparently each time something gets rendered into HTML.
Not sure if this repeated looping over windows.navigator.languages is a significant cost, but if so, it might be better to cache the results of the initial queries somewhere.

Not an Akkoma maintainer, so don't take my suggestion as having any weight. Getting rid of the forced US format for English is good, but I feel like the current approach creates a new problem. It will entirely discard the interface language selected in the frontend settings in favour of the primary browser locale. But those two might intentionally differ resulting in e.g. dates being formatted in a way not matching any variant of the FE language. Imho it would be better to use the browser languages to select the highest prio entry matching the FE language. If there’s no matching browser language, we’ll still have to fallback to the regionless FE language, but in that case it seems fair to assume the user doesn't care about the particular variant *(or there might be no regional variants. Anyway they can easily fix it by adding an entry to their browser’s languages)*. I.e. updating the patch to something like this: ```diff diff --git a/src/services/locale/locale.service.js b/src/services/locale/locale.service.js index c4f8ce21..55c46543 100644 --- a/src/services/locale/locale.service.js +++ b/src/services/locale/locale.service.js @@ -8,7 +8,18 @@ const specialLanguageCodes = { 'zh': 'zh-Hans' } -const internalToBrowserLocale = fallbackCode => specialLanguageCodes[fallbackCode] || window.navigator.language || fallbackCode +const browserRegion = genericLang => { + for (const blang of window.navigator.languages) { + if (genericLang === blang.split('-')[0]) + return blang; + } + return null; +} + +const internalToBrowserLocale = fallbackCode => { + const lang = specialLanguageCodes[fallbackCode] || fallbackCode; + return browserRegion(lang) || lang; +}; const internalToBackendLocale = code => internalToBrowserLocale(code).replace('_', '-') ``` Note: on page load `internalToBackendLocale` is called once for *all* existing localisations and after that only for the configured FE language, but apparently *each* time something gets rendered into HTML. Not sure if this repeated looping over `windows.navigator.languages` is a significant cost, but if so, it might be better to cache the results of the initial queries somewhere.

smitten added 1 commit 2023-11-02 03:11:05 +00:00

ci/woodpecker/pr/woodpecker Pipeline was successful Details

1b28ec3b72

Match UI i18n configuration to browser locales

smitten commented

2023-11-02 03:11:42 +00:00

Author

Contributor

@Oneric that makes sense to me, updated with those changes and I did do the cache too, might as well since it runs in render.

👍 1

floatingghost commented

2023-12-15 11:52:53 +00:00

Owner

this PR made me realise that my VM was using US english the whole time i was using it.. i legit did not realise, and now it can format in UK english

this works! thanks

this PR made me realise that my VM was using US english the whole time i was using it.. i legit did not realise, and now it can format in UK english this works! thanks