1789512 - Localization files in omni.ja have the locale twice in the path

Status: RESOLVED FIXED

(Thunderbird :: Build Config, task)

Description

[Rob Lemley [:rjl]]

The localization files in omni.ja end up at paths like:
chrome/es-MX/locale/es-MX/alerts/alert.dtd
The Firefox omni.ja files do not have the second locale name in the path. For consistency, dropping the second instance is desirable.
This is also affecting MSIX packaging work as the repackage process digs through omni.ja looking for strings and it currently fails for Thunderbird builds because the strings files are not where they're expected to be.

Comment 1

[Rob Lemley [:rjl]]

On closer inspection, Firefox has two omni.ja files, one in a browser/ subdirectory where the second locale name does not show up. It's only got files from the browser/ source directory though. toolkit/ and friends end up in another omni.ja in the application directory, and in that one localization files have the second locale name instance in their path.

This bug is really about getting mach repackage msix working for local builds. The only strings file that gets read during repackaging is brand.properties and as long as that can be found at **/chrome/en-US/locale/branding/brand.properties things will work. Currently, Thunderbird builds using nightly branding are okay, but thunderbird branded builds are not. So the fix will bring the jar.mn files in the branding directories into alignment.

Comment 2

[Rob Lemley [:rjl]]

Attachment: Bug 1789512 - Remove extra path component from "thunderbird" branding l10n files in omni.ja. r=dandarnell

Within omni.ja, this will drop the second instance of a locale name from the
path to a localization file. This will make beta and release builds consistent
with nightly builds.
Ex:
chrome/en-US/locale/en-US/branding/brand.dtd
becomes:
chrome/en-US/locale/branding/brand.dtd

This does not affect the chrome:// URLs to these resources, only their location
within omni.ja.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e9d755b282aa
Remove extra path component from "thunderbird" branding l10n files in omni.ja. r=dandarnell

Comment 4

[Rob Lemley [:rjl]]

Thomas:
When this change hits beta next week with 106.0b1, would you be able to check a few localized builds and make sure that the branding strings are properly translated? (I will check some as well, it would be good for someone else to confirm.)

Easiest string to check is the "trademarkInfo" string that appears in very small text at the bottom of the "About:" dialog. Most languages have that translated. In en-US it's "Mozilla Thunderbird and the Thunderbird logos are trademarks of the Mozilla Foundation."

Comment 5

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Correct trademarkInfo string in sample localizations

(In reply to Rob Lemley [:rjl] from comment #4)

Thomas:
When this change hits beta next week with 106.0b1, would you be able to check a few localized builds and make sure that the branding strings are properly translated? (I will check some as well, it would be good for someone else to confirm.)

No problem.

Easiest string to check is the "trademarkInfo" string that appears in very small text at the bottom of the "About:" dialog. Most languages have that translated. In en-US it's "Mozilla Thunderbird and the Thunderbird logos are trademarks of the Mozilla Foundation."

Have checked 106.0b1 (made available 3 days ago), DE and FR. trademarkInfo string correctly translated in both (thunderbird106-fixed).

German hasn't translated much of the recently moved-to-Fluent help menu yet, that's ok (task bug 1792145).