Australis schedule and l10n (localization)
dolske at mozilla.com
Tue Jul 2 18:17:33 UTC 2013
On 7/1/13 11:45 PM, Francesco Lodolo [:flod] wrote:
>> We're still planning on landing as soon as possible in Firefox 25.
>> We currently have three landing blockers...
> Not sure if these two bugs qualify as blockers, but it would certainly
> make sense to fix them before landing on central and exposing strings to
Those both sound like rather minor issues, so not blockers.
>> We're planning to land in 25, but also to back-out immediately after the
>> uplift to Aurora (Aug 5th). Australis will stay on mozilla-central
>> (only) until Firefox 26 uplifts to Aurora (Sep 16th), with intent to
>> ride the 26 train thru to release.
> I think you meant "before" the uplift to Aurora. Unfortunately that's
> quite a problem for l10n.
No, I really meant after uplift, so that there are no actual changes on
mozilla-central. (Backing out on m-c would mean also having to reland
it, which sounds like extra work.) But the backout would presumably
happen as part of the actual uplift process (or immediately afterwards),
so that its lifetime on Aurora would be a matter of minutes or hours.
This isn't something that should linger on Aurora for days.
In any case, I'm not so concerned about the exact process used on
uplift-day, so long as the results are the same... In the morning
mozilla-central will be 25 + Australis and mozilla-aurora will be 24; in
the evening mozilla-central will be 26 + Australis and mozilla-aurora
will be 25 without Australis.
> You're adding 29 strings, but you're also removing 17 of them, most
> important from the main UI. Most localization tools will remove those 17
> strings for localizers working on mozilla-central, and then they'll need
> to add them back for mozilla-aurora.
Between mozilla-central being very much not string-frozen and this being
a small number of strings, this doesn't sound like a big deal. But if
there's an easy tweak to make life easier, I have no objection.
> So, if you plan to to disable Australis just before the uplift to
> Aurora, a viable solution would be to add back those strings on the UX
> branch, *before landing Australis on central*. By doing this:
That sounds quite reasonable. It saves L10N work, and having the old
strings linger for a bit longer should be no issue.
Would you like to write the patch to reland them? :-)
> Note that this will cause some problems anyway for localizers who work
> on l10n-central (smaller teams work on mozilla-aurora), e.g. porting QA
> fixes between branches, or merging mozilla-aurora and l10n-central. But
> I guess that's inevitable.
More information about the firefox-dev