How do you build a multilingual Gatsby website when translated Markdown, GraphQL data, page routes and SEO tags do not automatically travel together? Searches for Gatsby localization, Gatsby i18n, gatsby-theme-i18n, Gatsby multilingual SEO and internationalized static sites reflect a practical challenge: each translated page needs a real route and the correct content at build time, not just a language button on the client.
Gatsby’s documentation describes several ways to internationalize React content, and its plugin directory documents gatsby-theme-i18n as an option for creating language-prefixed pages with locale metadata and React helpers. No single theme removes the need to translate articles, map equivalent entities, protect embedded code or check the generated HTML. Content sourced from files or external CMSs introduces another layer that must match the selected locale.
This guide explains how to design complete Gatsby language editions, compare plugin approaches without mixing their assumptions, shape localized GraphQL content, test generated routes, preserve navigation through language switches, and release indexable pages with honest canonical and alternate links. Worked scenarios cover small documentation sites and larger editorial catalogs. The measure of success is simple: can a visitor finish the same task in the language they selected?
Quick answer and reader checklist
Gatsby supports multiple localization approaches rather than one mandatory built-in translator; the documented gatsby-theme-i18n theme is one option for generating language-aware pages. For a dependable result, check the true language of the page, its underlying data, the next link in the task, numeric conditions, accessible interaction and the language of search results. Every Gatsby language page should be a complete, buildable edition whose navigation, data, metadata and links agree. Start with one complete high-value path, test it on the deployed site and expand only after readers can finish it.
Contents
- How Gatsby localization actually works
- Foundations for maintainable language editions
- Twenty-six worked problems with diagnosis and repairs
- A six-stage release plan
- Questions and official references
How the pieces of a translated system connect
A multilingual Gatsby project has several layers. The source language is the starting explanation, not an automatic guarantee that equivalent wording exists everywhere. A locale policy identifies audiences and permissible fallback behavior. A publication route connects a public URL to content and user interface. The underlying software must deliver the same actual permission, calculation, procedure or product state regardless of prose language. Search, accessibility and ongoing corrections determine whether the experience remains usable after release.
Separate those layers in review conversations. Ask which content edition is being rendered, which identifiers the underlying application expects, which user action is promised, and which release contains the correction. A successful translation is not merely a sentence that sounds natural. It is a trustworthy instruction attached to the correct state of Gatsby build pipeline, gatsby-theme-i18n, GraphQL page nodes, client navigation, metadata and localized content. This distinction also protects against accidental duplication: a general guide to translation theory cannot substitute for the specific mechanics of this platform.
Ten foundations for translating real systems
1. Gatsby is a build and data framework
Gatsby builds pages by combining React components, sourced content and build-time data. That architecture is powerful but it makes translation a coordinated publishing process. A translated markdown file is not helpful if no page is generated for it; a language-prefixed route is not helpful if its GraphQL query returns the original text. Draw the path from source file to final page before choosing a plugin.
Make the principle concrete with one current page, one source-language counterpart and one non-default-language counterpart. Follow the public URL and inspect the actual words and links a visitor receives. The most important evidence is what someone can do after reading, not whether a configuration switch is present. Write down the smallest observable check for that behavior.
2. Do not mix plugin assumptions
Gatsby’s i18n overview discusses a range of libraries for React, while the gatsby-theme-i18n plugin provides particular route and localization helpers. Community plugins have their own patterns and version histories. Select one tested route strategy and one message strategy, then document which module owns redirects, links, `lang` attributes and metadata. Copying unrelated snippets without checking compatibility invites subtle production bugs.
When reviewing this layer, separate language quality from technical correctness. A polished sentence can still point to the wrong route, name an obsolete setting or reverse a condition. Assign both a knowledgeable subject reviewer and someone fluent in the target language. They are answering different questions, and agreement between them is more useful than an automated completion percentage.
3. Use real content editions
Pages with long explanations, legal details or technical procedures need reviewed language-specific content. Translate summaries, headings, file metadata and image descriptions as well as body paragraphs. Keep a stable source-page identity across editions so translators and developers can tell which German document corresponds to which English document, even when slugs differ. Do not force word-for-word structure when a target audience needs clearer context.
A practical audit records a stable item identifier, source revision, language, destination URL, known gaps and a result after deployment. This may sound meticulous, but it prevents a common failure: a team fixes a translation in source control while readers continue receiving the previous version from a cache, static build or unupdated catalog. Confirm delivery, not intention.
4. Treat GraphQL as content delivery
A Gatsby source plugin or file transformer may expose locale fields, language-suffixed filenames or separate collection nodes. The query must filter correctly and avoid accidentally mixing language data. A page builder can create the right path while a component fetches default-language sidebar text. Write tests for complete page data, not only for route generation.
For the reader, the boundary between an application framework and editorial content is invisible. They see one page and form a single expectation about its instructions. Test the entire experience with a natural task such as finding a setting, completing a form, recovering from an error or sharing a link. Record any forced return to another language as a defect worth understanding.
5. Static output needs direct-link tests
Gatsby client navigation can look correct after one page has loaded, while a user arriving on a deep translated URL receives a 404 or an incorrect static page. Inspect generated public output and the hosting platform’s routing configuration. Treat a cold browser visit, a refresh and a copy-pasted link as distinct tests. All three should reach the same language edition.
Make the principle concrete with one current page, one source-language counterpart and one non-default-language counterpart. Follow the public URL and inspect the actual words and links a visitor receives. The most important evidence is what someone can do after reading, not whether a configuration switch is present. Write down the smallest observable check for that behavior.
6. Understand prefixed and unprefixed defaults
The gatsby-theme-i18n documentation describes default language and prefixDefault options. Those choices affect duplicate-path risk, link generation and canonical addresses. A multilingual site should have one declared URL policy with redirects for legacy paths. Language detection may be convenient, but should not defeat explicit links in a public article, checkout or support message.
When reviewing this layer, separate language quality from technical correctness. A polished sentence can still point to the wrong route, name an obsolete setting or reverse a condition. Assign both a knowledgeable subject reviewer and someone fluent in the target language. They are answering different questions, and agreement between them is more useful than an automated completion percentage.
7. Make localized links meaningful
A generic language switch that always goes to a homepage interrupts a reader’s task. Map equivalent page identity across locales and provide a considerate fallback where translation is missing. The Gatsby Link component and plugin-provided localization helpers have different responsibilities. Verify that links generated in templates, markdown content and navigation all retain appropriate locale context.
A practical audit records a stable item identifier, source revision, language, destination URL, known gaps and a result after deployment. This may sound meticulous, but it prevents a common failure: a team fixes a translation in source control while readers continue receiving the previous version from a cache, static build or unupdated catalog. Confirm delivery, not intention.
8. Build-time SEO is visible evidence
Search engines inspect the generated title, description, language declarations, canonical URL, alternate-language relationships and body. Gatsby’s Head API can contribute metadata; localization integrations may also add alternate links. Avoid duplicate or conflicting tags by clarifying ownership. A self-consistent set of actual translated pages is more valuable than mechanically generated hreflang references to missing documents.
For the reader, the boundary between an application framework and editorial content is invisible. They see one page and form a single expectation about its instructions. Test the entire experience with a natural task such as finding a setting, completing a form, recovering from an error or sharing a link. Record any forced return to another language as a defect worth understanding.
9. Technical content is not just prose
A Gatsby documentation site can contain fenced code, queries, React component names, environment variable examples, API endpoints and screenshots. Translate explanation and reader-facing labels but protect literal syntax. Run the snippets when possible. A translation that introduces a wrong GraphQL field can break a tutorial even when the page builds successfully.
Make the principle concrete with one current page, one source-language counterpart and one non-default-language counterpart. Follow the public URL and inspect the actual words and links a visitor receives. The most important evidence is what someone can do after reading, not whether a configuration switch is present. Write down the smallest observable check for that behavior.
10. Plan for partial publication and change
Not every article will be translated on the same day. Maintain per-language coverage and source revision status, and decide how untranslated routes respond. When the English article changes a procedure or guarantee, distinguish a critical translation update from a harmless style edit. A stable language-specific URL should never silently serve dangerously outdated advice without a notice.
When reviewing this layer, separate language quality from technical correctness. A polished sentence can still point to the wrong route, name an obsolete setting or reverse a condition. Assign both a knowledgeable subject reviewer and someone fluent in the target language. They are answering different questions, and agreement between them is more useful than an automated completion percentage.
Twenty-six worked Gatsby translation and publication problems
Each case below starts with a plausible reader-facing failure, explains why the technical or linguistic layer matters, proposes a repair and ends with a concrete test. The examples are operational patterns rather than promises that a particular package will supply every behavior automatically. Check the official documentation for the installed version and your actual publishing arrangement.
1. Choosing a plugin family
The situation: A developer installs gatsby-theme-i18n and copies navigation components from an unrelated Gatsby i18n plugin. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Two packages may use different context providers, route policies and locale identifiers despite similar marketing descriptions. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Select a documented architecture, remove conflicting route owners and verify the tested Gatsby version. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Build a minimal two-language site and inspect generated paths before adding editorial content. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
2. Default language route prefix
The situation: Some English pages live at /about and others at /en/about after a configuration change. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: A prefixDefault choice can produce different address expectations across templates and legacy links. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Choose one policy and add deliberate redirects and canonical signals for superseded paths. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Open home, article and category links under both address shapes and record the final response. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
3. Locale config accuracy
The situation: A team adds French-Canadian and French-French editions while treating both as a single ‘fr’ string. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Shared language and regional editorial differences may have different legal, pricing and terminology requirements. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Specify locale identity and real content coverage rather than assuming one code represents every audience. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Inspect two region-specific pricing or policy pages to ensure differences are intentional and reviewed. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
4. Markdown filename pairing
The situation: A German Markdown document exists but is never associated with the English article. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: File suffixes or source metadata may need explicit mapping based on the chosen theme and sourcing pipeline. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Define a stable translation identity and test the filename convention against documented plugin behavior. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Generate all pages and locate both language URLs in the build output. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
5. GraphQL query locale filter
The situation: A French route renders an English headline because its GraphQL query selects the first node. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: The route name and data filter can be assembled by different layers in a Gatsby template. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Filter content on explicit locale and page identity, then handle missing nodes deliberately. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Request a translated blog entry with a unique sentence that never appears in the English file. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
6. Distinct article slugs
The situation: The French edition uses a localized slug but the language switch appends /fr to the English slug. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Slugs are editorial URLs, not a predictable character-for-character translation. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Maintain approved route equivalents for each article and resolve switches through shared identity. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Switch from a deeply nested English article to its French equivalent and back. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
7. Page creation collision
The situation: Two generated page records claim the same path after language prefixes are disabled. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Overlapping paths can overwrite intended output or create unpredictable links. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Detect duplicate routes during build and review how default-language paths are generated. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Run a route inventory for identical public paths across the content collection. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
8. Client-side navigation mismatch
The situation: Clicking from a German home page keeps German state, but refreshing the target link displays English. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Client state can hide a missing static build or incorrect host rewrite rule. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Test actual built files and host behavior independently from React in-browser navigation. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Paste the link into a fresh browser and refresh it with cached assets disabled. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
9. Component message catalog
The situation: Menus are translated but modal confirmation text remains English. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: React message libraries may be wired into one subtree or not cover custom modal content. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Inventory components and provide the correct locale context at every rendering boundary. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Open account, help and confirmation dialogs under all supported languages. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
10. Plural message behavior
The situation: The page says ‘two articles’ correctly in English but gives an ungrammatical count in Polish. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Plural categories and formatting depend on language, not just the substitution of a numeral. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Use a suitable message library and translated plural rules, then review rendered values. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Test representative counts with native-language reviewers rather than checking only one item. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
11. Sourced CMS fallback
The situation: A remote CMS returns the English excerpt for a Japanese Gatsby page. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Locale requested during build may not be the same as the one encoded in the final path. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Pass an explicit locale to the source retrieval system and inspect returned field values. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Compare generated data, rendered HTML and CMS revision IDs for a known Japanese article. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
12. Build on stale translation cache
The situation: A newly translated article fails to appear until an unexpected cache reset. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Incremental builds can preserve old query results or generated pages when dependency tracking is wrong. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Trace Gatsby build inputs, deployment cache and content source changes before forcing rebuild policies. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Publish a small translated update and check the real deployment artifact and revision. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
13. Language-specific image
The situation: A screenshot shows an English software interface beneath Spanish instructional text. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: A translation can rely on visual affordances that do not match the actual audience’s interface. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Use localized images or accurate image notes, and update alt text with the target audience in mind. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Ask a reader to locate an option without assuming identical icon position or English words. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
14. GraphQL error after field rename
The situation: A translated field schema changes and only German builds fail. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: GraphQL selection and inferred schema can depend on available content fields across languages. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Use explicit schema expectations where suitable and test every locale with sparse example content. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Remove an optional translated field on staging and verify sensible fallback or build failure. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
15. Head metadata ownership
The situation: The localized component and theme both emit canonical links that disagree. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Multiple SEO helpers can write overlapping tags and create contradictory crawl signals. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Assign one clear owner for canonical, alternate links and page descriptions. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Inspect built HTML source for duplicate canonical tags and mismatched hreflang targets. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
16. Hreflang target existence
The situation: A language list automatically advertises a French URL for an article not yet translated. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Locale availability at site level does not guarantee page-level equivalence. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Generate alternate links only for confirmed published counterparts, or use a clear page-level policy. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Check every alternate destination on a sample of partially translated content. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
17. Search across language editions
The situation: A Spanish search query returns only English titles because a single default-language index was built. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Search pipelines can index one content collection while translated nodes stay outside the searchable set. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Build and evaluate language-appropriate indexes or result filtering using the selected search provider. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Have native speakers search common task phrases and open result pages for locale consistency. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
18. Header and footer links
The situation: The article is Italian, but footer links point to unprefixed English legal text. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Global UI often uses separate data and routing from article templates. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Localize global navigation where real editions exist and preserve meaningful fallback labels where they do not. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Use a mobile viewport to follow each main footer and account link. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
19. Anchor changes after translation
The situation: A shared support link to a heading fragment no longer works after French headings change. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Auto-generated IDs commonly derive from headings, so translated titles produce different fragments. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Set stable IDs where supported and maintain old anchors when readers have bookmarked them. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Open saved release-note links to specific translated sections and check correct scroll targets. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
20. Mixed-direction content
The situation: An Arabic article includes English code variables and numeric query arguments that display in confusing order. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: RTL direction may be appropriate for prose but should not change literal program syntax. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Isolate code and mixed-script identifiers so visual order and copy-pasted bytes remain correct. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Check rendered and copied GraphQL query fragments on mobile and desktop. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
21. Broken asset paths
The situation: A translated page references an image with a relative path that resolves under the locale prefix. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Route prefixing changes URL context and can expose fragile path construction in Markdown. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Use robust asset references supported by the Gatsby pipeline and test build-time resource resolution. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Open images and downloadable files directly from deep English and French pages. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
22. Redirect based on language detection
The situation: A browser configured for German is redirected away from an explicit French article link. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Aggressive browser-language redirects can ignore what the user chose or what another person shared. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Respect explicit locale paths and offer reversible user choice. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Open direct French links in German-language browser profiles and compare final URLs. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
23. Indexable partial translation
The situation: A language home page claims full coverage while its articles are mostly English fallbacks. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Search engines and visitors may see inconsistent language and thin duplicate material. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Publish genuinely useful translated collections and disclose missing coverage. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Sample ten indexable paths from the locale sitemap and inspect their actual language. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The correction should be traceable to a precise language edition, not a generic task called ‘fix localization’. Capture the URL, affected sentence or UI state and the release to which it belongs. A translator can then repair the wording while a developer ensures the right content and behavior are delivered to readers.
24. Stale procedure across editions
The situation: A product’s API key rotation instructions change in English but not on its translated Gatsby documentation site. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Static generation preserves whatever data existed at the last build, including outdated translated advice. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Record release alignment, prioritize hazardous procedures and block stale critical editions when necessary. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Compare revision history and current commands in two languages before shipping a new software release. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
If the content addresses a consequential choice, preserve negation, eligibility, thresholds, time conditions and who must act. Translation can change sentence order and culturally familiar examples, but cannot quietly expand permission or narrow a warning. Verify the meaning with the relevant subject specialist before publishing.
25. Static export and hosting
The situation: The Gatsby build succeeds, but hosting redirects missing localized routes to the default home page. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: A configured host can override the static output’s intended 404 or route fallback behavior. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Check the deployed edge rules and final response codes of language-specific deep URLs. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: Request a valid translated page and an intentionally missing one with browser and command-line clients. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
The reader-facing question is whether the same task can be completed without guessing what the original English meant. Ask a fluent reader to describe the action in their own words, then compare that description with the product’s real behavior. Where names and flags are literal inputs, avoid translating the bytes simply to make the sentence look uniform.
26. Correction ownership
The situation: Readers send translation corrections but the project cannot locate the corresponding source article. This is a useful test because the page may look convincingly localized at first glance, yet a visitor following the full task receives a different result from the one implied by the visible words.
Why it goes wrong: Unlinked language editions and inconsistent slugs make issue reports hard to reconcile. In Gatsby work, language selection, content retrieval and the action performed are separate stages. A failure in one stage may remain hidden while the others continue functioning. Review both the human interpretation and the actual output, particularly when a condition, permission, link or code sample affects what happens next.
A practical repair: Record stable content ID, language, source revision, severity and content owner. Keep the approved source meaning and technical identifiers available to reviewers. Record the relevant locale, content identity and software revision so this correction can be reproduced. A good fix improves the reader’s outcome rather than merely making a warning or button look cleaner.
A test worth running: File a sample French correction and trace it through review and rebuilt public HTML. Write down the expected result before testing, and verify the observed result in the rendered or deployed product. Repeat with the default language as a reference and a second target language if supported. When the outcome differs, identify whether the defect belongs to translation, routing, data, component rendering or publication.
Do not confuse a green build with a correct instruction. Inspect the page, link, search result or response that a real visitor receives from a fresh session. Then test a boundary condition: missing translation, unusual input, a refresh, or a recent source change. Boundary checks often reveal errors that the happy path hides.
A six-stage implementation and release plan
Stage 1: Choose architecture
Map Gatsby version, source plugins, content records and installed localization packages. Establish a single page and locale model before adding new dependencies.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Stage 2: Create the route inventory
Design prefix policies and equivalent page IDs; test static and client-only routes with direct navigation.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Stage 3: Translate meaningful content
Review prose, metadata, interface messages and images; protect code samples and link translated source nodes to their parent identity.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Stage 4: Validate GraphQL and builds
Run clean builds for each language, inspect data fields, detect duplicate routes and test source-to-output revision alignment.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Stage 5: SEO and user trials
Inspect Gatsby Head output, canonicals, alternates, accessibility and localized search; ask readers to finish complete tasks.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Stage 6: Sustain editions
Track content revisions, translation lag, build cache and correction reports; publish changes as coordinated language releases.
For this stage, produce a visible acceptance artifact: the URLs or message IDs examined, the locales supported, the current content or package revision, the reviewer responsible and the behavior observed. Do not close the stage on the basis of file existence or a successful build alone. Run at least one direct-link test, one task completion test and one nondefault-language test before progressing.
Reader workshop: how to judge a translated procedure
Choose one realistic user task from Gatsby—for example a settings change, a new account, a document search or a troubleshooting path. Read the source instructions once and note the exact outcome, conditions and data required. Now follow the translated edition without referring to English. If the result differs, do not immediately rewrite the translation. Identify whether the translated words, displayed controls, route mapping, backend data or a cached release caused the discrepancy.
A second reader should repeat the test using a shared deep link, not only navigation from the home page. A third reader should test with a narrow screen or keyboard navigation. Include an error state and one case with a quantity, deadline or permission boundary. These variations transform a language quality review into a usable service review. They also expose hidden dependencies that a spelling check cannot find.
Document the outcome as a short, concrete statement: ‘In language X, opening page Y from a fresh session showed the intended instructions for release Z, the next link stayed in language X, and the action matched its description.’ If that statement is false, it tells the team what to fix. A vague score such as ’98 percent translated’ does not.
Frequently asked questions
Does Gatsby have one required i18n solution?
No. Gatsby documents several approaches; choose tested integrations that agree on routing, messages and data.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
What does gatsby-theme-i18n contribute?
It documents locale-aware page generation and helpers, but it does not independently write accurate longform translations.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
Can GraphQL return the wrong language?
Yes. A correctly localized URL may still use a query missing a locale or content-identity filter.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
Must translated slugs match English?
No. Maintain a stable content identity and a deliberate URL for each language.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
Why do direct translated links fail?
A missing generated page or host routing issue can be hidden during client navigation.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
Can a language switcher lead to a home page?
It can, but equivalent-page navigation is generally more useful; explain when no counterpart exists.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
What should be translated in technical tutorials?
Human instructions, headings, captions and context; not literal syntax or identifiers unless the actual API changes.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
How should alternate SEO links be generated?
Only for verified published equivalents with consistent canonical targets.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
How can we test Gatsby localization?
Use clean builds, fresh direct URLs, real source data, native queries and accessibility checks.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
What should change when English content updates?
Review language editions for semantic changes, particularly safety, technical procedures and promises.
The safest verification is to test this claim on the installed version of Gatsby with a real translated page or message. Check both the words a visitor reads and the behavior promised by those words; if a capability belongs to an added library or hosting configuration, document that dependency rather than attributing it to the core framework.
Official references, related lessons and next reading
Read the official source material: Gatsby localization guide, gatsby-theme-i18n documentation, Gatsby Head API. Match examples to the versions installed in your project. For broader questions about meaning, context and equivalence, see Master Art of Translation. For this platform-focused family, use the Translate Like a Pro series index. These links connect a specific implementation guide to a larger understanding of translation without replacing the platform checks that make a localized product dependable.
The most useful definition of a good multilingual release is practical: people reach the intended information, understand the same conditions and can complete the same legitimate task. Every Gatsby language page should be a complete, buildable edition whose navigation, data, metadata and links agree. Maintain that standard after content updates, dependency upgrades, new locales and corrections. Language quality is not a one-time export; it is part of keeping the product truthful.