Translation glossary for apps: keep product names consistent

A translation glossary is the short list of terms in your app that must be translated the same way in every language, or left untranslated. For an indie app that's usually the app name, a few feature names, and the words that mean two different things. Write it before you upload the strings file.

Each row needs three things: the source term, a decision (keep it as-is, or translate it to one approved word per language), and a one-line note on what the term means inside your app. Internal keys and text the user never sees stay off the list.

Where the platform allows it, put the same decision into the strings file: Android has translatable="false" and the xliff:g tag, and Apple lets you attach a comment to each localized string. A glossary is separate from a translation memory, which stores whole translated segments, and from a style guide, which covers tone and grammar.

Why the list matters more when AI translates the file

A freelance translator who has worked on your app for two years remembers that "Pots" is a feature and has nothing to do with cooking. An AI model translating your file starts each request without any memory of the word it chose last month. If nothing in the request tells it that "Pots" is a feature name, you can get one word in March, another in October, and a kitchen pot in a third language.

Apple's localization page says the App Store is available in 175 regions and 50 languages, and each language you add is one more place for that drift to hide. If you ship to most of them, you won't be able to read your feature name in most of those languages and spot it yourself. A short glossary hands the same decisions to every run. I go into the wider trade-offs in whether AI translation is good enough for a shipping app.

How to write a translation glossary in five steps

1. Write down the names that must not drift

Open your source strings file and read it top to bottom once. Note every term that is yours: the app name, feature names, plan or tier names, names of things the user creates or collects, characters if it's a game. Skip ordinary UI words. Android's own example in the Translations Editor docs marks the product name EasyApp as untranslatable and leaves "Settings" translatable, and that split is the right instinct. "Settings", "Cancel" and "Done" have good standard translations on every platform, and a glossary row for them only adds noise.

My practical cap is around 30 terms for a typical indie app. Past that, you're writing a dictionary, and the terms that matter get lost in it.

2. Mark each term: keep as-is, or translate this way

Give every term one of two decisions. The first is DNT, short for Do Not Translate, which Smartling's glossary docs use for brand and trademarked terms that should stay untranslated. The second is "translate, but always to this word": you pick one approved target per language and keep it.

Product names don't have to be DNT. Apple says on the same localization page that you can translate your app's name and tailor screenshots for the local audience. The glossary records your decision for each language, and "translate it to this name in French" is a valid decision.

The App Store name is its own field, too. In App Store Connect, the Name is the localized app name shown on the product page and at install, and it must be 2 to 30 characters. The in-app name and the App Store name are separate fields, so decide both and write both down.

3. Split words that mean two things

Apple's NSLocalizedString documentation says to translate each phrase for its meaning, not its wording. Its example uses "Book" twice: once as a noun for literary items and once as a verb on the button that makes a reservation, each with a comment naming the part of speech. Many languages need two different words there.

Your glossary needs the same split. If one English word is two concepts in your app, give it two rows with two notes.

4. Put the decision in the file

A glossary in a spreadsheet helps you. A decision inside the strings file also helps whoever, or whatever, translates it.

On Android, the Translations Editor has an Untranslatable checkbox that adds translatable="false" to the string in the default strings.xml. For a name inside a longer sentence, Android's localization guide says to wrap the part that must stay as-is in an xliff:g tag. It lists code, value placeholders, special symbols and names as text that often shouldn't be translated.

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <string name="app_name" translatable="false">Ledgerling</string>
    <string name="welcome">Welcome to <xliff:g id="app">Ledgerling</xliff:g></string>
    <string name="balance">You have <xliff:g id="amount">%1$s</xliff:g> left</string>
</resources>

On Apple platforms, write the glossary note into the comment of the localized string:

let split = NSLocalizedString("split.button", value: "Split",
    comment: "Verb. Button that divides one expense between people.")

If you're unsure where your stack keeps its text, this guide covers which file holds the strings on each platform.

5. Keep it short and update it when you rename things

Keep the glossary as a plain table in the repo, next to the source strings. When you rename a feature, change the glossary row in the same commit. A stale row is worse than no row, because it tells the translator to use the old name.

Agencies exchange terminology in TBX, an XML format standardized as ISO 30042:2019, according to Microsoft's localization docs. You don't need a TBX file for an indie app. A six-row Markdown table does the job, and once the terms are decided you can translate the file.

A worked example (made-up app)

Ledgerling is a fictional budgeting app. Its whole glossary fits in six rows:

Term	Decision	Note
Ledgerling	Keep as-is inside the app	App name. The App Store name is decided separately per language.
Monthly Pots	Translate, one approved word per language	Feature name. Same word in onboarding, settings and notifications.
Split	Two rows: noun and verb	Noun: a shared expense. Verb: the button that creates one.
%1$s	Never touch	Placeholder for an amount. Its position can move, the token can't change.
sync_finished_notification	Leave off the glossary	Internal key. The user never sees it.
CSV	Keep as-is	File format with no common local equivalent.

The internal key row is there to show what doesn't belong. Apple's archived strings guide says strings that are never displayed, like notification names used internally, don't need translating, and translating them is a waste. They don't need glossary rows either.

Glossary, translation memory, style guide

Microsoft defines a translation memory as a database of source-language segments paired with their translations, where a segment can be a word, a sentence or a whole paragraph. The memory fills up as you translate. The glossary comes first and is much smaller: terms and decisions, written by you. A style guide covers voice, formality and punctuation. For a first release, the glossary is the one you can't skip.

Common mistakes

• Listing every UI word. "Save" and "Cancel" crowd out the terms that are yours.
• Making every product name DNT by reflex. Some names read better translated or transliterated, and Apple allows a translated app name.
• Adding internal keys and log messages, which the user never sees.
• Giving one row to a word that's two concepts, like "Split" or "Book".
• Writing the list once and never touching it again after a rename.
• Forgetting that a translated feature name is often longer than the English. Test the UI before you translate so a long name in German doesn't push a button off screen.

Using the glossary with Localize Your App

I built Localize Your App for indie developers who need to translate an app without running an enterprise workflow. You upload a .strings, .xcstrings, strings.xml, .arb or i18n JSON file, and it translates with AI. Its glossary keeps product terms consistent, placeholders are locked, and translation memory reuses strings you've approved, with those repeats free. You review source and target side by side and can edit any line before you download.

It doesn't hire human translators. It has no CLI, no git sync and no approval chains. The site says the uploaded file is never stored, only the extracted strings in your project. There's no subscription: 1 credit translates 1 string of up to 500 characters into 1 language, and credits never expire. Deciding which terms go on your list is still your part.

FAQ

Why does a translator turn a product name into its dictionary meaning?

The name is also an ordinary word, and nothing in the string told the translator it's a name. Mark it DNT in your glossary, add translatable="false" or xliff:g on Android, or a comment on Apple platforms.

Can a name be written in another script without being translated as a word?

Yes. Writing a name in katakana or Cyrillic keeps the sound and drops the dictionary meaning. Put that spelling in the glossary as the approved target for that language, so every string uses the same one.

What should I do with terms that have no real equivalent?

Keep them as-is and add a short note on what they mean. Android's docs name technical terms without a translation as a common case for marking text untranslatable.

Should my app name stay in English in every language?

Not necessarily. Apple says you can translate your app's name, so the choice is yours per language. Pick one rule per language and use it in the app and the store listing.

Do I need a TBX file or a translation management system?

No. TBX is the exchange format agencies use between tools. For one app and a short list, a table in your repo is enough.

Once your list is written, translate your first file and check each glossary term in the side-by-side review before you download.