Software Localisation

This service is not the same as website localisation. A website mostly holds flowing text whose context is plain to see; in software the text sits inside resource files in short, scattered fragments cut off from their context. Single words such as “Save”, “Open” and “None” are translated without anyone seeing where they will land on screen. That disconnection is the defining difficulty of software localisation.

Text sits apart from the code

In software that can be localised, every string the user sees is taken out of the code and gathered in separate resource files. The translator works with those files, not with the code. But the files carry elements of their own: placeholders where variables will be inserted, plural forms, formatting marks. Touch these and the application breaks. Software localisation therefore calls for knowing what is to be translated and what must be left alone.

In an agglutinative language such as Turkish, plural and case endings raise a further problem. A phrase that in English is simply appended to a variable changes in Turkish according to the final sound of the word before it. Designs that drop a variable into the middle of a sentence therefore tend to produce flawed results; places like this should be identified during localisation and reported to the developer.

How the process works

Software localisation resembles an engineering discipline more than it does translation; at every step, linguistic and technical accuracy are watched together. The workflow below is built around the fact that the text arrives in fragments cut off from context, which makes gathering context as important a step as the translation itself. Preserving placeholders and formatting codes is a rule that holds throughout. The testing that comes at the end of the sequence is its most decisive link, because whether a translation is genuinely right can only be judged inside the running application.

1. Collecting the source files. The language files holding the text are gathered, along with any screenshots or notes on context.
2. Terminology and style guide. The product’s core terms are fixed; it is settled which rendering will be used for closely related concepts such as “delete”, “remove” and “cancel”.
3. Translation. The text is translated with placeholders and character limits in view; where the context of a fragment is unclear, a question is put to the developer.
4. Testing on a build. The translation is placed into the application and seen on real screens; text that overflows, lands in the wrong place or reads oddly out of context is corrected.
5. Version maintenance. In each new release the strings that have changed are marked and only those are updated; no release starts from scratch.

How it is delivered

Delivery takes the form of the resource files with the translation in place, so that the developer can take them straight into a build. Placeholders, formatting codes and the file structure are preserved intact. Where a testing phase has been asked for, a list of the problems seen on screen and the corrections proposed is reported as well. If the product’s documentation and help text are to be translated too, they are handled in terminological agreement with the interface.

Points specific to this service

The greatest risk is the absence of context. A word translated without seeing where it lands on screen can carry the wrong sense: “close” means both to shut something and to be nearby, and only the context settles which is meant. Screenshots and an open channel for questions to the developer are therefore the single strongest influence on quality. On a project where no context is supplied, the error rate inevitably rises.

The second point is not calling the job finished until it has been seen in the real interface. A translation that looks right on paper may not fit a narrow menu, or may read badly because a variable falls in the middle of a sentence. Problems like these come to light only through testing on a build. If your website is to be localised alongside your application, the two are run in terminological agreement under our translation services.

Internationalisation and the testing cycle

The success of software localisation depends on a step taken before any translation: internationalisation. If the application has not been built to carry more than one language, the result will come out flawed however good the translation. Text separated from the code, date and number formats that can be configured, and an interface that leaves room for text to grow are all conditions to be met before translation begins. Where they are missing, the development side has to be put right first.

The second determining factor is the testing cycle. Localisation is not a one-way delivery but a repeating process: the translation is placed, seen in a build, problems are flagged and put right. As new releases arrive, only the strings that have changed are handled and the same cycle repeats on a smaller scale. Projects run without this arrangement start over with every update, which costs more and loses consistency along the way. Sound localisation defines the cycle as a flow from the outset.

What determines the price?

The first factor in the cost is the real volume of text to be translated, and in resource files that volume is usually greater than it appears, because error messages and help text get overlooked. The second is the state of the context: a project supplied with screenshots and notes moves quickly, one worked on blind slows down. The third is the extent of testing; a check on a build is a separate piece of work. A sound price cannot be given without seeing the source files.

You can share your source files and target languages through the quote form. The pricing tiers are on the pricing page and the languages we work in on the language pages.

Situations that come up often

• A list of strings with no context. A table of words sent without screenshots; nothing raises the risk of wrong meanings more.
• Broken placeholders. Variable markers touched by mistake; this makes the application crash, which is why they are left intact.
• Overflowing text. Wording that grows longer in the target language and no longer fits a narrow interface; only testing on a build reveals it.
• Version sprawl. Retranslating all the text at every update, when only the strings that have changed should be handled.

This page gives the general framework; the details of an individual case may differ. Because practice can change, go by the requirement as it stands at the time of your application.