Accesskey considerations
Cédric Corazza
I didn't know where to post this, but as it also involves the
localization process, it's not a so bad place ;) .
As far as I can see, developers and localizers have big troubles with
accesskeys : just make a query with 'bad' or 'wrong' "accesskey"...
Sometimes we are almost sure that there won't be accesskey conflicts and
sometimes we are totally puzzled : the only way to check this is to
launch a nightly build but we *cannot* test every case.
Recent posts from MoCo and MoFo asked how they could spend money on some
projects.
I think hiring some people to give us (en-US and l10n teams) some easy
way to know what accesskey is already used for a specific file would be
a *great* improvement.
For instance, we got complains (fr locale) because we used "d" as an
accesskey for the Help Menu (in French Ai_d_e)--ALT+D. But this was also
a shortcut to put the focus on the location bar !!!! This shouldn't be :
ALT+... is reserved for accesskey AFAIK. Anyway, the most difficult
thing are context menus...
Ville Pohjanheimo
I agree with Cedric. Accesskeys are a mess to deal with *and* not just
for localizers, but also for the en-US coders and *especially* for the
countless extension coders out there (and don't forget their localizers
too!). Context menus are a real pain as they change according to context
i.e. there are several unique context menus where a specific string +
accesskey is used.
I'm not sure, how impossible solving this problem completely is ... a
accesskeys per file approach doesn't seem to be enough as I understand
it: if a string is used in several types of context menus, shouldn't the
accesskey be checked against all those instances instead of just inside
a file? Someone who knows intimately how accesskeys are handled in
Mozillas codebase should take the lead here. Especially important would
be to have something, /anything more/ before we hit the RC1 mark.
In my mind, the optimal solution would understand the basic browser
chrome and check the accesskeys used in an l10n tree in what ever
context necessary (which would take care of the location bar problem
Cedric quotes)... too bad we don't live in an optimal world. :|
-ville
Ricardo Palomares Martinez
> For instance, we got complains (fr locale) because we used "d" as an
> accesskey for the Help Menu (in French Ai_d_e)--ALT+D. But this was also
> a shortcut to put the focus on the location bar !!!! This shouldn't be :
> ALT+... is reserved for accesskey AFAIK. Anyway, the most difficult
> thing are context menus...
Keeping separate accesskeys for quick access to often used features is
something desirable, but no matter how much work you devote to it, you
may end in a webpage using accesskeys for quick access to form fields
(and even links) in a effort to provide accessibility, and everything
in the browser UI reverts to pressing [F10] to launch the menus. :-)
I've tried to make MT a bit more aware of accesskeys and commandkeys
suffixes (now it will look for ".accesskey" and ".akey", ".commandkey"
and ".key" and ".label" and ".button" combinations, always in a case
insensitive way). In the long run, the best option is to enable a user
preference to declare every possible suffix for "labels", "accesskey"
and "commandkey" they want to, but I don't want to keep adding
features and delaying the new version...
I've though of another, small feature in the chrome view, that would
be a real-time automatic accesskey/commandkey checking (somehing like
a message in the upper part of the chrome view, next to "Edit Image"
and "Edit Phrase" buttons, saying: "The remaining available accesskeys
are: a c f z"). That would assume that every single file refers to
just one dialog, which of course won't be true a lot of times, but it
can give some clues on many others. I'll see if that's feasible in a
short time.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Giacomo Magnini
> I've tried to make MT a bit more aware of accesskeys and commandkeys
> suffixes
Please don't. There are so many wrongly named accesskeys, that it is
something impossible to do, and it is simply not correct. There are
rules in place for people to use in order to select names, and they
should obey to them. And reviewers should impose them more strictly at
times.
My take is that the source is the one to fix, not MT.
I would open bugs for this kind of problems, and there is some need to
verify all of dtd/properties files in order to address this situation.
You can't talk about rules in docs and then don't apply them in your own
source...
My €.02.
Ciao, Giacomo.
Robert Kaiser
> Ricardo Palomares Martinez wrote:
>> I've tried to make MT a bit more aware of accesskeys and commandkeys
>> suffixes
>
> Please don't. There are so many wrongly named accesskeys, that it is
> something impossible to do, and it is simply not correct. There are
> rules in place for people to use in order to select names, and they
> should obey to them. And reviewers should impose them more strictly at
> times.
We should have the most commonly used variants in MT (esp. the no
suffix/.label/.text/??? <--> .accesskey alignments), but we should
really try to get the original files fixed where the rules are not being
followed.
Robert Kaiser
Axel Hecht
I guess we want input on this on a more general level, cross-posting to
.quality and .platform.
I think this is most prominently a QA tool question, but that may be
just me.
Axel
Giacomo Magnini
> We should have the most commonly used variants in MT (esp. the no
> suffix/.label/.text/??? <--> .accesskey alignments), but we should
But there are some examples of "no suffix" where the accesskey name has
nothing in common with the original string...
> really try to get the original files fixed where the rules are not being
> followed.
I'm all for this, but as I tested myself in the past, "sanitizing"
entities' names is not something that many module owners/peers like to
review, or really approve... Going after every single module owner until
getting a r+ is going to be an endless work: I just hope that in the
mean time the number of strings/accesskeys needing such work has
lowered, but I have the feeling this hasn't really happened.
Ciao, Giacomo.
Robert Kaiser
>> really try to get the original files fixed where the rules are not
>> being followed.
>
> I'm all for this, but as I tested myself in the past, "sanitizing"
> entities' names is not something that many module owners/peers like to
> review, or really approve... Going after every single module owner until
> getting a r+ is going to be an endless work: I just hope that in the
> mean time the number of strings/accesskeys needing such work has
> lowered, but I have the feeling this hasn't really happened.
I'm sure we'll find reviews in SeaMonkey-specific files if such a patch
is made up. I can't talk for other projects though, but I think poking
the right people might also get us somewhere.
Robert Kaiser
Axel Hecht
CC me on bugs that lack tracking, maybe add a common whiteboard status
so that tracking is easier?
Axel
Giacomo Magnini
> CC me on bugs that lack tracking, maybe add a common whiteboard status
> so that tracking is easier?
Actually there is no bug lacking traction (there was a patch for DOMI
for changing the pref panel title name, but I simply dropped it because
it broke the tree with the localizations in-tree).
Can you explain "common whiteboard status"? Seems new to me...
Ciao, Giacomo.
Axel Hecht
There is one textfield on the top of each bug page saying
Status Whiteboard
where you can add arbitrary text and which you can explicitly search. So
for tracking issues for a particular state which don't deserve a keyword
per se, this is a good workaround.
Axel
Giacomo Magnini
> There is one textfield on the top of each bug page saying
>
> Status Whiteboard
>
> where you can add arbitrary text and which you can explicitly search. So
> for tracking issues for a particular state which don't deserve a keyword
> per se, this is a good workaround.
Ah, ok! Now that's more clear, thanks. I thought only predefined
keywords were allowed for it, so I didn't see how it would have fit with
our goal.
Ciao, Giacomo.
Robert Kaiser
No, that's only true for the "Keywords" field. BTW, the "L12y" keyword
may even fit for that category of bugs as well...
(We should care more about bugs that have that keyword set, BTW)
Robert Kaiser
Giacomo Magnini
> I'm sure we'll find reviews in SeaMonkey-specific files if such a patch
> is made up. I can't talk for other projects though, but I think poking
> the right people might also get us somewhere.
After a first roundup, I think there are around 60 .dtd/.properties
files to sanitize, plus the relative .xul files (or even .cpp?) where
the entities are used.
I'm sure quite a few of those are forked, too, which will double again
the number of affected files.
A quick classification:
21 are for Editor
3 for reporter
1 CZ
1 VK
5 pippki
3 platform-specific (wizard.properties)
2 Addressbook/LDAP
7 mailnews (or whereabouts)
11 communicator(or whereabouts)
3 uncertain (need more investigation: looks like ak were added wrongly
in those files, while referring entitites in other files)
So, as I guessed, this is going to be a huge undertaking: will I get
enough support? :)
Ciao, Giacomo.
Robert Kaiser
> So, as I guessed, this is going to be a huge undertaking: will I get
> enough support? :)
We'll try to poke the right people once we have patches :)
And for SeaMonkey-specific (communicator) stuff, we may even be able to
go with me reviewing that.
Robert Kaiser
Axel Hecht
I didn't talk to mscott yet, but I hope that we can get a week of "whack
the living shit out of tb" post 2.0. There are a plethora of evil and
scary things in the l10n parts, like for example editor.properties,
which just want focused clean up.
Axel
Giacomo Magnini
> I didn't talk to mscott yet, but I hope that we can get a week of "whack
> the living shit out of tb" post 2.0. There are a plethora of evil and
> scary things in the l10n parts, like for example editor.properties,
> which just want focused clean up.
Yeah, that is one of the 21 files for Editor... And editor.dtd,
editorOverlay.dtd, EditorSpellCheck.dtd, etc. :)
Actually not a single EditorXXXXProperties.dtd is following entities'
names conventions...
Ciao, Giacomo.
Ognyan Kulev
> We should have the most commonly used variants in MT (esp. the no
> suffix/.label/.text/??? <--> .accesskey alignments), but we should
> really try to get the original files fixed where the rules are not being
> followed.
Yes, and since you missed post it:
https://bugzilla.mozilla.org/show_bug.cgi?id=314785 :-)
Regards,
ogi
Aaron Leventhal
http://www.mozilla.org/access/keyboard/accesskey
Besides avoiding duplicates there are other hints in that doc, such as
avoiding letters with descenders like g, q, etc. and 1 pixel wide
letters like i and l
- Aaron