RE: Combining Marks and Keyboard Input on GUI systems (was:

From: Addison Phillips (
Date: Tue Oct 05 1999 - 19:07:40 EDT

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.


        Addison Phillips
        Director, Globalization Engineering
        SimulTrans, L.L.C.
        2606 Bayshore Parkway
        Mountain View, California 94043 USA

        +1 650-526-4652 (direct telephone)
        +1 650-969-9959 (facsimile) (Internet email) (website)

        "22 languages. One release date."

-----Original Message-----
From: []
Sent: Tuesday, October 05, 1999 3:11 PM
To: Unicode List
Subject: Re: Combining Marks and Keyboard Input on GUI systems (was:

>> > 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

       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.


This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT