[u]k[/u]itten->k
[u]h[/u]orse->h

p[u]o[/u]oes->o
p[u]a[/u]ard->a

(replaced lt and gt with [])

The plugin can, for example, process the triggerKey as follows:

typeof === ‘int’:
—————–
get the char in the specified index.
(should it also add underline to it?)

typeof === ‘string’:
——————–
Now, here comes the fun part:
If a ‘normal’ string is provided, namely a single char string, act as normal and add it to the trigger list.

However, we can decide on a certain value, for example ‘guess’, which when specified, the plugin will try to determine the key based on the item text.
(we can also test for the string length to decide if it is a ‘normal’ or ‘special’ string config).

I believe that we would like to give the user a hint for the key, and this is usually done by underlining the char.
So, we can use a regexp to search for the chars within ‘u’ tags and add them to the triggers list.

So, to make it a bit clearer:

text is: horse
if triggerKey is:
‘a’->’a’
‘guess’->(get the underlined chars)->’r’

We can even take an array, which will cause the triggerKey adder to call itself for each value in the array.

This way, the i18n issue can be resolved (given that the key is hinted via underline and the triggerkey is set to ‘guess’):

kitten->k
horse->h

pooes->o
paard->a

That said, here’s an idea for another project…
Having all of the available trigger keys shown next to the corresponding menu option. This can be done in several ways.
The most interesting, imho, is what I have seen done in MS Office 2007, where you hit ‘alt’ in order to see a small balloon next to the each menu, showing the available shortcut key for that menu (nicer than the default alt behavior in normal windows apps).
What do they do on Mac, btw?

key -> menu listens to
—————————-
3 -> ’s’
‘3′ -> ‘3′
‘y’ -> ‘y’

O I think we got some misunderstanding. What I mean is that
for example «horse» we will get these results:

key menu listens to
—————————-
3 ‘s’
’3′ ’3′
‘y’ ‘y’

See? if you supply a char for the ‘key’ property you mean an independent trigger key. On the other hand, if you supply an int instead, you are referring to the index of the menu caption “horse”.
That’s just an idea. You could also provide a seperate property for it, so you have triggerKey and triggerIndex or something.

> What Ext JS components change their behavior based on language? I thought changing a language was just changing screens. I think i’m a little inexperienced here.

Ghehe, let me assure you that I am *totally* inexperienced there. So yes, if it internalization is just changing all configuration data than this won’t be an issue.
After searching the docs I couldn’t find any info on I18N. There are some people (e.g. http://elmasse.blogspot.com/2008/04/i18n-with-extjs-resource-bundle.html) who builds some things themselves.

I am sorry that I alarmed you to early.

Most menus that I’ve encountered in the past have been triggered by menu item name, not index. What desktop applications have you used that used the menu index item instead of or in addition to the menu item name?

>However, in a translation we would still need to be able to set the key-index explicitly per item. Index 1 in your example works, but for a certain other example it doesn’t.

What Ext JS components change their behavior based on language? I thought changing a language was just changing screens. I think i’m a little inexperienced here.

Thanks for the comments and suggestions. They are valuable.

> Re: Internationalization Couldn’t you just do this:
yeah, that it way. But note that the english interface would then behave differently from the dutch interface. After some though: this is not really strange, and sometimes unavoidable.
Real keyboard shortcuts are normally cross-language (like CTRL+P etc), but keyboard navigation doesn’t need to be.

However, in a translation we would still need to be able to set the key-index explicitly per item. Index 1 in your example works, but for a certain other example it doesn’t.

–
So ideally you would be able to specify per item and per language what key [index] you want to assign.
—

Thank you for posts and screen casts. I always enjoy them.

Thoughts?

Re: Internationalization Couldn’t you just do this:

– lang:NL
p[o]oes
p[a]ard

?

Thanks so much for the feedback.

I can imagine that you have a menu with 3 items

low priority
normal priority
high priority

Now you are requiring that the trigger character is in the description itself.
Well, that requirement is not too bad.

1. low priority
2. normal priority
3. high priority

is more clear.

But there is a more fundamental problem and that is internationalization.

Using a numerical index can easily lead to inconsistencies and even serious problems:
– lang:EN
[k]itten
[h]orse

– lang:NL
[p]oes
[p]aard

index 0 will pose problems for this dutch translation.

That means that in keyboard navigation one should be able to tell what language dictates the key-strokes if you want a cross-language key scheme.