An app lives in the most intimate space with the user: on the phone screen, in the pocket, opened several times a day. Here every word is a decision: tapping a button, completing registration, buying a subscription or deleting the app. According to research, a large share of users abandon an app right after the first launch, and an incomprehensible, cut-off or awkwardly translated interface is one of the main reasons for that decision. App localisation is therefore not a language task but a product growth task.
What we localise in an app
The localisation of a mobile or web app is not limited to the interface text. The full package covers:
- UI strings: screen titles, buttons, menus, tabs, form fields, placeholders, toasts and dialogs.
- System and error messages: "connection lost", "wrong password", "payment failed". These texts reach the user at a stressful moment and must be as clear as possible.
- Onboarding: the first-launch screens, permission requests (camera, location, notifications), where convincing wording directly raises the consent rate.
- Push and in-app notifications: short, emotional, often with a strict character limit, where transcreation is essential.
- App Store and Google Play materials: the app name, subtitle, description, keywords, screenshot captions, release notes ("What's New").
- Accessibility texts: descriptions of elements intended for the screen reader, which are often forgotten.
- Supporting materials: FAQ, help centre, quick replies for the support chat, legal texts.
The space limit: the main localisation challenge on mobile
A mobile screen is counted in millimetres. The English "Save" is four characters, the Georgian equivalent seven, while "Continue with Google" grows further in Georgian and may not fit the button. Statistically a Georgian interface is 20-35% longer than the English one, and German even more so.
That is why our translators work not only on the text but on the screen:
- we take every string together with its context: where it appears, in what size of element, whether there is a character limit;
- we choose the shortest natural wording without loss of meaning, and offer an alternative if the limit still is not enough;
- we record where the design needs a change (for example, the button width or a two-line heading), which is passed to the developer as a specific task.
Variables, plurals and technical precision
App strings are rarely plain text. They contain variables ("%d new messages", "{user} sent you"), formatting marks and logic whose violation can even crash the app. Our team:
- keeps every variable, placeholder and escape character unchanged;
- handles plural forms correctly: English has two forms (1 item / 2 items), Georgian has a different logic, Russian three forms, Arabic six. ICU MessageFormat and the platforms' native plurals mechanisms solve this task, if the translation is composed with them in mind;
- takes word order differences into account: the English "{count} of {total}" may become "{total}-dan {count}" in Georgian, and the string must be built so that this move is possible;
- checks date, time, number and currency formatting for consistency with the system locale.
Platform conventions: iOS and Android speak differently
Apple's Human Interface Guidelines and Google's Material Design set different standards for interface text. It is "Settings" on iOS and also "Settings" on Android, but in the Georgian system localisation each platform has its own established variant. The user expects the app to use the same terms as their phone's operating system. So in localisation we rely on the platform's official terminology ("Share", "Settings", "Notifications" in their established Georgian forms) and add the brand's own terms only where there is a unique product feature.
In web apps (SaaS panels, customer accounts, dashboards) the conventions come from the browser environment, while tables, filters and data visualisation are separately sensitive to text length.
File formats and localisation platforms
We work with all the main formats, without manual copying by the developer:
- iOS: .strings, .stringsdict, String Catalogs (.xcstrings)
- Android: strings.xml, plurals
- cross-platform: JSON (i18next, Flutter ARB, React Native), YAML, PO/POT
- web: XLIFF, CSV, Excel export
- platforms: Crowdin, Lokalise, Phrase, POEditor, Transifex, as well as GitHub repository integration
Every translation is stored in translation memory, so every subsequent app update (a new screen, feature, A/B test variant) is localised with the same terminology and style, often within one working day.
Linguistic testing on a real device
Delivering the translated file is not enough: only in the real app can you see where the text is cut off, where a string landed on the wrong screen and where raw code shows instead of a variable. At the linguistic QA stage the tester goes through every screen of the app in the target language, via TestFlight, Google Play internal testing or a staging environment, and records every problem with a screenshot, the string identifier and a proposed fix. The developer is left with a ready, prioritised list, not a vague "something doesn't fit somewhere".
App Store optimisation (ASO) in the target language
The app store page is a separate marketing unit. The localised name, subtitle and keywords directly determine whether the user finds the app in the Georgian App Store and Google Play. Using the transcreation approach we create a description that takes local search behaviour into account, adapt the screenshot captions to the Georgian text, and regularly translate the release notes for the "What's New" section.
Frequently asked questions
What is needed to start localisation?
The strings file (or access to the localisation platform), screenshots or access to a test version for context, and the existing terminology, if you have any. The rest we prepare: the glossary, the style guide and the list of questions for the developer.
How long does it take to localise an app?
A medium-sized app (1,500-3,000 words in the interface) in 3-5 working days, including testing. Large products in stages, and subsequent updates, as a rule, within 1 working day.
Do you work directly in localisation platforms?
Yes. We work in the environment of Crowdin, Lokalise, Phrase, POEditor and similar platforms, which removes the need to exchange files and returns the translation directly to your repository.
Do you check the translation in the real app?
Yes, linguistic testing is part of the package. Via TestFlight, Google Play internal testing or a staging environment we go through every screen in the target language and record problems with the string identifier.
Can you localise the App Store and Google Play pages too?
Yes. The name, subtitle, description, keywords, screenshot texts and release notes are localised with ASO principles in mind.
What do you do when the Georgian translation does not fit the button?
First we look for a shorter natural variant. If the limit still is not enough, we record a specific recommendation for a design change, so that the developer can adjust the element without distorting the text.