Shortcut Keys: The Ampersand and the Problem of Conflicts

When you open a menu, some of the letters are underlined. Press that letter with the Alt key and the matching command runs. Shortcut keys are these small marks that make mouse-free working and accessibility possible. In localisation they are a source of error that is easily missed.

Contents

The problem has a simple cause: the letter that occurs in the source-language word may not occur in its target-language equivalent. Even where it does, another command on the same screen may already have claimed it. The result is a key combination that does nothing, or that goes to the wrong command.

Below we set out how this mark appears in the source file, how the letter is chosen, where conflicts arise and why the compilation stage carries a risk of its own.

What do shortcut keys do in the interface?

Shortcut keys give direct keyboard access to commands. Instead of navigating through a menu, you carry out the action with a single key. This is not only a matter of speed; for users who cannot work a mouse, or who work with a screen reader, it is the condition on which the interface is usable at all.

In the source file this function is encoded by a mark. The ampersand indicates that the letter following it is the shortcut. The mark itself is not visible in the interface; what is visible is the underlined letter. The ampersand is therefore not part of the text but a formatting instruction.

As an example, an entry that reads &Open in an English menu is localised as &Abrir in Spanish. The mark has been kept, the word has been translated, and the shortcut letter has moved onto the target-language word. When these three steps are not carried out together, the result is incomplete.

It is worth remembering that the ampersand does not carry the meaning of a conjunction. Translating a mark that stands on its own in the source text as “and” makes the shortcut disappear from the interface. This mark is one of the classic entries on the list of items that are not to be translated.

How do shortcut keys look in the source file?

You can see this mark most clearly in catalogue files. The translation files of an open-source subtitling program sit openly in its repository for a large number of locales. The header of the file defines the language code, the character encoding and the plural rules; the body holds the source and target strings side by side.

Some entries in these files carry both a variable and a shortcut mark. The English entry “For&ward”, for instance, has been localised into Spanish as “Hacia a&delante”. The shortcut letter has shifted from w to d, because the target word contains no w. The position of the mark has changed; its function has been kept.

The same file also holds entries without the mark. Strings such as “backward” and “forward” carry no shortcut, because they are not menu commands but labels that appear elsewhere in the interface. This distinction shows where the mark is needed: only on items that can be invoked from the keyboard.

These openly available repository files make a good practice ground. Opening the catalogue file for your own language and looking at how the shortcut assignments were made teaches you more than reading the rule does. The same method can be used to study earlier releases of your own product.

How is the letter chosen during translation?

The rule is this: the shortcut letter must occur inside the word in the target language. The D of “Delete” does not occur in its Turkish equivalent, “Sil”; the letter is therefore changed. This is not a deviation but the only way of preserving the function of the shortcut.

The first letter of the word is usually preferred. If the first letter is already taken on that screen, a second letter, or a stressed one, is used instead. In Turkish, with keyboard access to the special characters in mind, it is common practice to choose letters that are easy to reach on a standard keyboard rather than ş, ğ, ı, ö, ü and ç.

Consistency is another criterion. The same command should carry the same shortcut on every screen of the product. If the Save command works with one letter in one window and a different letter in another, the user never learns the shortcut at all. Recording the shortcut in the termbase as well is what keeps that consistency intact.

Finally, some shortcuts are established at operating system level. Actions such as copy and paste are engraved on user habit. Leaving established combinations of this kind alone keeps the interface predictable.

How does a conflict arise, and what does it do?

A conflict is two commands in the same menu, or in the same dialogue box, using the same letter. Because the words change in translation, an arrangement that gives no trouble in the source easily collides in the target. A menu in which all three commands begin with the letter S is a common sight in Turkish.

On the user’s side the result is uncertainty. The key may go only to the first command, may cycle through the commands in turn, or may do nothing at all. The behaviour varies with the framework; what the cases have in common is that the user cannot carry out the action they expected. This is a functional fault, not a cosmetic one.

The second source of conflict is commands added dynamically. A plug-in or a module can add new lines to a menu at run time. The shortcuts on those lines are invisible at the translation stage; yet they meet in the same menu on the user’s screen.

The table below summarises the situations met most often and the remedy that can be applied.

Situation	Symptom	Remedy
The letter is absent from the target word	The shortcut does not work at all	Another letter occurring in the word is chosen
Used a second time on the same screen	The key goes to the wrong command	A list of letters is kept for each screen
The mark has been deleted	The underlined letter disappears	The mark is put back
The mark has been translated	The word “and” appears on screen	The mark is kept, not translated
Assignment after compilation	An unexpected letter is assigned	Testing is done on the compiled product

The compilation stage: where new faults are born

Once the localised source files are ready, compilation follows. This step is usually referred to under the heading of localisation engineering. Catalogue files are converted into a form the application can use efficiently; in the gettext world, .po files are turned into binary .mo files.

The compilation process can itself produce faults. Wrongly assigned shortcut keys are one of the known examples of problems that surface at this stage. An assignment made correctly on the translation side, in other words, may look different in the compiled product.

Shortcut checking is therefore not carried out on the file alone. It has to be done on the screens of the compiled product, menu by menu. Where there is no way of running the product, a visual check on screenshots is the second-best option.

The problems found are logged and routed according to their type. Linguistic or textual problems are settled by the localiser; technical ones are handled together with the developer. Shortcut faults usually sit between the two, which is why clear ownership has to be defined.

When you set the scope of testing, the number of menus is a good measure. On a tool with only a few screens the check is over in half a day. On an enterprise product with dozens of modules, planning the shortcut review module by module is the only way of keeping the work manageable.

What do tools catch, and what do people catch?

Visual localisation tools are a marked help in this area. Their quality assurance functions can flag duplicated shortcut keys, overlapping or truncated text, and controls that have not been localised. Automated checking catches most of the conflicts that slip past the eye.

What the tool cannot know is which letter feels more natural to the user. Decisions about consistency, habit and keyboard access call for human judgement. Automated checking is therefore a first sift, and human review the stage at which the decision is actually made.

Visual tools have one further advantage: they show the localised item on screen. A menu or a button can be enlarged in place when the text grows longer. The shortcut letter and the width of the button are usually thought through together; seeing both on the same screen is quicker than working from two separate lists.

The sequence that works well in practice is this.

Keep a list of the letters used on each screen as you translate.
Run the automated conflict check before delivery.
Carry out a visual check on the compiled product, opening the menus one by one.
Compare the shortcut given to the same command on different screens.
Sort the faults you find into linguistic and technical ones and pass each to the right party.

The Türkiye context

The first factor that makes choosing a shortcut harder in Turkish interfaces is the shortness of command names. Words such as Sil, Aç, Kes and Kopyala are short, so there are few letters to choose from. That is why more than one command in the same menu often begins with the same letter.

The second factor is the keyboard layout. Both Q and F keyboards are used in Türkiye, and the position of the letters specific to Turkish changes with the layout. Choosing ş, ğ or ı as the shortcut letter can make access harder for some users. Preferring standard letters is safer.

The third factor is institutional expectation. Accessibility requirements come up ever more often in public sector and large corporate projects. Full keyboard access is a concrete part of those requirements; shortcut keys therefore become a matter of compliance and not merely of comfort.

The fourth factor is the habits formed by the Turkish versions of foreign software. Certain Turkish shortcuts established in widely used office programs are engraved on users’ memories. Choosing a different letter for the same command in a new product may be technically correct, yet it slows the user down; reviewing common usage is worth the effort.

What does this mean for you?

If the shortcut keys do not work in the Turkish version of your product, it may take a long time for user reports to tell you so. Most users simply carry on with the mouse and never complain. For heavy users who work from the keyboard, and for people with accessibility needs, however, it can make the product unusable.

It is therefore worth adding the shortcut check to your acceptance criteria for delivery. The check costs little; walking through the menus one by one takes a few hours on most products. For a comparison of price and scope you can look at our pricing page, and you can talk the details through with us.

Finally, do not neglect to document your shortcut decisions. When the same commands are translated again for the next release, consistency cannot be maintained without a record of the earlier decisions. A simple table holding the screen name, the command and the letter chosen is enough for this; no separate tool is needed.

Frequently asked questions

Why is a shortcut key marked with an ampersand?

The ampersand indicates that the letter following it is the shortcut. In the interface that letter appears underlined. The mark is not part of the text and is not translated.

Can I change the shortcut letter?

Yes, and most of the time you have to. After translation the source letter may not occur in the word. What matters is that the same letter is not used twice on the same screen.

What do conflicting shortcut keys do?

If two commands in the same menu use the same letter, the key goes to only one of them or cycles between them. The user cannot run the command they expected; this is a functional fault.

At what stage are shortcut faults found?

Some are found by the checks built into translation tools, the rest by visual testing on the compiled product. The compilation stage can also produce new conflicts.

Sources

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 161–166.
Torres del Rey, J. (2022). Machines and technology. Cited in: Jiménez-Crespo (2024), p. 169.
GNU gettext manual, catalogue compilation section, gnu.org (online document).