IT and Software Localization into Georgian

Software localization is not ordinary translation. The translator has to understand where a string appears, how much space it has, and which part is code and which part is text. TARGMANEBI localizes apps, SaaS platforms, fintech and e-commerce products into Georgian for the Georgian market and returns the files in the same format, so that your developers can drop them straight in. The first version is ready the same or the next day.

What we localize

If you need the content of a corporate website translated rather than a product interface, see our website translation page.

File formats

We work directly in your resource files, without copying the text into Excel:

• JSON and YAML - i18next, react-intl, Vue I18n, Rails;
• XLIFF - Angular, Xcode exports;
• gettext PO/POT - WordPress, Django, PHP projects;
• Android strings.xml, iOS .strings and .stringsdict;
• .resx (.NET) and .properties (Java);
• Localization platforms (TMS) - we join your project and work inside your environment.

The file structure, the keys, the encoding (UTF-8) and the order of entries stay unchanged.

Variables and code: what we leave untouched

A UI string often contains variables and markup that must stay in the translation exactly as they are in the original:

• {username}, {{count}}, %s, %d, %1$s - variables that the program fills in;
• <b>, <a href>, \n - markup and line breaks;
• ICU MessageFormat constructions, for example {count, plural, one {...} other {...}}.

Deleting or altering a variable crashes the app or puts meaningless text on the screen. Our CAT tool turns variables into protected tags, and an automated QA check compares whether the number and order of variables match in every single string.

Technical features of the Georgian language

• Length - Georgian text is often longer than English. If a button or a tab has a character limit, tell us and the translation will not exceed it. We check the limit for each string separately;
• Plurals - in Georgian a noun after a number stays in the singular: "5 ფაილი" (5 file), not "5 ფაილები" (5 files). Under CLDR, Georgian has two plural categories (one, other), so both forms are often identical, but the plural template still has to be filled in correctly;
• Capital letters - the Georgian Mkhedruli script does not use capital letters. In modern browsers, CSS text-transform: uppercase turns Georgian text into Mtavruli, which often gives buttons and headings an unexpected width and look. We flag such cases for your developers;
• Grammatical case next to a variable - "{name}'s profile" needs the genitive case in Georgian, which cannot be applied to a variable. We rebuild such strings so that the name stands without a case ending: "პროფილი: {name}" (Profile: {name});
• Form of address - at the start of the project we agree whether to use the formal "თქვენ" or the informal "შენ" form of "you". Mixing the two in one interface reads as unprofessional;
• Date, number, currency - dates in DD.MM.YYYY format, a comma as the decimal separator, and the ₾ currency symbol after the number.

What is not translated

At the start of localization we draw up a "Do Not Translate" list. It includes brand and product names, trademarked feature names, technology names (Wi-Fi, Bluetooth, QR) and abbreviations that Georgian users recognize in their original form, such as PIN or SMS.

The list also records what is written in Latin letters and what is transliterated into Georgian. Once a decision is made, it applies identically on every screen, in the store description and in the help center.

Context: why we need screenshots

The English "Save" can be "შენახვა" (saving a file), "დაზოგვა" (saving money) or "შენახული" (the saved status). "Book" is either a "book" or "to book" a reservation. A string key such as checkout.button.book often hints at the context, but the best results come from screenshots or access to a staging environment.

We collect ambiguous strings in a single list and check them with your developer in one go, so that the process does not eat into your team's time.

Tips for developers: code that is ready for localization

Half of localization quality is decided before translation, in the code. These are the most common problems we see when we receive files:

• Concatenated strings - "You have " + count + " new messages" is translated as three separate strings, and a correct Georgian sentence cannot be built from them. The right approach is one string with a variable;
• Hard-coded text - strings that are not in the resource file stay in English even after translation;
• Text in images - text written on banners and illustrations needs a separate file or a redesign;
• Fixed width - buttons and tabs that cannot adapt to the length of the text;
• Keys without context - "label1" or "text_23" tells the translator nothing. A developer comment in the file takes a few seconds and reduces translation errors.

If your project is still in development, we will share these points with you in advance, and localization will go much faster.

App store pages and transactional copy

Localization does not end with the interface. Users first see your product in the App Store, on Google Play or in an email:

• Store description - title and subtitle with strict character limits, short and full descriptions, "What's New" texts;
• Screenshot captions - short phrases that fit inside the image frame;
• Transactional emails and SMS - registration, password reset, payment confirmation. Georgian SMS text is sent in Unicode encoding, so fewer characters fit into one message than with Latin text, which makes concise wording especially important here;
• Push notifications - text that must be readable on the lock screen without being cut off.

Process and continuous localization

• Analysis - file format, number of strings, variable types, character limits;
• Style guide and terminology - form of address, tone, and product terms that are not translated;
• Translation in a CAT environment - with protected variables and a Translation Memory;
• Automated QA - variables, tags, length, empty strings, double spaces;
• Linguistic quality assurance (LQA) - in a staging environment or on screenshots, we check how the text looks on a real screen.

Your product changes with every sprint. Thanks to the Translation Memory, for each new release we translate only the new and changed strings, while text that has already been approved is kept automatically. Terms stay the same across all versions.

Unreleased features and staging access are trade secrets. On request we sign an NDA, and only the project team has access: confidentiality policy.

How to get started

Frequently asked questions

Related pages