L10n Mozmill Results for all Firefox 4.0 beta 10 locales
Henrik Skupin
Earlier this week I have finished a script which allows us to test all
available localized builds for a given Firefox version. As talked with
Axel we wanted to give it a first run for the implemented l10n tests. I
did that last night for all localized builds. The test itself checks the
preferences dialog for access keys which are used more than once inside
a given scope. While this task is really time intensive when it has to
be done manually, the Mozmill test-run was able to finish all 77 locales
in 50 minutes.
As it turned out mostly any locale has lesser or more failures, which
would need to be fixed. To help you with the investigation I have
uploaded the results and the automatically taken screenshots:
Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
For a quick glance you can check the last column of the results table.
If your locale is listed with 1 failure, there will be images listed in
the screenshots folder. Those will show you which access keys will have
to be updated. If 0 failures are show, your locale is ok (currently it
only applies to 4 locales out of 77).
When you file bugs to get those failures fixed, please add the
"[mozmill]" entry in the whiteboard, so we can track those issues found
by Mozmill. Also it would be great if you could reply to my message and
send me the bug report.
At the same time I will encourage everyone to test the Mozmill Crowd
extension, which can execute those l10n tests for the given build and
also saves screenshots. See the separate post from Axel some days ago.
The addon can be found here:
https://addons.mozilla.org/en-US/firefox/addon/mozmill-crowd/
Last but not least I would really appreciate your feedback. I'm also
open for enhancement requests. So if you have something in mind, please
tell us.
Best,
--
Henrik
Ankitkumar Rameshchandra Patel
Great stuff, I would say.
Thanks Henrik for putting efforts into such an important tool.
Just one thing, I can see "gu-IN" is failed, however in the screenshots
url I can't find any gu-IN screenshot. Could you please take a look at that?
Thanks
--
Regards,
Ankit Patel
www.ankit644.com
João Miguel Neves
> Hi,
>
> Earlier this week I have finished a script which allows us to test all
> available localized builds for a given Firefox version. As talked with
> Axel we wanted to give it a first run for the implemented l10n tests. I
> did that last night for all localized builds. The test itself checks the
> preferences dialog for access keys which are used more than once inside
> a given scope. While this task is really time intensive when it has to
> be done manually, the Mozmill test-run was able to finish all 77 locales
> in 50 minutes.
>
> As it turned out mostly any locale has lesser or more failures, which
> would need to be fixed. To help you with the investigation I have
> uploaded the results and the automatically taken screenshots:
>
> Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
> Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
me fixing some of the issues. Are those a bug? Do you know which
situations can cause them?
> For a quick glance you can check the last column of the results table.
> If your locale is listed with 1 failure, there will be images listed in
> the screenshots folder. Those will show you which access keys will have
> to be updated. If 0 failures are show, your locale is ok (currently it
> only applies to 4 locales out of 77).
>
> When you file bugs to get those failures fixed, please add the
> "[mozmill]" entry in the whiteboard, so we can track those issues found
> by Mozmill. Also it would be great if you could reply to my message and
> send me the bug report.
>
> At the same time I will encourage everyone to test the Mozmill Crowd
> extension, which can execute those l10n tests for the given build and
> also saves screenshots. See the separate post from Axel some days ago.
>
> The addon can be found here:
> https://addons.mozilla.org/en-US/firefox/addon/mozmill-crowd/
meant :). It's great being able to this tests on our own. For pt-PT we
missed the deadline for beta 10 for several of these fixes we had just
identified. Being able to test it on the nightlies is great!
Thanks for all your work,
João Miguel Neves
Henrik Skupin
> Just one thing, I can see "gu-IN" is failed, however in the screenshots
> url I can't find any gu-IN screenshot. Could you please take a look at that?
Something is wrong here. As long as no screenshots have been produced,
your locale is fine. I will check why we are reporting a failure here.
Thanks for telling me about.
--
Henrik
Henrik Skupin
> Just one thing, I can see "gu-IN" is failed, however in the screenshots
> url I can't find any gu-IN screenshot. Could you please take a look at that?
Something is wrong here. As long as no screenshots have been produced,
Henrik Skupin
>> Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
>> Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
> Can you check the pt-PT report? The undefined ids and label don't help
> me fixing some of the issues. Are those a bug? Do you know which
> situations can cause them?
All of those issues are covered in the 3 screenshots:
> 'a' and 'i': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT.png
> 's': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT-1.png
> 'o' and 'x': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT-2.png
For which of those you have problems? Not all labels seem to have an id,
so we have to grab other properties. There is a bug on file already, and
its patch will help to find better properties for investigation. If all
works well, I could even link those to MXR and your locale in the future.
> Ok, I'll run it again, now I finally understood what the red markers
> meant :). It's great being able to this tests on our own. For pt-PT we
> missed the deadline for beta 10 for several of these fixes we had just
> identified. Being able to test it on the nightlies is great!
Great to hear!
--
Henrik
Henrik Skupin
>> Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
>> Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
> Can you check the pt-PT report? The undefined ids and label don't help
> me fixing some of the issues. Are those a bug? Do you know which
> situations can cause them?
All of those issues are covered in the 3 screenshots:
> 'a' and 'i': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT.png
> 's': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT-1.png
> 'o' and 'x': http://people.mozilla.com/~hskupin/l10n-results/Firefox-pt-PT.4.0b10.20110121161358.WINNT-2.png
For which of those you have problems? Not all labels seem to have an id,
so we have to grab other properties. There is a bug on file already, and
its patch will help to find better properties for investigation. If all
works well, I could even link those to MXR and your locale in the future.
> Ok, I'll run it again, now I finally understood what the red markers
> meant :). It's great being able to this tests on our own. For pt-PT we
> missed the deadline for beta 10 for several of these fixes we had just
> identified. Being able to test it on the nightlies is great!
Great to hear!
--
Henrik
Julen
or., 2011.eko urtren 28a 01:42(e)an, Henrik Skupin(e)k idatzi zuen:
> Hi,
>
> Earlier this week I have finished a script which allows us to test all
> available localized builds for a given Firefox version. As talked with
> Axel we wanted to give it a first run for the implemented l10n tests. I
> did that last night for all localized builds. The test itself checks the
> preferences dialog for access keys which are used more than once inside
> a given scope. While this task is really time intensive when it has to
> be done manually, the Mozmill test-run was able to finish all 77 locales
> in 50 minutes.
This is great stuff, thanks for your efforts and for sharing the results.
> As it turned out mostly any locale has lesser or more failures, which
> would need to be fixed. To help you with the investigation I have
> uploaded the results and the automatically taken screenshots:
>
> Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
> Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
>
> For a quick glance you can check the last column of the results table.
> If your locale is listed with 1 failure, there will be images listed in
> the screenshots folder. Those will show you which access keys will have
> to be updated. If 0 failures are show, your locale is ok (currently it
> only applies to 4 locales out of 77).
>
> When you file bugs to get those failures fixed, please add the
> "[mozmill]" entry in the whiteboard, so we can track those issues found
> by Mozmill. Also it would be great if you could reply to my message and
> send me the bug report.
Most of the locales don't use bugzilla for reporting translation bugs or
as a way to fix stuff (if not for required special cases such as p12n).
Anyhow, we can use commit messages to indicate we are fixing issues
reported by these tests.
Is it enough for you to mention the word "mozmill" in the commit message?
> At the same time I will encourage everyone to test the Mozmill Crowd
> extension, which can execute those l10n tests for the given build and
> also saves screenshots. See the separate post from Axel some days ago.
>
> The addon can be found here:
> https://addons.mozilla.org/en-US/firefox/addon/mozmill-crowd/
>
> Last but not least I would really appreciate your feedback. I'm also
> open for enhancement requests. So if you have something in mind, please
> tell us.
>
How easy/difficult is expanding this for other windows/UI pieces?
Being able to test window sizes automatically would be great too.
Julen.
Axel Hecht
There is a so-called "crop" test already, the problem with that one is,
en-US fails it. We don't exactly know why and how, but there are a few
cropped xul elements in the pref window that you just can't do anything
about. Reporting on those is hard at this point, thus we didn't put
those results out yet. But if you run mozcrowd locally, you'll get those
results. If you see red lines, or red areas with no visual problem in
the end, just ignore them.
Writing more tests shouldn't be too hard, I'm a bit bothered about the
reporting of them in general right now, so maybe we have to restructure
some stuff down the road. But that shouldn't keep you from suggesting or
implementing new tests.
Axel
Henrik Skupin
>> Just one thing, I can see "gu-IN" is failed, however in the screenshots
>> url I can't find any gu-IN screenshot. Could you please take a look at that?
>
> Something is wrong here. As long as no screenshots have been produced,
> your locale is fine. I will check why we are reporting a failure here.
> Thanks for telling me about.
I have filed it for deeper investigation:
https://bugzilla.mozilla.org/show_bug.cgi?id=629644
--
Henrik
Henrik Skupin
>> Just one thing, I can see "gu-IN" is failed, however in the screenshots
>> url I can't find any gu-IN screenshot. Could you please take a look at that?
>
> Something is wrong here. As long as no screenshots have been produced,
> your locale is fine. I will check why we are reporting a failure here.
> Thanks for telling me about.
I have filed it for deeper investigation:
https://bugzilla.mozilla.org/show_bug.cgi?id=629644
--
Henrik
Henrik Skupin
> Most of the locales don't use bugzilla for reporting translation bugs or
> as a way to fix stuff (if not for required special cases such as p12n).
> Anyhow, we can use commit messages to indicate we are fixing issues
> reported by these tests.
>
> Is it enough for you to mention the word "mozmill" in the commit message?
You don't have to. It's fine leaving it out. It is just helpful for us
on Bugzilla for queries. But you are free to take whatever you want as
commit message, even Mozmill included. :)
> How easy/difficult is expanding this for other windows/UI pieces?
> Being able to test window sizes automatically would be great too.
I don't have too much to add, Axel already said most of it. But
expanding the tests for other windows is fairly trivial once you have
understood the structure of the JSON object we are using for the
configuration. For the preferences window and all sub-windows it looks
like that:
We have to restructure the tests itself, so they read in those
configurations from an external JSON file, and there is no need to
define them twice for the accesskeys and crop test. If you are
interested in, all work is tracked on bug 562084.
--
Henrik
Henrik Skupin
> Most of the locales don't use bugzilla for reporting translation bugs or
> as a way to fix stuff (if not for required special cases such as p12n).
> Anyhow, we can use commit messages to indicate we are fixing issues
> reported by these tests.
>
> Is it enough for you to mention the word "mozmill" in the commit message?
You don't have to. It's fine leaving it out. It is just helpful for us
on Bugzilla for queries. But you are free to take whatever you want as
commit message, even Mozmill included. :)
> How easy/difficult is expanding this for other windows/UI pieces?
> Being able to test window sizes automatically would be great too.
I don't have too much to add, Axel already said most of it. But
Ani Peter
I can see Malayalam (ml) has the short cut key bug and I have filed bug
for the same: https://bugzilla.mozilla.org/show_bug.cgi?id=629708
Please check and advise.
Thanking you
Best regards
Ani Peter
Malayalam (ml) Localization
-------- Original Message --------
Subject: L10n Mozmill Results for all Firefox 4.0 beta 10 locales
Date: Fri, 28 Jan 2011 01:42:11 +0100
From: Henrik Skupin <hsk...@gmail.com>
To: dev-...@lists.mozilla.org
Newsgroups: mozilla.dev.l10n
Hi,
Earlier this week I have finished a script which allows us to test all
available localized builds for a given Firefox version. As talked with
Axel we wanted to give it a first run for the implemented l10n tests. I
did that last night for all localized builds. The test itself checks the
preferences dialog for access keys which are used more than once inside
a given scope. While this task is really time intensive when it has to
be done manually, the Mozmill test-run was able to finish all 77 locales
in 50 minutes.
As it turned out mostly any locale has lesser or more failures, which
would need to be fixed. To help you with the investigation I have
uploaded the results and the automatically taken screenshots:
Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
For a quick glance you can check the last column of the results table.
If your locale is listed with 1 failure, there will be images listed in
the screenshots folder. Those will show you which access keys will have
to be updated. If 0 failures are show, your locale is ok (currently it
only applies to 4 locales out of 77).
When you file bugs to get those failures fixed, please add the
"[mozmill]" entry in the whiteboard, so we can track those issues found
by Mozmill. Also it would be great if you could reply to my message and
send me the bug report.
At the same time I will encourage everyone to test the Mozmill Crowd
extension, which can execute those l10n tests for the given build and
also saves screenshots. See the separate post from Axel some days ago.
The addon can be found here:
https://addons.mozilla.org/en-US/firefox/addon/mozmill-crowd/
Last but not least I would really appreciate your feedback. I'm also
open for enhancement requests. So if you have something in mind, please
tell us.
Best,
--
Henrik
_______________________________________________
dev-l10n mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-l10n
Henrik Skupin
> I can see Malayalam (ml) has the short cut key bug and I have filed bug
> for the same: https://bugzilla.mozilla.org/show_bug.cgi?id=629708
I have moved it to the correct component and added a comment. It's up to
you what works best.
--
Henrik
Henrik Skupin
> I can see Malayalam (ml) has the short cut key bug and I have filed bug
> for the same: https://bugzilla.mozilla.org/show_bug.cgi?id=629708
I have moved it to the correct component and added a comment. It's up to
Cédric Corazza
> Last but not least I would really appreciate your feedback. I'm also
> open for enhancement requests. So if you have something in mind, please
> tell us.
Thanks for this great work Henrik! This will save us so much time.
Cédric
Toni Hermoso Pulido
> Le 28/01/2011 01:42, Henrik Skupin a �crit :
>
>> Last but not least I would really appreciate your feedback. I'm also
>> open for enhancement requests. So if you have something in mind, please
>> tell us.
>
> Thanks for this great work Henrik! This will save us so much time.
Thanks as well! I would love this could be extended to the other Mozilla
applications!
--
Toni Hermoso Pulido
http://www.cau.cat
Henrik Skupin
> Thanks as well! I would love this could be extended to the other Mozilla
> applications!
It should already work, so only the test configuration (JSON object
definition for each window/dialog) would have to be added to allow those
l10n tests in other apps. You should talk with the responsible QA
persons for those applications.
--
Henrik
Henrik Skupin
> Thanks as well! I would love this could be extended to the other Mozilla
> applications!
It should already work, so only the test configuration (JSON object
Runa Bhattacharjee
On শুক্রবার 28 জানুয়ারি 2011 06:12 , Henrik Skupin wrote:
> Hi,
>
> Earlier this week I have finished a script which allows us to test all
> available localized builds for a given Firefox version. As talked with Axel
> we wanted to give it a first run for the implemented l10n tests.
[snip]
>
> As it turned out mostly any locale has lesser or more failures, which would
> need to be fixed. To help you with the investigation I have uploaded the
> results and the automatically taken screenshots:
>
> Results: http://mozmill-archive.brasstacks.mozilla.com/#/l10n/reports
> Screeshots: http://people.mozilla.com/~hskupin/l10n-results/
Thank you Henrik for the error pointers. I have a question for Axel about the
error that showed up for my locale (bn-IN).
There was a duplication in the accesskey for the Browser=>Preferences=>Privacy
dialog and the strings are in the file privacy.dtd. On checking them I found the
following:
English version from mozilla central
--------------------------------------
<!ENTITY acceptThirdParty.label "Accept third-party cookies">
<!ENTITY acceptThirdParty.accesskey "c">
Bengali version for bn-IN central (this contains the duplicate accesskey entry
and would need to be corrected)
---------------------------------
<!ENTITY acceptThirdParty.label "স্বতন্ত্র কুকি গ্রহণ করা হবে">
<!ENTITY acceptThirdParty.accesskey "p">
In both the cases the ENTITY identifiers are exactly same i.e.
'acceptThirdParty.accesskey'. Hence, in all probability it did not show up as a
modified entry in the compare locale listings. Same for acceptCookies.accesskey
and locbar.pre.accessKey in the same file, which would need to be updated. There
could be more such instances in other files.
I'd like to know, for changes like these where the key identifiers are the same
but key values are modified are there additional checks (i.e. besides compare
locales) that the translators can do to update the entries in the localized
versions?
Thanks
Runa
--
blog: http://arrbee.wordpress.com
irc: arrbee or runa_b on Freenode
http://fedoraproject.org/wiki/User:Runab
Axel Hecht
So, accesskeys and key-change-on-change policy:
http://hg.mozilla.org/mozilla-central/rev/4b3e63903f2e is an example
patch where accesskeys can flipped around as part of a landing. What's
the right way to signal this?
For localizations that can have useful accesskeys, the conflicts in
en-US likely have little to do with the accesskey conflicts in their
locale, and thus, changing the entity keys for the affected en-US
accesskeys wouldn't really make a whole lot of sense.
For localizations that don't have keyboard support, and that thus just
use en-US accesskeys, it would.
This one is a bad place to make policies for, but the one we have is to
optimize for the first, as they're plenty. Which implies that there's
currently nothing that warns localizers of the no-keyboard flock about
when what in en-US changes.
One could write such a tool, though. I'd argue that it should be
independent of compare-locales itself, as it doesn't apply to all
localizations. It could be part of the package, though, and re-use a
bunch of code.
Any takers?
Axel
Ehsan Akhgari
builds but are still not signed off for a beta.
Do you think it's possible to have these results for those locales too?
Thanks!
Ehsan
Henrik Skupin
> This will also be extremely helpful for locales which have nightly
> builds but are still not signed off for a beta.
>
> Do you think it's possible to have these results for those locales too?
Not at the moment, because we have to fix bug 628655 first.
But members of those localization teams can run tests for their own
locale on their own with the Mozmill Crowd extension. It will give you
the same results.
--
Henrik
Henrik Skupin
> This will also be extremely helpful for locales which have nightly
> builds but are still not signed off for a beta.
>
> Do you think it's possible to have these results for those locales too?
Not at the moment, because we have to fix bug 628655 first.
Runa Bhattacharjee
> This one is a bad place to make policies for, but the one we have is to
> optimize for the first, as they're plenty. Which implies that there's
> currently nothing that warns localizers of the no-keyboard flock about when
> what in en-US changes.
>
> One could write such a tool, though. I'd argue that it should be independent
> of compare-locales itself, as it doesn't apply to all localizations. It
> could be part of the package, though, and re-use a bunch of code.
>
Thank you. Until a tool of this nature is build, what do localizers need to do
to get flagged about these changes?
regards
Axel Hecht
> On সোমবার 31 জানুয়ারি 2011 05:14 অপরাহ্ণ, Axel Hecht wrote:
>
>> This one is a bad place to make policies for, but the one we have is to
>> optimize for the first, as they're plenty. Which implies that there's
>> currently nothing that warns localizers of the no-keyboard flock about
>> when
>> what in en-US changes.
>>
>> One could write such a tool, though. I'd argue that it should be
>> independent
>> of compare-locales itself, as it doesn't apply to all localizations. It
>> could be part of the package, though, and re-use a bunch of code.
>>
>
> Thank you. Until a tool of this nature is build, what do localizers need
> to do
> to get flagged about these changes?
>
I don't think there's low hanging fruit in this one, sadly. The only
thing that comes to my mind is that when you see a new accesskey added,
cross-check the other strings in the context. Which you can't really
tell from the source. Sucks.
Axel