Add localization note to region.properties about review from l10n drivers being required for any changes

NEW
Unassigned

Status

()

defect
10 years ago
4 years ago

People

(Reporter: stas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

L10n drivers would like to add a comment to the region.properties files reminding the developers and the localizers that any changes to this file need to go through a review process. This is to ensure that only approved changes to productization of Firefox land on hg.

Axel, what do you think about the wording?
Attachment #370905 - Flags: review?(mconnor)
Attachment #370905 - Flags: review?(l10n)
Depends on: 486177
Comment on attachment 370905 [details] [diff] [review]
Proposed patch with the note

Sounds good to me. mconnor?
Attachment #370905 - Flags: review?(l10n) → review+
Comment on attachment 370905 [details] [diff] [review]
Proposed patch with the note

>diff --git a/browser/locales/en-US/chrome/browser-region/region.properties b/browser/locales/en-US/chrome/browser-region/region.properties
>--- a/browser/locales/en-US/chrome/browser-region/region.properties
>+++ b/browser/locales/en-US/chrome/browser-region/region.properties
>@@ -1,8 +1,13 @@
>+# LOCALIZATION NOTE: REVIEW_REQUIRED
>+# Please do not commit any changes to this file without a review from
>+# the l10n-drivers team (this includes en-US). In order to get one, 
>+# please file a bug, add the "productization" keyword and CC l10n@mozilla.com.

We don't have a keyword named "productization", do we?
Ehsan:  See blocking bug 486177.
So I'm not actually clear on the process here wrt l10n-drivers vs. bizdev, and how this is expected to work in practice, or why l10n-drivers needs to gate changes in en-US.  If we add a new handler for, say, mailto, why does that require intervention/approval from l10n-drivers?

Kev, can you weigh in with any thoughts here?
Two main reasons from l10n-drivers' point of view, of which the first one is the most important:

1. en-US productization is the default one. If we don't have enough good suggestions for local services, we go with the en-US choices. That's because they're usually global enough and popular enough, regardless of the region/country. en-US is *the* locale of reference, so adding a new mailto handler would make us ask: "which locales will want this handler too?" (Hotmail, anyone?). So, any changes to en-US productization can have a big impact on other locales (like the Mibbit handler, which landed in 44 locales so far).

2. en-US is widely used outside the US, so it's always good to check with l10n-drivers before making any changes. Just to stay in sync.

As you can see, the productization of the en-US builds has impact on people all around the world. The note is intended to make sure l10n-drivers know in advance about changes to it, so that we can act upon it, e.g. by offering l12y suggestions and communicating to localizers in a timely manner.

I'll be happy to clarify this more, if needed. Thanks!
Another not-Kev comment:

I'd frame it differently. Whoever wants changes to region.properties should get l10n-drivers into the loop, independent of locale. We have a good set of guidelines for most stuff, in particular how to localize existing features, but also on how to extend our reach when we get the opportunity.

One of the things we commonly do is to keep bizdev in the loop, or ask the for guidance and evaluation.

In real life, "ask l10n-drivers" is just an easy formulation of "don't just land things without evaluating impact", and for many things l10n drivers won't need bizdev, and for those things that we do, I'm confident that we'll rather ask once too often and not enough. That's why we propose to keep the policy to follow by developers and localizers easy, and do the right thing between in-policy implementation and out-of-policy discussions behind the scenes.
Comment on attachment 370905 [details] [diff] [review]
Proposed patch with the note

So, this is really a matter of perspective.  What the localization note creates is a process where approval lies in the hands of l10n-drivers, via a process that seems... broken.  Filing a separate bug just doesn't seem to make a lot of sense (i.e. the Mibbit bug, as an example, why would we file a separate bug instead of adding the keyword to that bug?)

The process is strange and inefficient, and the desired outcomes don't really mesh for me.  More in a followup comment.
Attachment #370905 - Flags: review?(mconnor) → review-
So, there's different factors in play here:

* Technical/implementation considerations (how to best localize features)
* Product considerations (user experience changes)
* Partnership considerations (contractual/revenue-impacting changes)

The patch wasn't "ask l10n-drivers" as much as "approval from l10n-drivers is required" which is why I don't think it's right.  l10n-drivers need to be in the loop, though I do wonder why simply adding the keyword isn't enough.  My thinking is that I want to avoid enshrining the complex concept of buy-in into our process.  This is well-meaning, but I think it's the wrong approach.

I think if the assertion is that we haven't judged impact appropriately in the past, we shouldn't add process to strictly cover a file that's had three substantial changes in the past year, we should talk about what we really want, and how to best achieve it.

Is there an urgency here, or can we do this in a session at the all hands?
(In reply to comment #8)

> The patch wasn't "ask l10n-drivers" as much as "approval from l10n-drivers is
> required" which is why I don't think it's right.  l10n-drivers need to be in
> the loop, though I do wonder why simply adding the keyword isn't enough.  

It actually *was* my intention to say "adding the keyword *is* enough". I didn't mean to require filing new bugs with the sole purpose of notifying l10n-drivers. If there's a bug, add the keyword. If you're planning a change and there's no bug about it, then please file it and add the keyword.

In comment 7 you ask "i.e. the Mibbit bug, as an example, why would we file a separate bug instead of adding the keyword to that bug?". The idea was to do exactly that: just add the keyword to the existing bug. 

> Is there an urgency here, or can we do this in a session at the all hands?

Let's chat about this at the all hands, yeah.
Where are we on this bug? Stas, did you actually get a chance to talk to connor?
This apparantly didn't make progress in the last year.

Seth, could you take a stab at a wording here?

Not to dismiss connor's comments here, but who's the right person to talk to about this these days? shaver's listed as Firefox module owner now.
We work on a near-daily basis with someone from our localization community to perfect the set of search plugins, feed readers, mail handlers, etc.  The l10n-drivers team is leading low-level business development for Mozilla, researching the best local options, contacting providers to get approval to include them in the localized version, and discussing with our volunteer community what is best to ship.  So, when a change is made that will affect our global users via their localized builds, it would be helpful/strategic to involve the l10n-drivers in the decision making process.

Also, for the l10n-drivers team who has to maintain a precise status of search plugins for 80+ repositories, adding the comment proposed in this patch would make life much easier, allowing our l10n-src automation to work better.  That l10n-src allows us to check and verify the status of search plugins and region.properties for every locale before we ship.  With localizers who use tools, the note in their local repo is ignored.  If something were in this file, l10n-src-verification would pick that note up.

I'd like to work on a patch whose wording clearly asks to add a keyword, but doesn't seem like a tail wagging the dog.
Since the note also applies to en-US, could you add it to region.properties in mozilla-central?
Comment on attachment 487338 [details] [diff] [review]
Add "Review required" comments to mozilla-central

Thanks, Eduardo.  I think we'll go for something that tries to hone in on keyword.  Let me take some time to discuss with the team and then try to post another patch later.  In the meantime, I'll r- this one to the list of patches needing review up-to-date.
Attachment #487338 - Flags: review-
Another month has passed. Can we get someone's eyes here please? I really don't want to have to set a blocking? flag in order to get someone's attention. Pretty please?
It's the endgame of a major release.  If it's something you feel should block, nominate it.  If it's not critical enough to block, you probably won't get attention at this point.
See Also: → 1224173
You need to log in before you can comment on or make changes to this bug.