451964 - RFE: Add 'l10n' keyword for bugs that should be fixed before, not during, string freeze

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; is-IS; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: 

In the last weeks before a release there is a push while contributors look for bugs they can fix in the time remaining.  The current release cycle practice includes a "string freeze" weeks before the release to give localizers time translate all the UI text for the release.  However, currently there is no standard way to identify which bugs involve localization (l10n).  Bugs which involve localization (primarily new or changed UI text) should be fixed *before* string freeze, and should not be fixed *during* string freeze.  A 'l10n' keyword would help sort those bugs so contributors can focus on them in the weeks before string freeze, and skip them in the weeks during string freeze.

Reproducible: Always

Steps to Reproduce:
Search for bugs to fix during final weeks before release.
Actual Results:  
Cannot tell at a glance in query result which bugs involve changes to UI text.  Have to read bug description, or even start trying to solve it, before it becomes apparent that a bug requires change to UI text (e.g., new error messages), and therefore should not be fixed during string freeze.  So some bugs that might have been fixed for this release are not started until too late, and in last weeks before release during string freeze, contributors may waste time starting work on bugs that they later abort when they realize it won't be accepted in this release.

Expected Results:  
Can tell at a glance in query result which bugs involve changes to UI text by looking for 'l10n' in keywords column.  Just before string freeze, contributors can see which bugs involve UI text changes and make a push on those.  During string freeze, if someone starts work on a bug and realizes that it requires UI text changes and won't be accepted during string freeze, they can mark it so others can see it and can avoid working on it during string freeze.

A related keyword, 'late-l10n', already exists for check-ins during string freeze that involve localization changes.

Comment 1

[Reed Loden [:reed]]

We have late-l10n, l12y, and intl keywords already... I don't think there's really a need for an l10n keyword.

Pike, this is your call.

Comment 2

[Axel Hecht [:Pike]]

This is really about en-US triage, so not my call, moving over the ball to beltzner.

Mike, would a keyword help in tree management? What do you think? For 3.0 we talked about whiteboard status for l10n impact, but didn't get very far with that. Not sure if a binary flag would be easier to maintain.

Comment 3

[Gervase Markham [:gerv]]

Looks like Mike didn't think this was needed enough to comment, and we seem to have managed without :-)

Gerv