How do you translate an Eleventy website into multiple languages while keeping localized page URLs, language-switching links and missing-content behaviour under control? This Eleventy internationalization guide explains the built-in i18n plugin, page.lang, locale_url, locale_links, errorMode, content structure and multilingual quality assurance. It is designed for international publishers, documentation teams, nonprofits and small websites whose readers need dependable content rather than a decorative language menu.
Eleventy’s internationalization plugin helps manage relationships and links between localized pages, but the official documentation is explicit that it does not itself translate strings, numbers, dates or the content of articles. A language link can therefore be technically correct while the target page is untranslated or incomplete. A locale-specific date can be formatted differently without changing the actual event time. Teams need a workflow that connects translated meaning, route generation and the public experience.
Imagine a global conservation charity using Eleventy to publish habitat surveys, volunteer onboarding and community event information in English, Spanish and French. Volunteers may share links to specific instructions, download a checklist or search for a local event. The charity must keep the facts, permissions and deadlines accurate in every language. This tutorial develops a manageable publishing model using Eleventy’s documented i18n tools, with practical examples, fallback choices, review procedures and release tests.
Quick answer: the Eleventy localization workflow
Choose a source language and a set of target languages the organization can maintain. Organize translated pages under clear language directories or a documented alternative. Configure Eleventy’s bundled I18nPlugin, set the defaultLanguage and choose an errorMode appropriate to the release policy. Use locale_url for language-aware links in shared templates and locale_links to discover corresponding translated content. Then supply actual reviewed translations through files, data and any chosen string-localization library.
Test public deep links, missing-language cases, text and data formatting, navigation, accessibility and release freshness. The plugin helps connect page versions; it cannot determine whether a Spanish sentence preserves a conservation instruction or whether an updated English consent requirement has reached French readers. Publication requires both a working route and an approved explanation.
What Eleventy’s i18n plugin does and does not do
The official Eleventy documentation describes the I18nPlugin as utilities for managing pages and links between localized content. It is bundled with Eleventy in supported versions and supplies helpful page and template tools. Crucially, it does not localize text, numbers, dates or other content automatically. Those tasks may use translated templates, data files, an appropriate library, or a combination selected by the site developers.
Treat those as two separate projects. The route project provides stable language URLs and prevents incorrect links. The content project supplies trustworthy language, localized examples and reviewed regional facts. In the charity’s website, a Spanish page may load at /es/volunteer/ while still containing an English consent paragraph copied from the source. The plugin does not detect that semantic defect. A reviewer needs to read the final page and test what the volunteer is actually asked to do.
Start with a small reader journey
Choose a pilot that represents real visitor needs: discover the conservation event, understand eligibility, review a volunteer safety guideline, register an interest and find a current contact. The pilot should include one translated informational page, one structured data-driven page, one form and an intentionally missing translation. These cases reveal more about readiness than a dashboard that counts language folders.
Give the test a clear result. A Spanish-speaking reader should identify the location and time correctly and know whether registration is required. A French-speaking reader should understand the warning and reach a relevant contact. The site should not imply that submitting a form guarantees participation when the actual process only records interest. This approach defines translation quality in terms of reader decisions and obligations. Once those outcomes work, extend the model to the wider website.
Choose languages without confusing language and region
English, Spanish and French are language labels, not single-country descriptions. A translated article can serve audiences in several countries, while a local volunteer event still has a specific venue and applicable rules. Choose a language code that accurately describes content, and use region-specific variation only when the organization genuinely maintains distinct vocabulary, dates, policies or legal instructions. More locales create more review obligations.
Record the audience for each language edition. Will readers use a mobile phone in the field, a shared computer in a community office or a screen reader? What reading level and terminology are appropriate? Who can approve specialized habitat terms? A language decision should be supported by reader needs and a named reviewer. This helps prevent the common mistake of launching many language URLs with only fragments of translated content and no plan to maintain them.
Organize files so equivalent content can be identified
The Eleventy internationalization guide discusses organizing files by locale, often with a separate folder for each language. A predictable structure such as /en/, /es/ and /fr/ makes translated pages uniquely addressable. The team can keep matching conceptual names where useful, while allowing natural translated headings. The file structure is an editorial contract as well as a technical one: it should make it easy to identify corresponding versions without guessing from a translated title.
Create a page identity table with the original topic, source revision, target-language file, public URL, reviewer and publication state. This remains useful when one language combines two short source pages or needs a different introduction. Avoid relying on filename similarity alone as proof that pages say the same thing. A French page labeled ‘Volunteer guide’ could contain a procedure from an older programme. Stable identities help catch that mismatch before publication.
Understand the choice between distinct URLs and negotiation
Eleventy’s official i18n guide discusses two broad URL approaches: distinct paths for languages, such as /en/about/ and /es/about/, or content negotiation in which the server selects content for one apparent path. Distinct paths are generally straightforward to link, cache and share on static hosting, while content negotiation can require server configuration and introduces challenges for explicit language choices. Neither approach should be selected solely for visual neatness.
Think about a volunteer who sends a Spanish safety link to someone else. If the recipient’s browser silently selects English at the same URL, the shared link may no longer deliver the intended language. Distinct URLs make the choice explicit. If a project chooses negotiation, it needs an accessible language override and careful testing of cache keys, redirects and browser preferences. Write the expected behaviour down before translating large numbers of files.
Why explicit locale URLs are useful
A URL that identifies the language is easy to copy into a message, print as a QR code, share in a support email and review in a release checklist. It also gives editors a stable way to distinguish the Spanish event page from the French one. Eleventy documentation notes that distinct paths are linkable and cacheable without complex rewriting, although teams must normalize internal links so a language edition does not accidentally send visitors back to the default language.
A public site can still suggest a visitor’s browser-preferred language on first arrival. The essential safeguard is to respect an explicit selection. If someone opens /es/evento/ directly, do not force them to /en/event/ because their browser happens to prefer English. The language URL is part of the reader’s intent. A reliable multilingual website lets people choose, share and return to the same information deliberately.
Configure the bundled I18nPlugin correctly
The Eleventy documentation explains that the I18nPlugin is bundled with Eleventy in supported versions, so a separate plugin installation may not be needed. The configuration passes options including defaultLanguage and errorMode. Read the version-specific official guide before applying an example, especially when a project uses an older Eleventy release or different configuration-module syntax. A working code snippet from a recent guide may not match the installed project.
Keep the configuration small and explicit. The default language should match the actual source content. Decide how strict missing-page detection should be before a release, and test the intended plugin filters in the site’s chosen template language. Treat the configuration file as software: review changes, run a build and open the resulting pages. A syntactically valid configuration is only the first step; it does not prove that translated pages have meaningful content.
Use page.lang as the page’s language context
Eleventy’s plugin exposes page.lang for templates, representing the language associated with the page and falling back to the configured default when applicable. This helps shared layouts choose appropriate navigation, labels and language-related HTML. However, the value reflects routing or page context, not an independent reading of the article’s prose. A page.lang value of es cannot prove that the content was translated accurately into Spanish.
Test the emitted HTML lang value and the actual visible text together. If a missing Spanish article falls back to English content, decide how to communicate that fact instead of automatically labeling the result Spanish. Screen readers and search engines rely on accurate language signals. A simple release test should open the page, inspect its language attribute and read its first substantive paragraph. If those disagree, investigate whether the problem lies in routing, editorial content or the layout.
Use locale_url for links in shared templates
The official I18nPlugin provides a locale_url filter for transforming a link to the appropriate locale. This is particularly useful for shared navigation and footer templates where hard-coded paths are fragile. A template can generate an appropriate blog or contact URL based on the current page’s language rather than requiring a separate set of English, Spanish and French links typed by hand. The result still needs testing against pages that actually exist.
Avoid treating locale_url as a translation-content availability checker. A properly transformed path can point to an untranslated or unpublished page. Build an explicit coverage map or apply an honest fallback rule. Test links in a full reader journey and from several starting pages, not only the homepage. When a visitor follows a Spanish introduction to a safety checklist, the link should point to the correct reviewed Spanish checklist or clearly explain why it cannot.
Use locale_links to find actual translated relatives
Eleventy also supplies locale_links, which helps discover other localized content associated with an input file. This can support a language switcher that offers the relevant translated versions of the current page. Its value is greatest when the site has a coherent file organization and the team understands how content relationships are detected. It is not a substitute for checking that a target’s meaning and factual revision match the source.
Test pages with full translation coverage, partial coverage and deliberately missing versions. A language switcher should not imply that French content exists merely because the site has a French homepage. Check a deep volunteer-guideline page and an event page whose translation has been withdrawn for correction. If locale_links does not find a valid target, design a clear reader experience. The correct behaviour might be to omit the unavailable option or offer a labeled source-language fallback. Never invent a translation by linking to an unrelated page.
Make errorMode a conscious release decision
The Eleventy plugin documents errorMode options including strict, allow-fallback and never. These control when missing localized content should trigger errors. A strict setting can catch absent expected pages early. A permissive setting may suit a staged rollout but can also allow gaps to pass a build unnoticed if the team stops paying attention. The correct choice depends on the site’s architecture and the risk of incomplete information.
Test each chosen mode against an intentionally missing target page in a small staging project. Record the expected build result and the intended reader-facing outcome separately. A build that refuses missing content protects against one class of omission; it does not detect poor translation. A build that permits fallback does not certify the fallback’s accuracy or accessibility. Do not call the language edition complete because the build returned success. Use the plugin behaviour as one control within an editorial acceptance process.
Distinguish allow-fallback from honest content coverage
Allowing fallback can be helpful when a source-language page remains useful while translations are in progress. But the reader must know which language is actually displayed. A Spanish page shell with an English body may cause frustration, while an inaccurate Spanish safety page could create greater risk. Decide what fallback means at the page level and whether a warning, explicit link to the source or publication block is appropriate.
Keep a coverage table with states such as ready, awaiting language review, awaiting subject review, outdated and missing. Use the table to control what the language menu advertises. For high-impact instructions, a permissive build option may need an additional editorial gate that prevents unreviewed target content from being deployed. This is not unnecessary bureaucracy: it protects the meaning and conditions of the action a reader is about to take.
Use the right tool for translated UI strings
Eleventy’s documentation explicitly notes that the bundled I18nPlugin does not localize strings, numbers or dates. Projects can use translated template data or another string-localization library, depending on their needs. The official documentation mentions several possible libraries but does not declare one universal choice for every Eleventy website. Select one that fits the template language, development workflow and maintainer skills.
Create a list of UI strings: menu items, button labels, confirmation messages, form errors, donation or registration statements, cookie notices and footer links. Give each stable identity and reviewed target values. Test variable interpolation so a number or name is inserted without changing its meaning. If the form indicates that a request was received, do not translate that as approval of participation. Localizing interface strings is part of communicating product behaviour, not just visual polish.
Format numbers and dates without altering facts
Locale-aware number and date presentation can make content easier to understand, but formatting is not translation of the underlying factual value. A conservation event that begins at 14:00 local time should not acquire a new time when the page is displayed in Spanish. A date written as 05/06 may be ambiguous internationally. Prefer unambiguous formatting in important public notices and state the relevant time zone where visitors may come from different regions.
Test values that commonly cause errors: decimal separators, grouping, dates, currencies, percentages and units. Preserve machine-readable identifiers and data keys. If a report contains a site coordinate or scientific measurement, changing punctuation can alter the interpretation or break a parser. Distinguish display formatting from data storage and verify both. A library that formats a date cannot decide whether the underlying event date is correct; that still requires editorial approval.
Give structured data its own translation model
Many Eleventy sites generate pages from collections or data files, not only standalone Markdown articles. An event page may combine a translated description with shared identifiers, dates, locations and registration status. Decide which fields are language-dependent and which must remain common across locales. A stable event ID and start time should not be manually duplicated differently in every translation file. Descriptions and explanatory labels may need separate target-language values.
Test the page after changing the shared event data. Does every language display the same actual location and capacity? If a venue changes, who approves the update and how quickly does it reach the Spanish and French editions? Avoid making translators responsible for guessing factual data. Keep a source-of-truth record for operational values and a translation record for human-facing language. This separation reduces accidental contradictions while allowing natural writing in each language.
Translate Markdown and template content deliberately
Eleventy supports multiple template languages and content formats. A multilingual project can mix Markdown articles, Nunjucks or Liquid layouts, JavaScript templates and data-driven components. Each format has a different surface where reader-facing text appears. A team should inventory those surfaces before asking translators to work, because not everything the visitor sees is located in a Markdown file. Some labels are generated by a layout or collection filter.
Create one representative sample with a heading, paragraph, list, table, external link, internal link, code-like identifier and a form error. Translate it, build the site and inspect the rendered output. Confirm that template syntax remains valid, variable names are unchanged and the intended language appears in every user-facing surface. Good translation can be broken by an unescaped character or a misplaced template delimiter, so rendering is part of the review.
Preserve placeholders and data relationships
A string such as ‘Registration closes on {date}’ contains both meaning and a placeholder. The target language may require a different word order, but the placeholder must continue to receive the correct value. Do not translate the machine key unless the code explicitly supports it. For pluralized phrases, do not assume English singular and plural rules cover every language. Use an appropriate message format or library when the language requires more forms.
Test with values zero, one, two and a larger count. A phrase that looks correct when ten places remain may be wrong when one remains. Validate a volunteer confirmation email as well as the on-screen message if both derive from translated strings. Translation quality includes the complete sentence after variables are substituted. A reviewer should see example outputs rather than approving only raw placeholders without context.
Make the language switcher stateful only when needed
The simplest language switcher offers clear links to actual corresponding pages. A site may also remember a visitor’s choice, but persistent preferences should not override a direct language URL. If someone opens a French guide shared by a colleague, the page should not instantly switch to Spanish merely because the browser stored an older preference. The visible language and the address should agree.
Test the selector without JavaScript if the site’s architecture supports ordinary links. Try keyboard navigation, narrow screens and a screen reader. If the chosen page has no target version, the selector should not send the reader silently to an unrelated homepage. A good selector helps people navigate the same topic in another language, with an honest explanation when an equivalent is not available. It is a content relationship tool as much as a UI control.
Respect accessibility when changing languages
A translated website needs correct document language metadata, meaningful link text and a keyboard-operable language menu. Screen readers use language information to choose pronunciation, and users may depend on the heading hierarchy to navigate long guides. Test each edition rather than assuming that accessibility work done on English pages carries over automatically. Longer text can overflow buttons, and accented characters can expose font or encoding problems.
For a French volunteer safety guide, listen to one section with a screen reader and check the order of headings, warnings and links. Verify alternative text for important images. If the site includes mixed-language quotations or technical terms, handle them thoughtfully. Avoid using a country flag alone as an accessible name for a language option. A person choosing a language should understand the option without needing to infer which nation the icon represents.
Preserve technical and scientific identifiers
Conservation documentation may contain species codes, survey identifiers, coordinates, software commands and measurement units. These are often precise tokens rather than ordinary language. Translate their explanations but keep the identifiers and underlying values stable unless the responsible subject specialist explicitly approves a change. A friendly-looking local-language name is not a substitute for a scientifically valid species identification or a code expected by a data system.
In a translated field checklist, distinguish a word that describes a sampling site from the exact site ID stored in a database. Test any example upload against a safe fixture. If a translated CSV header is meant for readers, it may be appropriate; if it is a machine schema key, changing it can break downstream processing. Document those boundaries before translators begin. A translation that preserves meaning but destroys a data import is not successful documentation.
Localize images, captions and downloadable files
A Markdown page might be fully translated while its diagram, PDF checklist or video captions remain in the source language. Inventory those assets and assign an explicit state. A shared photograph can often be reused, but its alt text and caption may need local-language descriptions. A diagram containing actions or labels may require a translated version and a technical check that the visual relationships have not changed.
Do not rename an English PDF with a Spanish filename to create an illusion of translated coverage. Label the asset’s actual language and version. Test download links in each locale and compare attachments with the linked article’s current instructions. A volunteer may print a field checklist and never return to the website. That makes the accuracy and version of the downloaded file as important as the article that introduced it.
Design terminology guidance around real actions
A glossary should explain how terms are used rather than merely list word pairs. Words such as observation, detection, record, sample and specimen have different meanings in scientific and volunteer contexts. Describe the intended concept, approved target term and common misleading synonyms. Include a sentence showing the action and an unchanged technical identifier where relevant. Ask readers or regional reviewers which expressions are recognizable in their work.
Review terminology when a source project changes definitions. A term used for preliminary sightings may later be reserved for verified observations. The translation should reflect the updated concept, not only maintain an older preferred word. Treat consistency as a way to preserve understanding. An overly rigid glossary that forces one term into unrelated contexts can create errors, while an undocumented free-for-all makes maintenance difficult. Context is the useful middle ground.
Track source revisions and trigger targeted re-review
A translated page depends on the source version it represents. Store a stable source identifier and revision in the editorial record. When the English source changes, classify the change as cosmetic, terminology-related, procedural, factual or safety-critical. Send reviewers the relevant diff and a short explanation. Do not assume that every commit requires complete retranslation, but do not allow a changed obligation or warning to pass without human consideration.
If volunteer registration eligibility changes, the target versions must be checked quickly. If a photograph is replaced with an equivalent image, the review may focus on alt text and captions. Keep a list of language editions that are current, pending review or intentionally held. Public pages should not display a broad ‘updated’ label implying that all languages match the newest source when some important translations still reflect older conditions.
Distinguish translation from regional applicability
A Spanish-language article may serve readers in several countries, but a particular conservation activity takes place under local permits and safety rules. A translator must not change legal conditions, field-access restrictions or emergency contacts based solely on the target language. The project owner should determine the factual scope of each page. If a region has genuinely different requirements, provide a clearly labeled local variant or separate section with approved information.
This is particularly important for permissions and consent. A translated volunteer form should preserve what participants are agreeing to. Regional privacy or safeguarding requirements cannot be invented by an editor and should not be copied blindly from another jurisdiction. Give policy owners the source and target passages that create obligations, and ask them to approve the appropriate claims. The language team can then express those decisions clearly and naturally.
Make SEO reflect real language coverage
A search-engine result should bring someone to content in the language promised by its title and metadata. Distinct language URLs make those expectations easier to manage, but they are not sufficient by themselves. A Spanish route with English text and a Spanish title is misleading. Use natural search-intent phrases in the article’s opening, provide meaningful headings and explain the task thoroughly rather than repeating keywords to attract traffic.
Inspect canonical and alternate-language signals in the generated HTML. Verify they point to public, genuine translations of the same topic and do not advertise unavailable variants. Check that internal links remain in the selected language where equivalents exist. If a target edition is in progress or outdated, apply an honest editorial policy instead of presenting it as a complete current guide. Search visibility should support reader success, not disguise gaps.
Test collections and pagination in every language
Eleventy can generate lists, archives and navigation from collections. A shared collection template may accidentally mix English and Spanish articles if it does not account for locale. Test index pages, tags, search results and next/previous links as part of the translated site. A Spanish volunteer landing page should not interleave unmarked English stories when visitors expect Spanish content. If cross-language links are intentionally offered, identify their language.
Pagination creates additional edge cases. A locale with fewer translated posts may have fewer pages than the source edition. Avoid generating empty or broken page links just because a shared template assumes equal counts. Test the first page, a middle page and the end of each collection. Ensure pagination labels, dates, excerpts and destination links are understandable and correct. Lists are not secondary: many visitors encounter the content through an archive before reaching an individual article.
Use a realistic production build for acceptance
A local Eleventy build can confirm that templates compile, but public behaviour also depends on deployment, redirects, caching, link paths and asset hosting. Build with the intended plugin and dependency versions, then examine the generated HTML and visit the staging site as an anonymous reader. Test the default-language root, several localized deep links, the selector, search if installed and downloadable files. Confirm that no staging hostname appears in public canonical or alternate links.
If the site uses content negotiation, test the server’s language response and cache behaviour with different browser preferences. If it uses distinct routes, verify those routes work from a direct request and not only from internal navigation. A build that completes successfully may still contain broken links to unbuilt target pages. Release evidence should include both a clean build and a real end-to-end reader task.
Test error modes with deliberately missing content
Create a low-risk pilot page with English and Spanish versions but no French equivalent. Run the configured Eleventy build and observe the result under the selected errorMode. Confirm that the behaviour matches the policy the team intended: fail when missing content matters, allow a documented fallback when suitable, or tolerate absence without pretending that the missing page exists. The plugin’s documented options are a tool for enforcing expectations, not a judgment of translation quality.
Then follow the public page’s language links. Does the selector offer French, and if so, where does it lead? If French content is unavailable, is the source language labeled clearly? Repeat with a high-impact safety page where the fallback policy may be stricter. Separate the result of the build from the result of the reader test, because both need to pass. This exercise catches hidden assumptions before the site expands to hundreds of pages.
Test a complete translated form journey
A volunteer form has multiple language surfaces: introduction, field labels, hints, required-field notices, error states, privacy statement and confirmation. The site may generate these from an Eleventy page plus a third-party service. Translating the visible page is not enough if the hosted form reverts to English during validation or the confirmation message makes a promise the organization did not make.
Use fictional test data and follow the process through submission or a safe staging endpoint. Check whether the language remains understandable when a required field is missing. Confirm that dates and names are displayed without corruption, that consent choices remain explicit and that a confirmation does not imply an accepted placement when only an enquiry was submitted. Assign ownership of third-party text separately, because the Eleventy plugin cannot fix external service behaviour.
Investigate broken locale links systematically
When someone reports that a Spanish page opens English content, capture the source URL, expected language, actual destination and whether the link came from navigation, an article or the language selector. Determine whether the shared template used locale_url, whether the translated file exists and whether locale_links identified the appropriate equivalent. Then inspect any host redirect or cache rule that may override the generated URL. Avoid changing correct translations until the routing cause is understood.
Reproduce the issue in a clean browser session and after a direct request. Fix the smallest responsible layer, then rerun the same path and a neighboring page to check for regressions. Record the result in language and technical terms: the navigation filter was corrected, a missing French file was created and reviewed, or a redirect rule was removed. This gives future maintainers actionable evidence instead of vague reassurance.
Investigate outdated target content
A translated page can link correctly and still be factually stale. Compare its source revision against the latest approved source document. Look at what changed: event dates, eligibility, required equipment, safety instructions or an explanation of methodology. A target page may need a small terminology update or a complete specialist review depending on the changed claim. Do not simply overwrite the target file with a newer machine-generated draft and call the issue closed.
Record the target’s current state and give the reviewer a focused change summary. If the issue affects a live high-stakes instruction, temporarily warn readers or withdraw the target until the meaning is verified. If the target remains useful but incomplete, say so clearly. A link relationship is a helpful maintenance signal, not proof that two language versions communicate the same current facts.
Investigate a missing language selector entry
Check whether the language edition and corresponding page exist, whether the selected template calls locale_links correctly and whether the site’s directory relationships match the plugin’s expectations. Then inspect rendered markup and any custom navigation rules. A locale may be intentionally absent for an untranslated deep page, even while its homepage exists. Do not force every language into the menu merely to make it visually symmetrical.
If a valid target exists but is not offered, repair the file relationship or template logic according to the documented plugin behaviour. Test the selector at the target page and on several other pages. Check keyboard access and long labels on mobile. The correct end state is a language choice that points to the same substantive topic and does not create false availability claims. A working dropdown that lies about content is not a completed fix.
A practical seven-page pilot for a small organization
Build a source homepage, programme overview, volunteer guide, safety notice, event listing, contact page and application form. Translate the first six into Spanish, and only a subset into French. Configure the Eleventy I18nPlugin and deliberate errorMode, then use locale_url for shared navigation and locale_links for available equivalents. Add reviewed strings for buttons, errors and confirmation text using the chosen content method. Test date formatting and the content of shared data-driven event listings.
Ask volunteers who did not build the site to follow a realistic task from a shared link. Observe whether they find the right event, understand eligibility and reach the form without unexpected language changes. Include a missing French page to verify how absence is handled. Review links, downloads and screen-reader behaviour. Fix the pilot before expanding the language programme. This small investment saves the team from replicating broken assumptions throughout a large site.
How to measure progress without misleading completion claims
Count meaningful readiness, not only files. Track the number of current, approved translated pages that support important user tasks, the number of overdue source changes, unresolved critical errors and broken language links. Record whether translated forms and downloads are included in coverage. A high percentage of existing files can coexist with serious gaps if the most consequential workflow remains untranslated.
Review test failures by cause: source ambiguity, terminology, template string, wrong locale URL, missing target page, stale content, accessibility or formatting. This helps allocate work correctly. The translation team should not be blamed for a CDN redirect, and developers should not be asked to decide the right level of certainty in a scientific claim. Progress is meaningful when fewer readers encounter wrong information and more can complete tasks reliably in their chosen language.
Release checklist for Eleventy i18n
Verify the approved source revision and target-language content, then confirm Eleventy version, I18nPlugin configuration, defaultLanguage and chosen errorMode. Check page.lang, locale_url links and locale_links results in the final rendered site. Inspect source-to-target page equivalence, navigation, collections, pagination, translated template strings, numeric formatting, accessible language labels, images, downloads and forms. Validate technical identifiers and obligations against the approved source.
Test direct deep links, an unavailable translation, browser preference handling if used, SEO metadata and actual public deployment. Record whether a fallback is visible and truthful. Attach the build and reader-task results to a release record. Do not publish a high-consequence target page with unresolved substantive issues merely because a permissive errorMode allowed the site to compile. The last gate is a reader who can act on the translated information safely.
Frequently asked questions about Eleventy internationalization
Does Eleventy’s I18nPlugin automatically translate text? No; the official documentation explicitly says it helps link localized content rather than translate strings or format numbers and dates. Do I need to install it separately? It is bundled with supported Eleventy versions; check the installed version. What does locale_url do? It transforms links for the page’s locale in shared templates. What does locale_links do? It helps find related localized pages. Does page.lang certify translation quality? No; it expresses page language context.
What is errorMode for? It controls missing-localized-content error handling; it is not a semantic review. Are distinct language URLs useful? Yes, particularly for shareability and static hosting, though content negotiation is another documented approach. Should missing content be silently displayed as translated? No. Can a site launch with partial translation? Yes, with honest scope and appropriate quality gates. What is the best test? Follow a real reader task, including links, labels, forms and the final action.
Official Eleventy references and further reading
Consult Eleventy Internationalization plugin documentation for the bundled plugin, page.lang, locale_url, locale_links and errorMode settings. Read Eleventy Internationalization overview for file organization, distinct URLs, content negotiation and related design choices. These are the primary references for the feature-specific guidance here; verify the installed version before copying any configuration examples.
For broader translation concepts, see Master Art of Translation and browse the Translate Like a Pro series index. The purpose of this chapter is to make Eleventy-specific multilingual publishing practical. Translation accuracy, source factual review and regional applicability remain separate responsibilities even when every link works as intended.
Conclusion: a localized link must lead to trusted information
Eleventy supplies useful tools for associating localized pages and keeping links in the intended language. These tools are valuable precisely because multilingual sites are difficult to maintain as their source content and navigation change. But a correct locale URL cannot tell a reader whether a safety warning is current or an event condition was translated accurately. Technical structure and editorial reliability must work together.
Begin with explicit language paths, tested locale filters, a deliberate missing-content policy and a small complete reader journey. Keep content identities and revisions connected, use real reviewers for consequential claims and inspect the public result after deployment. A successful multilingual Eleventy site is not one with the most language folders. It is one where readers can find the right information and rely on what it tells them to do.