Metro and l10n, is there a plan?

[flod]

Hi everyone,
I think I need some information before devoting more time on mozilla-central to Metro's strings, and I believe that dev.planning is more suited than dev.l10n for this discussion.

https://bugzilla.mozilla.org/show_bug.cgi?id=840888#c3
"Ux may tweak the strings before we get to Aurora."

This comment scares me because, when you land 300 strings a week before merge day, it kind of screams "I'm going to break Aurora to fix things".

https://bugzilla.mozilla.org/show_bug.cgi?id=843988#c1
"This was just a placeholder until I knew what ux wanted here. Should be fixed in a few days."

What's exactly the plan with Metro and l10n? Should we at least think/talk about it?

Francesco

[Axel Hecht]

I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=844068 to drop
l10n of metro.

I don't think that development of this kind should happen on central in
general, but we surely need to stop wasting dozens of people's time on
this on the l10n side.

Axel

[flod]

Thanks Axel, this definitely makes more sense. If that's the situation, and strings are not in use (unless I misunderstood), I guess we should also think about Aurora and those 300 strings.

Francesco

[Matt Brubeck]

On 2/22/2013 5:20 AM, Axel Hecht wrote:
> I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=844068 to drop
> l10n of metro.
>
> I don't think that development of this kind should happen on central in
> general, but we surely need to stop wasting dozens of people's time on
> this on the l10n side.

I agree we should prevent people from wasting time translating Metro at
this point. I *thought* we asked several months ago whether we could
exclude Metro strings from localization and were told it wasn't
possible; otherwise we'd have done it much sooner. Sorry for the
misunderstanding there! If there's any way to disable localization of
our strings, that is definitely the best next step.

In general however, there should be no expectation that UI that lands on
mozilla-central has the same UX maturity as code that gets shipped on
our other testing channels. It is necessary at times for projects like
the download panel or the native Android browser to go through many
iterations on Nightly before being enabled for later release channels.
This has been explicitly called out in the rapid release process
documentation since its earliest drafts on GitHub. We won't do this
lightly, but there are cases like Android and Metro where we believe we
need to move fast to avoid losing *millions* of users and significantly
harming the Mozilla project.

That said, landing right before the Aurora uplift and allowing the
strings to get uplifted into Aurora (where the code is disabled and so
the strings are unused) was especially bad, and we should have prevented
that before it happened. We should *at least* make sure that localizers
working in Aurora are only translating frozen, shippable strings.
Apologies from the dev team for dropping the ball there.

Keeping Metro out of mozilla-central longer may have had benefits for
localizers, but it also has significant costs for other groups like
developers, releng, QA, sheriffs, crashkill, and the nightly testing
audience. We have a lot of code in Metro Firefox that is *not* under
any UX churn and can benefit greatly from being in mozilla-central
builds. Hopefully we can obtain these benefits but also minimize the
cost to the l10n community, by disabling l10n of metro strings.

[Axel Hecht]

On 22.02.13 17:20, Matt Brubeck wrote:
> On 2/22/2013 5:20 AM, Axel Hecht wrote:
>> I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=844068 to drop
>> l10n of metro.
>>
>> I don't think that development of this kind should happen on central in
>> general, but we surely need to stop wasting dozens of people's time on
>> this on the l10n side.
>
> I agree we should prevent people from wasting time translating Metro at
> this point. I *thought* we asked several months ago whether we could
> exclude Metro strings from localization and were told it wasn't
> possible; otherwise we'd have done it much sooner. Sorry for the
> misunderstanding there! If there's any way to disable localization of
> our strings, that is definitely the best next step.

Yes, there's apparently been a huge disconnect in communication. I think
my answer would have been "put your strings into `content` instead of
`locale` until they're ready for l10n", or just avoid doing a build system.

I have been quite rigorous about getting the obvious things figured out
before merging elm to central, and I'm thankful for your help there.
Which may have made our status-quo even more surprising to me, oddly
enough. I really assumed we'd be ready to expose these strings to
localizers, now that all unused stuff was removed, and duplicate efforts
had been refactored.

At the point of merging, things felt really in place to me.

> In general however, there should be no expectation that UI that lands on
> mozilla-central has the same UX maturity as code that gets shipped on
> our other testing channels. It is necessary at times for projects like
> the download panel or the native Android browser to go through many
> iterations on Nightly before being enabled for later release channels.
> This has been explicitly called out in the rapid release process
> documentation since its earliest drafts on GitHub. We won't do this
> lightly, but there are cases like Android and Metro where we believe we
> need to move fast to avoid losing *millions* of users and significantly
> harming the Mozilla project.

I totally agree that stuff on central isn't 100% stable. Landing a
user-visible string that has 'XXX' in it (well, it was two ., but still)
for the lack of knowing what to land ... that's a completely different
ball game in my book.

We are localizing central, and central needs to follow all coding
guidelines for having a properly localized build at any point of the day.

Also, the rapid release cycle clearly states that any feature on central
needs to be able to be pref'ed off, if it's not ready to release. The
metro landing isn't pref'ed off on aurora as far as I can tell.
https://bugzilla.mozilla.org/show_bug.cgi?id=841919 claimed to do that,
but actually didn't switch off metro for aurora for localizers. Found
that bug by going through version history of the l10n mozconfigs, too.
It would have been easier to CC me.

Sadly, .ini files don't support #ifdef's, but the switch-off patch
should have touched l10n.ini as well.

> That said, landing right before the Aurora uplift and allowing the
> strings to get uplifted into Aurora (where the code is disabled and so
> the strings are unused) was especially bad, and we should have prevented
> that before it happened. We should *at least* make sure that localizers
> working in Aurora are only translating frozen, shippable strings.
> Apologies from the dev team for dropping the ball there.
>
> Keeping Metro out of mozilla-central longer may have had benefits for
> localizers, but it also has significant costs for other groups like
> developers, releng, QA, sheriffs, crashkill, and the nightly testing
> audience. We have a lot of code in Metro Firefox that is *not* under
> any UX churn and can benefit greatly from being in mozilla-central
> builds. Hopefully we can obtain these benefits but also minimize the
> cost to the l10n community, by disabling l10n of metro strings.

I'm not convinced that switching metro on for the nightly builds is the
right thing, tbh. Whether you want to be on mozilla-central is a
different question, but folks like the ux-branch make good use of their
freedom.

Axel