{"id":120,"date":"2026-08-17T16:17:49","date_gmt":"2026-08-17T09:17:49","guid":{"rendered":"https:\/\/bkmos.com\/en\/?p=120"},"modified":"2026-08-17T16:17:49","modified_gmt":"2026-08-17T09:17:49","slug":"app-localization-checklist-translation-team","status":"publish","type":"post","link":"https:\/\/bkmos.com\/en\/blog\/app-localization-checklist-translation-team\/","title":{"rendered":"App Localization Checklist: What to Give Your Translation Team"},"content":{"rendered":"
\n

<\/p>\n

\n
\n<\/p>\n\n\n
<\/p>\n


\n APP LOCALIZATION
\n <\/span><\/p>\n


\n App localization works best when translators receive more than a
\n spreadsheet of isolated strings. They need enough context to understand
\n where each string appears, what the user is doing, which terms are fixed
\n product terminology and what technical constraints apply.\n <\/p>\n


\n A well-prepared localization package can reduce questions,
\n inconsistent terminology, broken placeholders, text-overflow issues
\n and unnecessary revisions later in the release cycle.\n <\/p>\n<\/td>\n

<\/p>\n
<\/p>\n

\"App<\/p>\n<\/figure>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\n

\n The goal is to give the translation team enough product, linguistic
\n and technical information to translate each string in context without
\n requiring them to reverse-engineer the app.\n <\/p>\n

\n This guide explains what product teams should prepare before sending
\n an app for translation and localization.\n <\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n QUICK OVERVIEW<\/span><\/p>\n

What Should You Give Your Translation Team?<\/h2>\n<\/p><\/div>\n
\n
\n 01<\/span><\/p>\n

Product Context<\/h3>\n

\n Explain what the app does, who uses it and what the main
\n user journeys and product features are.\n <\/p>\n<\/article>\n

\n 02<\/span><\/p>\n

Localization Files<\/h3>\n

\n Provide the actual string files or structured exports together
\n with clear identifiers and version information.\n <\/p>\n<\/article>\n

\n 03<\/span><\/p>\n

Terminology & Style<\/h3>\n

\n Share product names, approved terminology, brand voice,
\n style guidance and reference translations.\n <\/p>\n<\/article>\n

\n 04<\/span><\/p>\n

Technical Constraints<\/h3>\n

\n Identify placeholders, variables, character limits, formatting
\n rules and strings that must not be translated.\n <\/p>\n<\/article><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n PRODUCT CONTEXT<\/span><\/p>\n

Start by Explaining What the App Actually Does<\/h2>\n

\n A translator who understands the product can make better choices than
\n one working from isolated words. A short product overview can clarify
\n the app\u2019s purpose, audience and major features before translation starts.\n <\/p>\n

\n This is especially useful when the same English word can have different
\n meanings depending on whether it appears in navigation, payments,
\n account management, messaging, security or another part of the app.\n <\/p>\n

\n Product documentation does not need to be long. It simply needs to
\n give translators enough context to understand the intended user experience.\n <\/p>\n<\/p><\/div>\n

\n
\n

Target Users<\/h3>\n

Who uses the app and what level of technical knowledge do they have?<\/p>\n<\/p><\/div>\n

\n

Main Features<\/h3>\n

Explain the core functions and the most important user journeys.<\/p>\n<\/p><\/div>\n

\n

Platform<\/h3>\n

Identify whether the project covers iOS, Android, web or several platforms.<\/p>\n<\/p><\/div>\n

\n

Release Context<\/h3>\n

State whether the project is a new launch, update or continuous localization workflow.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n SOURCE FILES<\/span><\/p>\n

Provide Strings in a Structured, Usable Format<\/h2>\n

\n The translation team should be able to identify each string, its source
\n text and its relationship to the app without manually copying text from screenshots.\n <\/p>\n<\/p><\/div>\n

\n
\n Resource Files<\/strong><\/p>\n

JSON, XML, XLIFF, ARB, PO or other localization-ready formats.<\/p>\n<\/p><\/div>\n

\n String IDs<\/strong><\/p>\n

Meaningful identifiers can help explain where and how a string is used.<\/p>\n<\/p><\/div>\n

\n Comments<\/strong><\/p>\n

Developer notes can provide context that is not visible in the source string.<\/p>\n<\/p><\/div>\n

\n Current Version<\/strong><\/p>\n

Make sure the exported strings match the build or release being localized.<\/p>\n<\/p><\/div>\n

\n Non-Translatable Text<\/strong><\/p>\n

Identify product names, codes, variables or technical content that must stay unchanged.<\/p>\n<\/p><\/div>\n

\n Reference Files<\/strong><\/p>\n

Provide previous releases or approved translations where available.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n VISUAL CONTEXT<\/span><\/p>\n

Screenshots Can Resolve Ambiguous Strings Quickly<\/h2>\n

\n Short UI strings are often difficult to translate without seeing
\n the screen where they appear. A word such as \u201cSave,\u201d \u201cOrder,\u201d
\n \u201cAccount\u201d or \u201cClose\u201d may represent different actions or concepts
\n depending on the interface.\n <\/p>\n

\n Screenshots, prototypes or access to a staging build can show translators
\n the surrounding labels, buttons, menus and user actions.\n <\/p>\n

\n Visual context also helps identify text-length constraints before
\n localized strings cause buttons, tabs or dialog boxes to overflow.\n <\/p>\n<\/p><\/div>\n

\n
\n

Annotated Screenshots<\/h3>\n

Link screenshots to string IDs or specific screens where practical.<\/p>\n<\/p><\/div>\n

\n

Prototype Access<\/h3>\n

Provide Figma or other prototype access when it helps explain the UI flow.<\/p>\n<\/p><\/div>\n

\n

Staging Build<\/h3>\n

A test build can give translators first-hand context for complex interactions.<\/p>\n<\/p><\/div>\n

\n

Screen Names<\/h3>\n

Identify where strings appear so questions can be resolved faster.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n TERMINOLOGY & STYLE<\/span><\/p>\n

Give Translators the Language Rules of Your Product<\/h2>\n

\n Apps often reuse the same product terms across navigation, onboarding,
\n notifications, support content and marketing. A glossary can keep
\n recurring terms consistent across all of these touchpoints.\n <\/p>\n

\n A style guide can also explain whether the app should sound formal,
\n conversational, concise, technical or playful in the target language.\n <\/p>\n

\n Brand names, feature names and terms that should remain in English
\n should be identified before translation begins.\n <\/p>\n<\/p><\/div>\n

\n
\n

Glossary<\/h3>\n

Approved translations for product features, actions and recurring UI terms.<\/p>\n<\/p><\/div>\n

\n

Style Guide<\/h3>\n

Instructions for tone, capitalization, punctuation and user address.<\/p>\n<\/p><\/div>\n

\n

Brand Terms<\/h3>\n

Identify trademarks, product names and names that should not be translated.<\/p>\n<\/p><\/div>\n

\n

Reference Translation<\/h3>\n

Share previously approved translations when consistency with earlier releases matters.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n<\/p>\n\n\n
<\/p>\n

TECHNICAL INFORMATION<\/span><\/p>\n

\n Tell Translators Which Parts of a String Are Technical
\n <\/h2>\n

\n Localization files often contain variables, placeholders,
\n markup, escape characters, tags and formatting syntax that should
\n not be translated or altered.\n <\/p>\n

\n Translators should know which elements must remain unchanged and
\n how those elements behave when the localized string is displayed.\n <\/p>\n

\n Clear technical instructions reduce the risk of broken strings,
\n missing variables and formatting errors during integration.\n <\/p>\n


\n LOCALIZATION SERVICES
\n <\/a><\/p>\n<\/td>\n

<\/p>\n
\n
\n {user_name} \u2192 Preserve placeholder<\/strong>\n <\/div>\n
\n %s \/ %d \u2192 Keep technical syntax intact<\/strong>\n <\/div>\n
\n HTML \/ markup \u2192 Identify translatable content<\/strong>\n <\/div>\n
\n Character limit \u2192 Communicate before translation<\/strong>\n <\/div>\n
\n Do-not-translate list \u2192 Provide explicitly<\/strong>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n TARGET LOCALES<\/span><\/p>\n

Define the Market, Not Just the Language<\/h2>\n

\n \u201cEnglish,\u201d \u201cSpanish\u201d or \u201cChinese\u201d may not be enough information for
\n a localization project. Product teams should identify the actual target
\n locale and market whenever regional differences matter.\n <\/p>\n

\n The target locale can affect terminology, date formats, number formats,
\n currency presentation, units, formality and other user-facing conventions.\n <\/p>\n

\n The translation team should also know whether the same localized build
\n will serve several markets or whether separate locale variants are required.\n <\/p>\n<\/p><\/div>\n

\n
Language \u2192 Specify clearly<\/strong><\/div>\n
Country \/ region \u2192 Define the target market<\/strong><\/div>\n
Currency \u2192 Confirm display requirements<\/strong><\/div>\n
Dates & numbers \u2192 Identify locale conventions<\/strong><\/div>\n
Units \u2192 State whether conversion is required<\/strong><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n UI CONSTRAINTS<\/span><\/p>\n

Tell the Team Where Space Is Limited<\/h2>\n

\n Localized text can be longer or shorter than the source language.
\n A label that fits comfortably in English may overflow a button,
\n tab, navigation item or notification in another language.\n <\/p>\n

\n Where the interface has a real character or pixel constraint,
\n the translation team should know it before translation rather
\n than discovering the problem only during localization testing.\n <\/p>\n

\n Screenshots and prototypes are particularly useful for deciding
\n where concise wording is necessary.\n <\/p>\n<\/p><\/div>\n

\n
\n

Buttons<\/h3>\n

Identify controls where only a short action label can fit.<\/p>\n<\/p><\/div>\n

\n

Navigation<\/h3>\n

Tabs and menu items may require concise, consistent terminology.<\/p>\n<\/p><\/div>\n

\n

Notifications<\/h3>\n

Specify limits where operating systems restrict visible text.<\/p>\n<\/p><\/div>\n

\n

Store Listings<\/h3>\n

Provide title and description limits for app-store metadata where relevant.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n COLLABORATION<\/span><\/p>\n

Give the Translation Team a Clear Way to Ask Questions<\/h2>\n

\n Even a well-prepared project can contain ambiguous strings.
\n A clear question-and-answer workflow helps translators resolve
\n uncertainty before assumptions enter the localized product.\n <\/p>\n

\n Product, engineering or localization owners should identify the person
\n who can answer questions about product behavior, terminology and technical constraints.\n <\/p>\n

\n For ongoing localization, keeping decisions in a shared glossary or
\n issue log can prevent the same questions from returning in every release.\n <\/p>\n<\/p><\/div>\n

\n
\n

Project Contact<\/h3>\n

Nominate a person who can answer product and terminology questions.<\/p>\n<\/p><\/div>\n

\n

Shared Q&A<\/h3>\n

Record answers so they can be reused throughout the localization project.<\/p>\n<\/p><\/div>\n

\n

Tool Access<\/h3>\n

Provide necessary access to prototypes, TMS platforms or test builds.<\/p>\n<\/p><\/div>\n

\n

Review Ownership<\/h3>\n

Define who approves terminology and who performs in-context review.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n RELEASE MANAGEMENT<\/span><\/p>\n

Keep Translation Aligned With the Current App Build<\/h2>\n

\n App strings can change throughout development. New features may add
\n strings while product changes remove or rewrite existing content.\n <\/p>\n

\n If translators work from an old export while developers continue
\n updating the source, the final translation package may contain
\n missing, obsolete or inconsistent strings.\n <\/p>\n

\n Use version information, release dates or clear export names so
\n everyone knows which source package belongs to the current release.\n <\/p>\n<\/p><\/div>\n

\n
Build \/ release \u2192 Identify clearly<\/strong><\/div>\n
String export \u2192 Date or version it<\/strong><\/div>\n
Changed strings \u2192 Flag when possible<\/strong><\/div>\n
Deleted strings \u2192 Remove from active workflow<\/strong><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n BKMOS WORKFLOW<\/span><\/p>\n

App Localization Workflow<\/h2>\n<\/p><\/div>\n
\n
\n 1<\/span><\/p>\n

Package Review<\/h3>\n

Review files, target locales, context, technical constraints and deadline.<\/p>\n<\/p><\/div>\n

\n 2<\/span><\/p>\n

Terminology Setup<\/h3>\n

Prepare glossary, style guidance, do-not-translate terms and references.<\/p>\n<\/p><\/div>\n

\n 3<\/span><\/p>\n

Translation & QA<\/h3>\n

Translate strings and review placeholders, terminology and completeness.<\/p>\n<\/p><\/div>\n

\n 4<\/span><\/p>\n

In-Context Review<\/h3>\n

Check localized strings in the product or screenshots and resolve UI issues.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n PROJECT CHECKLIST<\/span><\/p>\n

Before Handing Your App to a Translation Team<\/h2>\n

\n A complete handoff reduces avoidable questions and gives the localization
\n team the information needed to work efficiently from the beginning.\n <\/p>\n


\n DISCUSS YOUR APP LOCALIZATION
\n <\/a>\n <\/div>\n

\n
\u2713 Product overview and target users<\/strong><\/div>\n
\u2713 Localization-ready source files<\/strong><\/div>\n
\u2713 Screenshots or prototype access<\/strong><\/div>\n
\u2713 Glossary and style guide<\/strong><\/div>\n
\u2713 Placeholder and technical instructions<\/strong><\/div>\n
\u2713 Target locales and release deadline<\/strong><\/div>\n
\u2713 Product contact for questions<\/strong><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n RELATED SERVICES<\/span><\/p>\n

Related BKMOS Translation Services<\/h2>\n<\/p><\/div>\n
\n
\n Localization Services<\/strong><\/p>\n

\n Localization support for apps, software, websites and other
\n digital products entering multilingual markets.\n <\/p>\n


\n Localization Services \u2192
\n <\/a>\n <\/div>\n

\n Specialized Translation<\/strong><\/p>\n

\n Technical and specialist translation for product documentation,
\n support materials and related business content.\n <\/p>\n


\n Specialized Translation \u2192
\n <\/a>\n <\/div>\n

\n Translation Project Support<\/strong><\/p>\n

\n Send representative files and project requirements so BKMOS
\n can review the language, format and localization scope.\n <\/p>\n


\n Contact BKMOS \u2192
\n <\/a>\n <\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n FREQUENTLY ASKED QUESTIONS<\/span><\/p>\n

App Localization Handoff FAQs<\/h2>\n<\/p><\/div>\n
\n
\n

Can we send only a spreadsheet of strings?<\/h3>\n

\n A spreadsheet can work for some projects, but translators usually
\n perform better when strings are accompanied by screenshots, comments,
\n product context and technical instructions.\n <\/p>\n<\/p><\/div>\n

\n

Should translators receive access to the app?<\/h3>\n

\n When practical, a staging build, prototype or screenshot set can provide
\n valuable context and support more accurate in-context translation.\n <\/p>\n<\/p><\/div>\n

\n

What should go in an app localization glossary?<\/h3>\n

\n Include recurring UI terms, feature names, product terminology,
\n approved translations and terms that should remain untranslated.\n <\/p>\n<\/p><\/div>\n

\n

Do we need to explain placeholders and variables?<\/h3>\n

\n Yes. Translators should know which elements must remain unchanged
\n and how placeholders behave in the final interface.\n <\/p>\n<\/p><\/div>\n

\n

When should localization testing happen?<\/h3>\n

\n In-context review should happen before release whenever possible,
\n especially for UI text where space, layout and interaction matter.\n <\/p>\n<\/p><\/div>\n

\n

What should we send for a quotation?<\/h3>\n

\n Send sample strings or localization files, target locales, approximate
\n volume, platform information, required workflow and release deadline.\n <\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n

EXPERT REVIEW<\/span><\/p>\n

Reviewed by Nguyen Dinh Phuc<\/h2>\n

\n Founder & CEO of BKMOS. Working in professional translation
\n since 2005 and responsible for BKMOS’s professional direction,
\n translation workflows and expert content.\n <\/p>\n


\n About BKMOS \u2192
\n <\/a><\/p><\/div>\n<\/p><\/div>\n<\/section>\n

<\/p>\n

\n
\n
\n
\n APP LOCALIZATION<\/span><\/p>\n

Preparing Your App for a New Language?<\/h2>\n

\n Send BKMOS your localization files or representative sample strings
\n together with the target locales, platform, product context and
\n release deadline. We will review the content and project requirements
\n before quoting.\n <\/p>\n<\/p><\/div>\n

\n
\n GET A LOCALIZATION QUOTE
\n <\/a>\n <\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/section>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

APP LOCALIZATION App localization works best when translators receive more than a spreadsheet of isolated strings. They need enough context to understand where each string appears, what the user is doing, which terms are fixed product terminology and what technical constraints apply. A well-prepared localization package can reduce questions, inconsistent terminology, broken placeholders, text-overflow issues […]\n","protected":false},"author":1,"featured_media":121,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-120","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-localization-multilingual-content"],"_links":{"self":[{"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/posts\/120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/comments?post=120"}],"version-history":[{"count":1,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/posts\/120\/revisions"}],"predecessor-version":[{"id":122,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/posts\/120\/revisions\/122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/media\/121"}],"wp:attachment":[{"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/media?parent=120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/categories?post=120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bkmos.com\/en\/wp-json\/wp\/v2\/tags?post=120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}