Closed
Bug 137614
Opened 22 years ago
Closed 21 years ago
shistory.accesskey used instead of shistoryDescription2.accesskey
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
VERIFIED
INVALID
People
(Reporter: jaagup.irve, Assigned: dbragg)
Details
Mozilla/5.0 (Windows; U; Win98; et-EE; rv:0.9.9+) Gecko/20020410 in prefs-history.dtd there is a shortcut key named shistory.accesskey, which is used on label named shistoryDescription2.label in the xul. shistory.accesskey should be renamed to shistoryDescription2.accesskey and the corresponding XUL file needs updating. localization tools are currently associating the accesskey with wrong label.
Comment 2•22 years ago
|
||
why this is a bug. I think this is invalid. Is there any documentation suggest the relationship between the naming of a label and an accesskey? over to tao to make decision. I think this bug is invalid.
Assignee: ftang → tao
Don - would you pleae take a look? Seems to me the developer should use match the entity names with their usage.
Assignee: tao → dbragg
Reporter | ||
Comment 5•22 years ago
|
||
MozillaTranslator, but I think it will affect anyone using a tool that can associate labels and accesskeys by their name prefixes. Otherwise localizers must go digging XUL files (or DOM inspector, I presume) to find out where that particurlar label gets its accesskey from. Apart from being a way for programs to group labels, accesskeys and command keys, it is also an elegant solution.
I agree with you. It is good practice to make the accesskey prefix match the label prefix with which it is associated. I'm just not sure we can depend on it happening across the product so that a translation tool can be based on it.
Reporter | ||
Comment 7•22 years ago
|
||
Of course, 100% consistency is hard to get, but in this case, the accesskey is associated with totally irrelevant label.
Searching lxr and looking in pref-history.xul|dtd i can't find either of the entities you refer to so i'm presuming this has disappeared. Marking INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•