That “&” chooses a key: do not delete it while translating

The marker is part of the string’s intent

When translating text for a Windows Forms control that interprets mnemonics, & can mark an access key. Removing it as stray punctuation can lose that intent. Placing it before an arbitrary letter is not enough either: review the context and neighbouring menu options.

Iria Localization Studio handles JSON and RESX projects. It includes structural access-key checks and requires explicit review of mnemonic proposals. That does not establish that the target application has been tested or guarantee an appropriate choice for every menu.

A small example with explicit context

This fictional example assumes a Windows Forms menu with mnemonic interpretation. The logical English value is &Save; you propose &Guardar in Spanish. Microsoft’s documentation explains placing the marker before the letter and using Alt with controls that support it.

Inside RESX XML, escape that character. An illustrative fragment, not a complete RESX file, would be:

<data name="SaveCommand" xml:space="preserve">
  <value>&amp;Guardar</value>
  <comment>Save command; file menu with an access key.</comment>
</data>

The decoded value is &Guardar. & is the XML representation, not five characters intended to appear on the button. Do not copy the fragment into a project without preserving the structure and headers that project requires.

A second command exposes the remaining decision

Suppose you also proposed G for another command in the same menu. Both translations can be linguistically correct while their access-key choices still require joint review. Passing a check does not mean you chose an appropriate key for the entire menu.

Preserve the command’s real comment or context in Studio. Review its key proposal and project blockers before approval and export. Do not change a command’s meaning to avoid a collision: seek an appropriate letter within a faithful translation, with human review.

Not every ampersand is an access key

For controls interpreting the marker, Windows Forms permits && to display a literal &. XML requires the corresponding escaping too. That is a destination-specific rule, not permission to double every & in every file. First determine whether the string represents literal text, a mnemonic or another syntax.

Iria translates locally on Windows; structural checks replace neither linguistic review nor checking the program consuming the resource. Consult the current facts and official downloads. Bring the string, comment and neighbouring options to your next RESX review: the key only makes sense within that context.