AccessKey Conflict Finder for Firefox!

[Ankitkumar Rameshchandra Patel]

AccessKeys in your localization of Firefox that differs from English
ones (mozilla-central) are listed here:
http://indianoss.sourceforge.net/mozilla/

more details: http://www.ankit644.com/?p=201

Thanks!
--
Regards,
Ankit Patel
http://www.ankit644.com/

[Ricardo Palomares Martí­nez]

Ankitkumar Rameshchandra Patel escribió:

> AccessKeys in your localization of Firefox that differs from English
> ones (mozilla-central) are listed here:
> http://indianoss.sourceforge.net/mozilla/
>
> more details: http://www.ankit644.com/?p=201

Actually, I think you are confusing accesskeys with commandkeys. It is
perfectly right for a localization to change accesskeys to a different
value from en-US to better fit the translated associated label value.
In fact, not doing so leads to the (accesskey_between_parenthesis)
anti-aesthetic effect.

Some tools (MozillaTranslator among them) take care exactly from this
latter effect, as long as the entity/key names of the label and the
accesskey adhere to some simple rules (in the case of
MozillaTranslator, label ending in .label or .button, accesskey ending
in .accesskey or .akey, both entities sharing a common root name).

However, commandkeys are other story. There are a lot of people (and I
stick to this) that think that commandkeys should be kept in the
localization with the same value than en-US, and that some software
makers like Microsoft do the wrong thing changing them. AFAIK,
Mozilla's official position is to keep commandkeys in localizations to
the en-US value.

So, I think your test would be more useful if, instead of taking care
of accesskeys, looked it for differences in commandkeys.

Ricardo

[Hasse]

In article <q8qdnVsDcf7NJcLQ...@mozilla.org>, Ricardo
Palomares Martí­nez wrote...

> However, commandkeys are other story. There are a lot of people (and I
> stick to this) that think that commandkeys should be kept in the
> localization with the same value than en-US, and that some software
> makers like Microsoft do the wrong thing changing them. AFAIK,
> Mozilla's official position is to keep commandkeys in localizations to
> the en-US value.

I agree in general, but there are instances where the en-US value is
ill-suited for other keyboard layouts. The Back and Forward command
keys and the key for the new Addon Bar are problematic for Mac users
with a Swedish keyboard for example.

--
Hasse
sv-SE l10n team

[Axel Hecht]

Accesskeys need a keyboard, and thus languages without keyboard support
try to do anything reasonable. Using the same keys as en-US is as good
as anything, and that's what this tool is checking.

Whether this criteria is any good or not depends on the language.

See also a discussion in this group with Runa a few days back.

Axel

[Gintautas Grigas]

2011-02-19 16:16, Hasse rašė:
> In article<q8qdnVsDcf7NJcLQ...@mozilla.org>, Ricardo
> Palomares Martí­nez wrote...
>

>> However, commandkeys are other story. There are a lot of people (and I
>> stick to this) that think that commandkeys should be kept in the
>> localization with the same value than en-US, and that some software
>> makers like Microsoft do the wrong thing changing them. AFAIK,
>> Mozilla's official position is to keep commandkeys in localizations to
>> the en-US value.

> I agree in general, but there are instances where the en-US value is
> ill-suited for other keyboard layouts. The Back and Forward command
> keys and the key for the new Addon Bar are problematic for Mac users
> with a Swedish keyboard for example.
>

The investigation was made on this issue by our fellow Agnė
Strelkauskytė. She has analyzed 40 widely used applications (including
Firefox, Thunderbird) against the commandkeys Ctrl+... The
letters A, C, N, O, S, V, W, X were used for the same commands in all
applications (if were used at all). Remaining 18 letters were used for
different commands. So the letters A, C, N, O, S, V, W, X may be
considered as having uniform meaning and it is reasonable to keep them
with the same value as in en-US. Remaining letters may be localized as
not having such property.

Regards,
Gintautas Grigas

[Axel Hecht]

Sharing this with our UX group. Should be good data to share.

Axel

[Ankitkumar Rameshchandra Patel]

After receiving feedback on the need of the tool, have updated the code.

It will now check for the commandkeys as well:
http://indianoss.sourceforge.net/mozilla/

Haven't noticed many commits mentioning accesskey conflicts in the hg
repo though!

Anyways, tool is there for the help. More feedback on improvisation is
welcome.

Thank You!

[Gintautas Grigas]

BTW the word "conflicts" is misleading here. If so all lacalized strings
conflict with en-US! More neutral such as „differs“ may be better.

Gintautas

[Ankitkumar Rameshchandra Patel]

Thanks for your valuable feedback Gintautas. I have already mentioned
the same on the webpage, though I need to think about a new name.

Btw, I was going through the diff (of [*]keys with en-US) for all
languages and found that,

* Locales with no keys differing from en-US are:
bn-IN, en-ZA, gu-IN, hi-IN, kn, ml, mr, or, ta, te

* Locales with few keys differing from en-US are:
as, en-GB, ja, ja-JP-mac, ka, ko, mai, pa-IN, si, ta-LK, zh-CN, zh-TW

Thought this would be helpful for above languages at least.

Thanks!