1917411 - Calendar shows mixed languages in month display when localised TB is used on English OS

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Francesco (no longer active, use PM for contact)]

Attachment: mixed-languages.png

Use TB in Italian from
http://ftp.mozilla.org/pub/thunderbird/nightly/2024/09/2024-09-07-10-06-48-comm-central-l10n/
on an English Windows system and configure TB to use the regional settings locale, English US or UK.

Display calendar. The month is displayed in two languages, should be displayed consistently, apparently in Italian. Apparently the Calendar follows the application locate (it) when the rest of the system follows the regional settings locale (en-US/GB), for example in the message list. (Note that many people use TB in original English, but their OS uses their local language, which is the opposite of what is described here.)

Partly a regression of bug 1906593. Likely toLocaleDateString() isn't the correct formatting function to be used:
https://hg.mozilla.org/comm-central/rev/a98c77474448#l1.48

6/9/2024:
Day: September (already inconsistent)
Week: Settembre
Multi-Week: Settembre
Month: Settembre

7/9/2024:
Day: September (still inconsistent)
Week: Settembre
Multi-Week: Settembre
Month: September (now inconsistent) <--

There are other date displays which are inconsistent, for example the date picker when creating a new event is in English.

Comment 1

[Francesco (no longer active, use PM for contact)]

Attachment: Inconsistent date picker display

Comment 2

[Alessandro Castellani [:aleca]]

Well, that's disappointing.
Geoff, any suggestions on how we can ensure the correct locale is used?

Comment 3

[Geoff Lankow (:darktrojan)]

Is "burn it all to the ground" a helpful suggestion?

I'm going to ramble on a bit here because calendar localisation is … complicated. While we're here I'd like to fix it properly so that we stop having these problems.

In the preferences a user can choose to format dates using "application locale", in this case Italian, and this will use the Italian strings our translators provide, not only for the UI but when we construct a string like "9–15 Settembre 2024" for the week view. When we just format a date using Intl.DateTimeFormatter, the Italian strings are provided by toolkit to get "9 settembre 2024".

Or the user can choose "regional settings locale", which still uses Italian strings to create "9–15 Settembre 2024", but English strings for "9 September 2024".

I think the thing to do is convert all of our date/time formatting to use Intl.DateTimeFormatter, and this will magically obey the preference (after restarting), but where do we draw the line? Just the dates and times? What about week day labels? Is it weird that the rest of the calendar UI will be in Italian? The view selection will still be Giorno/Settimana/Multi-settimana/Mese, for example.

Comment 4

[Francesco (no longer active, use PM for contact)]

Is it Intl.DateTimeFormatter or Services.intl.DateTimeFormat?
https://searchfox.org/comm-central/rev/e0ebb00f1a0a30bbea2cc82db35b73850325b838/calendar/base/modules/utils/calDateTimeFormatter.sys.mjs#604,606

As a quick fix, you could add the locale to the formatter call. Here's a test script:

console.log(new Date(2024, 8).toLocaleDateString(undefined, { month: "long", year: "numeric" }));
console.log(new Date(2024, 8).toLocaleDateString("it", { month: "long", year: "numeric" }));
console.log(new Intl.DateTimeFormat(undefined, { month: "long", year: "numeric" }).format(new Date(2024, 8)));
console.log(new Intl.DateTimeFormat("it", { month: "long", year: "numeric" }).format(new Date(2024, 8)));
console.log(new Services.intl.DateTimeFormat(undefined, { month: "long", year: "numeric" }).format(new Date(2024, 8)));
console.log(new Services.intl.DateTimeFormat("it", { month: "long", year: "numeric" }).format(new Date(2024, 8)));

Comment 5

[Geoff Lankow (:darktrojan)]

I'm working on this, but it won't be a "quick" fix.

Comment 6

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1917411 - Stop assembling date, time, and interval strings from localised parts. r=aleca

This patch removes all (that I could find) attempts to assemble localised strings from their
various components (e.g. day + " " + monthName + " " + year) and replaces then with standard
methods using Intl.DateTimeFormatter.

After the change, the preference intl.regional_prefs.use_os_locales should behave as intended for
all calendar code. That is:

• if the pref is false, and the application and operating system use different languages (ignoring
  regional variations), the application's language will be used to format date and times.
• if the pref is true, or the both use the same language, that language will be used.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ba75b4c47bfc
Stop assembling date, time, and interval strings from localised parts. r=aleca

Comment 8

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Confirming this issue as verified fixed with 133.0b3(20241107210012) using Windows 11, macOS 14, and Ubuntu 22.