Open Bug 1548500 Opened 2 years ago Updated 2 years ago

Create automated test to check for string conflicts with android-l10n localization

Categories

(Release Engineering :: Release Automation: L10N, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Pike, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #1353680 +++

In bug 1353680, I landed a linter in m-c that checks for string conflicts with gecko-strings, and we should have the same thing for our android-l10n projects. This is the answer to the question on how engineers will find out when they introduce conflicts with strings exposed to l10n.

Here's what I'd like to do, across Fenix, a-c, FxR, and lockbox-android:

Update compare-locales to 7.2.4.

Replace compare-locales --validate l10n.toml . with moz-l10n-lint l10n.toml.

Note the removal of the trailing . in that command.

The compare jobs for locales, aka, compare-locales l10n.toml . should stay the way they are, with just the update to compare-locales.

In a second phase, which we can also spin off into a separate bug, it'd be good to add ID conflict checks:

On PRs, we should also check for string conflicts, and for that, we want to git clone ...mozilla-l10n/android-l10n.git, and pass two additional arguments to moz-l10n-lint, --reference-project android-l10n/mozilla-mobile/fenix/ -W, with the right subdir in android-l10n for each project. The -W will make the test fail on conflicts.

Given this spans a number of gh projects and issue trackers, filing a bug to have a central point of reference.

You need to log in before you can comment on or make changes to this bug.