A Strapi 5 translation can look complete inside the content editor yet fail the one test that matters to a reader: opening the intended page and receiving the intended language. Strapi 5 locale delivery QA is the practical process of checking that a localized document exists, its right fields are translated, its publication status is correct, and the public API returns the expected version. It is a faster way to validate multilingual Strapi content because it separates writing from delivery.
People searching for Strapi i18n API locale, Strapi 5 internationalization, localized content publishing, and Strapi REST locale parameter are often confronting the same puzzle. An editor can see French copy; a developer can query the API; and a visitor can still receive an English page. The missing connection is not always an inaccurate translation. Sometimes the locale parameter is absent, a localized field is not configured, or a draft exists without a published counterpart.
This guide gives one dominant job: verify the journey of an existing translated Strapi 5 document from content model to published API response and then to the visible frontend. It is not a general tutorial about choosing machine translation, writing better French, or moving content between unrelated systems. The examples use a hypothetical school information site, but the decision method applies to product guides, service pages, museum exhibits and other headless-CMS experiences.
The short answer: test the chain, not merely the sentence
A reliable check follows five objects in sequence: configured locale, localizable content type, localizable fields, document identity and version, and consumer response. If one object is wrong, improvements to vocabulary cannot solve the delivery failure. You need to find the first point where the requested language stops being the one supplied. For that reason a quick localization review should begin with a repeatable test record, not a random browse through many pages. Choose an entry whose source text is easy to recognize, such as a parent guide titled “Preparing for Secondary One.” Record its stable document identifier, expected French title, and expected public path. Then inspect what Strapi and the website each return.
The result should be evidence rather than reassurance. A green publishing indicator proves one thing about a CMS record; it does not prove that a deployment, cache, page renderer or language selector has consumed that record. By the end of the process, the team should be able to answer which locale was requested, which locale was returned, which fields were shared, what the publication state was, and what a reader actually saw. Those answers make translation checks both quicker and less argumentative.
Why Strapi localization has more than one moving part
Strapi is a headless content management system. Its editor manages structured content, while websites or applications retrieve that content through interfaces such as REST. A conventional article can consist of a title, summary, body, author, image, category, slug and visibility status. Multilingual publishing adds decisions about which pieces vary across languages and which remain common. The title might become French while the same author identifier and internal category relationship remain shared. The configured rules are part of the meaning-delivery mechanism.
In Strapi 5, internationalization is enabled at a content-type level and localizable behavior can be specified for individual fields. This distinction matters whenever a team says “we translated the article.” Did it translate every customer-facing text field, or just those the model allows to vary? A translator may see the title and body but not the image alternative text if the field is configured differently. A website may pull the summary from another source. Before diagnosing a text error, map the actual fields that reach the reader.
Treat locale codes as routing instructions
A locale code is not a decorative label to attach after translating. It directs the API to a particular language version. For a French audience, a request might include ?locale=fr; the same request without a locale uses the application’s configured default. An English-looking response to a French-language request may therefore arise because the request omitted the parameter, not because Strapi discarded translated words. The small detail is especially easy to miss when a developer checks the source page successfully in the browser and assumes the translation route is also working.
Start with a simple comparison. Retrieve the same known document once with the default locale and once with the target locale. Observe the locale value returned in the result, rather than inferring it from a title that could coincidentally be identical. A label such as “Science” can be unchanged in more than one language; it is not reliable proof of localization. Also distinguish language from region. fr, fr-CA and another configured variant should not be treated as interchangeable merely because people can understand similar vocabulary.
Confirm the content type before spending time on copy
A localization workflow fails early if the content type was never marked for internationalization. Open the Content-Type Builder or the project’s schema and check the intended type, not a neighboring type with a similar name. In a hypothetical site, parent-guide might support localized entries while event-registration does not. An editor could still create a French-looking article in the wrong collection, but the normal locale query would not retrieve it as the corresponding variant of the right document. That is a modeling failure disguised as editorial progress.
Next, inspect the localizable settings of the fields readers encounter. A title translated into French does not imply that excerpt, seoDescription, callToAction and slug are also localizable. Record which fields deliberately stay shared: a telephone number, product identifier or internal taxonomy ID may need consistency. Do not indiscriminately turn every field into a language-specific value. The goal is to preserve meaning where text should change and identity where operational data should remain stable.
Use the Strapi 5 document ID as a stable comparison point
Strapi 5 works with the concept of a document that can have locale and status variations. The documentId identifies that content object in API operations. This is different from treating one visible database-row identifier as the permanent cross-locale identity. In a quality-control sheet, write one row for the intended document and additional columns for the tested locales. This keeps the English and French records aligned with a single editorial purpose.
Imagine an information page that explains how a school consultation works. The English headline might be “Prepare for a Parent–Student Consultation”; the French version should preserve the same page role, even if the title requires a natural rewrite. If two independently created documents happen to share similar words, their linkage may not be what the frontend expects. Conversely, if the correct document has a missing target locale, a URL constructed from the source edition cannot invent a translated version. Testing document identity is more reliable than searching the dashboard for similar titles.
Do not confuse REST publication defaults with Document Service defaults
One of Strapi 5’s most consequential details is that the REST API and Document Service API have different default assumptions. The official REST documentation says the REST API targets published versions by default when Draft & Publish is enabled, including for common create and update operations unless draft status is requested. The Document Service API, by contrast, typically returns draft versions by default when status is omitted. Those defaults can make two apparently reasonable checks disagree. The CMS developer reports a French document; the public REST consumer sees none.
Write down which interface produced each screenshot or JSON example. A response from an internal server method is not interchangeable with the public API response. To test the live reader path, request the locale and published state that the site truly uses. To inspect drafts for review, do that explicitly and label the result as draft evidence. A helpful rule is to never say “Strapi has the translation” without specifying whether it exists as an editable draft, a published locale, or both.
A controlled read-only test that anyone can repeat
Select a single known entry with an approved French version. Record its documentId from the authorized development environment and use a read-only request. For illustration, a collection endpoint could be /api/parent-guides/KNOWN_DOCUMENT_ID?locale=fr&status=published. The exact collection path depends on the project schema. Do not paste a private API token into public documentation, screenshots or notes. Prefer a controlled staging environment and the minimum permissions required for a read.
Compare five properties: the requested locale, returned locale, stable document identity, translated text fields and publication timestamp or state. Follow with a request for locale=en or the configured source locale. If the French query yields no entry while the English query succeeds, stop and inspect locale availability or publication status. If French JSON is correct but the public page remains English, the issue is downstream: routing, transformation, caching or frontend rendering. This two-query technique converts a vague complaint into a bounded diagnosis.
Separate a missing translation from a hidden one
A missing localized version and an unpublished localized version are different problems. The first requires creating or linking content for the target locale. The second requires editorial approval and a publication operation performed by an authorized person. A read-only QA routine should not silently publish an unreviewed draft merely to make the test pass. That changes a production state and bypasses the workflow that may exist to protect factual accuracy, legal review, branding or safeguarding language.
In a practical status table, distinguish “not created,” “draft exists,” “published exists,” “published content differs from draft,” and “public page verified.” This vocabulary prevents a common confusion: an editor sees recently corrected French text in the draft but the public endpoint still exposes the earlier published version. The visible problem is now a version mismatch, not a failure to translate. A precise report can say which French sentence is in each version and who must decide whether to release the change.
Check field-level localization with an explicit inventory
A record can look translated at a glance and still contain language leaks in less prominent fields. Build a field inventory for the page template. Typical fields include card title, short description, main body, button label, image caption, image alternative text, breadcrumbs, tab headings, related-content teasers and SEO metadata. For each field, note whether it is stored in the localized document, inherited or drawn from another collection. This matters especially on pages assembled from reusable components or relationships.
The inventory should be short enough to use, not a document designed only for auditors. Take the actual page and work from top to bottom. If the page shows an English consultation button beside French paragraphs, trace the button to its owner. It may be a global frontend dictionary, a reusable component in Strapi or hard-coded application copy. Editing the wrong Strapi article will not fix it. The fastest fix is found by identifying the source of the rendered string before writing another translation.
Worked example: the article title is French but its card is English
Suppose a school’s French landing page links to a guide. When visitors open the guide, the title and body are French. Yet the card in the listing says “How We Teach Algebra.” A rushed team might retranslate the guide’s title or clear every cache. Neither is a justified first move. Inspect the listing API request and the card field it actually uses. The card might draw from a distinct teaserTitle attribute, from a manually curated featured-content component, or from a default-locale response generated in a separate server request.
The diagnostic question is whether the English string exists in the correct French API response. If the teaserTitle is English, the issue lies with the content record or field-localization configuration. If the API gives French but the component renders English, inspect its data mapping, localization state and cache key. The worked example illustrates a general rule: match every visible output to the precise field and request that produced it. Similar-looking words can come from different places in a structured system.
Worked example: an article exists only in the editorial draft
A tutor reviews a new article about examination timelines and approves its French translation in the editor. The translator sends a screenshot showing the polished title. The public French link still produces a not-found page. Before assuming the URL is broken, compare the published French API response with the explicit draft response available to authorized reviewers. If only the draft exists, the translation has not completed the publication workflow. That is an intentional system state, even if someone assumed completion.
The correct action is to identify the publishing owner and record the pending approval. Meanwhile, the site should avoid presenting a broken language-switcher link if its policy is to show only published locale variants. A front end may instead omit that locale from the available languages or direct visitors to a clearly labeled fallback, depending on product requirements. Never impersonate a complete translation by silently displaying source-language copy under a French indicator; such a design creates false confidence about what a visitor is reading.
Worked example: a locale switcher changes the flag but not the page
An interface offers English and French buttons. Clicking French changes the selected icon, but the article remains in English. Two separate activities may have happened: the state of the language control changed, and the data request did not. Check the browser network request if appropriate, or the server-rendered fetch logic in a controlled environment. Does it pass locale=fr? Does the router map the chosen locale to the correct page? Does a cache use locale as part of its key? A change of icon alone is not evidence of a translated response.
A robust switcher is constrained by available published locale versions. If the corresponding French content does not exist, the interface should implement a documented fallback or show a truthful unavailable state. A quick QA record can include source URL, target URL, requested locale, returned locale field and screenshot of the final page. This turns a subjective report—“the language button is confusing”—into evidence that a developer can reproduce in minutes.
Worked example: the language is right but an important fact changed
Correct locale routing does not guarantee faithful content. Imagine an English parent notice says that a consultation takes approximately ninety minutes, while the French version promises a two-hour meeting. The API returns fr; the publishing state is correct; the website looks polished. The error is now semantic, not technical. Technical QA should hand the record to a language and factual reviewer rather than marking it complete because all fields exist.
Use a small invariant register for facts that must survive translation: dates, prices, quantities, ages, eligibility requirements, safety instructions, contact details and named institutions. Invariant does not mean the presentation must be identical. A date may be formatted differently for the audience; its calendar meaning must remain the same. A level name in a Singapore syllabus may deserve an explanation rather than an invented local school equivalent. Treat the reader’s decision as the quality criterion: after reading either language, should they take the same informed action?
How relational content complicates the last ten per cent
Many Strapi pages are assembled from linked objects. A guide may reference a subject, school level, staff profile or location. Translating the guide’s body does not guarantee that linked content is localized or that its relationship points to the version the application expects. Some relations and fields can be intentionally shared; others should vary. Your QA task is not to impose a universal rule, but to read the configured schema and observe the actual response with relationships populated as the site uses them.
A useful isolation test checks the localized root entry before adding nested data. Then enable only the relationship the page needs and inspect whether text values are in the correct language. If an English subject label appears inside a French guide, find the object and field that owns it. Do not duplicate an entire subject taxonomy merely to fix one display label unless the content architecture calls for it. The best remedy may be a localized label on an existing classification, a frontend dictionary or a corrected query to a related localized entry.
Why slugs and URLs deserve their own decision
Some teams want localized page slugs; others preserve language-neutral route identifiers. Both can be workable when implemented consistently. The QA obligation is to make the selected rule visible to readers and to ensure the route resolves to the intended published content. A French headline does not automatically imply that its URL changes. Equally, a French-looking slug can route to English text if the underlying query ignores locale. Avoid using the slug alone as proof of language correctness.
Test a direct visit to the French URL, not only navigation from the home page. Visitors arrive from bookmarks, messages and search results, often without the locale state of an earlier page. Then test what happens if the French article is unpublished, renamed or missing. The expected outcome should be explicit: redirect, unavailable page, visible default-language fallback or removal from language navigation. Unplanned behavior produces duplicate pages, search confusion and a frustrating loop when the user switches languages.
Build a compact comparison matrix for release review
For every translation candidate, create a row with its content type, document ID and reader job. Add columns for the expected source and target locales, field inventory, draft status, published status, direct API result and public page result. A matrix is more useful than a folder of random screenshots because it preserves what each item proved. A reviewer can see that the French body passed but the metadata failed, or that the API passed but the old frontend deployment still serves the source text.
Use descriptive outcomes rather than one ambiguous green tick. “Pass” should mean that the specified assertion was checked. “Blocked” should identify the dependency, such as an unpublished French entry. “Needs language review” means that the technical route works but the meaning is uncertain. “Not applicable” is suitable for an intentionally shared numeric identifier, not for an ignored textual field. This structure lets editors and developers coordinate without having to explain the whole CMS repeatedly.
Detect fallback behavior instead of assuming it
A fallback is a deliberate product decision about what to show when a target-language value is missing. Strapi’s API locale behavior should be tested as documented for the installed version, while any frontend fallback must be designed and verified separately. Never assume that a missing localized entry will automatically return English or that it will automatically generate a 404. A proxy, server layer or application component may implement its own rule. The consequence can be hard to notice when the target page is partly translated.
Write one test for a fully translated article, one for a missing target locale and one for a partial translation. In each case, record whether the reader is told when fallback occurs. A visitor who sees an English safety notice on an otherwise French page must not be led to believe the notice has been reviewed in French. The appropriate response could be explicit source-language labeling, a translation-unavailable message or withheld publication, depending on risk. The crucial requirement is honest behavior that matches the product’s documented policy.
Read cached output as a separate artifact
Even with correct Strapi records and requests, public output may lag behind. A website could use server rendering, static regeneration, a content delivery cache, or an application cache. The translation route may fetch the correct document once, then reuse the result incorrectly because a key omits the locale. Alternatively, content may simply remain stale until an approved rebuild or invalidation occurs. A reviewer should not clear caches blindly, especially in production; that can mask a defective caching strategy without fixing it.
Use evidence to distinguish the layers. Capture the current Strapi REST response, the direct page response and the visible component. If the REST response shows a new French phrase but the page shows the prior approved phrase, record the mismatch and its timestamps. The development team can then trace rebuild hooks, cache tags or route parameters. When the page is correct but navigation cards are stale, test those components independently. A localized site has several consumers, and each consumer can have a different refresh path.
A no-surprises approach to previewing translations
A preview environment should let authorized reviewers inspect drafts without exposing unfinished content to ordinary visitors. It must also make clear that preview output is not a public published response. Put a visible preview label in the review process, or use a distinct staging hostname. Capture the locale, build version and content status in the test notes so an editor cannot accidentally approve a screenshot of yesterday’s draft. Avoid sharing raw preview tokens in chat logs or screenshots.
For a small team, the simplest useful preview checklist asks whether the right draft is being viewed, whether components render with expected typography, whether internal links remain valid, and whether all factual claims match the source. The technical test can be followed by a parent or end-user test: can someone unfamiliar with the CMS understand the French call to action and what happens next? Good localization QA stops being a developer-only exercise at the point where a reader has to act.
Test structured blocks one component at a time
A rich Strapi article can contain structured content or dynamic components. Translation work may alter a label inside a block while leaving a button destination untouched, or may accidentally omit a component from the target version. Some content types use a dynamic zone in which component identity is part of the data shape. The goal is not to translate a technical component identifier; it is to preserve the arrangement and required operational values while translating reader-facing copy.
Check a page with one heading, one callout, a short list, a related link and an image. Compare the target locale’s structure with the source. If a translated page is missing its second callout, first determine whether the absence is intentional local adaptation or an import/update mistake. If a callout points to an English-only guide, the link may need a localized target or a truthful fallback notice. Content structure is often invisible to a pure language review, which is why the rendered page must be part of the test.
Images, captions and alternative text are separate requirements
A translated page can carry an image whose embedded words remain in English. This is not necessarily wrong, but it demands a conscious decision. The caption may explain it, the image may be replaced by a language-neutral diagram, or a translated version may be created with proper rights and design review. Do not assume that a translated alt attribute will make on-image text accessible; alternative text should describe the informational function of the image in context, and it should be accurate for the asset actually shown.
For a hypothetical diagram about algebra, distinguish the mathematical notation, which may remain common, from descriptive callouts that need translation. If an image contains the date of an exam, verify that the localized replacement uses the same real date. If a profile photograph is intentionally shared, preserve its identity and license. The fastest review sequence is to list images visible to the reader, note textual content embedded in each, and confirm that captions and alternative text are owned by the correct localized or shared field.
Make SEO metadata part of the same delivery test
A multilingual page has at least two kinds of language output: the words a reader sees and the metadata that search engines or link previews may consume. If the French article’s main body is correct but its title tag and description remain English, publication is incomplete for a French search audience. Check where metadata is stored. It may live in a Strapi component, a frontend route, or a separate marketing configuration. The API record alone does not prove that HTML metadata was rendered correctly.
Open the delivered HTML, not merely the content editor. Verify page language declarations, meaningful localized title and description, canonical behavior, and any reciprocal language annotations the architecture intends to publish. Such annotations should point only to valid, equivalent locale pages. A French translation that is still a draft should not be advertised as a published alternate. Localization SEO is a consequence of correct content ownership and route availability; it is not repaired by stuffing translation keywords into every heading.
Protect private data and permissions during inspection
Localization QA sometimes involves user accounts, hidden previews or confidential content. Choose a harmless test record with no real student, patient or customer data. Use authorized read permissions and redacted request logs. Avoid copying bearer tokens into an editorial spreadsheet, because those tokens can grant access beyond the one entry being checked. When a request returns a permission error, record it as a permissions outcome rather than advising people to turn off safeguards just to make QA easier.
The intended public reader and the internal editor often have different rights. A French draft may be visible to staff and correctly unavailable to anonymous visitors. That distinction should not be diagnosed as a broken localization feature. Test with a public-like account or unauthenticated route where suitable, and with an authorized editorial account for drafts. The exact account state is part of reproducibility. A good issue report says who could see which version and why that mattered.
Error taxonomy: six failures that look deceptively alike
A wrong-language page can arise from at least six causes: a missing locale configuration, a non-localizable field, a missing locale variant, an unpublished target version, a wrong API query, or an incorrect frontend consumer. Each creates a different repair task. The first belongs to site configuration; the next two belong to content modeling and editorial coverage; publication belongs to release workflow; querying belongs to integration; rendering belongs to application logic. The trick is to avoid jumping straight to whichever layer one team knows best.
A concise bug report describes the expected and actual locale, the document ID, the precise read-only request, the observed response and the public symptom. Put the smallest reproducible example first. Only then add screenshots or hypotheses. This order prevents a developer from blaming the translation and a translator from blaming the CMS without checking the evidence. It is also kinder to the reader, because fixing one confirmed cause is usually faster than changing several unrelated settings at once.
When a quick check needs a deeper language review
Not every defect is visible through keys, timestamps and requests. A French sentence can be grammatically correct yet communicate a different admission requirement or misstate a school stage. Test any text that directs a consequential action more carefully than a decorative caption. A translator or competent reviewer should see the complete field context, the intended audience and nearby interface copy. Without that context, a short phrase such as “Apply now” may be translated as a formal application when the button only opens an enquiry form.
Use example-based review rather than a universal percentage score. Ask a reader to explain what they expect after selecting a button, whether a time commitment is clear, and whether a disclaimer changes the meaning of a claim. If two readers reach materially different interpretations, the issue deserves revision even if the API and grammar are flawless. Speed comes from prioritizing consequential ambiguity, not from eliminating human judgement.
Scenario: staggered releases across locales
Suppose an English guide receives a new policy section on Monday, while the French edition must be reviewed before it can go live on Thursday. Publishing all locales simultaneously would bypass the French review. The system should support a content-state plan: English published at its approved version, French remaining at its previously approved version, and a clear owner for the pending French update. The editorial team needs to know whether the two editions intentionally differ temporarily.
At release time, test the French article again from a fresh direct URL and confirm that the newly approved paragraph is present. Do not rely on the English update event as proof that another locale has deployed. For high-stakes pages, a small release note recording the affected locales and fact changes can prevent confusion. The point is not to synchronize every language at any cost; it is to make differences in revision status explicit and controlled.
Scenario: a new field is introduced after translation
A developer adds a noticeBanner field to the source content type so every parent guide can display an important update. Existing French entries are not necessarily ready to show meaningful French text in that field. The page can still appear largely translated, which makes the defect easy to overlook. Add the new field to the localization inventory, inspect its field setting, and decide whether it is required before publication. Some notices may be appropriately shared; user-facing safety and scheduling text usually deserve deliberate localized treatment.
A release test should include a target-locale entry created before the schema change, not only a brand-new entry. Old records are the ones most likely to lack newly required content. If the frontend renders an empty banner, check whether that is acceptable. If it falls back to English without a label, assess the reader risk. If it hides the banner, confirm whether the omitted information was essential. Schema evolution is a localization event even when translators receive no new document title.
Scenario: content is copied instead of localized
A hurried editor creates a fresh French article by copying the English entry into another record, changing the title and leaving the other fields to be completed later. The copy may look reasonable in the dashboard but will not necessarily behave as the intended locale version of the same Strapi document. Links, route mappings and language navigation can be based on document identity, not on a human’s idea that two articles are equivalent. First verify whether the French entry is the localized version of the existing document.
If it is an unrelated document, decide how to repair the content model under the site’s approved workflow. Do not casually delete an entry that may already have links, revisions or analytics. Record both identifiers, check what each public path serves, and plan a controlled correction. This is an example of why quick translation does not mean quick copying. The cost of a duplicated content identity often appears much later when search engines or language selectors expose inconsistencies.
Scenario: one section changes meaning because the unit was localized
A family programme description states that a workshop lasts 1.5 hours. A target-language editor interprets this as one hour and five minutes, or converts it to two hours to make a sentence flow naturally. Both changes affect the real commitment. A structured fact ledger can catch them: duration, date, location, eligibility, price, registration limits and contact channel are checked independently from grammar. If numbers are displayed through a separate component, confirm that the localized page still uses the same underlying value.
The correction process should ask whether the source fact is itself current. A perfectly faithful translation of obsolete information is not good service. When the official schedule changes, both language versions should be flagged for review. This is especially important on education sites where parents plan transport or exam preparation around a published date. Translation QA and editorial fact maintenance must cooperate without being confused as the same job.
Scenario: regional spelling and actual locale availability
A team wants separate versions for French used in France and French used in Canada. That is a valid content strategy only if the project has the intended locale codes configured and meaningful editorial distinctions to support them. Making a language selector with regional flags does not create region-specific API content. Test the exact codes rather than assuming that fr-CA will automatically retrieve fr or that both codes mean the same audience obligations.
Where a regional variant lacks translated coverage, the team should document the fallback and be transparent in its interface. A Canadian family reading a French page may expect region-appropriate terms for school levels and services; a France-specific term might be unfamiliar or misleading. Editors can deliberately share neutral phrasing where suitable. But the CMS audit must begin with what is configured, what is published, and what the consumer requests. Those three facts should guide the language decision, not the appearance of the selector.
Practical release checklist for one localized document
Before release, test the following in a fixed order: the locale exists in Strapi; the content type has internationalization enabled; the visible fields have intentional localization settings; the expected documentId is used; the target locale draft has passed content review; the target locale published version is present; read-only REST requests return the correct locale; related components display the expected language; direct public URLs resolve; and metadata, navigation, images and calls to action are checked in the browser. Record any exception rather than hiding it inside a general approval.
Do a final check from the perspective of a visitor who has never used the CMS. Open the page through a shared link and try to complete the action suggested by the text. If the route, language indicator, contact form and explanatory content agree, the translation is ready for more confident release. If they disagree, the best next move is to name the exact failed assertion. One broken assertion is easier to fix than an unqualified statement that the translation “does not work.”
Transfer: use the same reasoning beyond Strapi
Although this guide is specific to Strapi 5, its conceptual lesson travels well. A localized experience is not one text file; it is a chain of content identity, locale selection, publication state, field ownership and rendering. A student building a school website can practice by making two language versions of a harmless announcement, then checking the record and page separately. A tutor can use the example to teach a wider skill: distinguish the author’s intended message from the mechanism that delivers it.
The same form of reasoning appears in scientific experiments and Mathematics. Hold one variable constant, change one variable deliberately, and observe the result. Here the document ID remains constant while the requested locale changes. Later, the locale remains constant while the status changes. The outcome teaches causal diagnosis: when a system looks wrong, isolate the first decision that made the output diverge. That habit is more valuable than memorizing one interface’s buttons, which can change in later software versions.
Summary: what a successful Strapi 5 locale check proves
A good localization release is not certified by the presence of translated paragraphs in a dashboard. It is supported by evidence that the correct Strapi document has the right target-language fields, has reached the intended publication state, can be retrieved by a correctly parameterized request, and is rendered accurately at the URL a reader uses. The workflow is fast because it follows the content from origin to consumption instead of revising every word whenever something displays in the wrong language.
Keep the test narrow and repeatable. Start with one document, identify its locale and version, inspect the data fields, then visit the page directly. For every failure, write the first broken connection and the person responsible for fixing it. That is how a multilingual website turns translation from a hopeful editorial activity into a reliable public service.
Frequently asked questions
Why is my Strapi 5 page still in English after I translated it?
Check whether the frontend actually requests the target locale, whether the correct document has that locale version, whether relevant fields are localized, and whether the translated version is published. Test the REST response before changing the text.
What does ?locale=fr do in Strapi 5?
It requests the French locale version where available and supported by the content type. Without a locale parameter, a REST query uses the application’s default locale. The installed Strapi version and project’s configuration should always be checked.
Why does a developer see a French draft while the public API does not?
Strapi 5 Document Service queries and public REST queries have different default publication-status behavior. An internal draft result should not be treated as proof that the published public version is available.
Should translated pages always use translated slugs?
Not necessarily. Localized slugs are an architectural choice. Test direct URLs, equivalence between language versions and the behavior when a localized edition is unpublished or unavailable.
Can translation QA be completed without publishing anything?
Yes. Read-only API tests, staging previews, comparison matrices and editorial reviews can establish readiness. Actual publication should remain a separate authorized step.
Are machine-translated fields automatically ready for public use?
No. Automation may accelerate drafting, but fields that influence decisions, rights, safety or costs need a factual and linguistic review before publication.
Suggested internal reading routes
Editors can link this guide to existing eduKateSG coverage of missing localization key QA, resource-key syntax and localization build validation. Those pieces address narrower structural defects; this page owns the distinct reader job of verifying Strapi 5’s locale-and-publication delivery chain.
Sources and product documentation
- Strapi 5: Internationalization
- Strapi 5: REST API locale parameter
- Strapi 5: REST API status parameter
- Strapi 5: Document Service locale parameter
Editorial verification date: 25 October 2026. The examples are hypothetical and do not disclose real user data. Platform details should be rechecked for the installed Strapi release before applying a production change.