Accesskeys progress - MT and the other tools
Giacomo Magnini
accesskeys issue we are trying to address.
I have started to patch a few files, and I have to thank all of the
people involved (reviewers, module owners, and even people with checkin
rights) for the fast and kind feedback.
Axel asked why I didn't change the entities' names while I was there and
the answer is that I was trying to make the least impact both on the
files (and module owners' nerves) and on the work of localizers
(changing entities names will result in a "new" string to translate,
while changing the name of an accesskey will mean "translating" only a
char). Still, if module owners/programmers feel that a complete overhawl
of some file is needed, I'll happily patch much deeper (and obviously
the review will take longer, I guess): just ask!
For Ricardo's work, it seems that the only association that MT deals
correctly with is .label-.accesskey; the following list definetely
doesn't work with .accesskey (examples given):
(noext) [both with dots in the entity name or without them]
pippki/deviceManager.dtd: loaddevice.browse
navigator/pageInfo.dtd: generalTab
.value
chatzilla/chatzilla.dtd: op.value
.button
pippki/pref-validation.dtd: validation.managecrls.button
.title
pippki/certManager.dtd: certmgr.detail.general_tab.title
How the other translators' tools deal with these?
Can we find a common ground?
Do we need to stick to a more uniform entity name specification?
Should we note somewhere how to choose an entity name and its relative
accesskey?
There are a few things to correct in Reporter, but they also touch the
part with the BIG note DON'T TOUCH... With who should I discuss about those?
Kairo suggested that I isolated the entities used for two distinct
labels (ie, like Enable/Disable _F_IPS). Thus far, here is what I found:
deviceManager.dtd: F (for the example above)
am-offline.dtd: S (Select IMAP/NNTP)
cookieAcceptDialog.properties: D (Show/Hide Details)
There are probably more not yet found.
Will file bugs (and patches) once I get the accesskeys fixes in place
for those files (if any), or someone else can deal with those (good
first bug-type?).
When I (easily) found unused entities, I tried to open a followup bug
about the removal: and believe me, there is a lot of work to do in there
(just think about the placeholder entities, the ones starting with a
dot, for example, in mailnews or editor). Some of it will be easy, some
will take much more attention.
Axel: before I start to deal with editor/ files, I remember you
mentioned some deep work to be done in there by someone else. Should I
start dealing with those, or should I wait and deal with the rest for
the moment?
A special "thank you" goes to James Ross: he will overlook chatzilla.dtd
to remove unused entities and hopefully fix the accesskeys relations! ;)
I think this is all for now. Please comment and suggest: I will have
dialup connection till the 20th and then none till the end of August.
If I missed something, please note it here, too!
Ciao, Giacomo.
Robert Kaiser
> There are a few things to correct in Reporter, but they also touch the
> part with the BIG note DON'T TOUCH... With who should I discuss about
> those?
Try to contact Robert Acettura, the reporter owner, I guess he should
know about this stuff...
Robert Kaiser
Ricardo Palomares Martinez
> Before I leave for some days off, I'll report back a bit on the
> accesskeys issue we are trying to address.
>
> For Ricardo's work, it seems that the only association that MT deals
> correctly with is .label-.accesskey;
More or less, this was the case with MT 5.0x, except that in some
parts it was done in a case insensitive way (both .accesskey and
.accessKey were accepted).
> the following list definetely
> doesn't work with .accesskey (examples given):
Thanks a lot for the list, I'll use the files to test MT 5.1 new
behaviour. I already can confirm that .button is recognized now
(provided that ".button" is set as a label suffix, of course).
> Do we need to stick to a more uniform entity name specification?
> Should we note somewhere how to choose an entity name and its relative
> accesskey?
The biggest problem for MT 5.1 will keep being the case when the
equivalence is not 1:1 (two labels share a single accesskey, or the
opposite if such thing may happen).
> I think this is all for now. Please comment and suggest: I will have
> dialup connection till the 20th and then none till the end of August.
Thank you a lot for your effort. Reviewing other's work is a boring
task and few people are willing to undertake it.
(If all goes well, I expect to internally use MT 5.1 with Firefox and
Thunderbird real translation by Monday)
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Ricardo Palomares Martinez
>
> For Ricardo's work, it seems that the only association that MT deals
> correctly with is .label-.accesskey; the following list definetely
> doesn't work with .accesskey (examples given):
This is a reminder so when I manage to publish MT 5.1 (I think I'm
narrowing the problem with JARs/XPIs), people have some examples of
what can be accomplished through labels/accesskeys/commandkeys
suffixes customization.
> (noext) [both with dots in the entity name or without them]
> pippki/deviceManager.dtd: loaddevice.browse
> navigator/pageInfo.dtd: generalTab
With MT 5.1 defaults for label suffixes, this will be catched. The
special suffix "[:empty:]" will be the one doing the magic here.
> .value
> chatzilla/chatzilla.dtd: op.value
This would need a customization, adding "|.value" to the list of label
suffixes.
> .button
> pippki/pref-validation.dtd: validation.managecrls.button
This will work with MT defaults.
> .title
> pippki/certManager.dtd: certmgr.detail.general_tab.title
I don't really recommend adding .title as a label suffix. I'd rather
file a bug to have this changed. It developers really need to put an
accesskey to a title (maybe a frame title?), I'd go with a new suffix
instead, something like ".titleLabel" or so.
>
> How the other translators' tools deal with these?
> Can we find a common ground?
> Do we need to stick to a more uniform entity name specification?
> Should we note somewhere how to choose an entity name and its relative
> accesskey?
Assuming that other tools already deal with this, and now that MT 5.1
has a way to better handle the suffixes, I'd start to worry about the
prefixes. I've got an open bug because of duplicate accesskeys in
Thunderbird menu options. Besides waiting for a build to be available
and visually checking, the only option I've found to try to not
duplicate accesskeys is to take a piece of paper and start writing
used letters in the UI unit in which I have to add another option.
When I find duplicate accesskeys, or I end writing down all used
letters, it's time to see what letters are still available and try to
fit it.
This can easily take five minutes or so for an accesskey, and is a
rather mechanical procedure. So, it's something to be done by a
computer. :-) But the problem is that, currently, the only equivalence
I could do in MT to a UI unit (in which accesskeys must be unique), is
one DTD <=> one UI unit. This won't work with many dialogs, and the
Thunderbird menu is a extreme case, with a huge messenger.dtd
containing the whole menu layout (or nearly).
I've thought of two possible solutions, none of which seems to me like
something easily accepted, but here I don't expect to be bashed by
speaking :-) so there I go:
- make the 1 DTD <=> 1 UI unit with unique accesskeys set a rule. This
would involve a massive split and creation of DTD files (and, if
needed, .properties files).
- do the same through a well defined way of naming the entitites, so
no DTD splitting would be needed. messenger.dtd has some examples, but
they are just partial and not fully valid. Some almost valid examples:
openMessageFileCmd.label and openMessageFileCmd.accesskey
saveAsFileCmd.label, saveAsFile.key and saveAsFile.accesskey
Some not valid would be:
getAllNewMsgCmd.label and getAllNewMsgCmd.key
getNewMsgForCmd.label and getNewMsgForCmd.accesskey
The almost valid examples represent menu commands ("Cmd") hanging
directly from File ("...FileCmd"). It would be better if the naming
were done in a more reliable way, for instance
"CmdFileOpenmessagefile.label". Every uppercase would start a new level.
So, the not valid examples should have been named something like:
CmdFileGetnewmsgGetallnew.label
CmdFileGetnewmsgGetmsgfor.label
This way it would be possible to automate the checking of duplicate
accesskeys.
Is something like this a crazy idea? That would make life a lot easier
and would enhance the QA.
Ricardo.