Mobile app localization is the string catalog, the plurals and formats, the memory, the handoff and the locale build that any software localization needs, with two things a mobile app adds: a catalog per platform, because the resource formats and plural handling differ between the two, and a store listing per locale that ships on a different schedule from the app. SaaS localization adds its own two: strings that change every week rather than every release, and a product where the locale is chosen per user rather than per device. SaaS translation, as teams search for it, usually means that continuous loop. This page sets out what a mobile app and a SaaS product keep to localize, and where the free worksheets on this site fit.
One catalog, two platform formats
A mobile app ships its strings in the resource format each platform reads, with plural forms handled the way each platform expects, and a team that keeps two catalogs by hand keeps two sets of mistakes. Mobile app localization keeps one keyed catalog and exports it in each platform's shape, so a key translated once ships on both, and the pseudo-locale build on each platform finds the strings that stayed in code. The catalog gap the localization testing checklist counts is worked per platform for exactly that reason.
SaaS localization is continuous, and the locale is the user's
A SaaS product changes strings weekly, so its localization runs continuously: changed keys known on merge, handoffs on a cadence, translations read back against keys, locale builds tested with every build. The locale is chosen per user, so dates, numbers, currencies and plurals have to come from locale data at request time rather than from a build setting. SaaS translation on that footing is costed per handoff from the memory's leverage, which the translation memory leverage sheet on this site works from your own figures, with no account.
The store listing and the marketing screens are a catalog of their own
A mobile app's store listing, screenshots and release notes are localized per locale and ship on the store's schedule, not the app's, and a SaaS product's onboarding and billing screens change on the marketing team's schedule. Keeping them as a section of the same catalog, with their own keys and statuses, is what stops the store listing lagging the app by a version. Xlifflane Pro keeps every section against the same locales so the release report shows the app and its listing together.
Questions people ask about mobile app localization
Does mobile app localization need a different tool from SaaS localization?
No. Both need a keyed catalog, a memory, an XLIFF handoff and a tested locale build; the app adds a platform export and the SaaS adds a continuous cadence, and both are settings on the same record.
How are plurals handled across the two mobile platforms?
Each platform has its own plural syntax in its resource format, and both follow the same per-language plural categories. A catalog that stores the plural forms as data exports them into each platform's syntax.
What does SaaS translation cost per release?
The changed word count at the effective rate after the memory's leverage, per locale, which on a weekly cadence is small per handoff and large per year. The leverage sheet works both from the same inputs.