Coupled Train Model, Localizers, and Localization Testers

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Coupled Train Model, Localizers, and Localization Testers

Alexander 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

文少华
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


On Thu, Nov 21, 2013 at 9:21 AM, Alex Keybl <[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-l10n
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Alexander 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

On Nov 21, 2013, at 1:17 AM, 文少华 <[hidden email]> wrote:

> 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
>
>
> On Thu, Nov 21, 2013 at 9:21 AM, Alex Keybl <[hidden email]> wrote:
> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-l10n
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

文少华
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


On Fri, Nov 22, 2013 at 8:50 AM, Alex Keybl <[hidden email]> wrote:

> 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
>
> On Nov 21, 2013, at 1:17 AM, 文少华 <[hidden email]> wrote:
>
> 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
>
>
> On Thu, Nov 21, 2013 at 9:21 AM, Alex Keybl <[hidden email]> wrote:
>
>> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-l10n
>>
>
>
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Alexander 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

On Nov 21, 2013, at 9:03 PM, 文少华 <[hidden email]> wrote:

> 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
>
>
> On Fri, Nov 22, 2013 at 8:50 AM, Alex Keybl <[hidden email]> wrote:
>> 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
>
> On Nov 21, 2013, at 1:17 AM, 文少华 <[hidden email]> wrote:
>
>> 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
>>
>>
>> On Thu, Nov 21, 2013 at 9:21 AM, Alex Keybl <[hidden email]> wrote:
>> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-l10n
>>
>
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Fjoerfoks
In reply to this post by Alexander Keybl
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
[hidden email]
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-l10n
> .
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Julen Ruiz Aizpuru
Alex,

2013/11/24 Wim Benes <[hidden email]>:

> 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.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Khaled Hosny-2
On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:

> Alex,
>
> 2013/11/24 Wim Benes <[hidden email]>:
> > 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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

lsblakk
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 <[hidden email]> wrote:

> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>> Alex,
>>
>> 2013/11/24 Wim Benes <[hidden email]>:
>>> 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

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Chris Hofmann-3
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 <[hidden email]> wrote:
>
>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>> Alex,
>>>
>>> 2013/11/24 Wim Benes <[hidden email]>:
>>>> 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
> _______________________________________________
> dev-l10n mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-l10n

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

lsblakk
In reply to this post by Chris Hofmann-3

On Nov 24, 2013, at 4:49 PM, chris hofmann <[hidden email]> 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

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Chris Hofmann-3
On 11/25/13 8:41 AM, Lukas Blakk wrote:

>
> On Nov 24, 2013, at 4:49 PM, chris hofmann <[hidden email]
> <mailto:[hidden email]>> 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?

> 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
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

lsblakk

On Nov 25, 2013, at 9:28 AM, chris hofmann <[hidden email]> wrote:

> is there a bug to track progress on this?


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

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Alexander Keybl
In reply to this post by lsblakk
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>> Alex,
>>>
>>> 2013/11/24 Wim Benes <[hidden email]>:
>>>> 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
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Fjoerfoks
Hi Alex,

2013/11/27 Alex Keybl <[hidden email]>

> 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


>
> -Alex
>
> On Nov 24, 2013, at 1:16 PM, Lukas Blakk <[hidden email]> 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 <[hidden email]> wrote:
> >
> >> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
> >>> Alex,
> >>>
> >>> 2013/11/24 Wim Benes <[hidden email]>:
> >>>> 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
> >
>
> _______________________________________________
> dev-l10n mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-l10n
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Axel Hecht
In reply to this post by lsblakk
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

On 11/27/13 3:36 PM, Alex Keybl wrote:

> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>>> Alex,
>>>>
>>>> 2013/11/24 Wim Benes <[hidden email]>:
>>>>> 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

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Theo 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 :

> 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
>
> On 11/27/13 3:36 PM, Alex Keybl wrote:
>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>> On Sun, Nov 24, 2013 at 12:02:51PM +0100, Julen Ruiz Aizpuru wrote:
>>>>> Alex,
>>>>>
>>>>> 2013/11/24 Wim Benes <[hidden email]>:
>>>>>> 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
>

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

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

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model, Localizers, and Localization Testers

Francesco Lodolo [:flod]
In reply to this post by Theo Chevalier
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
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
12