info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Recent community outreach efforts
32 views
Skip to first unread message
Jeff Beatty
Jul 10, 2012, 12:13:04 PM7/10/12
to
Hi localizers,
Recently the l10n drivers (specifically Axel, chofmann, arky, and
myself) have begun an outreach initiative to help all of the l10n teams
bring their official Firefox desktop localizations up-to-date. If you
have received an email from any of us regarding the state of your team's
Aurora channel, then you are already aware of this effort.
The response to our initial outreach has been relatively successful.
Before the outreach, only around 55% of l10n teams were current on their
Firefox desktop localizations (i.e., only 55% had completed localization
of Firefox 14). Since our initial outreach, 23 locales have completed
localization and sign-offs on Ffx 14. On Aurora, we have 50-53 locales
completed.
Reasons for the fallback have varied, but some commonalities have included:
1) Teams tracking their projects on the wrong dashboards
(https://l10n.mozilla.org/teams/).
2) Teams needing additional information on the Rapid Release process
(https://wiki.mozilla.org/L10n:Becoming_an_Official_Localization).
3) Teams unaware of the Rapid Release calendar or dates
(https://mail.mozilla.com/home/ake...@mozilla.com/Release%20Management.html).
4) Significant changes to team rosters affecting hg commit access and
available resources.
5) Delays due to string freeze breaks on Aurora.
To those who responded to this outreach, thank you very much! In this
next phase of outreach, we hope to have Firefox 16 Aurora at 90%
complete and signed off by the last week of the cycle. We hope to do
this by helping teams overcome the above-mentioned challenges.
If there are questions about any of this, please respond to this
newsgroup thread.
Thanks,
Jeff (gueroJeff)
Recently the l10n drivers (specifically Axel, chofmann, arky, and
myself) have begun an outreach initiative to help all of the l10n teams
bring their official Firefox desktop localizations up-to-date. If you
have received an email from any of us regarding the state of your team's
Aurora channel, then you are already aware of this effort.
The response to our initial outreach has been relatively successful.
Before the outreach, only around 55% of l10n teams were current on their
Firefox desktop localizations (i.e., only 55% had completed localization
of Firefox 14). Since our initial outreach, 23 locales have completed
localization and sign-offs on Ffx 14. On Aurora, we have 50-53 locales
completed.
Reasons for the fallback have varied, but some commonalities have included:
1) Teams tracking their projects on the wrong dashboards
(https://l10n.mozilla.org/teams/).
2) Teams needing additional information on the Rapid Release process
(https://wiki.mozilla.org/L10n:Becoming_an_Official_Localization).
3) Teams unaware of the Rapid Release calendar or dates
(https://mail.mozilla.com/home/ake...@mozilla.com/Release%20Management.html).
4) Significant changes to team rosters affecting hg commit access and
available resources.
5) Delays due to string freeze breaks on Aurora.
To those who responded to this outreach, thank you very much! In this
next phase of outreach, we hope to have Firefox 16 Aurora at 90%
complete and signed off by the last week of the cycle. We hope to do
this by helping teams overcome the above-mentioned challenges.
If there are questions about any of this, please respond to this
newsgroup thread.
Thanks,
Jeff (gueroJeff)
flod
Jul 10, 2012, 2:35:23 PM7/10/12
to dev-...@lists.mozilla.org
Il 10/07/12 18.13, Jeff Beatty ha scritto:
I've just realized that my locale is red not only on Aurora, but on Beta
too.
I look at the schedule but I don't really understand it when it comes to
mobile
https://mail.mozilla.com/home/ake...@mozilla.com/Release%20Management.html
Francesco
> To those who responded to this outreach, thank you very much! In this
> next phase of outreach, we hope to have Firefox 16 Aurora at 90%
> complete and signed off by the last week of the cycle. We hope to do
> this by helping teams overcome the above-mentioned challenges.
Probably OT, but could you explain what is going on (again) with mobile?
> next phase of outreach, we hope to have Firefox 16 Aurora at 90%
> complete and signed off by the last week of the cycle. We hope to do
> this by helping teams overcome the above-mentioned challenges.
I've just realized that my locale is red not only on Aurora, but on Beta
too.
I look at the schedule but I don't really understand it when it comes to
mobile
https://mail.mozilla.com/home/ake...@mozilla.com/Release%20Management.html
Francesco
Axel Hecht
Jul 10, 2012, 4:04:27 PM7/10/12
to Alex Keybl
FWIW, I had a talking point on the platform meeting, asking for help of
the developers to get some sanity back on string landings. Took me a bit
of patience to do that 10 minutes after I saw that the final changeset
in the last beta is an l10n impact landing.
Just ignore the string change, we won't be taking updates to
localizations for 14 anymore, AFAICT. CC akeybl to confirm.
Axel
Axel Hecht
Jul 15, 2012, 8:35:00 AM7/15/12
to Erin Lancaster
On 15.07.12 07:26, flod wrote:
> Il 10/07/12 22.04, Axel Hecht ha scritto:
> after mobile on Aurora a couple of days from merge day.
> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
Yeah, I haven't heard of a string freeze date for fennec 15 yet. Erin?
> Someone from en-US should also start to get a look at strings in
> browser/devtools before they land, I could be wrong but the quality[1]
> is getting lower and lower.
I agree that we need to be pushing for better strings again, and I
started doing that. I've took a talking point in the Tuesday engineering
meeting, and I'll also post in .planning. I've also talked with Alex,
and he came up with a bug query that shows patches waiting to land with
string changes, which we could build a community around. I need to read
that bug query in detail to understand it myself, though.
Axel
>
> Francesco
>
> [1] consistency within the devtool and Firefox
> Il 10/07/12 22.04, Axel Hecht ha scritto:
>> /me neither.
>>
>> FWIW, I had a talking point on the platform meeting, asking for help
>> of the developers to get some sanity back on string landings. Took me
>> a bit of patience to do that 10 minutes after I saw that the final
>> changeset in the last beta is an l10n impact landing.
>>
>> Just ignore the string change, we won't be taking updates to
>> localizations for 14 anymore, AFAICT. CC akeybl to confirm.
> Any chance to get a clear answer? Honestly, I'm getting tired of running
>>
>> FWIW, I had a talking point on the platform meeting, asking for help
>> of the developers to get some sanity back on string landings. Took me
>> a bit of patience to do that 10 minutes after I saw that the final
>> changeset in the last beta is an l10n impact landing.
>>
>> Just ignore the string change, we won't be taking updates to
>> localizations for 14 anymore, AFAICT. CC akeybl to confirm.
> after mobile on Aurora a couple of days from merge day.
> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
Yeah, I haven't heard of a string freeze date for fennec 15 yet. Erin?
> Someone from en-US should also start to get a look at strings in
> browser/devtools before they land, I could be wrong but the quality[1]
> is getting lower and lower.
I agree that we need to be pushing for better strings again, and I
started doing that. I've took a talking point in the Tuesday engineering
meeting, and I'll also post in .planning. I've also talked with Alex,
and he came up with a bug query that shows patches waiting to land with
string changes, which we could build a community around. I need to read
that bug query in detail to understand it myself, though.
Axel
>
> Francesco
>
> [1] consistency within the devtool and Firefox
flod
Jul 19, 2012, 2:58:21 PM7/19/12
to dev-...@lists.mozilla.org
Il 15/07/12 14.35, Axel Hecht ha scritto:
any news on this? I've been reading dev.planning in these days but I
haven't seen meeting notes around.
I really think we should start doing something on this matter, almost
all landings lately on mozilla-central have some kind of problems with
l10n [1] (I guess that's a new "generation" of developers, but reviewers
should be able to catch that kind of problems before giving r+). Some of
them land so late that's impossible to catch them before they move (and
stick) to aurora.
Francesco
[1] fresh one https://bugzilla.mozilla.org/show_bug.cgi?id=712469
> I agree that we need to be pushing for better strings again, and I
> started doing that. I've took a talking point in the Tuesday
> engineering meeting, and I'll also post in .planning. I've also talked
> with Alex, and he came up with a bug query that shows patches waiting
> to land with string changes, which we could build a community around.
> I need to read that bug query in detail to understand it myself, though.
Hi Axel,
> started doing that. I've took a talking point in the Tuesday
> engineering meeting, and I'll also post in .planning. I've also talked
> with Alex, and he came up with a bug query that shows patches waiting
> to land with string changes, which we could build a community around.
> I need to read that bug query in detail to understand it myself, though.
any news on this? I've been reading dev.planning in these days but I
haven't seen meeting notes around.
I really think we should start doing something on this matter, almost
all landings lately on mozilla-central have some kind of problems with
l10n [1] (I guess that's a new "generation" of developers, but reviewers
should be able to catch that kind of problems before giving r+). Some of
them land so late that's impossible to catch them before they move (and
stick) to aurora.
Francesco
[1] fresh one https://bugzilla.mozilla.org/show_bug.cgi?id=712469
Alex Keybl
Jul 23, 2012, 6:15:12 PM7/23/12
to flod, Axel Hecht, dev-...@lists.mozilla.org
Hey guys,
Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
This was the right thing to do.
> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
Axel now has a fairly lightweight method of verifying en-US strings we came up with, and he's offered to pass it off to the technical writers at Mozilla. Hopefully that will help string quality moving forward.
-Alex
On Jul 14, 2012, at 10:26 PM, flod wrote:
> Il 10/07/12 22.04, Axel Hecht ha scritto:
Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
-Alex
On Jul 14, 2012, at 10:26 PM, flod wrote:
> Il 10/07/12 22.04, Axel Hecht ha scritto:
>> /me neither.
>>
>> FWIW, I had a talking point on the platform meeting, asking for help of the developers to get some sanity back on string landings. Took me a bit of patience to do that 10 minutes after I saw that the final changeset in the last beta is an l10n impact landing.
>>
>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>>
>> FWIW, I had a talking point on the platform meeting, asking for help of the developers to get some sanity back on string landings. Took me a bit of patience to do that 10 minutes after I saw that the final changeset in the last beta is an l10n impact landing.
>>
>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
> Any chance to get a clear answer? Honestly, I'm getting tired of running after mobile on Aurora a couple of days from merge day.
> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
>
> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
>
> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
>
>
Axel Hecht
Jul 23, 2012, 6:51:02 PM7/23/12
to Alex Keybl
On 24.07.12 00:15, Alex Keybl wrote:
> Hey guys,
>
> Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>
>>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>
> This was the right thing to do.
>
>> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
> Axel now has a fairly lightweight method of verifying en-US strings we came up with, and he's offered to pass it off to the technical writers at Mozilla. Hopefully that will help string quality moving forward.
>
I actually went through the review? list today, and it's not not really
> Hey guys,
>
> Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>
>>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>
> This was the right thing to do.
>
>> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
> Axel now has a fairly lightweight method of verifying en-US strings we came up with, and he's offered to pass it off to the technical writers at Mozilla. Hopefully that will help string quality moving forward.
>
lightweight. Mostly, because there's actually a large list of bugs that
need follow-up, so the tracking of "strings are good in this bug" is
probably not granular enough.
I haven't yet made up my mind on whether sending out bugmail for "I have
no complaints about what you're doing" is the polite way to go about
this. I've also come across patches from 2009 with open review requests,
which are not OK string-wise. Just taking the review and making it a r-
doesn't sound about right. Don't remember which bug that was.
Maybe doing an attachment flag is right, maybe we need something out of
band. Also, in particular in the case where we need follow-up, I don't
think the query correlates strongly enough between the various states
that attachments can have.
I'm bothered that we'll quickly end up with a too large base of bugs
that match the query, and don't provide new data to look at, and thus
we'll miss out on stuff.
Axel
Dwayne Bailey
Jul 24, 2012, 4:51:38 AM7/24/12
to dev-...@lists.mozilla.org
On 23/07/2012 23:15, Alex Keybl wrote:
> Hey guys,
>
> Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>
> Hey guys,
>
> Just found this in the wrong folder (filters), and wanted to apologize for the late reply.
>
>>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>
>
> This was the right thing to do.
>
>> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
> Axel now has a fairly lightweight method of verifying en-US strings we came up with, and he's offered to pass it off to the technical writers at Mozilla. Hopefully that will help string quality moving forward.
Ignoring new strings. What is the best way to report issues with
>
>> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
> Axel now has a fairly lightweight method of verifying en-US strings we came up with, and he's offered to pass it off to the technical writers at Mozilla. Hopefully that will help string quality moving forward.
existing strings?
We've added a source error reporting feature to Pootle and ideally that
would make it possible for a translator to easily report a problem with
an English string. Where should that issue be reported? My ideal would
be some clearing house in bugzilla so that translators don't need to
know what component this should be filed against and programmers don't
need to engage the issues until they are confirmed.
Does such a place exists or can we create one?
>
> -Alex
>
> On Jul 14, 2012, at 10:26 PM, flod wrote:
>
>> Il 10/07/12 22.04, Axel Hecht ha scritto:
> -Alex
>
> On Jul 14, 2012, at 10:26 PM, flod wrote:
>
>> Il 10/07/12 22.04, Axel Hecht ha scritto:
>>> /me neither.
>>>
>>> FWIW, I had a talking point on the platform meeting, asking for help of the developers to get some sanity back on string landings. Took me a bit of patience to do that 10 minutes after I saw that the final changeset in the last beta is an l10n impact landing.
>>>
>>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>>>
>>> FWIW, I had a talking point on the platform meeting, asking for help of the developers to get some sanity back on string landings. Took me a bit of patience to do that 10 minutes after I saw that the final changeset in the last beta is an l10n impact landing.
>>>
>>> Just ignore the string change, we won't be taking updates to localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>> Any chance to get a clear answer? Honestly, I'm getting tired of running after mobile on Aurora a couple of days from merge day.
>> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
>>
>> https://l10n.mozilla.org/dashboard/history?tree=fennec_aurora&locale=it
>>
>> Someone from en-US should also start to get a look at strings in browser/devtools before they land, I could be wrong but the quality[1] is getting lower and lower.
>>
>>
>> Francesco
>>
>> [1] consistency within the devtool and Firefox
> _______________________________________________
>>
>> [1] consistency within the devtool and Firefox
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
--
Dwayne Bailey
+27 12 460 1095
Axel Hecht
Jul 24, 2012, 7:29:32 AM7/24/12
to
On 24.07.12 10:51, Dwayne Bailey wrote:
> On 23/07/2012 23:15, Alex Keybl wrote:
>> Hey guys,
>>
>> Just found this in the wrong folder (filters), and wanted to apologize
>> for the late reply.
>>
>>>> Just ignore the string change, we won't be taking updates to
>>>> localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>>
>> This was the right thing to do.
>>
>>> Someone from en-US should also start to get a look at strings in
>>> browser/devtools before they land, I could be wrong but the
>>> quality[1] is getting lower and lower.
>> Axel now has a fairly lightweight method of verifying en-US strings we
>> came up with, and he's offered to pass it off to the technical writers
>> at Mozilla. Hopefully that will help string quality moving forward.
> Ignoring new strings. What is the best way to report issues with
> existing strings?
>
> We've added a source error reporting feature to Pootle and ideally that
> would make it possible for a translator to easily report a problem with
> an English string. Where should that issue be reported? My ideal would
> be some clearing house in bugzilla so that translators don't need to
> know what component this should be filed against and programmers don't
> need to engage the issues until they are confirmed.
>
> Does such a place exists or can we create one?
Finding the right component in bugzilla isn't all that hard anymore,
> On 23/07/2012 23:15, Alex Keybl wrote:
>> Hey guys,
>>
>> Just found this in the wrong folder (filters), and wanted to apologize
>> for the late reply.
>>
>>>> Just ignore the string change, we won't be taking updates to
>>>> localizations for 14 anymore, AFAICT. CC akeybl to confirm.
>>
>> This was the right thing to do.
>>
>>> Someone from en-US should also start to get a look at strings in
>>> browser/devtools before they land, I could be wrong but the
>>> quality[1] is getting lower and lower.
>> Axel now has a fairly lightweight method of verifying en-US strings we
>> came up with, and he's offered to pass it off to the technical writers
>> at Mozilla. Hopefully that will help string quality moving forward.
> Ignoring new strings. What is the best way to report issues with
> existing strings?
>
> We've added a source error reporting feature to Pootle and ideally that
> would make it possible for a translator to easily report a problem with
> an English string. Where should that issue be reported? My ideal would
> be some clearing house in bugzilla so that translators don't need to
> know what component this should be filed against and programmers don't
> need to engage the issues until they are confirmed.
>
> Does such a place exists or can we create one?
just go to https://bugzilla.mozilla.org/enter_bug.cgi?full=1 and use the
text field to describe the thing that bugs you. Say, "download" will
offer you all the products/components that have download in their names
or description. Commonly, you can guess pretty well from the string, and
where it is.
If you'd want to sanity check, you could ask here. Or file the bug in
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Untriaged,
and CC :l10n. But that's one hell of a big bag. I guess I'd start here
until people complain about the noise, at which point we're hopefully
either proficient in telling good from bad strings, or ran out of bad
strings :-)
Axel
flod
Jul 25, 2012, 2:33:56 AM7/25/12
to dev-...@lists.mozilla.org, Alex Keybl
FWY, I opened a discussion on dev.planning after I found, again, another
new string on beta
https://groups.google.com/d/topic/mozilla.dev.planning/fdhcnriEzfQ/discussion
Francesco
new string on beta
https://groups.google.com/d/topic/mozilla.dev.planning/fdhcnriEzfQ/discussion
Francesco
Alex Keybl
Jul 25, 2012, 2:47:07 AM7/25/12
to Axel Hecht, dev-...@lists.mozilla.org
[this was sent to Axel earlier today, but dev-l10n somehow dropped]
I think an approval flag is very likely too heavy weight. Taking a look at bugs fixed in 16 with strings changes, I'm only seeing 95 (see [1]). Seems pretty doable to me. What percentage of bugs on that list would need followup? If bugs are marked as needing followup, release management would be happy to help with prodding.
-Alex
[1] https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=substring;list_id=3818669;field0-1-0=attach_data.thedata;field0-0-0=target_milestone;query_format=advanced;value0-1-0=locales/en-US;bug_status=RESOLVED;bug_status=VERIFIED;type0-0-0=substring;value0-0-0=16
I think an approval flag is very likely too heavy weight. Taking a look at bugs fixed in 16 with strings changes, I'm only seeing 95 (see [1]). Seems pretty doable to me. What percentage of bugs on that list would need followup? If bugs are marked as needing followup, release management would be happy to help with prodding.
-Alex
[1] https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=substring;list_id=3818669;field0-1-0=attach_data.thedata;field0-0-0=target_milestone;query_format=advanced;value0-1-0=locales/en-US;bug_status=RESOLVED;bug_status=VERIFIED;type0-0-0=substring;value0-0-0=16
0 new messages