Taking software into another market involves far more than translating the words on the screen. Date and number formats, currencies, the rules of the language itself and user expectations all change, and the interface has to adapt to those changes. Software localization makes a product look and work in the target market as if it had been built for that market. Below you will find how software localization differs from translation, the challenges specific to Turkish and how the process works.
Translation conveys the meaning of a text; localization adapts the whole product to the target market. Date and time formats, decimal and thousands separators, currency display, address and phone formats and units of measurement are all part of that adaptation. Unicode CLDR, a widely used source in the software world, provides this kind of locale data.
For localization to go smoothly, the software needs to be built for it from the start. This is called internationalization, or i18n: separating text from code, supporting different character sets and allowing the interface to accommodate longer text. Well-internationalized software can be taken into a new language far faster and with fewer errors.
Turkish is one of the languages that raises distinctive problems in software localization. The best-known is the letter “i.” In Turkish, the uppercase form of lowercase “i” is “İ,” and the lowercase form of uppercase “I” is “ı.” Software that converts case according to English rules will write “istanbul” as “ISTANBUL,” which causes errors in functions such as search, sorting and input validation.
The second challenge is plurals. In Turkish, a noun stays singular after a number: the English “3 files” becomes “3 dosya,” not “3 dosyalar.” Software or translation that ignores plural rules produces phrases on screen that sound wrong to a native speaker.
The third is string concatenation. Software often builds sentences by joining pieces, for example the word “Delete,” a file name and a question mark. This works in English but often breaks in Turkish, where the verb comes last and the suffix changes with the sound of the word it attaches to (“dosyayı,” “klasörü”). Problems like these need to be solved during development, not during translation.
UI strings are short, space-limited and context-dependent. When a button label gets longer in the target language, it may not fit the screen or may be truncated. Variables inside strings, the placeholders such as {0} or %s that the software fills in at run time, must be preserved exactly in translation; otherwise the application may throw an error.
The biggest problem, however, is missing context. When a translator receives only the word “Open,” there is no way to tell whether it is a button command or a label describing a state, and Turkish uses different words for each. Screenshots, descriptions and character limit information therefore directly determine the quality of the translation.
In Türkiye, the Regulation on Introduction and User Manuals requires the written, spoken and visual content of the user interface of goods offered to consumers and covered by the regulation to be in Turkish. For products with an interface, from appliances with displays to smart devices, software localization is therefore a legal requirement for entering the Turkish market.
Software localization is not limited to the interface. Help centers, knowledge base articles, release notes, in-app messages, notification e-mails and training content are all part of the user's relationship with the product. Whatever a function is called in the interface, the help content must use the same name; otherwise the user cannot find the menu you are describing on screen.
In software that is updated frequently, localization becomes a continuous process. Only new and changed strings are translated in each release, and translation memory and the glossary keep releases consistent with each other.
Software strings arrive in files such as JSON, XML, .resx, .strings and .po, or in interchange formats developed for localization, such as XLIFF. The translation must be delivered without breaking the structure, tags or encoding of these files; a single missing quotation mark can stop a build.
Running a pseudo-localization test before translation begins is also good practice. In this test, strings are artificially lengthened and replaced with special characters, so hard-coded text that cannot be translated and overflow problems surface before real translation starts.
Checking translated software in its real environment is the last and most decisive step of the process. In linguistic testing, strings are read on screen in context and checked for meaning, tone and consistency. In functional testing, the focus is on truncated text, overlapping elements, corrupted characters and incorrectly formatted dates or numbers. For the testing we carry out with a similar method in the gaming sector, see our Game Testing Services page.
The problems most often seen in software localization are: translating strings without context; breaking variables and tags; ignoring character limits; overlooking the Turkish “i” and plural rules; translating concatenated sentences as they are; giving the same function different names in the interface and the help content; and skipping testing and releasing the translation directly.
For website and game localization, see our Website Localization and Game Localization pages, and for mobile apps, our article on Mobile App Localization Services . For one of the giants of the furniture hardware industry, we localized all content, including mobile apps, in nine languages; you can find the details on our Technical Translation page.
With more than thirty years of experience, Mirora runs technical translation projects with subject-matter expert translators, independent editors and industry-standard CAT tools, under an ISO 9001-certified quality system and an ISO 17100-aligned workflow.
Translation conveys the meaning of a text; localization adapts the whole product to the target market, from date, number and currency formats to the interface layout.
The best-known are case conversion of “i/İ” and “ı/I,” nouns that stay singular after numbers, and concatenated sentences that break because the verb comes last in Turkish.
The Regulation on Introduction and User Manuals requires the written, spoken and visual content of the user interface of goods offered to consumers and covered by the regulation to be in Turkish.
A word sent on its own can have more than one meaning; “Open,” for example, can be a command or a state, and Turkish uses different words for each. Screenshots and descriptions make an accurate translation possible.
It is a pre-test in which strings are artificially lengthened and replaced with special characters. It reveals hard-coded text and overflow problems before real translation begins.
Only new and changed strings are translated in each release. Translation memory and the glossary keep releases consistent with each other.
Please provide your contact information so we can get back to you.
Türkçe Türkçe 
English
