-
Is there any way to set the default territory for a language? We have these settings: use Cldr,
locales: ["ja", "en"],
default_locale: "ja" "en" has US-style date formats, though, so we'd like to use "en_SE" instead. However, just changing it to: use Cldr,
locales: ["ja", "en_SE"],
default_locale: "ja" will only work if the user actually requests that territory. If the accept-language header requests "en" or any other territory, it will fall back to "en" instead of "en_SE". Is there any way to get around this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
TLDR; no automated way to do this. Longer version: If the user requests Secondly, the formats (number, dates, times, units, ...) are linked to the locale ( There is, as you have seen, a locale fallback mechanism. And But ... that doesn't always work in the real world of course. I think there are a couple of ways forward:
iex> MyApp.Cldr.Date.to_string Date.utc_today(), format: "yyyy/MM/dd", locale: "en-SE"
{:ok, "2024/05/13"} Do either of those show some hope for you? I'm open to ideas. |
Beta Was this translation helpful? Give feedback.
TLDR; no automated way to do this.
Longer version: If the user requests
en
, then the locale will be interpreted asen-US
as you have found. This is typical in CLDR - the default territory is that which has the largest number of native speakers of the given language. Sometimes this is surprising since it means thatpt
is interpreted aspt-BR
because there are more native Portuguese speakers in Brazil than there are in Portugal.Secondly, the formats (number, dates, times, units, ...) are linked to the locale (
en-SE
for example), noten
orSE
. There are some situations where it's possible to override the territory code. For example,en-u-rg-SEzzzz
. But that does not affect locale formats li…