Peter's right... you should localize the hotkeys (your product won't make
sense to the end user's otherwise).

However, the original poster was writing from Japan. Asian language products
typically use the source language's hotkeys (FWIW usually the English
hotkeys) or typical homologues (when there is no source language... use "F"
for "file" and "P" for Print, etc.)... this is also sensible, if you think
about the nature of Asian keyboards, input methods, and menus.

This makes using "Far East" editions of certain software much easier for
English speakers familiar with the English UI... but that's a by-product,
not the germ of the idea.

>> > Even in the GUI world, as many have pointed out already,
we commonly see > > single-letter shortcuts in dropdown menus.
Suppose a German application
> > has:
> >
> > [Ö]ffnen
> > [O]rdnen

>Aren't you not supposed to localize/internationalize the
hot-keys? If you did, you would break keyboard macro short-cut
programs (they would have to have a localized version of the
macro file for each language).

I thought you *were* supposed to do this, but I'm still
learning what's involved in localisation. I would have thought
that most shortcut keys are intended to be
mnemonic, e.g. "F" for "file", and this would be
language-specific.

With the use of COM/Automation in VBA, this is a non-issue
since the menu hotkeys are not intended to be used to access
application functionality programmatically -- there should be a
COM interface exposed. With the (not terribly extensive) amount
I have worked with VBA in Word, Excel and Access, I *very much*
prefer this way of doing things to what I had learned to do in
Excel 4, Wordbasic, and Word 3 & 4 for DOS before that. I
wouldn't complain one bit if someone decided to add VBA or
similar scripting support to a good text editor, or perhaps an
XML editor.