1074605 - Run multilocale steps on dep builds for beta/release ?

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect, P3)

Description

[Nick Thomas [:nthomas] (UTC+12)]

Bug 1074603 describes an l10n problem which wasn't caught until the release automation failed. AIUI we only run the mozharness_multilocale step in nightly builds for nightly/aurora, and not at all for beta/release because nightlies are disabled. 

We might catch this problem earlier if we ran multilocale on dep builds on beta/release, except we should be aware of these edge cases:
* l10n changes don't trigger en-US dep builds
* the en-US dep builds may appear to break randomly (from a sheriff point of view) when a locale repo changes
* we care about the signed off revision in the l10n dashboard, which may not be the current tip of an l10n repo

Which makes me wonder if the l10n dashboard should have caught this before the rev was signed off. Axel ?

Comment 1

[Axel Hecht [:Pike]]

Catching unknown entities is hard, because the best guess we have is "well, if en-US uses it, it should be OK, but else ... ?". And we do have places where HTML entities are totally fine, and we have places where branding entities are fine.

That's why in general missing entities are warnings. Right now, we have quite a few locale with quite a few warnings, which makes it easy to ignore new ones. Some of those can be solved on the automation side, by rewriting the checker logic and how it's hooked up (make them file based instead of string based so that moving entity references from a to b doesn't warn).

Given how finicky the multi-locale android build is, it's probably a good idea to get better coverage on testing the actual builds.

Comment 2

[Aki Sasaki (not active)]

Multilocale is now out of Gecko tree, and we're looking at langpack solutions.