A developer describes their team's localization approach: "We send content to translators two weeks before each release." A localization engineer calls this a batch waterfall approach and suggests switching to continuous localization. What is the key difference?
Continuous localization integrates translation into the development workflow — the translation backlog is small and constant rather than large and crisis-driven at release time.
The engineering implementation: a CI job (triggered on merge to main) runs string extraction, compares new/changed strings to the previous baseline, uploads only the delta to the TMS via API, and the TMS immediately assigns the new strings to translators. Another CI job (scheduled every few hours) syncs completed translations back to the repo via a bot PR. The result: when a feature ships, translations are already in the repo for most languages. Release-blocking "waiting for translations" situations become rare. The caveat: translators need context for new strings — screenshots, descriptions, and in-context review tooling become more important in continuous workflows.
Key vocabulary: • continuous localization — strings extracted and uploaded to TMS automatically on every commit • localization crunch — the time pressure created by batch waterfall: all translations due right before release • delta upload — uploading only new or changed strings to the TMS (not the full file) to minimize translator work
2 / 15
A TMS project manager refers to a language pair in the context of a translation project. What does this term mean?
A language pair (source language → target language) is the fundamental unit of translation work and TMS organisation.
Every translation task, TM lookup, and glossary entry is associated with a specific language pair. en-US → de-DE and en-US → de-AT are different language pairs (Austrian German vs. German German may have different vocabulary preferences). TMS platforms like Crowdin and Phrase allow you to add as many target language pairs as needed while maintaining a single source. The language pair also determines which translation memories are applicable — a TM built from English-to-French translations isn't useful for English-to-Japanese.
Key vocabulary: • language pair — source language + target language combination (e.g., en-US → fr-FR) • source language — the original language the content is written in • target language — the language being translated into; a project may have many target languages with a single source
3 / 15
In a localization review meeting, a PM says: "The strings passed linguistic QA but failed functional QA." What is the difference between these two review stages?
Linguistic QA is about the words (are they correct?); functional QA is about the application (does it work with the translated words?).
Linguistic QA typically catches: mistranslated terms, inconsistent terminology (calling the same UI element by two different names), incorrect register (formal vs. informal), and glossary violations. Functional QA (also called in-context review or localization testing) catches: placeholder not replaced ({name} shows literally in the UI), UI truncation in the target language, incorrect number/currency formatting (displaying $1,234.56 instead of 1.234,56 in German locale), and links or buttons not working after translation. Many teams skip functional QA — then users report seeing {name} literally in the app in their language.
Key vocabulary: • linguistic QA — review of translation quality: accuracy, fluency, terminology, register • functional QA — testing translated strings in the running application; verifies placeholders, layout, formatting • in-context review — translators or reviewers seeing strings in the actual application UI, not just in a spreadsheet
4 / 15
A localization engineer describes a string freeze. What is this, and why is it important in a release workflow?
A string freeze protects translator effort — there's no point translating a string that engineers will rewrite before the release ships.
Without a string freeze, this scenario is common: a translator spends 20 minutes carefully translating a complex error message → a developer changes the message's wording two days later → the translation is now stale and needs to be redone. String freeze discipline prevents this waste. Typical process: declare string freeze 2-3 weeks before release, finish translating all strings, do functional QA, ship. Post-freeze string changes require a change request process with impact assessment (how many languages need retranslation?). In continuous localization workflows, the concept still applies — a "feature string freeze" per feature rather than per release.
Key vocabulary: • string freeze — developer commitment: no new or changed translatable strings after this date • stale translation — a translation that no longer matches the current source string because the source was edited post-translation • change request (l10n context) — process for requesting a post-freeze string change; includes impact on translations
5 / 15
A developer asks: "What is a glossary in a localization context, and why should engineers care about it?"
Glossaries enforce terminology consistency at the source — if source terms are inconsistent, target translations will be inconsistent in every language.
A typical glossary entry: term (English) = "workspace", approved translations: French = "espace de travail", German = "Arbeitsbereich", do not translate: "workspace" in technical contexts (UI element names). Engineers care because terminology inconsistency in the source creates a multiplier effect: if developers use "workspace", "project", and "environment" interchangeably for the same concept, translators will create three different translations across the app — confusing users in every language. The glossary is also used in LQA to flag glossary violations. Engineering contribution: agree on product terminology early, keep it consistent in the source, and add it to the glossary before starting localization.
Key vocabulary: • localization glossary — approved translations for key product terms; enforced in CAT tools to ensure consistency • terminology consistency — using the same term for the same concept throughout the source (and therefore all translations) • glossary violation — using a non-approved translation for a glossary term; caught in LQA
6 / 15
Sarah (Senior Localization Engineer) posts in the team Slack channel: 'Just flagged a potential issue with the French translations for our new UI. They're using 'dark mode' terminology incorrectly – calling buttons 'light' instead of 'dark'. We need to escalate this to the translator.' What is most likely the immediate next step Sarah should take, given her role?
Sarah is responsible for quality assurance and escalating issues. Requesting a full rewrite is often overly aggressive; reverting immediately risks breaking functionality. Scheduling a discussion allows her to collaboratively guide the translator towards the correct usage. Submitting a bug report would be useful later but isn't the immediate priority.
7 / 15
David, a localization specialist, is reviewing a PR description for a new feature. The description reads: 'Implemented enhanced date formatting support across all supported locales. Utilized the i18next library to handle locale-specific date formats.' What does David's review primarily focus on?
David's role involves verifying localization aspects. The description highlights the use of i18next and 'supported locales,' indicating he's checking if the feature correctly handles different date formats across various languages – a core element of translation pipeline success. The other options relate to general development practices rather than specifically localization.
8 / 15
John (Lead Developer) comments on a PR: 'This string is missing context. We need to ensure consistent terminology across all languages.' What does 'consistent terminology' refer to in the context of localization engineering?
'Consistent terminology' is crucial in localization because it prevents translators from making independent interpretations of terms and ensures that the translated output aligns with the intended meaning and brand voice. A glossary or termbase would be a key tool to enforce this consistency across different language pairs. Option A is incorrect as code files should not be identical; option C is misleading, assuming a single source always guarantees quality; and option D isn't relevant to the process.
9 / 15
Maria (Localization Specialist) sends this Slack message: 'The 'dark mode' terminology is causing issues – calling buttons 'ligh' instead of 'dark'. We need to update the glossary immediately.' What is the primary purpose of updating a glossary in response to feedback like this?
The glossary serves as a central repository for defining terms and their intended meanings. When feedback highlights an incorrect translation (like 'ligh' instead of 'dark'), updating the glossary ensures that translators have access to the correct terminology moving forward, mitigating future errors and improving overall quality. Options A and D are related to documentation or task management, not the core function of a glossary.
10 / 15
A localization engineer is reviewing a draft translation for a marketing campaign. The source text reads: 'Limited time offer!' One of the translated versions says 'Offre limitée dans le temps !'. Which best describes the issue?
The core message – 'limited time' – is preserved. While a more direct translation might have been possible, the current phrasing is acceptable and doesn't fundamentally alter the meaning or urgency. A key issue here isn't *incorrect* terminology, but rather a stylistic difference that, while noticeable, doesn't compromise comprehension.
11 / 15
Sarah (Senior Localization Engineer) posts in the team Slack channel: 'Just flagged a potential issue with the Spanish translations for our mobile app. The UI text is using gendered nouns without proper adaptation – e.g., 'el usuario' instead of 'los usuarios'. We need to review this immediately.' What does she primarily mean?
Sarah is highlighting a common localization challenge: gender agreement. Spanish nouns have genders (masculine or feminine), and translations need to reflect this accurately. Using 'el usuario' instead of 'los usuarios' demonstrates a failure to adapt the text for correct grammatical usage within the target language.
12 / 15
A localization engineer is preparing for a new product launch. They identify several strings that need translation but also notes the need to create a glossary of key terms related to the product's features. Why is this glossary important?
The glossary serves as a central reference point for translators. It guarantees they use the correct and approved terminology throughout the project, preventing inconsistencies and errors that can arise from relying on individual interpretations or assumptions.
13 / 15
During a Slack discussion about the localization of a new e-commerce feature, Sarah (Localization Engineer) posts: 'We need to ensure all UI strings are translated into Japanese and that we're using the correct honorifics.' Which workflow step does this primarily represent?
This message highlights the importance of maintaining consistent terminology – a core principle of localization. The correct answer reflects the direct action of managing terms across languages; the other options represent different aspects of the process but aren't the primary focus of Sarah's communication. It's about *terminology management*, not just style or validation, although those are related concerns.
14 / 15
A localization engineer discovers that a translated string contains an incorrect gendered noun in Spanish. The source text was: 'El cliente es amable.' (The client is friendly). One of the translated versions says 'El cliente es amables'. What does this represent?
This scenario highlights a *grammatical inconsistency*. Spanish requires gender agreement – nouns must match their articles and adjectives in gender. 'Amables' is incorrect; the correct form would be 'amigable' (masculine) or 'amigables' (feminine), depending on the context. The other options represent potential issues, but this specific error directly relates to grammatical rules.
15 / 15
During a standup meeting, John (Lead Developer) says: 'We're freezing the strings for the German version of our mobile app. We need to finalize the translations before we start development.' What does 'string freeze' mean in this context?
A 'string freeze' signifies a *development pause*. It means that no further development work should proceed until all necessary translations are finalized. This prevents integration issues and ensures consistency between the source code and the localized versions. The other options represent subsequent steps after the freeze is lifted.
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Localization Engineering Language exercises?
Browse the full Localization Engineering Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.