Coupled Train Model, Localizers, and Localization Testers

[Alex Keybl]

In October, I proposed a modification to the current release model on dev.planning (see [1]). The motivation behind the proposed Coupled Train Model is to improve Release channel quality and developer focus by getting feedback from our test populations sooner after landing, with more time for developers to resolve critical issues prior to release. I won't go into all of the technical/merge details, but did want to touch upon the high level impact to localizers and get your impressions.

1) Cycles would be longer than today (every nine weeks instead of six), meaning less frequent l10n deadlines
2) A Firefox version will no longer spend six weeks on Aurora, instead moving quickly from Nightly to Beta within two weeks
3) String freeze would stay the same - the day that a Firefox version comes off of Nightly

I believe #1 is a big positive for everybody in the l10n community. I'd love to hear feedback on #2, since my understanding is that many localizers do not begin their localization process until string complete is declared. Given the longer cycles, these localizers would of course have less time between string complete and our first Beta. Are you all concerned about significant Beta tester frustration if more strings are left unlocalized in the first beta than today?

Depending on your feedback, we can explore ways to mitigate the Beta tester impact, but we're not sure how significant it would actually be. Keep in mind that Release channel l10n quality will likely be better than today, given the longer timelines. Thanks in advance!

-Alex

[1] https://groups.google.com/forum/#!msg/mozilla.dev.planning/x17zOBsQMsY/5lYn2iZPEF4J

[文少华]

Hi Alex,
Right now most of the l10n team are working on the Aurora channel, based
on your description, it seems that now every two weeks we'll have new
strings on aurora. But on Beta channel there should be no string changes
right? Then the impact to l10n teams is we need to switch to work on beta
channels instead of Aurora if we expecting string freezing.
For l10n teams need to still keep aurora channel updated, then every two
weeks we need to update the translation.
Br.
Holy

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>

[Alex Keybl]

> But on Beta channel there should be no string changes right?

That's correct, we will do our best for there to be no string changes on Beta. There would also be no string changes on Aurora the two weeks after a version bump on Nightly, for those who want to begin localizing there.

> Then the impact to l10n teams is we need to switch to work on beta channels instead of Aurora if we expecting string freezing.

That's one option, although you could also start on Aurora a couple of weeks earlier upon string freeze (as mentioned above). Ultimately, we'd love to enable you all to localize Nightly (if you're interested) by better managing UX/string landings. That would come in the future though.

A quick question for you - do you feel that a few more unlocalized strings on Beta would be very frustrating for l10n Beta testers? That's the biggest open question here.

-Alex

[文少华]

Hi Alex,
For me or zh-CN l10n team, it's not a problem if not more than 10%
percent of the total changed strings happen in beta channel.
Actually we hope we can update even more strings in the Beta channel, I
guess this has be considered as a big risk for release team?
Br.
Holy

[Alex Keybl]

> Actually we hope we can update even more strings in the Beta channel, I guess this has be considered as a big risk for release team?

We're comfortable with l10n work being completed on the Beta channel, just not in the last 1-2 weeks of a cycle. Earlier localization is of course always better though, and something we should strive for through future l10n process change.

-Alex

[Wim Benes]

Hi Alex,

I can't say I feel comfortable with this cycle right away.
Although the cycle becomes 9 weeks, it is the final cycle, after that it
won't
be possible anymore to fix things like we can do now in the betachannel.
After all, we now have 12 weeks for localizing instead of your proposed
9 weeks.
Adding 2 weeks for Aurora is a bit short if you have to do the
localizing work
crossing over several weeks.
For me keeping up in Aurora in 2 weeks is a no-go, leaving with "only" 9
weeks in the final stage
this can lead to unfixed/unlocalized strings.

Kind regards
fryske firefox Wim
fryske...@gmail.com
Typ mar Frysk
fjoerfoks.blogspot.com
www.mozilla-nl.org/
www.mozbrowser.nl
www.fryskesoftware.nl

Op 21-11-2013 2:21, skreau Alex Keybl:
> In October, I proposed a modification to the current release model on dev.planning (see [1]). The motivation behind the proposed Coupled Train Model is to improve Release channel quality and developer focus by getting feedback from our test populations sooner after landing, with more time for developers to resolve critical issues prior to release. I won't go into all of the technical/merge details, but did want to touch upon the high level impact to localizers and get your impressions.
>
> 1) Cycles would be longer than today (every nine weeks instead of six), meaning less frequent l10n deadlines
> 2) A Firefox version will no longer spend six weeks on Aurora, instead moving quickly from Nightly to Beta within two weeks
> 3) String freeze would stay the same - the day that a Firefox version comes off of Nightly
>
> I believe #1 is a big positive for everybody in the l10n community. I'd love to hear feedback on #2, since my understanding is that many localizers do not begin their localization process until string complete is declared. Given the longer cycles, these localizers would of course have less time between string complete and our first Beta. Are you all concerned about significant Beta tester frustration if more strings are left unlocalized in the first beta than today?
>
> Depending on your feedback, we can explore ways to mitigate the Beta tester impact, but we're not sure how significant it would actually be. Keep in mind that Release channel l10n quality will likely be better than today, given the longer timelines. Thanks in advance!
>
> -Alex
>
> [1] https://groups.google.com/forum/#!msg/mozilla.dev.planning/x17zOBsQMsY/5lYn2iZPEF4J
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n

> .
>

[Julen Ruiz Aizpuru]

Alex,

2013/11/24 Wim Benes <fryske...@gmail.com>:

> Hi Alex,
>
> I can't say I feel comfortable with this cycle right away.
> Although the cycle becomes 9 weeks, it is the final cycle, after that it
> won't
> be possible anymore to fix things like we can do now in the betachannel.
> After all, we now have 12 weeks for localizing instead of your proposed 9
> weeks.
> Adding 2 weeks for Aurora is a bit short if you have to do the localizing
> work
> crossing over several weeks.
> For me keeping up in Aurora in 2 weeks is a no-go, leaving with "only" 9
> weeks in the final stage
> this can lead to unfixed/unlocalized strings.

>From my perspective as a localizer working on Aurora I completely
agree with all the points raised by Wim.

Also keep in mind that we are just volunteers —and moreover, quite a
bit of localization teams are 1-person teams—, and currently having
the beta channel as a B plan comes very handy in case a localizer
can't contribute for some weeks due to life-related reasons (exams,
heavy workload, family obligations, vacation...).


Julen.

[Khaled Hosny]

The same here. I had to work on Beta few cycles already when I missed
Aurora deadline.

Regards,
Khaled

[Lukas Blakk]

As Alex pointed out in the original email there will be more time on Beta to continue doing localization post string-freeze and what we're really looking for feedback on is "Are you all concerned about significant Beta tester frustration if more strings are left unlocalized in the first beta than today?" i.e.: If we string freeze after 9 weeks when Nightly moves to Aurora to stabilize, you would then have 9 weeks in which to do localization before release.

Are there any concerns about this with regards to affecting our Beta testers who run localized builds?

Cheers,
Lukas

[chris hofmann]

On 11/24/13 10:16 AM, Lukas Blakk wrote:
> As Alex pointed out in the original email there will be more time on Beta to continue doing localization post string-freeze and what we're really looking for feedback on is "Are you all concerned about significant Beta tester frustration if more strings are left unlocalized in the first beta than today?" i.e.: If we string freeze after 9 weeks when Nightly moves to Aurora to stabilize, you would then have 9 weeks in which to do localization before release.
>
> Are there any concerns about this with regards to affecting our Beta testers who run localized builds?
>
> Cheers,
> Lukas

After talking with Alex a bit this week it might be worthwhile to
re-frame and expand the question(s) a bit, and also explain and get
feedback on some assumptions behind the questions.

Lilly once had a very interesting observation: If you tell me what the
assumptions are its much easier for me to give you feedback on your
conclusion or plan.

The first part of expanding the question might look something like this.

If strings aren't changing much (like many of the past releases) is is
ok for nightly and aurora to "fall though" to beta and just start
getting international feedback on for core gecko crash bugs that might
surface bugs in say Russian or other international sites like we have
seen in the past?

On reflection I'd venture to say this is probably ok, and something we
should be doing. The value of the feedback on core geck features would
be greater than the need to evaluate any of the changed strings that
remain untranslated. It makes logical sense that we won't see any user
frustration with not understanding, or being able to use, the product if
its mostly all translated, if any string changes that remain
untranslated are buried deep in mostly unused parts the product, or are
for things like devtools (that don't get translated at all for the most
localizations). But this is one point and assumption for localizers to
validate.

Jeff's recent "Aurora Reports" help to understand that this kind of
scenario is happening a lot in recent releases.
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/X_AO5-g8lE4 and
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/OXStvPnz2C0
show that basically 150 stings are changing each release with most of
the work in devtools.

Here is the second part of expanding the question and some more
assumptions to validate.

On the other hand if we do have a scenario where strings are changing a
lot in UI features that are visible and important to key mozilla's
initiatives, do users get frustrated, or do we loose the opportunity to
get feedback on those changes if they remain untranslated early in the
beta cycle? And would this kind of scenario cause us to loose
international beta testers if we continually do this?

Bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=932310 , and lots
of localization research, helps us to understand that the frustration
for shipping english strings in international builds, but does that kind
of frustration for encounting untranslated strings apply to beta testers?

One assumption is that beta testers might have a greater chance of being
multi-lingual. If that's the case they wouldn't potencially be blocked
when they encounter english strings. Instead they could just switch
over to understanding the new untranslated feature in English. Not
sure we have data on this kind of assumption but it would be interesting
to get anadotal opinions from localizers on what percentage of their
pre-release testing help is multi-lingual or speak English in addition
to their preferred language.

Another thought is that we might need to start operating in two modes.
One for release cycles that have essentially no string changes, and
other cycles that add new platforms or have lots of string changes since
the assumptions and needs might be widely different between the two.
Espcially if we shift to a development plan that emphasizes more UI
facing features, and away from the historical pattern of not changing
much UI.

Also we should look more closely at the assumption that we might have a
full 9 weeks in beta for translation work and follow up translation bug
fixes. The experience in bugs like
https://bugzilla.mozilla.org/show_bug.cgi?id
<https://bugzilla.mozilla.org/show_bug.cgi?id=902173>=902173
<https://bugzilla.mozilla.org/show_bug.cgi?id=902173> shows we should
really shut down changes on beta some time before the end of a beta
cycle to avoid regressions that we can't detect with community testing
and recover from in time for the shipping the release. If we account
for things like this the localization cycle is shorted a bit on the
release side of the beta cycle.

They would also be shortened a bit on the nightly side of the beta cycle
if the tree is unstable coming off the mozilla-central, we don't have
builds, or if we are spending days or weeks disabling features that we
don't intend to ship as we get ready for the first beta build and
update. At any rate the window looks more like 5-7 weeks of
localization time in beta not the full 9 weeks. That's an assumption
that's worth looking at an challenging by everyone if it doesn't sound
right.

In the new plan is it expected that we might get builds and updates to
beta testers every day, or in the first part of beta work? That's a
capability that allows localizers to get the most rapid feedback on
translation work on a aurora. It might help greatly if we planned for
that so localizers could land changes early in beta, get nightly builds,
then respond to any feedback before we need to taper changes to only
blockers, or close down the tree to prepare for shipping.

-chofmann

>
>
>
> On Nov 24, 2013, at 3:14 AM, Khaled Hosny <khale...@eglug.org> wrote:
>
>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>> Alex,
>>>
>>> 2013/11/24 Wim Benes <fryske...@gmail.com>:
>>>> Hi Alex,
>>>>
>>>> I can't say I feel comfortable with this cycle right away.
>>>> Although the cycle becomes 9 weeks, it is the final cycle, after that it
>>>> won't
>>>> be possible anymore to fix things like we can do now in the betachannel.
>>>> After all, we now have 12 weeks for localizing instead of your proposed 9
>>>> weeks.
>>>> Adding 2 weeks for Aurora is a bit short if you have to do the localizing
>>>> work
>>>> crossing over several weeks.
>>>> For me keeping up in Aurora in 2 weeks is a no-go, leaving with "only" 9
>>>> weeks in the final stage
>>>> this can lead to unfixed/unlocalized strings.
>>> From my perspective as a localizer working on Aurora I completely
>>> agree with all the points raised by Wim.
>>>

>>> Also keep in mind that we are just volunteers �and moreover, quite a
>>> bit of localization teams are 1-person teams�, and currently having

>>> the beta channel as a B plan comes very handy in case a localizer
>>> can't contribute for some weeks due to life-related reasons (exams,
>>> heavy workload, family obligations, vacation...).
>> The same here. I had to work on Beta few cycles already when I missed
>> Aurora deadline.
>>
>> Regards,
>> Khaled

[Francesco Lodolo [:flod]]

> One assumption is that beta testers might have a greater chance of being
> multi-lingual. If that's the case they wouldn't potencially be blocked
> when they encounter english strings. Instead they could just switch over
> to understanding the new untranslated feature in English. Not sure we
> have data on this kind of assumption but it would be interesting to get
> anadotal opinions from localizers on what percentage of their pre-release
> testing help is multi-lingual or speak English in addition to their
> preferred language.
>

In my experience people with multi-lingual skills just switch directly to
the English version.
I myself always use Linux in English, because the localization is so
fragmented and low quality for some softwares that I can't really digest it
(and time to fix broken things, like I did in the past, is just not enough).

One starting point could be to compare the ratio between nightly, aurora,
beta and release users between English and other sample locales. My guess
is that this numbers will be different for en-US.

Another point: based on the requests I receive from the contribute page to
do beta testing (https://www.mozilla.org/contribute), there are two
conclusions that I can draw:
1. We are doing a really bad job in publicizing non release channels
(people ask to get access to beta products, like we were Microsoft or
something).
2. Based on the level of Italian of most requests, I doubt these people
have multi-lingual skills at all.

Francesco

[Lukas Blakk]

On Nov 24, 2013, at 4:49 PM, chris hofmann <chof...@meer.net> wrote:

> Bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=932310 , and lots of localization research, helps us to understand that the frustration for shipping english strings in international builds, but does that kind of frustration for encounting untranslated strings apply to beta testers?
>

I don't see the above example as a relevant comparison. Taking the l10n changesets from 17esr and using them in 24esr (8 whole versions later) would accumulate hundreds of missing string changes and have a significant impact. That's in no way similar to what we're looking at on a per-beta basis where you've confirmed we currently see about 150 string changes per release, largely in devtools these days. We've been discussing pulling back major feature work UI to be something that has to have approval to land in Nightly (ie: string complete) so that while it's on Nightly it can be localized without much churn. I think that's a fair approach to the occasions where a release might break from the pattern above of mostly behind-the-scenes changes. So when we talk about the frustration of beta testers in encountering untranslated strings, let's really keep that in a realistic scope.

> Another thought is that we might need to start operating in two modes. One for release cycles that have essentially no string changes, and other cycles that add new platforms or have lots of string changes since the assumptions and needs might be widely different between the two. Espcially if we shift to a development plan that emphasizes more UI facing features, and away from the historical pattern of not changing much UI.
>

See above re: getting a complete string set for a UX feature before it lands to trunk

> Also we should look more closely at the assumption that we might have a full 9 weeks in beta for translation work and follow up translation bug fixes. The experience in bugs likehttps://bugzilla.mozilla.org/show_bug.cgi?id=902173 shows we should really shut down changes on beta some time before the end of a beta cycle to avoid regressions that we can't detect with community testing and recover from in time for the shipping the release. If we account for things like this the localization cycle is shorted a bit on the release side of the beta cycle.
>

Again I think this is a poor example since it was quite the outlier. We typically start to take less on beta, leaving the last two betas for primarily backouts and sec-critical landings so you're right to call out that it's not a full 9 weeks of landings. However we could look into putting hooks on l10n repos to check for any changes to strings that rarely change (core strings) such as the main user facing menus and protect ourselves a bit from accidents like what happened in bug 902173. Considering we're talking about adding localization time to Nightly as well as while on Aurora and then for at least 7 full weeks while on Beta there's still an overall increase in localization time per release.

> In the new plan is it expected that we might get builds and updates to beta testers every day, or in the first part of beta work? That's a capability that allows localizers to get the most rapid feedback on translation work on a aurora. It might help greatly if we planned for that so localizers could land changes early in beta, get nightly builds, then respond to any feedback before we need to taper changes to only blockers, or close down the tree to prepare for shipping.

We are definitely continuing to work towards a daily beta model similar to Nightly and Aurora are now. That will be a bonus once in place but currently we do push out 2 betas per week and with the time on Nightly/Aurora and two betas per week it should still be possible to be getting builds to testers often enough to verify fixes. This new process has certainly helped QA verify more bugs in the beta timeframe so I suspect that can be assumed for l10n verifications as well, and then improved upon going forward as teams involved pull together the last bit of work needed for smooth, daily releases.

-Lukas

[chris hofmann]

On 11/25/13 8:41 AM, Lukas Blakk wrote:
>
> On Nov 24, 2013, at 4:49 PM, chris hofmann <chof...@meer.net

> <mailto:chof...@meer.net>> wrote:
>
>> Bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=932310, and

>> lots of localization research, helps us to understand that the
>> frustration for shipping english strings in international builds, but
>> does that kind of frustration for encounting untranslated strings
>> apply to beta testers?
>>
>
> I don't see the above example as a relevant comparison. Taking the
> l10n changesets from 17esr and using them in 24esr (8 whole versions
> later) would accumulate hundreds of missing string changes and have a
> significant impact. That's in no way similar to what we're looking at
> on a per-beta basis where you've confirmed we currently see about 150
> string changes per release, largely in devtools these days. We've
> been discussing pulling back major feature work UI to be something
> that has to have approval to land in Nightly (ie: string complete) so
> that while it's on Nightly it can be localized without much churn. I
> think that's a fair approach to the occasions where a release might
> break from the pattern above of mostly behind-the-scenes changes. So
> when we talk about the frustration of beta testers in encountering
> untranslated strings, let's really keep that in a realistic scope.

I'm not talking about how bug 902173 happened; I'm talking only about
its effects, and what the user response was.

You asked the question about what the response is when users encounter
untranslated strings and that is one data point. Its a data point that
reflects the accumulation of a low volume of string changes over 7
release cycles. If we did one or two major UI facing features in a
single release we might be in the ball park of the same number of
important changing in one cycle.

Sure we need to look at historical rates of string changes which are low
since there hasn't been UI work going on, but i think its folly only to
design a release system for that. If/when we change our behavior and
start doing more UI work to surface new features there will be more
strings landed and in need of translation. It doesn't matter if these
strings bunch up on a few UI branches, central, aurora or beta, they
will need to be dealt with by localizers and localization testers and
they will be in higher volume.

So lets at least think about a mode that we can shift into that we can
handle this scenario, to help reduce the chaos and add adequate time for
translation work before we ship those builds to international testers
and users.

>
>> Another thought is that we might need to start operating in two
>> modes. One for release cycles that have essentially no string
>> changes, and other cycles that add new platforms or have lots of
>> string changes since the assumptions and needs might be widely
>> different between the two. Espcially if we shift to a development
>> plan that emphasizes more UI facing features, and away from the
>> historical pattern of not changing much UI.
>>
>
> See above re: getting a complete string set for a UX feature before it
> lands to trunk
>
>> Also we should look more closely at the assumption that we might have
>> a full 9 weeks in beta for translation work and follow up translation
>> bug fixes. The experience in bugs

>> likehttps://bugzilla.mozilla.org/show_bug.cgi?id

>> <https://bugzilla.mozilla.org/show_bug.cgi?id=902173>=902173
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=902173> showsweshould

>> really shut down changes on beta some time before the end of a beta
>> cycle to avoid regressions that we can't detect with community
>> testing and recover from in time for the shipping the release. If we
>> account for things like this the localization cycle is shorted a bit
>> on the release side of the beta cycle.
>>
>
> Again I think this is a poor example since it was quite the outlier.
> We typically start to take less on beta, leaving the last two betas
> for primarily backouts and sec-critical landings so you're right to
> call out that it's not a full 9 weeks of landings. However we could
> look into putting hooks on l10n repos to check for any changes to
> strings that rarely change (core strings) such as the main user facing
> menus and protect ourselves a bit from accidents like what happened in
> bug 902173. Considering we're talking about adding localization time
> to Nightly as well as while on Aurora and then for at least 7 full
> weeks while on Beta there's still an overall increase in localization
> time per release.

Here I think you are making an assumption that *all* localization teams
can work effectively and efficiently across multiple repositories.
That's not the case now. Axel and I have a post coming that explains
why and sheds some light on the the tools we have in place now, their
limitations, and why they are designed that way, and who uses them.

This what was behind Axel's statement on the dev.planning thread when he
said "my head's spinning at what we might do here..."

Certainly some teams work directly off the HG repositories and translate
using text editors. They can work of any, or multiple repositories and
do so when asked. Its definitely not a productive or efficient mode
for any of our developers to to work in, and I don't think its advisable
for us to design a system where every localization team needs to work
across 2 or more repositories to get the time they need to do their work.

About 40% of our localization teams use locamotion and other tools that
connect only to a single repository. To bring these localization teams
along into the new release cycle plans we need to construct a system
where most, if not all the localization work is focused on a single
repository, at least for the near term.

Again, more on this soon. The post should help layout the options and
trade offs on which repository might be the best one to connect to, but
for the sake of argument lets be thinking of ways where we can
concentrate localization on a single repository, or at least as few as
possible, and only in extreme emergencies ask teams to work across
multiple repositories and land blocker fixes. That's basically what we
ask of, and have set up for, all of our development teams.

>
>> In the new plan is it expected that we might get builds and updates
>> to beta testers every day, or in the first part of beta work? That's
>> a capability that allows localizers to get the most rapid feedback on
>> translation work on a aurora. It might help greatly if we planned
>> for that so localizers could land changes early in beta, get nightly
>> builds, then respond to any feedback before we need to taper changes
>> to only blockers, or close down the tree to prepare for shipping.
>
> We are definitely continuing to work towards a daily beta model
> similar to Nightly and Aurora are now. That will be a bonus once in place

is there a bug to track progress on this?

[Lukas Blakk]

On Nov 25, 2013, at 9:28 AM, chris hofmann <chof...@meer.net> wrote:

> is there a bug to track progress on this?

https://bugzilla.mozilla.org/show_bug.cgi?id=755978

[Alex Keybl]

We're going to consider this topic as closed at the end of this week - please provide feedback prior. As of right now, we're under the impression that a few more unlocalized strings for l10n beta testers would not ultimately be very disruptive.

-Alex

On Nov 24, 2013, at 1:16 PM, Lukas Blakk <lsb...@mozilla.com> wrote:

> As Alex pointed out in the original email there will be more time on Beta to continue doing localization post string-freeze and what we're really looking for feedback on is "Are you all concerned about significant Beta tester frustration if more strings are left unlocalized in the first beta than today?" i.e.: If we string freeze after 9 weeks when Nightly moves to Aurora to stabilize, you would then have 9 weeks in which to do localization before release.
>
> Are there any concerns about this with regards to affecting our Beta testers who run localized builds?
>
> Cheers,
> Lukas
>
>
>

> On Nov 24, 2013, at 3:14 AM, Khaled Hosny <khale...@eglug.org> wrote:
>
>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>> Alex,
>>>
>>> 2013/11/24 Wim Benes <fryske...@gmail.com>:
>>>> Hi Alex,
>>>>
>>>> I can't say I feel comfortable with this cycle right away.
>>>> Although the cycle becomes 9 weeks, it is the final cycle, after that it
>>>> won't
>>>> be possible anymore to fix things like we can do now in the betachannel.
>>>> After all, we now have 12 weeks for localizing instead of your proposed 9
>>>> weeks.
>>>> Adding 2 weeks for Aurora is a bit short if you have to do the localizing
>>>> work
>>>> crossing over several weeks.
>>>> For me keeping up in Aurora in 2 weeks is a no-go, leaving with "only" 9
>>>> weeks in the final stage
>>>> this can lead to unfixed/unlocalized strings.
>>>
>>> From my perspective as a localizer working on Aurora I completely
>>> agree with all the points raised by Wim.
>>>

>>> Also keep in mind that we are just volunteers —and moreover, quite a
>>> bit of localization teams are 1-person teams—, and currently having

[Fjoerfoks]

Hi Alex,

2013/11/27 Alex Keybl <ake...@mozilla.com>

> We're going to consider this topic as closed at the end of this week -
> please provide feedback prior. As of right now, we're under the impression
> that a few more unlocalized strings for l10n beta testers would not
> ultimately be very disruptive.
>

I agree that unlocalized strings won't be disruptive, since users
(probably) know they are on bèta.
On the other hand though, as Chris also pointed out, if a localizer is
swamped with other responsibilities,
you might end up with a final version with unlocalized strings too.
In my opinion the timeframe for localizing is still getting smaller and
less plan-able, also taking into account
like holiday-seasons and working around them. For my local this won't have
a great impact and maybe also for
other small locals, but for Dutch I also know there's 1 and a half
localizer, problems may arize.

The argument that "it's only 150 lines" per release sounds patronizing,
we've had more stuff to do when e.g. Metro came in, like 300.
Jeff Beaty might back me up on this, but I believe Firefox is decreasing in
number of locals sadly enough.

I'd still opt for a check-out point in beta if you're going through with
this, probably 2 weeks before release.

Kind regards,
Wim

[Axel Hecht]

I think there are overlapping variants of "silence" here.

There's probably some of "silence is consent".

Looking at common communication patterns in this group, though, having
interaction with 5 members of the community on a thread is actually
pretty good. Very often in this group, silence actually means that you
didn't reach people. I'm afraid that this thread is pretty
representative on our ability to reach people.

To your point, we won't know what users think until they get the thing.
How will we find out if they care, and what can we do if they actually care?

Axel

>>>> Also keep in mind that we are just volunteers �and moreover, quite a
>>>> bit of localization teams are 1-person teams�, and currently having

[Théo Chevalier]

Hi,

About how the user will react with en-US in Beta, FWIW for French
locale, we already receive negative feedback (not a lot, but still) on
our community forums when there are English strings in Thunderbird Beta
because of the lack of sign-off. Our Firefox Desktop users are used to
use a fully translated Beta (and Aurora, too), so it might be an issue.
But as Axel said, we can't be sure until we do some tests.
Moreover users might think there is less care about l10n.


What is changing for teams working on central? Do we still have the same
6 weeks to get Nightly localized?

What about the strings moving quickly to Beta, is a sign-off still
needed to get them exposed to the user? If yes, it's an issue to get
quick feedback on those new strings.

Would it be still possible, like it is today, to have all Beta fully
localized if Nightly is up-to-date? It seems not because early Aurora
cycle is not string frozen, so we can't ask for a sign-off and get the
strings just landed on Aurora exposed to Beta users.

Th�o


Le 27/11/2013 17:03, Axel Hecht a �crit :

[Robert Kaiser]

Théo Chevalier schrieb:

> What is changing for teams working on central? Do we still have the same
> 6 weeks to get Nightly localized?

No, it's 9 weeks of new code coming in on Nightly, so 50% more, but the
rate of change on Nightly will be the same.

What will change is that there will be 50% more string change on Nightly
(9 weeks instead of 6 weeks) coming to Beta within 1-2 weeks instead of
6 weeks, so the gap between the last new strings coming to Nightly and
the first Beta users being annoyed by strings in a weird language (i.e.
English, which AFAIK is offensive to some French users, possibly also
some people in other countries) is going to be pretty short if/when this
model is adopted.

Robert Kaiser

[Francesco Lodolo [:flod]]

Il 29/11/13 01:15, Th�o Chevalier ha scritto:

> Moreover users might think there is less care about l10n.

Agreed. It would look sloppy, like it did for the ESR sign-off problem.

> What is changing for teams working on central? Do we still have the same
> 6 weeks to get Nightly localized?

From what I understand (TBH I'm not sure I'm getting it completely right):

1. mozilla-central will remain the same hot mess that it's today, the
difference is that it will be merged to Aurora every 2 weeks.
2. mozilla-aurora is supposed to stay string frozen (the only string
changes will be those coming from the merge from central)
3. mozilla-aurora and mozilla-beta will get new strings every 2 weeks.

So, basically, if you take one week of holiday at least Aurora will
likely get English strings. Not so great, isn't it?

And then you need to fix Aurora and merge back the missing strings to
Central, and if there's one thing I learned in the last 10 days, is that
VCS are good to store localizations, but merges are a complete mess in
this context.

About point 1, I don't see how we can stay on a 2 week cycles when
flawed strings (low quality English, bad i18n, strings changed without
new IDs) keep landing on Nightly without anyone noticing during the
review process. Aurora is supposed to be a l10n friendly place, were
only nice strings arrive.

The real problem is that most of our localization teams don't work on
l10n-central. Look at this page and order it by missing strings
https://l10n.mozilla.org/shipping/dashboard?tree=fx_central

We're on week 5 of this cycle, and based on the numbers I'd say there
are only 11 locales who worked on l10n-central. I count 91 locales in
Aurora's shipped-locales
http://hg.mozilla.org/releases/mozilla-aurora/file/566926400786/browser/locales/shipped-locales

That's 12% of our localization teams. For the other 88%, in case they
care to ship a fully localized build, it doesn't turn to a 9 weeks
cycle, but a 2 weeks cycle.

Francesco

[Besnik Bleta]

Më 11/29/2013 09:35 AM, Francesco Lodolo [:flod] shkrojti:
> Il 29/11/13 01:15, Th�o Chevalier ha scritto:

>> Moreover users might think there is less care about l10n.

> Agreed. It would look sloppy, like it did for the ESR sign-off problem.

>> What is changing for teams working on central? Do we still have the same
>> 6 weeks to get Nightly localized?

> From what I understand (TBH I'm not sure I'm getting it completely
> right):
>
> 1. mozilla-central will remain the same hot mess that it's today, the
> difference is that it will be merged to Aurora every 2 weeks.
> 2. mozilla-aurora is supposed to stay string frozen (the only string
> changes will be those coming from the merge from central)
> 3. mozilla-aurora and mozilla-beta will get new strings every 2 weeks.
>
> So, basically, if you take one week of holiday at least Aurora will
> likely get English strings. Not so great, isn't it?
>
> And then you need to fix Aurora and merge back the missing strings to
> Central, and if there's one thing I learned in the last 10 days, is
> that VCS are good to store localizations, but merges are a complete
> mess in this context.
>
> About point 1, I don't see how we can stay on a 2 week cycles when
> flawed strings (low quality English, bad i18n, strings changed without
> new IDs) keep landing on Nightly without anyone noticing during the
> review process. Aurora is supposed to be a l10n friendly place, were
> only nice strings arrive.
>
> The real problem is that most of our localization teams don't work on
> l10n-central.

Perhaps because back then we were told that the most convenient channel
to work on was Aurora.
I remember asking and being pointed to Aurora, rather than l10n-central.

Cheers
Besnik

> Look at this page and order it by missing strings
> https://l10n.mozilla.org/shipping/dashboard?tree=fx_central
>
> We're on week 5 of this cycle, and based on the numbers I'd say there
> are only 11 locales who worked on l10n-central. I count 91 locales in
> Aurora's shipped-locales
> http://hg.mozilla.org/releases/mozilla-aurora/file/566926400786/browser/locales/shipped-locales
>
>
> That's 12% of our localization teams. For the other 88%, in case they
> care to ship a fully localized build, it doesn't turn to a 9 weeks
> cycle, but a 2 weeks cycle.
>
> Francesco

[Akerbeltz.org]

Agreed, I was pointed at Aurora too.

This is beginning to feel a bit like the latter days of the Google in Your
Language project when Google stopped caring about l10n for everyone and began
seeing it as more of a problem than an integral feature and selling point...

Michael

[Francesco Lodolo [:flod]]

Il 29/11/13 08:53, Besnik Bleta ha scritto:

> Perhaps because back then we were told that the most convenient
> channel to work on was Aurora.
> I remember asking and being pointed to Aurora, rather than l10n-central.

That's still absolutely true.

Unless you want to localize on a daily basis, take care of merging your
content between mozilla-aurora and l10n-central on merge day, and often
localize the same string twice because what landed the first time isn't
as good as it should.

I respect localizers who work on l10n-central (I am), but I would never
suggest it, in particular considering the amount of other stuff there's
to localize (mozilla.org, Firefox OS with its load of marketing stuff
and websites, web projects).

Francesco

[Julen Ruiz Aizpuru]

2013/11/27 Alex Keybl <ake...@mozilla.com>:

> We're going to consider this topic as closed at the end of this week - please provide feedback prior. As of right now, we're under the impression that a few more unlocalized strings for l10n beta testers would not ultimately be very disruptive.

That depends on:

1) The visibility and relevance of those few unlocalized strings you mention
2) The locale

For the first point, messages displayed in edge cases wouldn't
probably hurt. Highly visible strings would definitely hurt.

For the second point, it will be less disruptive for small locales who
have few users on dev channels (at least that's our case), but other
locales will suffer from a higher impact as Théo has already pointed
out.
Although this won't happen, I wonder if you have thought how
disruptive would be to have strings from a foreign language ab-CD in
an en-US Beta build.

Apart from this, and taking into account the current Beta version of
Firefox has a certain meaning for developers and users, by altering
the concept of what's being shipped you're mangling its meaning,
therefore if you proceed with this proposal I'm not sure if you still
want to call this Beta or something else.

All in all, I don't think this proposal addresses any problems I have
as a localizer, but it reduces the amount of time I would have to work
and adds the burden of a changing process.

Julen.

[Axel Hecht]

I'd not be too focused on the current nightly numbers, we're just behind
on stopping builds for teams that don't work on nightly.

For people currently working on Nightly, I don't expect a lot of change.

For people that are currently working on Aurora, I'd expect them to be
on Beta.

Axel

[chris hofmann]

Alex, when you do close of the discussion can you also summarize what
you heard and what information you are using to arrive at your
conclusion. That will help us all to understand the assumptions you are
working from.

I've round up another data point to consider on this thread. It might
also help localization teams understand where their pre-release testers
are now, allows to probe a bit on the patterns we might see in the
data, and other things we might all work together to make sure we get
more international testing on localized builds.

Pike grabbed a sample of data on active users for a week on each of the
development channels and averaged the data for the whole week. This is
just a single sample so we need to refine the technique and execute
regularly to see of the sample we took is reflective of the general use
patterns. It looks like it might be a bit more heavily skewed toward a
weekend/holiday kind of use pattern. Anyway here is what pct. of user
looks like for the top 20 most popular locales over each of the channels.





% of users


*All* on release on
beta on
aurora on
nightly
*en-US* 44.09% 76.00% 53.68% 93.56%
*de* 9.52% 2.36% 5.73% 0.22%
*fr* 6.30% 0.28% 7.77% 0.38%
*es-ES* 6.26% 2.03% 4.55% 0.33%
*pt-BR* 5.46% 5.92% 3.55% 0.18%
*ru* 4.65% 1.94% 4.36% 2.70%
*pl* 3.57% 1.00% 2.70% 0.17%
*it* 1.97% 0.27% 0.99% 0.04%
*en-GB* 1.90% 0.69% 2.65% 0.07%
*ja* 1.65% 0.27% 0.80% 0.19%
*tr* 1.12% 0.80% 0.12% 0.01%
*es-MX* 1.06% 0.38% 1.50% 0.04%
*hu* 0.97% 0.18% 0.47% 0.02%
*vi* 0.91% 0.38% 0.27% 0.01%
*ar* 0.86% 1.03% 0 0.00%
*nl* 0.83% 0.20% 0.51% 0.01%
*cs* 0.76% 0.14% 0.37% 0.02%
*zh-TW* 0.75% 0.30% 0.28% 0.10%


One of the first things to look at is the 44% of users on en-US.
That's actually higher than previous samples I've looked at indicating
there might be some problems in the data sample or there might
be a relative decline in international users.

Second interesting thing is that our beta population isn't reflective
of the release channel. That's something we should all be working
on and designing programs that will get us to a higher pct. of international
beta testing and pre-release testing in general.

I think there are two basic reasons why users are attracted and stay
on a particular channel. First is that they learn about and perceive
the channel will useful to them. Engagement with users can help on this.
The second is that the software is actually ready for them to use.

The data above helps us to understand when we might be meeting both
standards.

For example the French team localizes on nightly within hours of each
string landing, so when we get to aurora the software is ready.
This sample of data might also show that French speaking users
might also have a stronger relative preference for aurora over beta
than other locales. In real terms there were about 1000 users on both
beta and aurora channels, and about 500 on nightly. This was a pretty
interesting skew that we don't see in many of the other locales.

Another interesting example might be pt-BR. Jefferson usually localizes
on aurora and the software is ready to go on beta. Brazillian users
also seem to have a stronger relative desire to be on beta than some
of the other locales in the sample.

Anyway, more food for thought, and the start of some analysis
that I hope will lead us to serving international users in better ways
by getting localization work done earlier in cycles, and building
a larger testing audience around the world. This kind of analysis
and reporting might help us to measure progress against those
two goals. If folks think it does help I'll file a bug and try to get
metrics
to automate the report.

-chofmann

[chris hofmann]

The formating on that table didn't come though to good so I put a better
table at
http://people.mozilla.org/~chofmann/l10n/international-channel-use.html

-chofmann

[Théo Chevalier]

On 11/29/13 10:00 AM, chris hofmann wrote:

>>
>> For example the French team localizes on nightly within hours of each
>> string landing, so when we get to aurora the software is ready.
>> This sample of data might also show that French speaking users
>> might also have a stronger relative preference for aurora over beta
>> than other locales. In real terms there were about 1000 users on both
>> beta and aurora channels, and about 500 on nightly. This was a pretty
>> interesting skew that we don't see in many of the other locales.

Wow, I thought we had a lot more users on Beta than on Aurora, that's
totally a surprise to me.
Do we really have ~20 million users on release and only ~2500 on other
channels?
Really useful data to plan our work/sign-off.

And it confirms the importance (at least for French) to get fully
localized builds on Aurora. And if we switch to the new workflow, I
won't be able to clean the dashboard each two weeks to get Aurora
localized. (And as pointed by Flod, additional merges will be needed on
our side, for initial translation and QA. That's a pain.)

>> Anyway, more food for thought, and the start of some analysis
>> that I hope will lead us to serving international users in better ways
>> by getting localization work done earlier in cycles, and building
>> a larger testing audience around the world. This kind of analysis
>> and reporting might help us to measure progress against those
>> two goals. If folks think it does help I'll file a bug and try to get
>> metrics
>> to automate the report.

It could be interesting to keep an eye on that, yes!


Th�o

[chris hofmann]

On 11/30/13 5:27 AM, Th�o Chevalier wrote:
> On 11/29/13 10:00 AM, chris hofmann wrote:
>
>>> For example the French team localizes on nightly within hours of each
>>> string landing, so when we get to aurora the software is ready.
>>> This sample of data might also show that French speaking users
>>> might also have a stronger relative preference for aurora over beta
>>> than other locales. In real terms there were about 1000 users on both
>>> beta and aurora channels, and about 500 on nightly. This was a pretty
>>> interesting skew that we don't see in many of the other locales.
> Wow, I thought we had a lot more users on Beta than on Aurora, that's
> totally a surprise to me.
> Do we really have ~20 million users on release and only ~2500 on other
> channels?

using the standard multiplier yeah, numbers might look something like that.

I'm not sure the multiplier works so well on pre-release channels where
they don't have so many users, and we get a population of users are
closer to using their browser everyday.

-chofmann

> Really useful data to plan our work/sign-off.
>
> And it confirms the importance (at least for French) to get fully
> localized builds on Aurora. And if we switch to the new workflow, I
> won't be able to clean the dashboard each two weeks to get Aurora
> localized. (And as pointed by Flod, additional merges will be needed on
> our side, for initial translation and QA. That's a pain.)
>
>>> Anyway, more food for thought, and the start of some analysis
>>> that I hope will lead us to serving international users in better ways
>>> by getting localization work done earlier in cycles, and building
>>> a larger testing audience around the world. This kind of analysis
>>> and reporting might help us to measure progress against those
>>> two goals. If folks think it does help I'll file a bug and try to get
>>> metrics
>>> to automate the report.
> It could be interesting to keep an eye on that, yes!
>
>
> Th�o

[Alex Keybl]

> All in all, I don't think this proposal addresses any problems I have
> as a localizer,

Working on l10n process (with engineering buy-in) to help you all localize as early as Nightly is high on the list of desktop improvements Lukas and I are planning to work on in 2014. It's true that this proposal is not l10n focused, but it's also meant to have no negative impact to localizers or release l10n users.

> but it reduces the amount of time I would have to work
> and adds the burden of a changing process.

This reduces the amount of time you have to work prior to beta, but actually makes release dates a little less frequent (deadlines futher apart). Would be great to have clarification on your thinking here.

> Apart from this, and taking into account the current Beta version of
> Firefox has a certain meaning for developers and users, by altering
> the concept of what's being shipped you're mangling its meaning,
> therefore if you proceed with this proposal I'm not sure if you still
> want to call this Beta or something else.

This came up in conversations with others as well. Beta is meant to still be a stabilizing work in progress, with the purpose of giving Release users a better experience. It's not a final product yet, and we don't need to treat it as such. The Couple Train proposal will improve the Release product overall.

-Alex

On Nov 29, 2013, at 3:29 AM, Julen Ruiz Aizpuru <jul...@gmail.com> wrote:

> 2013/11/27 Alex Keybl <ake...@mozilla.com>:

>> We're going to consider this topic as closed at the end of this week - please provide feedback prior. As of right now, we're under the impression that a few more unlocalized strings for l10n beta testers would not ultimately be very disruptive.
>

[Julen Ruiz Aizpuru]

2013/12/2 Alex Keybl <ake...@mozilla.com>:

>
>> but it reduces the amount of time I would have to work
>> and adds the burden of a changing process.
>
> This reduces the amount of time you have to work prior to beta, but actually makes release dates a little less frequent (deadlines futher apart). Would be great to have clarification on your thinking here.

As a localizer I want to localize Firefox version X.

If I understood your proposal correctly, working in Aurora will become
a no-go, since new code/strings will come in every two weeks,
therefore folks will need to focus on Beta and be left with a 9 weeks
cycle. Nowadays we have a 6 weeks cycle in Aurora + a 6 weeks cycle in
Beta: the focus is on Aurora, and Beta receives fixes or late work,
making it 12 weeks in total.

Julen.

[Fjoerfoks]

Another thing to keep in mind is that most localizers went away from
central,
because of the frequent changes and the possibility of localizing stuff
which is
being backed out later on. This indeed lowered the workload for localizers.
Getting localizers to work on central again doesn't seem obvious to me.

Wim


2013/12/3 Julen Ruiz Aizpuru <jul...@gmail.com>

[Ricardo Palomares Martí­nez]

El 03/12/13 09:33, Julen Ruiz Aizpuru escribió:

> If I understood your proposal correctly, working in Aurora will become
> a no-go, since new code/strings will come in every two weeks,
> therefore folks will need to focus on Beta and be left with a 9 weeks
> cycle. Nowadays we have a 6 weeks cycle in Aurora + a 6 weeks cycle in
> Beta: the focus is on Aurora, and Beta receives fixes or late work,
> making it 12 weeks in total.

IIUC, Nightly and Beta will use 9-week cycles, whereas Aurora would
use 2-week cycles. So the cycle workflow would be:

- Nightly starts a cycle in day 0.

- Nightly ends cycle in day 0 + 9 weeks. It gets transported to
Aurora. A new cycle starts in Nightly.
- Aurora starts cycle in day 0 + 9 weeks.

- Aurora ends cycle in day 0 + 11 weeks. It gets transported to Beta.
*No new cycle in Aurora (no new code+strings arrived from Nightly).*
- Beta starts cycle in day 0 + 11 weeks.

- Nightly ends cycle in day 0 + 18 weeks. It gets transported to
Aurora. A new cycle starts in Nightly.
- Aurora starts cycle in day 0 + 18 weeks. New code+strings arrived.

- Beta ends cycle in day 0 + 20 weeks. New version at release channel.
- Aurora ends cycle in day 0 + 20 weeks. It gets transported to Beta.
*No new cycle in Aurora (no new code+strings arrived from Nightly).
- Beta starts cycle in day 0 + 20 weeks.


If it is really this way, then not only it is confusing, it also
shortens *a lot* the time localizers would have available to put
Aurora in shape so it is ready for Beta shift. And, as the Nightly
cycle is 50% longer, we could expect a 50% more new strings in each
Aurora cycle.

Moving localizers to Nightly is not as painless as Alex suggests. I
work in Nightly and it is relatively easy than en-US strings are not
in the best shape when they first land, so they must be updated (i.e.,
deleted and re-added with different entity/key names), so for those
used to Aurora the workload would be bigger.

If the change is really needed for better development, go ahead, but
don't think, or make us think, that it will be better or neutral for
localization.

--
Ricardo Palomares (RickieES)
http://www.mozilla-hispano.org/
http://www.proyectonave.es/
https://diasp.eu/u/rickiees

[Adrian Kalla]

Dnia 12/02/2013 05:34 PM, Użytkownik Alex Keybl napisał:
>> but it reduces the amount of time I would have to work
>> and adds the burden of a changing process.
>
> This reduces the amount of time you have to work prior to beta, but actually makes release dates a little less frequent (deadlines futher apart). Would be great to have clarification on your thinking here.

It doesn't reduce the work time at all. You forget to add the painful
and time consuming merges, that will now happen every two weeks.
And it will cause much confusion compared to the current "merge day on
the same day for every branch and every six weeks". I bet some L10n
teams will miss deadlines because of this.

>> Apart from this, and taking into account the current Beta version of
>> Firefox has a certain meaning for developers and users, by altering
>> the concept of what's being shipped you're mangling its meaning,
>> therefore if you proceed with this proposal I'm not sure if you still
>> want to call this Beta or something else.
>
> This came up in conversations with others as well. Beta is meant to still be a stabilizing work in progress, with the purpose of giving Release users a better experience. It's not a final product yet, and we don't need to treat it as such. The Couple Train proposal will improve the Release product overall.

With this proposal, Beta would become "nightly" in terms of L10n
quality. Builds with completely untested L10n changes and no
"stabilization" time. And with many untranslated strings. Think this is
not a problem? Then think of a en-US Firefox showing some messages in
e.g. Chinese - because for someone not knowing English, it feels exactly
like that.

Also, as was mentioned here before, most users knowing English use en-US
builds. Users not on the release channels of L10n builds want - and for
Polish expect - to see a full localization on aurora and beta. With this
proposal, there will be builds without full localization even on beta,
which is imho unacceptable.

Adrian

[Adrian Kalla]

Dnia 12/04/2013 10:20 PM, Użytkownik Ricardo Palomares Martí­nez napisał:

> If it is really this way, then not only it is confusing, it also
> shortens *a lot* the time localizers would have available to put
> Aurora in shape so it is ready for Beta shift. And, as the Nightly
> cycle is 50% longer, we could expect a 50% more new strings in each
> Aurora cycle.

Agreed.

> Moving localizers to Nightly is not as painless as Alex suggests. I
> work in Nightly and it is relatively easy than en-US strings are not
> in the best shape when they first land, so they must be updated (i.e.,
> deleted and re-added with different entity/key names), so for those
> used to Aurora the workload would be bigger.

Exactly. That's the reason for me, even though I work mostly on nightly,
to wait for aurora if I see that it is much happening on nightly. There
is nothing more frustrating, if you localize something on nightly and
then the strings get backed out. That's why Aurora in it's current shape
makes so much sense for most locales: you have 12 weeks to prepare L10n
for a release - without a high risk of backed out strings like on nightly.

> If the change is really needed for better development, go ahead, but
> don't think, or make us think, that it will be better or neutral for
> localization.

Agreed. This change is definitely a step backwards for L10n. So please,
don't expect us thinking that it is not.

Adrian

[Adrian Kalla]

Dnia 11/27/2013 05:03 PM, Użytkownik Axel Hecht napisał:
> I think there are overlapping variants of "silence" here.
>
> There's probably some of "silence is consent".

> (...)

> Very often in this group, silence actually means that you
> didn't reach people.

Another possibility: you didn't give people enough time to speak out. We
are volunteers. I read this group when I have some free time - which
happens I didn't have for four weeks...

When such important decisions like this are being discussed, the people
which will be affected by them should be contacted directly, that there
is a important discussion happening. Afaik, Mozilla knows the E-Mail
addresses of most, if not all, localization teams, so this should be not
much of a hassle.

Adrian

[Adrian Kalla]

Dnia 12/14/2013 02:55 PM, Użytkownik Adrian Kalla napisał:
> Users not on the release channels of L10n builds want - and for
> Polish expect - to see a full localization on aurora and beta.

Forgot to add on what I did base that expectation: in the past we had
many angry posts or bug reports from users, that something was not
localized.

Adrian

[Kim Ludvigsen]

Alex Keybl wrote:
> In October, I proposed a modification to the current release model on dev.planning (see [1]).
>
> [1] https://groups.google.com/forum/#!msg/mozilla.dev.planning/x17zOBsQMsY/5lYn2iZPEF4J

Is this already in effect, or will it happen at a later
date? It would be nice to know if we should move to beta now
or when to do so.

I don't think we (the Danish team) can stay on aurora - at
least not with Firefox - with a two week cycle.

If we should choose to stay on aurora with some of the minor
products: Would that mean that we would have to sign off
every two weeks? If so, I think we will move all the
products to beta.

--
Kim Ludvigsen

[Axel Hecht]

Nothing has changed so far, and thanks for your feedback.

Axel