Still with current iOS there are few problems with the Voice Control and romanian diacritics. Romanian language has only a small number of diacritical characters but it looks that speaking fails to recognize them.

English voice recognition and voice over used in iOS could be easily be tuned to support romanian diacritics.

• ș – reads like sh in shut
• ț – reads like zz in pizza
• ă – reads like a in above
• î – close central unrounded vowel
• â – reads the same as î

More details regarding phonetic reading of romanian characters can be found on wikipedia.

In addition to the voice issues listed about there is another very annoying bug inside the Romanian keyboard dictionary. Inside the default dictionary there is the word “La“, with the first letter uppercase. This is an extremely common work in Romanian and the auto-correct function will try to replace every “la” with “La”, making typing very hard. Probably this is one of the reasons why most romanians are disabling the auto-correct functionality.

I contacted Apple again and I hope they will solve these bugs soon. And from my Romanian friends, I expect some replies with their experience and maybe some likes on Facebook if they encountered the same problems.

Update #1 – Also I have to mention the the Romanian keyboard lacks the Romanian quotation marks:

• U+201E , U+201d – first level
• U+00AB , U+00BB  - second level

In order to keep the article simple I will ignore the modifiers state and I will explain only key related issues. Making modifiers work on different platforms is, usually, not a big deal.

Example #1: Latin letters – CTRL+S (Save)

You may think that foreign language users are using other letters for defining the Save action. For example Save is Bruscar in Spanish so you may think that they are inclined to use Ctrl+B to save. No, this isn’t happening. I wasn’t able to identify any application that is localizing these shortcuts.

Many are forgetting that the most important function of the keyboard shortcuts is the accessibility or the ease of use. It’s important to have common used functions easy to access: imagine you would have to press 4 keys spread all over the keyboard in order to access a common function like Save.

So we may consider that we could check the character code returned by the keyboard event in order to detect the shortcut. This will not work in cases like Greek keyboard where the same key will produce the sigma character(σ).

On Windows luckily Microsoft introduced the virtual key codes and any keyboard layout will generate VK_KEY_S (same code as ASCII character ‘S’). They did a very good job in defining virtual key codes for all keys including special ones like ESC, Del, Ins, …

On Windows it’s a good idea to define keyboard shortcuts using virtual keys for most keys. Yes, but only most, not all, because there is a small set of them that are dependent on the current keyboard layout being selected. I call these keys OEM keys because this is how they are named VK_OEM_…. and they are the key

Figure 1 OEM Keys

On the above layout there are 11 keys, called OEM keys that do have different virtual keycodes on localized keyboard layouts. The problem is that there may have values from a range of around ~16 values and that the characters produced by them are not consistent.

Example #2: Zoom-in/out using Ctrl+Plus/Minus on small keyboard layout or from the keypad

First we have two sets of Plus/Minus keys on a normal keyboard layout and it would be a mistake to consider them the same. For the keypad it is simple, by using the virtual keycodes they will work just fine (VK_ADD and VK_SUBTRACT).

Now the problem with the Plus and Minus from the US English keyboard layout is that they are OEM keys and if you use their codes (VK_OEM_MINUS and VK_OEM_PLUS) you will have problems with around 1/3 of the foreign keyboard layouts. For example on French layouts the zoom-in will work because the key is using the same code bug the zoom-out will not work because there is no such virtual key on the entire French layout.

Figure 2 Plus and Minus from US English layout.

The easy workaround for this problem is to fallback to character code verification if the key event does not match any current keyboard shortcut.

Visual representation of keyboard shortcuts

Especially if you want to use the OEM keys in shortcuts you will have to generate the shortcuts text description at runtime because this text depends on the current keyboard layout. If the user switches the keyboard layout the shortcut text (description) may change.

I managed to find an application, MediaPlayer Classic, that does let the user define the shortcuts using both virtual keys and character codes.

Remember that using these settings you can enter Romanian characters using ALT-GR even when current language is English. This is important because if you do not follow this you may have problems in Microsoft Office because the English spellchecker will not work because it will be confused by the current language settings. 

Keyboard shortcuts in green and mnemonics in yellow.

The best keyboard related definition I’ve found for mnemonic it was on Sun Java glossary:

mnemonic – An underlined alphanumeric character, typically in a menu title, menu item, or the text of a button or component. A mnemonic shows the user which key to press (in conjunction with the Alt key) to activate a command or navigate to a component.

If you had Win32 experience you may call them “menu accelerators”. They define the letter used for triggering them by using Ampersand (&) inside the menu text. I would not recommend the usage of “accelerator” term because looking over the net I’ve found that in many cases it does refer to keyboard shortcuts.

If you are wondering why it’s important to clearly distinguish between them: it’s because the mnemonics are changing when the UI language is localized but the keyboard shortcuts are not supposed to be localized.
.

I’ve did some research to see how different companies are dealing with the shortcuts when people are using different languages and different keyboard layouts. Here are a short list of my results:

• If possible the shortcut is not changed
• If a key is not available on a specific layout we should try to use the same physical position
• There should be no link between application language and keyboard layouts. It’s a mistake to consider that application language will match the keyboard layout. I’ll give you just an example: in Romania over 95% of the computers are using US keyboard layout and the other 5% are using one of the 4-5 different Romanian keyboard layouts.
• some people are using multiple keyboard layouts – usually they are power users and we can’t ignore them
• keyboard layouts can be switched anytime
• characters are safe to be used only if they are Latin

Physical position rules

I think that the physical position of a key is more important than the letter printed on it. Here are my arguments:

• human brain is learning the shortcuts by hand movements (see Pavlov’s dog experiment)
• it’s compatible with the usage of multiple keyboard layouts

But it’s not always so simple: we can’t expect that the French users would swap the usage of Ctrl-Q with Ctrl-A ( Quit vs Select All) just because they are using different layouts. So a basic rule would be to stick to the layout for letters and numbers BUT try to use the physical position for other keys.

Anyway is high likely that people using multiple layouts would choose alike layouts (derived from the same root).

One-to-one key matching

Because the number of keys is the same we have to find a way of remapping the keys so all shortcuts working on US to be usable on other layouts. When I’m referring to keys, I’m referring to the hardware keys.

Case study

Question: How do I make OS X tell me that the key pressed by the user was ‘q’ when current layout is Arabic?

Rules:

• we are not allowed to assume it’s a ‘q’ just because the key code is the same, maybe it’s a Arabic DVORAK keyboard!.
• the shortcuts cannot be hardcoded (user can edit them)

On Windows it does work 98% using virtual key codes and you can use them to extract this info, but on OS X the key codes (even Apple call them sometimes virtual key codes) they are some kind of scan codes. For the rest of 2% you have to do some small hacks with the OEMs.

Current code


case kEventRawKeyDown:
{
unsigned char macChar;
unsigned int keycode;
unsigned int modifiers;
unsigned int keyboardtype;

// kEventParamKeyMacCharCodes
// for Latin characters it does behaves like Windows
// for !Latin it does not return consistent data: on Arabic it does return the same as on US but on French it does return French specific characters for the OEM keys.
...


• VK_A code is present on any keyboard layout even if the character produced is not A

• usually is on the same position, it does move only on some layouts like French AZERTY, and it’s logical to be moved – if the keyboard has an “A” printed on it user is supposed to press this button – we can’t request French users to switch Ctrl-Q and Ctrl-A just because they have a different keyboard layout.

• we can’t rely on the characters because many layouts do not produce Latin characters or some keys are not even producing a character (dead keys).

• it’s not safe to use the scan codes because they will break on AZERTY, DVORAK and other layouts.

I think I do not have to explain more why virtual keys are the way we must store and process keyboard shortcuts.
And now let’s try the same thing on Apple OS X platform. It does seem that apple has only 2 properties for keyboard events: key codes (kEventParamKeyCode) and characters. They consider key codes to be some sort of virtual keys, but in fact they are just physical key positions and this does mean that they are some sort of hardware independent scan codes.
So now I’m stuck with this big question:

How do I detect that the user pressed Command+A under OS X in a way that will work with any keyboard layout?

I should add that the user can have multiple keyboard layouts installed.

External links

• Carbon keyboard events
• Virtual keys on Apple
• http://rentzsch.com/macosx/virtualKeyCodes – Article about Virtual Key Codes on OS X
• Carbon Event Manager Reference
• Text Input Event Handling for Applications With Carbon
• Losing the character code when using the control key

From my point of view there are two types of keyboard shortcuts: the mnenonics (hot keys) and the normal keyboard shortcuts. Mnemonics are the underlined letters and they are fully translatable.

_{Position is more important than the letter on the key.}

One simple example is the Cut-Copy-Paste group they are all consecutive keys on the keyboard and are accesible only with one hand (Ctrl-X, Ctrl-C, Ctrl-V).

Anoher example would be the Undo function that is using Ctrl-Z on English. On a French keyboard it should map to Ctrl-Y because ‘Y’ and ‘Z’ are switched on these keyboards and we need to keep the position.

Use the virtual key codes for remembering the shortcuts

In order to be able to make the shortcuts available on multiple keyboard layouts you need to store the virtual key codes reported by the keyboard not the letter reported. There are many people using multiple keyboard shortcuts on their computer and they are switching from one layout to another very often. So you can’t rely on letters reported by OS but you can safely use the virtual key codes reported because these are not changing when the used is changing the layouts. In fact virtual key codes are.

You can find a full list of virtual key codes here.