How do you translate a CrafterCMS website into several languages without serving the wrong page or silently falling back to an older source? This CrafterCMS localization guide explains language-based content targeting, locale folders, fallback rules, navigation, preview and publishing tests. It is designed for site editors, developers and translation teams who need a multilingual CrafterCMS site that real readers can use with confidence.
If you are setting up CrafterCMS multilingual content, the first decision is not which word to translate. It is how each requested URL maps to a target language, which content file will answer the request, and what happens when that file does not exist. A site may display a translated headline while linking to a default-language form or presenting an unreviewed fallback as though the entire page had been approved.
This practical CrafterCMS content localization tutorial starts with a small English-Spanish example and then moves through Engine targeting configuration, localized content paths, file-based content, Git-backed publication, templates, APIs, accessibility and search. It distinguishes documented platform behavior from editorial choices. By the end, you will have a reproducible acceptance checklist for an international website, not merely a language picker that looks correct in preview.
Quick answer: what to do before translating your first page
Begin with a list of supported locales, public routes, source owners and people allowed to approve translations. Create an English source page and a Spanish destination page with the same content purpose. Confirm which URL each audience enters, which locale the engine selects, which fallback applies and how the navigation finds its destination. Translate the page’s meaning, not only its title. Then check any form, image, date and related link used to complete the task.
Keep the original page identifier, editorial state and revision information together in the translation register. Do not assume a content folder proves that a page is published. Make a deliberate decision about missing languages: show a clearly identified fallback, return a helpful unavailable page, or delay that route. Finally visit the production-style route in a clean session and compare what was delivered with what was approved. Each answer becomes a repeatable publishing test.
The central idea: language targeting is content resolution
CrafterCMS can resolve targeted content by a configured target, often a language. Its documented 4.1 localization example enables targeting in Engine configuration, defines a root content folder and chooses a fallback target. Under the documented folder convention, related locale folders sit beneath a site website root. That makes localized paths part of content delivery, not simply a label in the authoring screen.
For a team, this means two questions must be answered separately. Can a visitor request a locale, and is there an appropriate item to serve in that locale? The language selector may answer the first while the repository answers the second. A successful request can still return the fallback page. Editors need a visible way to know which language actually supplied the content, especially when readers rely on instructions, promises, deadlines or eligibility information.
A realistic example: an international public science exhibition
Imagine a nonprofit publishing an exhibition called Rivers After Rain. The source site contains an introductory page, downloadable visitor guide, registration form, program schedule and location information. Visitors in Spain require Spanish explanations; visitors in Costa Rica need Spanish wording and perhaps market-specific contact instructions. The team maintains one approved scientific description but publishes several language-specific reader experiences.
The source might describe how a watershed responds to heavy rainfall. An inaccurate translation could imply every flooded river has identical risks. A careless implementation could display a Spanish introductory page with an English safety notice. Neither failure is fixed by translating an additional button. Build a map of every component that contributes to the journey: URL, template, body, sidebar, assets, form validation, search result, email confirmation and outbound reference. Then decide which items are translated, regionally adapted or shared unchanged.
Start with a language and market register
Use a compact register with one row for each locale: display name, intended audience, locale code, owner, reviewer, source language, public path, fallback rule and release date. Do not use a country code to stand in for a language. Spanish can be read in many markets; a separate country-specific message might be necessary, but only where policy, contact details or context actually differ.
The register should also say whether a language variant is being prepared, reviewed, visible to staff or publicly available. Those are not synonyms. Give the translator a clear scope and an accountable owner for claims. The same Spanish phrase can be correct in one context and misleading in another if the underlying service is limited to a market. The register prevents a change to one local audience from becoming a silent claim for everyone who happens to read that language.
Set up content roots and folder structure carefully
In the published CrafterCMS 4.1 localization guide, an illustrative Engine targeting configuration uses /site/website as the root, with locale-named folders such as en and es beneath that root. A page may then be represented by related descriptors, for example under /site/website/en or /site/website/es. These are illustrative paths; a site’s blueprint and conventions determine its actual content tree.
Before copying a large library, test a single route and document which descriptor serves it. If a Spanish route points to a nonexistent file, observe the fallback rather than guessing. Avoid creating parallel folders with inconsistent names or mixing neutral and region-specific variants casually. A structure that looks tidy to editors can still create public duplicates or missing pages. Make the locale directory decision once, test it against navigation and deployment, and explain it in ordinary language to every contributor.
Understand the target-selection configuration
The CrafterCMS 4.1 documentation shows targeting settings such as enabled, rootFolders, fallbackTargetId, mergeFolders and redirectToTargetedUrl. They control distinct aspects of resolution. Enabling targeting is not the same as choosing a visitor’s language, and specifying the root does not decide which translations are trustworthy. Fallback gives Engine another location to try when the requested targeted content is not present.
Treat each setting as a testable behavior. With targeting disabled, document what the route returns. With it enabled, request a language-specific page. If the direct URL is expected to redirect to a targeted path, compare the response status and destination. If folders are merged for navigation, inspect the resulting list of items. Keep a change log showing which environment and product version were used, because configuration examples cannot substitute for an actual deployment test.
Fallback is an editorial decision as well as a technical one
The documented resolution example shows a region-specific target such as es_CR falling through to the base language es and then to a configured fallback such as en. That is useful for sharing a trustworthy generic Spanish explanation when a Costa Rican page has not been authored. It can be dangerous when a regional rule, phone number or eligibility requirement differs. A fallback chain says where content may be found; it does not establish whether that content may safely be presented.
Classify content by risk. Universal educational background often tolerates transparent fallback. A registration deadline, fee, consent request or local safety message may require a reviewed market-specific version. Decide whether the visitor should see a notice, a temporary unavailability response or the fallback with its language plainly marked. Test those choices for every important route, not just the home page. Otherwise the site can appear more translated than it really is.
How folder merging changes navigation expectations
When configured, merging targeted folders can help the engine construct a combined content tree for navigation. The benefit is continuity: a site can know that certain pages exist in related target locations. The hazard is that a menu may acquire items whose final content is absent, unreviewed or inappropriate for the visitor’s market. The rendered list must still be checked from the point of view of the reader.
Walk the full navigation under each locale. Click the third-level article, open the breadcrumb parent, follow the related reading link and inspect the search result. Observe which language supplies the visible title and which page supplies the destination. A navigation tree is not a translation-quality certificate. Publishing teams should have an explicit rule for suppressing incomplete links rather than assuming merged trees always provide a useful fallback.
Custom target IDs need a narrow specification
CrafterCMS documents customization through a TargetIdManager when an application wants targeting by aspects other than straightforward language. A custom manager can determine the current target, available targets and fallback. This allows more complex scenarios, but also moves the responsibility for correctness into project code. Do not deploy a custom rule just because a translation team wants a market name in a spreadsheet.
First write sample requests and expected outcomes. For example, a visitor asking for Spanish content with a Costa Rican market preference should receive a specific market variant only where one has been approved. A visitor with no preference should get a predictable public default. Explain which user setting, request parameter or route determines selection, and which wins when two signals conflict. Test unauthenticated users and caching; otherwise one visitor’s language may leak into another’s response.
Do not confuse translated content with interface translation
A page body is only one surface. Templates may generate headings, search controls, alert labels, breadcrumbs, empty states and error messages. The source content can be fully localized while the interface strings remain English. Conversely, a Spanish interface may wrap an English article that is being served through fallback. Both are legitimate technical outcomes and require explicit editorial decisions.
Inventory those surfaces separately. Assign each string a context and expected audience. A button labeled Apply might mean submitting a form, accepting a discount or applying a filter. Translation cannot be approved from that word alone. Store the destination text and the action it represents together in the review notes. Test the rendered interface by completing the action, not by inspecting isolated labels. Readers need the entire interaction to remain understandable even when validation fails.
Keep stable identifiers separate from prose
Content descriptors often contain machine-oriented identifiers, paths, template references and other structural values. Those should generally stay stable when editors translate visible fields. A translator who rewrites a page identifier to make it sound natural can break a link or move the wrong item. Conversely, a deliberately translated public slug can help readers, provided the route mapping remains explicit and durable.
For every model field, mark one of four behaviors: shared unchanged, translated, market-specific or computed at runtime. The choice should be documented beside the field and illustrated with a real example. Shared data may include item IDs and scientific measurement units; translated content includes explanatory prose and accessible labels; local data may include contact information and schedules. Avoid solving all four with a single text-replacement rule. Preserve source records so a future revision can be traced to its translated dependents.
Content models should make completeness visible
A content type that hides important explanatory text inside loosely structured HTML is harder to translate safely than one with meaningful fields. Consider storing title, summary, body, hero image, caption, call to action, publication date and contact details in predictable places. Not every field needs a different value in every locale, but editors should know which ones do.
Create an authoring checklist for each content type. A translated article cannot pass merely because title and body are filled when its button still links to the original-language payment page. Provide a content status for each locale that separates drafted from approved. When a field is legitimately identical across languages, record that deliberate reuse instead of treating it as missing work. This turns the content model into a quality-supporting instrument rather than a place where omissions hide until a visitor reports them.
Translate linked components as a connected system
A museum page may embed a speaker biography, news card and schedule widget. Each element can have its own source revision and language availability. If the main page is Spanish but the linked biography was updated yesterday in English, which version should a visitor receive? The answer depends on the site’s promise and the risk of the information. At minimum, the experience should not pretend that missing translation is a completed one.
Use a dependency map: main page links to components, components link to assets, assets link to captions and downloads. Include reusable elements that appear on dozens of pages. A changed contact detail might require one source correction; an altered claim may require several locale reviews. Test shared components under each language before approving the page. A single incorrect reusable CTA can spread a misleading action across an otherwise high-quality multilingual website.
Handle editorial preview and public delivery separately
CrafterCMS authoring and delivery commonly involve different environments or targets. A preview can expose content that is not yet live, and the Crafter Engine content-store API documentation explicitly warns that preview can return disabled items for authoring purposes. This is useful for editors and unsafe as the only proof of publication. A page appearing in Studio does not mean a public reader can retrieve it.
For each release, capture both preview and public outcomes. Record the source revision being reviewed, the target-language version and the expected public URL. Check direct access while signed out, not only through an editor session. Observe the rendered page, its assets and internal links. If an endpoint returns a descriptor successfully, still verify that the public template interprets it correctly. Document the last complete public test rather than reporting the project as finished at the moment somebody presses Publish.
Git-backed publication requires release discipline
CrafterCMS uses Git-backed project content in its broader architecture, and publication is an operation that must be distinguished from translation approval. Editing one locale’s content files can be tracked, compared and moved through environments; it can also introduce conflicts if several branches change related descriptions or templates. A successful merge establishes a repository state, not the quality of the resulting translation.
Use coherent change sets. A Spanish release should identify its source revision, changed descriptors, relevant media, routes and any shared template changes. Review diffs for accidental deletions and strings left in the wrong language. Confirm that the actual delivery target has received the intended change. Be careful with emergency fixes: publishing a source correction while a translation is under review can invalidate target claims. The release record should answer exactly which wording went live, in which locale and with whose approval.
Design URL patterns before SEO begins
Search engines and readers both need unambiguous language destinations. Decide whether public URLs use language paths, subdomains or a separately managed host. Make the site serve each intended URL reliably with direct requests and sensible redirects. A browser preference should not unexpectedly take a reader away from a URL that was deliberately shared. If automatic language selection exists, provide a visible way to choose differently.
The website should emit appropriate HTML language metadata and language alternate relationships where applicable. Search snippets, title tags, descriptions, structured data and accessible names must correspond to the actual page language. Avoid marking a fallback English page as a completed Spanish translation simply because it is reachable under a Spanish path. Determine whether an incomplete locale should be indexed, redirected or withheld under the site’s publication policy. Test the outcome using rendered HTML rather than only a CMS field list.
Hreflang and canonical URLs describe different things
A canonical URL answers which URL is preferred for substantially equivalent indexing. An alternate-language link helps identify different language or regional versions. They are not interchangeable. A multilingual site that sends every language page’s canonical URL to English can make its translated pages less discoverable. But claiming a missing Spanish page in an alternate-language set also misleads crawlers.
Build a small matrix of approved public pages. For each one, list its canonical URL and its approved alternate language URLs. Only publish relationships supported by actual, accessible destinations. If a page lacks a valid target translation, do not create a fabricated alternate merely to complete a neat table. Revisit the matrix after redirects or slug changes. Readers and search engines alike benefit from a route system that describes what exists rather than what the team plans to translate someday.
Language metadata and right-to-left layouts
Every delivered page should declare the appropriate language for its primary content. When a quote or embedded segment uses another language, mark that segment instead of mislabeling the whole page. If the product adds Arabic or Hebrew, the team must review directional layout, numbers, inline links, punctuation and mixed-script passages. Translation is not achieved by reversing all alignment settings.
Test headings, navigation, tables, footnotes and form controls at mobile widths. Names, email addresses and URLs may require directional isolation within a right-to-left sentence. Buttons should not be reordered in ways that change the meaning of a dangerous or irreversible action. Images containing text need separate localization decisions. Assistive technologies rely on accurate language markup to select the correct pronunciation and reading conventions. Include at least one screen-reader and keyboard-only journey in release acceptance.
Forms are a separate localization project
A visitor may read an exhibition guide successfully but abandon a registration form because labels, required-field errors and confirmation email remain in another language. Make a form inventory covering the input label, help text, validation message, privacy notice, button, post-submit result and follow-up communication. The meaning of an agreement or consent choice must remain consistent throughout the journey.
Do not translate machine keys or backend field identifiers as if they were visible prose. Preserve the submitted data model and test how values appear in staff workflows. In a staging environment, submit one valid record and several invalid records under each locale. Examine server-side errors, not only client-side warnings. A translated form that loses the country code, mishandles decimal separators or displays an unapproved privacy statement is not ready to publish merely because its interface looks polished.
Handle dates, currencies and numbers as data
A locale affects presentation, but it should not silently alter the underlying value. A source schedule saying 14:30 UTC is a different kind of information from a translated sentence about the schedule. Store timestamps and time zone identities as data, then render an understandable local form with context. Never replace a currency amount with another country’s number as though the exchange were a translation.
Record which facts are universal and which are market-specific. An admission fee may genuinely vary by region, but then the content must link to a policy owner and revision. A scientific quantity must retain its dimension and units even if punctuation changes. Test a page containing a four-digit year, a decimal, a range, a negative value and an explicit time zone. Review what the visitor believes, not merely whether separators look customary. Context prevents a beautifully localized error from becoming a consequential one.
Search indexing needs its own acceptance tests
A translated page is less useful if the search function does not retrieve it. A headless or API-driven implementation may index content using a separate service with its own language analyzers and caching. Do not assume that publishing locale folders automatically creates good translated search behavior. The crawler may index a default-language fallback, or an editor-only result may appear in a public index.
Search for a distinctive approved phrase in each language and confirm that the result title, excerpt and destination share the reader’s locale. Test an untranslated term and a proper name as controls. Decide how search should handle diacritics and language variants without rewriting identifiers. Inspect whether a withdrawn translation remains in results after the page disappears. Record the index refresh event separately from the content publication event, because a page and its search card can disagree for some time.
Media and downloadable files must be reviewed
Images can carry meaning through labels, legends, instructions or cultural assumptions. A translated page may display a photograph safely across languages, yet still require a translated caption and alternative text. A map or infographic with embedded words needs a language-specific replacement or an accessible text equivalent. Do not treat the file name as a sufficient description of its content.
For downloads, record whether the document itself is translated and what version it represents. Label an English-only PDF clearly on a Spanish page rather than implying that it is a Spanish resource. Make sure links point to the correct current file. Review video captions, transcripts and audio language selection. When the same file is reused in several markets, ensure that its legal or safety statements are genuinely valid in all of them. The content repository should help teams see reuse, not conceal it.
Write a reviewer-friendly translation brief
A helpful brief includes the audience, page purpose, intended action, source facts, terminology, links and any non-translatable values. Explain whether the reader is learning a concept, buying a ticket, reporting a problem or following a safety instruction. Give translators examples of what successful understanding looks like. Without this context, a polished sentence can point the reader toward the wrong action.
Ask reviewers to annotate two categories of change separately: linguistic adaptation and factual or policy adaptation. A linguist may improve clarity without authorizing a change to a deadline. A regional product owner may approve a different address without approving a change in scientific meaning. The distinction speeds revisions and protects accountability. Keep evidence visible next to changes. The aim is not bureaucratic paperwork; it is a decision trail that enables a future colleague to understand why a translation says what it says.
When machine translation is useful and when it is not
Machine translation can provide a draft for low-risk, clearly scoped content if the team reviews it with the original meaning in view. It cannot certify that a content descriptor, fallback decision, linked page or legal promise is correct. Use protected-value rules for identifiers, variables, markup and route references, and require human review where claims can affect decisions. Never equate a fluent output with an approved outcome.
Run a round-trip check on a sample only as a diagnostic, not as proof of accuracy. Compare claims, negation, conditions, numbers, named entities and intended actions against the source directly. Ask the target-language reviewer to explain the meaning in ordinary words. A statement that appears stylistically natural but turns might into must is a serious error. Keep the raw source, candidate translation and approved target as distinguishable records so future source revisions can be evaluated honestly.
Maintain a change-impact register after launch
The first successful release is the beginning of the translation lifecycle. Source pages change, events get cancelled, policies gain exceptions and software templates evolve. A change in a reusable call to action may affect dozens of localized pages. A newly added content field may silently default to English. Without a change-impact method, every launch gradually accumulates hidden inconsistencies.
Record each material source change and identify the locales and components that depend on it. Assign a translation owner and a deadline appropriate to the risk. A spelling correction may require little review; a change in safety instructions requires fresh approval and a public delivery test. Preserve old versions long enough to explain what a reader previously saw. Do not simply reset every translation to a completed state because a release build succeeded. The publishing record should reflect actual target-language readiness.
Build a repeatable QA matrix
Create rows for the homepage, a long article, an unavailable translation, a multi-step form, an embedded component, a search result and a downloadable resource. Add columns for each supported locale, direct URL, displayed language, source revision, accessibility, metadata and outcome. Mark pass only when there is observed evidence. A screenshot can help, but a recorded route and revision is more useful for reproducibility.
Include failure tests: remove a Spanish descriptor in staging and verify the expected fallback; request an unsupported locale; enter a direct link without a prior language cookie; disable JavaScript where practical; test stale cache responses after publication. Check that the error page is understandable. A team’s acceptance matrix should catch what a real visitor experiences, including situations the editor did not plan to visit. That is the difference between configuration verification and product-quality verification.
How to diagnose the wrong-language page
Start with the exact request URL and the response the browser received. Record whether a redirect occurred, the resulting path and the selected locale. Check the target identifier and folder structure against the documented site configuration. Determine whether the intended descriptor exists and is published in the relevant delivery environment. Next inspect fallback, cache behavior, layout and any client-side language state.
Avoid changing translations at random. If the correct Spanish descriptor exists but the browser gets English, the problem may be routing or cached delivery rather than prose. If the engine returns Spanish content while the form remains English, inspect how the template gets its strings. If preview succeeds but public delivery fails, trace publication rather than translating again. Each symptom should lead to a specific observation, a reversible fix in a test environment and a repeated acceptance journey.
What to do when two locales show the same text
Identical text can be legitimate for proper names, equations or identifiers, but it deserves investigation for user-facing explanations. Inspect whether the field is intentionally shared, the requested target lacks a variant, the engine fell back or the template hard-coded a source string. Check the exact value in the content descriptor and rendered output. Do not edit a source field blindly to force visible difference.
A helpful test sentence contains language-specific grammar and an obvious contextual clue. Publish it only in staging and verify that locale selection actually changes the displayed content. Then restore normal reviewed copy. If the identical text is deliberate, annotate the content register. If it is not, record the root cause so future contributors do not repeat it. The goal is not maximal textual difference; it is correct meaning in the correct language at the correct destination.
Accessibility is part of the source-to-reader path
People using keyboards, screen readers, captions or magnification tools should be able to navigate translated content without losing the promised information. Check heading order, landmark labels, link descriptions, skip navigation, form errors, visible focus and reading direction. A localized button can be visually accurate while its accessible name remains in another language. Hidden strings deserve the same review status as visible prose.
Test with one real task: open a translated article, reach its related resource, submit the form incorrectly, understand the error and complete the corrected action. Verify that any language switch keeps the user in a meaningful location rather than sending them unexpectedly home. If a text expansion breaks the layout, repair the component design rather than shortening the translation until it loses essential conditions. Accessibility supports meaning, not merely compliance paperwork.
Governance: who can declare a translation ready?
Separate drafting, linguistic review, subject-matter review and public release where the risk calls for it. A fluent editor may not know whether a refund rule is accurate. A subject expert may not notice that a conditional verb has become absolute. Assign approval by responsibility rather than by whoever last opened the page. A single reviewer may cover several roles on a small team, but the checks should remain explicit.
Set a withdrawal and correction route. If a translation becomes outdated, editors need authority to mark it unavailable, replace it with a clearly signposted fallback or publish an urgent correction. Avoid silently rewriting the source or a protected owner to make an incomplete variant appear finished. A durable system can answer what changed, who reviewed it, which locales were affected and whether a visitor can still reach a misleading version through search or an old link.
Release plan: move from one reliable journey to the entire site
Begin with one low-risk, high-traffic content journey and a small set of locales. Inventory every visible and hidden surface. Configure targeting, create the localized descriptor, translate the associated components, review the content and test direct public delivery. Then add a negative test for an unavailable target, followed by a source-change test. Only after those pass should you expand to a second content type or a market-specific variant.
The release checklist should include content files, templates, images, redirects, metadata, search indexing, cache invalidation and a named rollback decision. Agree on what counts as a blocking failure. An unlocalized decorative label may be tolerable for a limited pilot; an incorrect eligibility condition should not be. Explain tradeoffs to stakeholders in terms of what readers will see and do, not an unexplained percentage of translated strings. Keep the procedure readable enough that another editor can repeat it.
Ten practical situations that test the whole multilingual journey
Case study: regional Spanish without inventing a new policy
The nonprofit has an existing Spanish exhibition page and requests a Costa Rican landing page. The team first lists which facts are genuinely specific to Costa Rica: contact details, attendance methods, local partners and availability. It keeps the scientific description equivalent unless a subject expert approves an adjustment. It tests the es_CR request against an es base variant and verifies whether a missing market-specific paragraph inherits the correct content or triggers an explicit notice. The review report records which fields are shared and which differ. That prevents a minor regional adaptation from becoming an uncontrolled second source of truth.
Case study: a withdrawn event notice
An exhibition session is cancelled after both languages have been published. The source editor changes its status and message. The localization owner traces all dependent pages, schedule widgets and email links. Where approved Spanish cancellation copy is ready, the site publishes it. Where not, the team favors a clear temporary notice over a stale booking instruction. Public QA checks the cached page, on-site search, shared social links and direct old URL. The translation task is complete only when a reader cannot follow an outdated instruction into a cancelled event. The repository’s change history remains intact for future questions.
Case study: a translated title with an English download
A Spanish programme page links to a PDF visitor guide. The title and button are Spanish, but the PDF itself remains English. The content owner labels the download honestly, determines whether a translated version is required for the audience and checks that the link opens the intended file. If a Spanish PDF is later approved, its version and accessible text are recorded, and only then is the label updated. The lesson is that a translated page cannot certify a linked asset. The reader’s expectation is formed by the entire call to action, including the language and status of the material obtained.
Case study: language cookie versus shared URL
A visitor copies a Spanish event URL to a colleague. The colleague’s browser preference is English. If the system automatically overrides the explicit path, the colleague may not see the same content. The team tests direct requests with fresh cookies, existing preferences and no session. It defines precedence between a human-chosen URL and automatic negotiation. Redirects are documented and kept free of loops. The language control is designed to let the recipient choose a different version without losing the event context. The objective is to make links reliable objects that can be shared, cited and revisited.
Case study: a form error crosses language boundaries
A Spanish visitor leaves a required field blank. The visual label is translated, but the server returns an English validation message. The editor identifies whether the text comes from a template, form component or external service. The developer adds the missing localized resource and checks the same error under several invalid inputs. The data field name and storage schema remain unchanged. The team also verifies that the confirmation email uses the chosen language and communicates the same submission status. Without this second part, the visitor may believe the form was submitted when it was merely rejected.
Case study: a public site serves draft content
A page is visible in authoring preview, and a tester assumes it has shipped. A public reader gets an older version. The release lead compares the exact preview descriptor with the public delivery environment, then checks the Git-backed publication and relevant index. It asks whether an older cache is still in front of Engine. The incident record separates content approval from transport and runtime delivery. After a safe fix, the team repeats the direct public test while signed out. This case shows why a green preview screenshot is not enough to claim that a translated page is live.
Case study: a source update changes the strength of a claim
The source article once said a river can rise quickly after severe rainfall; a revision now says it may rise quickly in certain conditions. The Spanish version still states an unqualified certainty. A terminology check would not catch that difference because most words remain familiar. A semantic review compares the condition, likelihood and scope. The translator adjusts the sentence and the subject expert checks the claim. A revision link records which target was affected. The page is republished and its summary card rechecked. Good localization tracks meaning when the source evolves, not merely the count of changed characters.
Case study: an unsupported target language
A reader requests a locale the project has never published. The team decides whether to show a language-neutral choice page, a clearly labeled fallback or a not-found response. It ensures that the returned page does not falsely declare an unsupported locale in HTML metadata or appear as a completed translation in the sitemap. Navigation should remain useful; errors should offer a legitimate route forward. A log entry can reveal demand for a new language, but it should not silently create a placeholder indexable page. The response must be safe, predictable and truthful about what language is available.
Case study: RTL expansion after launch
The organization adds Arabic after establishing English and Spanish routes. The developer can configure a new target, but its mere existence does not solve directional layout. The team checks mixed-script article titles, phone numbers, embedded science symbols, form controls and the meaning of forward and back actions. It validates accessible names and document language, not only visual alignment. The source files stay stable, while approved Arabic descriptions and alternate routes are added. A restricted pilot exposes real layout problems before a public promise is made. Translation quality includes typography, movement through the interface and correct interpretation of actions.
Case study: a multilingual search-result mismatch
A Spanish visitor searches for a program title and receives a Spanish result card whose link opens the English article. The investigation checks the search index’s language field, the localized path stored with the result and whether the source item was updated without reindexing. The fix is validated by searching the exact phrase, opening the result and comparing the visible claim with the approved source revision. Old incorrect cards are purged. Search was an independent reader-facing product surface all along; the project cannot call itself localized if discovery sends visitors to the wrong language. Record this as a regression test.
Frequently asked questions
Does CrafterCMS translate content automatically?
Targeted content resolution chooses which content to deliver. It does not, by itself, write or approve the translated prose. Teams still need content creation, context, review and release.
Can es_CR fall back to es?
The documented targeting example illustrates region-specific to language-level resolution before the configured final fallback. Verify the precise target identifiers and folder layout on the version installed in your project.
Why do English words appear on a Spanish page?
They may come from shared fields, a missing localized descriptor, a template resource, an embedded component or a configured fallback. Inspect the delivered value and its source before editing translations.
Should every language page be indexed?
Only pages that satisfy the site’s content and search policy. A nonapproved fallback or placeholder should not be presented as a completed translated page in search metadata.
Is publishing a Git change enough?
No. Check the delivery environment, the exact public URL, search and cache behavior, plus the final meaning visible to readers. Publication is a separate technical state from translation approval.
What is the first test to run?
Choose one source page, one target language and one direct public URL. Ask a reader to complete the page’s intended action, then compare what they understood with the source’s documented meaning.
Official documentation and further reading
Check the documentation for the version actually installed. The following official sources describe the language-targeting and delivery concepts discussed here. Treat implementation samples as examples to test rather than code to paste blindly into production.
- CrafterCMS 4.1: Localization and targeted content
- CrafterCMS Deployer and publishing architecture
- Crafter Engine content-store API
Continue through the eduKate translation library
For wider principles of meaning, evidence, source revision and cross-language review, see Master Art of Translation. For related implementation guides, visit the Translate Like a Pro series index. This chapter is specifically about CrafterCMS language targeting, content paths and delivery behavior; it is not intended to replace the general translation or rapid production guides.
A multilingual CMS succeeds when a person can open a trustworthy page, recognize what is available, understand its meaning and take the intended next step. The strongest test is a real reader journey, observed on the public version of the site, after the content has actually shipped.