accesskey script and testing results
Tim Babych
I have hacked together a script to check accesskeys in mozilla
localizations. I ran it for all locales and uploaded results here, сheck
out yours.
http://clear.com.ua/misc/l10n-keys/
Technical details: uses trunk Silme, lives on bitbucket
http://bitbucket.org/tymofiy/silme-apps/src/tip/scripts/check_accesskeys.py
---
WBR, Tim
Seth Bindernagel
This looks mighty nice.
Can you provide just a bit more documentation on exactly what your
scripts are checking about accesskeys? It's not entirely evident to me
when I click through. My guess is that other localizers might also
benefit from just a bit more explanation.
I'm eager to learn more!
Thanks,
Seth
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
Tim Babych
08.06.10 00:40, Seth Bindernagel написав(ла):
> Can you provide just a bit more documentation on exactly what your
> scripts are checking about accesskeys? It's not entirely evident to me
> when I click through. My guess is that other localizers might also
> benefit from just a bit more explanation.
It takes directory as a command-line parameter and goes through all .dtd
files in that directory. In each of these, it looks for entities whose
ids end with ".accesskey"
for, say, blah.accesskey it tries to find mathing entity in the same file
tries name blah.label, blah.caption, blah2.label, blah2.caption, blah
if that does not help, then the last check:
may be there is _one_ entity whose name contains blah?
(because if there are two, who knows which one is right to deal with)
If matching entity is found it is checked that accesskey key is present
in it. If it is not present, then the pair and their file is outputted.
Also it checks that accesskey is actually a key, not a whole word.
It does not check things when label has something like &brand… in it,
because that would yield false positive.
Quite a bunch of accesskey is not checked, because with such
straightforward approach their labels are not found - to implement that
the script would have to take into account xul files from mozilla source.
But those mistakes that were found by current approach were useful for
me, and I hope for others too :)
Philippe
> Hello guys.
>
> I have hacked together a script to check accesskeys in mozilla
> localizations. I ran it for all locales and uploaded results here, сheck
> out yours.
>
> http://clear.com.ua/misc/l10n-keys/
>
And I'm happy to see that the french locale has not to many errors :)
I see also that your html and style are as good as mine !
Philippe
Jørgen Rasmussen
This is great. I certainly could have used it a couple of months ago :)
I am not sure your results are up to date. And by the way there are a
few bugs.
security/manager/chrome/pippki/certManager.dtd
exceptionMgr.certstatus.accesskey
exceptionMgr.certlocation.accesskey
calendar/chrome/calendar/preferences/advanced.dtd
pref.calendar.advanced.configEdit.accesskey
--
JR
Ricardo Palomares Martínez
> Hello guys.
>
> I have hacked together a script to check accesskeys in mozilla
> localizations. I ran it for all locales and uploaded results here, сheck
> out yours.
>
> http://clear.com.ua/misc/l10n-keys/
>
Nice tool, MozillaTranslator has had this feature for a number of
years, too, and it really helps localization. You should remove
.caption from the list of "label" keys suffixes, though, since it is
leading to two false positives for es-ES.
Ricardo
Eduard Gamonal
however, it would be useful that the app checks wether an access key
is suitable for the sentence it'll be in. For example
the access key R is suitable for "Reset settings", but the accesskey W isn't.
We may make this kind of mistakes after a l10n process and the
consequence is a layout bug. In the previous example, the output would
probably be "Reset settings (W)".
Thank you!
Edu
Eduard Gamonal
Tim Babych
> nice tool!
> however, it would be useful that the app checks wether an access key
> is suitable for the sentence it'll be in. For example
> the access key R is suitable for "Reset settings", but the accesskey W isn't.
> We may make this kind of mistakes after a l10n process and the
> consequence is a layout bug. In the previous example, the output would
> probably be "Reset settings (W)".
Hi, Eduard. I did not really understood your point, because the tool was
designed to make exactly that:
show the accesskeys that are not in the sentence
Adrian Kalla
> I have hacked together a script to check accesskeys in mozilla
> localizations. I ran it for all locales and uploaded results here, сheck
> out yours.
I also have an accesskey checker as part of my L10n Checks suite (also
based on Silme :) ):
http://hg.mozilla.org/users/akalla_aviary.pl/silme-patched/file/21a67f0e738f/lib/mozilla/core/testing.py#l78
One of the hardest things is to find out all the IDs of the accesskeys
and the corresponding labels:
http://hg.mozilla.org/users/akalla_aviary.pl/silme-patched/file/21a67f0e738f/lib/mozilla/core/testing.py#l88
http://hg.mozilla.org/users/akalla_aviary.pl/silme-patched/file/21a67f0e738f/lib/mozilla/core/testing.py#l111
Thanks to your script I could add even more items to this lists, but I'm
still sure that they don't catch 100% of the IDs...
To try it out:
hg clone http://hg.mozilla.org/users/akalla_aviary.pl/silme-patched
python scripts/check-l10n-completeness.py -a 3 "/path/to/l10n.ini"
"/path/to/dir/containing/locale-dir" "locale-dir-name"
or:
python scripts/check-l10n-completeness.py -a 3 -i dir
"/path/to/locale-dir" "/path/to/locale-dir"
Where "-a 3" is the verbose level, which can be 1, 2 or 3.
smo
Looks it will be long weekend for me (;\) - doing Lanikai.
smo
smo
> Hello guys.
>
> I have hacked together a script to check accesskeys in mozilla
> localizations. I ran it for all locales and uploaded results here, сheck
> out yours.
>
instead of just listing the inconsistencies, replace the offending
letter with the first character from the label.
In a lot of cases that's what we eventually do to fix the problem.
At least those (X) will be gone from the interface.
Does anybody see any side-effects - except having to press now
and then the same key N-times, to get to the Nth nistance?
Regards
Vito
Mohomodou Houssouba
Our Songhay language team joined the African Localization Network
(ANLoc) in September 2009. Songhay language packs are complete and
reviewed (Virtaal, Pootle, Fennec and Firefox):
http://pootle.locamotion.org/son/
We've registered to Bugzilla and Mozilla wiki. But the next steps are
not clear to us. Our priority is to have the Songhay translation of
Firefox recognized.
Any tips and (very) clear directions to this end will be greatly
appreciated. If such a message should be addressed to a specific
person, please let us know. We're new on the block so to speak – and
feeling our way around.
Thank you in advance and best wishes,
Mohomodou Houssouba
Soŋay berandiyan konda (son-ML)
Songhay Language Team (son-ML)
--
Rimas Kudelis
The first letter is far from always preferred. The change could be done
of course, but it should be an opt-in feature requiring a command-line
argument, ant not the default (or only) behavior.
Rimas
Matjaz Horvat
Rimas, I agree first letter is not optimal choice, but it's always better
than having (X) in the interface.
Script should of course list all the changes it made, so localizers could
easily skim them and improve them by hand. If necessary.
Cheers,
Matjaž
Rimas Kudelis
instructed to do so. Mainly for one reason: the localizer may want to
scan their translation for accesskey problems today, but fix them
tomorrow or the day after. And with those problems silently fixed by a
script, there will be no way to see what they actually were except by
checking hg logs.
This could be done during the build process though, along with
l10n-merge. But then again, educated choice should be made about the
locales subject to this. I suspect that at least Asian locales would not
want this for sure.
Cheers,
Rimas
Rimas Kudelis
instructed to do so. Mainly for one reason: the localizer may want to
scan their translation for accesskey problems today, but fix them
tomorrow or the day after. And with those problems silently fixed by a
script, there will be no way to see what they actually were except by
checking hg logs.
This could be done during the build process though, along with
l10n-merge. But then again, educated choice should be made about the
locales subject to this. I suspect that at least Asian locales would not
want this for sure.
Cheers,
Rimas
2010.06.14 10:59, Matjaz Horvat rašė:
Matjaz Horvat
command-line argument.
Matjaž