Translation, localization & transcreation FAQs

Translation focuses on meaning between languages. Localization adapts the complete experience for a locale, which may include formats, layout, images, product behavior, legal requirements, testing, and release operations.

Use transcreation when the content's job depends on persuasion, humor, wordplay, emotion, brand voice, or cultural reference. Give the team a creative brief and define what must remain fixed, what can change, and who approves market-level choices.

It can. A complete inventory may include interface strings, documents, help, screenshots, graphics, on-screen text, metadata, subtitles, captions, dubbing, voice-over, and audio description. The statement of work should name every modality and delivery format.

Localization covers the complete work needed for a locale, including language, formats, product behavior, and testing. Cultural adaptation is the narrower decision to change references, imagery, examples, interaction, or assumptions for an audience. State which changes are permitted and who approves them.

Localization can prepare and coordinate regulated content, but a translator or localization reviewer is not automatically local counsel or a regulatory approver. Identify which material requires qualified legal, medical, financial, safety, or compliance review and keep that approval separate and traceable.

Prioritize complete user journeys rather than isolated string counts: acquisition, onboarding, core tasks, payment, support, safety, and recovery. Include the content, emails, help, data, and operational support those journeys depend on so the first release is usable rather than superficially translated.

Combine user demand, revenue or mission potential, regulatory obligations, current product readiness, language data and talent availability, support capacity, and cost of failure. A language name alone is not a market plan; define region, script, audience, and product coverage.

Clear, stable, unambiguous source; complete sentences; defined variables; approved terminology; content ownership; useful context; and a controlled change process. Source cleanup often saves more downstream effort than negotiating a lower translation rate.

Purpose, audience, market, screen or media context, character limits, variables, screenshots, related strings, product behavior, terminology, voice, legal constraints, and examples. Context should travel with the content, not live only in someone's inbox.

Name the language tag or market variety, script, audience, product surfaces, content versions, platforms, accessibility assets, and fallback behavior. Separate interface language from support, legal, marketing, and user-generated content coverage; they may launch on different schedules.

Forecast by content class and service, then include engineering, project management, terminology, review, testing, minimums, multimedia, tools, and contingency. Model release frequency and source churn as well as initial volume. A word count alone omits much of the work that makes a launch function.

Freeze what can be frozen, send versioned deltas, mark obsolete content, preserve translator work, and identify which targets need retranslation or review. Agree a change cutoff and change-order rule before production so urgent corrections do not become silent scope expansion.

Inventory and prepare source content; extract or hand off assets; analyze scope and reuse; translate or adapt; review; run automated checks; build or render; perform in-context and functional QA; fix and verify; approve; deliver or release; then capture feedback and update assets.

Self-review is always useful, but it is not equivalent to an independent second judgment. Use separation when risk, visibility, regulation, contractual assurance, or evaluator bias requires it. Define who has final authority.

Classify feedback as defect, preference, source change, terminology decision, or scope change. Resolve disagreements against the brief and evidence, record accepted decisions in assets or guidance, and avoid silently training a workflow on contradictory reviewer preferences.

Treat a match as prior evidence, not automatic approval. Review according to match type, context, age, provenance, previous quality, product version, and risk. Exact text can require a different translation when the speaker, screen, variable, or intended meaning changes.

Give market reviewers a defined purpose, in-context access, terminology authority, severity guidance, and a deadline. Ask them to explain requirements rather than rewrite by preference. Route language defects, source changes, legal decisions, and brand choices to the owners who can resolve each one.

Tie every target to a source version, locale, asset or string identifier, workflow state, and release or build. Preserve change history and approval evidence. A filename containing final does not provide enough control for parallel releases, recuts, or post-launch corrections.

It fulfills the intended purpose for the target audience while preserving required meaning, terminology, tone, completeness, and constraints. Quality is contextual; define the requirements before scoring the output.

No. Native or dominant-language competence can support target writing, but professional work also needs source comprehension, writing skill, domain knowledge, research, tools, reliability, and knowledge of the target market. Qualification should be task-specific and demonstrated.

Language often allows several valid solutions, and reviewers may apply different briefs, variants, styles, or risk assumptions. Calibration, examples, terminology, severity rules, and a clear decision owner turn disagreement into useful evidence.

It is language review inside the screen, document, design, or media where the audience encounters the content. It reveals ambiguous source relationships, truncation, variable behavior, tone, visual hierarchy, and cross-string consistency that a bilingual editor cannot show by itself.

Check approved and forbidden terms in context, not only exact word matches. Review concept, inflection, capitalization, product naming, audience, and surrounding grammar. Record legitimate exceptions so automated checks do not keep reporting the same false positive.

Define purpose-specific requirements. A support article may prioritize accuracy and search terminology; a campaign may prioritize effect and voice; a safety warning prioritizes unambiguous meaning; interface text must also fit interaction and variables. One universal rubric creates misleading scores.

Check completeness, tags, variables, numbers, terminology, status, encoding, file validity, target rendering, links, fonts, layout, directionality, locale formats, and the actual user journey. A clean bilingual file is not proof that the product works.

List delivered files and versions, languages and locales, checks performed, unresolved issues, deviations, approved changes, dependencies, build or media identifiers, review window, and the contact path for defects.

The deliverable may include final monolingual assets, bilingual working files, translation memory, terminology, reports, media packages, and a delivery note. Specify formats, versions, naming, encoding, metadata, and ownership before work begins so usable assets are not trapped in a tool.

Choose a window that reflects volume, reviewer availability, release timing, and the consequence of acceptance. Define whether silence means acceptance, how defects discovered later are handled, and which changes are corrections versus new scope. Avoid windows too short for meaningful in-context review.

List each issue with locale, asset, impact, evidence, owner, workaround, decision deadline, and whether it blocks release. Accepted risk needs a named approver. Do not bury open issues in email threads or deliver a clean status while exceptions remain.

It verifies that agreed files, locales, checks, approvals, and evidence are complete and that open deviations are understood. Acceptance is a contractual or release decision; it should not be confused with a reviewer making stylistic changes after delivery.

It is a release-connected operating model, not simply an automatic repository sync. Content states, source quality, branching, context, review rules, exception queues, QA, observability, and rollback all need owners.

Stabilize source messages, externalize complete content, provide context, govern terms, remove duplicate review authority, test hard files early, separate defects from preferences, and measure where work returns for correction.

Provide locale, product version, exact location, source and target, screenshot or media timecode, user impact, steps, and urgency. Route the issue to the right owner, verify the correction in context, and update reusable assets or tests when the cause can recur.

Show demand, queue state, lead time, release coverage, severe defects, rework, exceptions, cost, and evidence by locale and content class. Every metric should support an operational decision. Avoid dashboards that reward raw throughput while hiding delayed or low-quality locales.

Pause when critical meaning, safety, legal, payment, privacy, or functional failures exceed the agreed risk threshold and cannot be contained. Define rollback ownership, fallback language, user communication, data preservation, and re-release evidence before an incident occurs.

Assign owners and review cadences for translation memory, terminology, style, screenshots, test data, connectors, and locale rules. Retire obsolete content, correct confirmed errors at the source, and version material changes so future work does not inherit hidden defects.