More accesskeys findings
Giacomo Magnini
After another deeper inspection, I found more things to report, and
doubts to be cleared:
- Seems like I had some "false positives": MT can't handle entities with
multiple dots (eg. pref.look.smart.label & pref.look.smart.accesskey or
even with.again.more.dots.inside.the.label), breaking the link between
the twos. Should we fix MT to handles those, or should we fix the
entities' names?
- At times commandkeys (not accesskeys) end with .commandkey, or with
.key: should we stick to a single convention?
- Is it about time to totally remove unused entities and/or placeholder
ones (the one starting with ".Stop")?
- In a few cases we get a single accesskey for two mutually exclusive
labels (eg. Enable/Disable FIPS -> F): there is nothing we can do there
(and we don't want to do anything).
- Do we have to fix .properties files (and the relative stringBundle
accesses)?
- What to do with totally wrongly placed accesskeys (eg. textZoom ones)?
- Should we use .button for buttons (eg. Browse), .label for labels,
radio buttons, checkboxes and submenus, nameCmd for menu entries,
nameTab for tabs? Add more if necessary.
- I have found also a few .commandkey2 and similar: still useful?
So far, it seems to me that MT should handle at least:
- names with no postfix (eg. securityTab & securityTab.accesskey, or
editCmd & editCmd.accesskey)
- names ending with .button
- names ending with .label
Maybe linking entity + accesskey + commandkey could be useful, too.
Ciao, Giacomo.
Robert Kaiser
> - Seems like I had some "false positives": MT can't handle entities with
> multiple dots (eg. pref.look.smart.label & pref.look.smart.accesskey or
> even with.again.more.dots.inside.the.label), breaking the link between
> the twos. Should we fix MT to handles those, or should we fix the
> entities' names?
This is certainly a case where we should fix MT.
> - At times commandkeys (not accesskeys) end with .commandkey, or with
> .key: should we stick to a single convention?
This would be good, but I'm not seeing us going there yet, as any of
those would probably need a bigger amount of patches. And I keep
wondering if we could find a better solution for command keys overall,
as we continue to have request from people who want to be able to
customize them (and OTOH, we may want to keep them out of L10n).
So, I think, it would be best for now to make MT understand both
conventions.
> - Is it about time to totally remove unused entities and/or placeholder
> ones (the one starting with ".Stop")?
Good question. I think it might be a good idea, but we should do so in
separate bugs.
> - In a few cases we get a single accesskey for two mutually exclusive
> labels (eg. Enable/Disable FIPS -> F): there is nothing we can do there
> (and we don't want to do anything).
Sure. We want to file a bug against that and try to get people to fix
this. I know of a few cases where we ran into problems during L10n of
such labels just because we needed to find one single accesskey that can
be used for both, probably very different strings.
> - Do we have to fix .properties files (and the relative stringBundle
> accesses)?
Why shouldn't we?
> - What to do with totally wrongly placed accesskeys (eg. textZoom ones)?
File a bug to fix them, so they get correctly placed :)
> - Should we use .button for buttons (eg. Browse), .label for labels,
> radio buttons, checkboxes and submenus, nameCmd for menu entries,
> nameTab for tabs? Add more if necessary.
That's a hard question, and probably not easy to answer here. MT should
understand the most common of those, though.
> - I have found also a few .commandkey2 and similar: still useful?
For command keys, probably yes, but as we don't encourage localizing
command keys at all, MT doesn't have to understand all those.
> So far, it seems to me that MT should handle at least:
> - names with no postfix (eg. securityTab & securityTab.accesskey, or
> editCmd & editCmd.accesskey)
> - names ending with .button
> - names ending with .label
> Maybe linking entity + accesskey + commandkey could be useful, too.
I'm with you on that :)
Robert Kaiser
Ricardo Palomares Martinez
> (please comment and discuss before we start patching!)
>
> After another deeper inspection, I found more things to report, and
> doubts to be cleared:
>
> - Seems like I had some "false positives": MT can't handle entities with
> multiple dots (eg. pref.look.smart.label & pref.look.smart.accesskey or
> even with.again.more.dots.inside.the.label), breaking the link between
> the twos. Should we fix MT to handles those, or should we fix the
> entities' names?
I'll look into it.
>
> - At times commandkeys (not accesskeys) end with .commandkey, or with
> .key: should we stick to a single convention?
>
I've changed MT to look for both. Besides, accesskeys are most times
named .accesskey and sometimes named .akey. MT 5.1 will look for both,
or maybe it will simply add preferences to let users add suffixes for
accesskeys, commandkeys and buttons/labels/menus.
> - Should we use .button for buttons (eg. Browse), .label for labels,
> radio buttons, checkboxes and submenus, nameCmd for menu entries,
> nameTab for tabs? Add more if necessary.
I haven't thought about menus, I must admit it.
> - I have found also a few .commandkey2 and similar: still useful?
I think I can tell the reason behind some of those things: the l10n
policy that forces developers to create new entities whenever they do
a semantic change. Let's suppose that you have this (I'll use
accesskey instead of commandkey):
<!ENTITY testButton.label "Test now">
<!ENTITY testButton.accesskey "T">
Now suppose that you realize that letter "T" is already used in the
dialog where that button is placed. You need to change the accesskey,
but the label is fine. The poor developer has heard about Axel's
temper ;-) and follows the rules, so he does this:
- <!ENTITY testButton.accesskey "T">
+ <!ENTITY testButton.accesskey2 "n">
And you get something that MT can't catch now.
> So far, it seems to me that MT should handle at least:
> - names with no postfix (eg. securityTab & securityTab.accesskey, or
> editCmd & editCmd.accesskey)
> - names ending with .button
> - names ending with .label
> Maybe linking entity + accesskey + commandkey could be useful, too.
No prefix is not handed right now. Again, I'll take a look into it.
Regarding linking, it _is_ done internally (and it has been way before
I started modifying MT). You can see it in the Advanced tab of the
Edit Phrase dialog.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Ricardo Palomares Martinez
> - Seems like I had some "false positives": MT can't handle entities with
> multiple dots (eg. pref.look.smart.label & pref.look.smart.accesskey or
> even with.again.more.dots.inside.the.label), breaking the link between
> the twos. Should we fix MT to handles those, or should we fix the
> entities' names?
I can confirm now that MT didn't have problems, to the best of my
knowledge, with those patterns. The previous rules only looked for
entities names ending with ".accesskey", not being altered by any
additional dots.
Anyway, that doesn't matter now. Keep reading.
>
> - At times commandkeys (not accesskeys) end with .commandkey, or with
> .key: should we stick to a single convention?
>
As I suggested previously, I've gone with the user preferences. Now
you can give MT multiple suffixes for all labels, accesskeys and
commandkeys. I still have to test if giving an empty suffix will work.
> - Should we use .button for buttons (eg. Browse), .label for labels,
> radio buttons, checkboxes and submenus, nameCmd for menu entries,
> nameTab for tabs? Add more if necessary.
Add it yourself when MT 5.1 is ready. ;-)
Now, it turns out that, even if we have a better way to markup labels,
accesskeys and commandkeys, it doesn't serve to any useful purpose if
I don't add a "Relink labels and keys" option, since they are read
while loading Glossary.zip, not rebuilt. Do anyone have any problem
with me adding such option?
Giacomo Magnini
> Giacomo Magnini escribió:
>> - Seems like I had some "false positives": MT can't handle entities with
>> multiple dots (eg. pref.look.smart.label & pref.look.smart.accesskey or
>> even with.again.more.dots.inside.the.label), breaking the link between
>> the twos. Should we fix MT to handles those, or should we fix the
>> entities' names?
> I can confirm now that MT didn't have problems, to the best of my
> knowledge, with those patterns. The previous rules only looked for
> entities names ending with ".accesskey", not being altered by any
> additional dots.
Well, after further investigations I've found the problem to be related
NOT to dots, but to associations: MT handles only (noext)-.accesskey and
.label-.accesskey couples (maybe even .caption-.accesskey? Should
check), while mozilla source has many more variants. Here are some examples:
reporterOverlay.dtd ->
<!ENTITY reporterMenu.title "Report Broken Web Site"> [menu entry]
<!ENTITY reporterMenu.accesskey "R">
reporterWizard.dtd ->
<!ENTITY reportForm.describe.title "Describe Problem:"> [caption?]
<!ENTITY reportForm.describe.accesskey "D">
viewSource.dtd ->
[menu entry, association NOT working]
<!ENTITY menu_wrapLongLines.title "Wrap Long Lines">
<!ENTITY menu_wrapLongLines.accesskey "W">
[menu entry, association working, same menu]
<!ENTITY menu_highlightSyntax.label "Syntax Highlighting">
<!ENTITY menu_highlightSyntax.accesskey "H">
> As I suggested previously, I've gone with the user preferences. Now
> you can give MT multiple suffixes for all labels, accesskeys and
> commandkeys. I still have to test if giving an empty suffix will work.
I still believe we shuld fix the source, not MT!
>> - Should we use .button for buttons (eg. Browse), .label for labels,
>> radio buttons, checkboxes and submenus, nameCmd for menu entries,
>> nameTab for tabs? Add more if necessary.
>
>
> Add it yourself when MT 5.1 is ready. ;-)
See above.
> Now, it turns out that, even if we have a better way to markup labels,
> accesskeys and commandkeys, it doesn't serve to any useful purpose if
> I don't add a "Relink labels and keys" option, since they are read
> while loading Glossary.zip, not rebuilt. Do anyone have any problem
> with me adding such option?
See above again: please spend your precious time fixing MT bugs and
adding more useful options. Providing a workaround for mozilla source
shortcomings should not be high on your list (and makes other people lazy).
Ciao, Giacomo.
Robert Kaiser
> I still believe we shuld fix the source, not MT!
Yes, in many cases, that's true.
Robert Kaiser
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote:
>
> Well, after further investigations I've found the problem to be related
> NOT to dots, but to associations: MT handles only (noext)-.accesskey
I somewhat doubt that MT handled noext-.accesskey, but, as I said, it
doesn't matter anymore.
> and
> .label-.accesskey couples (maybe even .caption-.accesskey? Should
> check), while mozilla source has many more variants. Here are some
> examples:
> reporterOverlay.dtd ->
> <!ENTITY reporterMenu.title "Report Broken Web Site"> [menu entry]
> <!ENTITY reporterMenu.accesskey "R">
>
> reporterWizard.dtd ->
> <!ENTITY reportForm.describe.title "Describe Problem:"> [caption?]
> <!ENTITY reportForm.describe.accesskey "D">
>
> viewSource.dtd ->
> [menu entry, association NOT working]
> <!ENTITY menu_wrapLongLines.title "Wrap Long Lines">
> <!ENTITY menu_wrapLongLines.accesskey "W">
>
> [menu entry, association working, same menu]
> <!ENTITY menu_highlightSyntax.label "Syntax Highlighting">
> <!ENTITY menu_highlightSyntax.accesskey "H">
>
".title" suffix is a poor choice for label, menu entries or whatever.
While I can't provide an example right now, I'm pretty sure that there
exist combinations of keyname.title, keyname.label and
keyname.accesskey. That would lead to failed associations. IMHO,
".title" shouldn't be allowed as a "label with accesskey" possible suffix.
>> As I suggested previously, I've gone with the user preferences. Now
>> you can give MT multiple suffixes for all labels, accesskeys and
>> commandkeys. I still have to test if giving an empty suffix will work.
>
> I still believe we shuld fix the source, not MT!
I agree that, many times, the problem is in the source code, but
letting the suffixes to be declared as user preferences gives
flexibility to MT. Who knows if in a couple of months everyone agree
to add a "label" suffix, for instance?
>> Now, it turns out that, even if we have a better way to markup labels,
>> accesskeys and commandkeys, it doesn't serve to any useful purpose if
>> I don't add a "Relink labels and keys" option, since they are read
>> while loading Glossary.zip, not rebuilt. Do anyone have any problem
>> with me adding such option?
>
> See above again: please spend your precious time fixing MT bugs and
> adding more useful options. Providing a workaround for mozilla source
> shortcomings should not be high on your list (and makes other people lazy).
This is not the case. I think that we all agree that ".button", among
others, should be taken as a label suffix, and MT 5.0x didn't
recognize it. Unless a "relink" option is made available, it will take
a long time for MT to correctly link .button <-> .accesskey entries
(basically, either you'll have to drop your current Glossary.zip and
start over, or you'll have to wait until all currently existing
.button entries disappear and new ones are introduced).
Ricardo