Software localization

Cost of the release across every locale

$11,592

New words per locale

9,600

Fuzzy-matched words per locale

6,000

Every figure here comes from the figures you enter and the method stated beside it: your word count, your locales, your memory's match shares, your vendor's rates, your strings and the defects your locale pass found. Where a guide names a published figure it names the source and the date it was read. This site publishes no translation, no vendor's price and no ranking: what a word costs in a language is your vendor's quote, and the standards cited on each guide are the starting point, not the ruling.

Software localization has one job a spreadsheet of strings and a folder of XLIFF files do not do: say, on any day, which keys exist, what each says in the source language, what it says in every locale the product ships in, whether that translation is new, translated, reviewed or shipped, and what the next release will cost against the memory. Most teams keep the keys in the developers' resource files, the translations in the translator's files and the status in a spreadsheet, and the three disagree by the second sprint. This page sets out what the software localization record has to keep for a product team, how a release runs through it from the string freeze to the locale build, and what it costs to keep the catalog as a record rather than a set of files only one engineer can reconcile.

Open the Translation memory leverage sheet Free to use. No account, no card, no trial clock.

Freeze the strings and cost the release from the memory

A release starts when the keys that changed or were added are known, and the word count of those keys is what the vendor quotes on. Reading the memory's leverage first, the exact and fuzzy match shares, turns the quote into a cost the team can check; the free translation memory leverage sheet on this site gives the cost per locale and the share the memory removed before the purchase order is raised.

Generate the handoff from the catalog and read it back

The XLIFF goes out generated from the record, one file per locale with every changed key in it, and the translator's file comes back and is read against the same keys, so a key that was renamed, dropped or added mid-sprint is a mismatch the record reports rather than a string that ships in English. Every translation that comes back is recorded against its key and locale with the status the reviewer gives it.

Score the locale build and ship at the threshold

The locale build is checked for what the pseudo-locale and the reviewer find, untranslated strings, truncation, hardcoded text and plural or format failures, and the count per locale is read against the team's ship threshold. The free localization testing checklist on this site works the defect rate and the fixes owed; Xlifflane Pro files the results against the release so the next release starts from a known catalog.

Will it hold your string catalog, beyond the Software localization?

Tell us how your strings are kept today, which file formats and locales you ship, how the handoff works, and what keeps breaking at release.

Send it

What a localisation engineer asks before running the Software localization

Is software localization the same as translation?

No. Translation is the work of rendering a string in another language; localization is the whole of adapting the product, the strings and their plural forms, dates, numbers, currencies, layouts and the tests that prove the locale build works. The record this hub keeps is the localization record, and the translation is one field in it.

Does a product with three locales need a translation management system?

It needs the catalog somewhere more than one person can read. The moment a second developer adds a key, or a release ships with a string in English because nobody knew it changed, the strings have to be in a record with a status per locale, and that is the system whatever the locale count.

Which file formats does the record take in and hand off?

The catalog is keyed, so the source can be a resource file, a JSON or YAML catalog, a strings or properties file, and the handoff is XLIFF, the interchange format the trade's tools read. Whatever the developers ship, the translator receives XLIFF and the record reads it back.

Xlifflane Pro

Keeping the string catalog the whole release reads from

Upgrading turns the worksheet into the record. The word count becomes a catalog with keys on it; every translation is recorded against its key and locale with a status; the handoff is generated from the record and the translator's file is read back against it; every release's leverage sheet and locale test results file themselves under the release. Export is always available, so the catalog and the memory are yours whether or not you stay.

• Download the leverage sheet or the checklist as a file to send to the team
• Your leverage sheets and test reports without our name on them
• Save a release's sheet and open it again next sprint
• Your product name and logo on every printed sheet and handoff
• Take every sheet, handoff and test report out at once
• Send a handoff or a locale test report to the translator or the team from inside the record

$135per month, whole team

Start Xlifflane Pro Pricing

Xlifflane Pro is $135 per month for your whole team, billed monthly, and renews each month at that price until you cancel. The price and the renewal terms are shown again before checkout.