A support team can translate a Zendesk Guide article and still hear customers say, “The French help page is missing.” Searches for Zendesk Guide article translation not showing , Zendesk Help Center multilingual articles , Zendesk category section translations , and Zendesk translated article draft point to a distinct technical problem: the target text can exist without being reachable in the help center’s intended language. Fast troubleshooting begins with the entire category–section–article path, not with translating the article a second time.
Zendesk’s current help-center documentation warns that translated articles need corresponding translations of their parent section and category to appear properly. Its article and translation APIs also distinguish the item itself from language-specific title, body, draft and outdated properties. These are not minor implementation details. They explain why a fluent, published French article may not be discoverable from a French help center, and why fixing the article text alone can waste an afternoon.
On this page
Quick answer: follow the language hierarchy
Start at the public help-center URL for the intended locale. Confirm the language is enabled and that the category exists in that language. Confirm the parent section’s translated title and visibility. Then inspect the article translation: locale, title, body, draft state, publication, permissions and public URL. Finally test navigation from category to section to article, plus a direct article link in a private browsing session. Each stage should preserve language and reader access.
The central diagnostic rule is a translated article is not automatically a discoverable article . Zendesk help-center structure determines how people browse, and publication controls determine what ordinary readers can see. A useful report distinguishes “the French article translation exists,” “the French article is published,” and “an unauthenticated French-speaking reader can reach it through the French category and section.” These are separate claims, and each needs its own evidence.
Why Zendesk Guide has more than one layer
A Help Center is not a flat list of translated paragraphs. Categories contain sections; sections contain articles. The default interface itself can be localized by the platform, while custom knowledge-base content is maintained in language-specific versions. Some help centers also control article visibility by user segment or other access rules. A missing page can therefore result from content localization, parent hierarchy, publication or reader permissions. The symptom looks similar to a visitor even when the cause is different.
When someone says an article is “translated in Zendesk,” ask what they observed. Did an editor see the target title and body? Did an authenticated agent open a preview? Did a customer open the page through the target-language help center? Did a direct link work while the category listing did not? These details reveal the failing boundary. Translation quality review becomes useful only after the correct object and visible state are established.
Language must be enabled before an article can serve it
Zendesk’s localized help-center workflow begins with configuring the languages that the help center supports. A target-language article created or imported for a locale that is not enabled for the help center will not behave like an ordinary published variation available through the site’s normal language navigation. The language settings, displayed selection labels and precise locale codes should be recorded together. Do not assume that an agent’s account language automatically adds the same option to the public knowledge base.
Inspect the supported locale list before working on individual items. If a support team intends French for France, verify its configured locale rather than guessing from a language flag. If the help center uses a broader language option, document how that maps to content and URLs. The goal is to avoid a class of false translation failures where the article is present in an editorial tool, but the public help center has not been configured to offer the requested language at all.
Translate the category before its section
Zendesk’s official guidance explains that a translated article must have translated parent pages in the same language to display within the help center. The chain is category → section → article. If the category’s French translation is missing, adding a French title to its child section may still leave the French navigation incomplete. This is one of the most important differences between translating content text and releasing a usable localized information architecture.
Start at the top. Confirm the target-language category label, then the child section label, and only then the article translation. This order is not a claim that every category description must be perfect before writing an article; it is an operational way to establish a navigable route. A user should be able to browse the intended language from the help-center landing area to the needed answer without being stranded in untranslated navigation or an invisible parent.
Worked example: a published French article has no French parent
Imagine a support editor translates an article titled How to change a tuition lesson time into French and publishes it. Agents can open its translated version in the editor. Yet French-speaking parents cannot find it under the French help-center category. The English source article sits in a section called Lesson Changes, and that section belongs to a category called Classes and Scheduling. Neither parent has a French title. The article is linguistically complete but structurally orphaned for French navigation.
The fastest fix is to translate and make available the required category and section within the help center, using authorized administrative controls. Then inspect the article’s existing French version rather than recreating it. Open the French category page, follow its section and confirm the translated article appears. Test a direct French article URL as well. This shows that the user’s path now works, not merely that an editor can locate the child article through internal search.
The hierarchy can be correct in English and broken in German
Editors often inspect the original source language because it is easiest to navigate. A German article may be filed under the correct English category and section, giving a false sense of structural readiness. The relevant question is whether the German category and section translations exist and are usable. The original-language hierarchy tells you where the item belongs, but not whether the target-language browsing path has been prepared.
Build a small tree view with three columns: source item, German title, German availability. Start with the category, follow its actual section ID and article ID, and check the corresponding translations. Do not create a new German category as a standalone copy when the architecture expects translations of the existing category. That can fracture navigation and make later updates inconsistent. Use the system’s language-translation features for the established hierarchy wherever appropriate.
Distinguish article identity from translation identity
Zendesk’s Help Center API represents an article as an underlying knowledge-base item and exposes translations associated with that item. A translation has its own properties, including locale, title, body, draft and outdated; the same article ID can have several language versions. This matters because creating an entirely new article for French may not be equivalent to adding French translation content to the existing item. It can produce duplicate search results or split comment and content management behavior.
When investigating a missing translation, record the article ID and the locale of the version you want. Use the supported editorial interface or read-only API access to list its available translations and states. Confirm the French content is attached to the intended source article. If a second independent article has been mistakenly created, correct the information architecture through an approved workflow rather than changing a public URL without considering existing customer links.
Publication and draft state must be checked per translation
An editor’s view can expose draft content that ordinary visitors cannot access. Zendesk’s translation API includes a draft property, and the platform’s knowledge-base publishing workflows vary by plan and features. A translated article may be unfinished, awaiting review or intentionally unpublished even while its source-language article is publicly available. A source article’s status is not sufficient evidence that its French text can be read by a customer.
Check the exact target translation’s draft and publication state. If it is not approved, do not bypass the review workflow by changing permissions or using a preview link as a public destination. If it is approved, use the authorized publishing path and then re-open the actual locale-specific URL as an ordinary reader. Keep the distinction between content authoring and publication visible in your release notes. It prevents a mistaken attempt to “repair” a correctly protected draft.
A preview is not the same as a customer session
Knowledge administrators can see information that anonymous or restricted users cannot. An agent testing while signed in may report that the French article opens successfully, while a customer outside the permitted user segment receives a missing page. Both can be true. That is why a release check should include a session that matches the intended audience, with an unauthenticated browser when the content is supposed to be public, or a properly authorized test account when it is restricted.
Capture the URL, locale and user role under which the page was tested. Do not copy preview URLs to customers simply because those links work for staff. Preview routes can have different access assumptions or remain tied to drafts. If a public customer cannot view an approved article, compare the article’s access settings and parent visibility before editing translated text. This separates permission failure from localization failure and directs the problem to its real owner.
A target-language direct link answers only one question
When the direct French article link works, you have proved that this version can be rendered under that reader context. You have not proved that customers can find it through normal navigation or search. Conversely, if the article is absent from a French section list, the direct link might reveal whether the text is present but the hierarchy is broken. Both tests are valuable because they inspect different routes through the same information system.
Run the tests in order. Open the French category, then section, then article. Record where the path first fails. Then open the article’s direct URL and compare the outcome. If the direct URL works but navigation does not, inspect parent translations and browsing configuration. If both fail, investigate locale support, target translation publication and access rules. This branch-based reasoning is faster than repeatedly changing article titles in the hope that search will start working.
How to read Zendesk translation states accurately
Zendesk’s official translation API documents a draft flag and an outdated flag among translation properties. They mean different things. Draft concerns whether a translation is publicly released under the relevant workflow. Outdated is a status indicating that the translation needs attention or has been marked as requiring update. An outdated translation may still be visible, depending on the content and publishing state; it should not be treated as automatically unpublished solely because its review status is stale.
In a status ledger, keep draft, outdated, and reader visible as separate columns. This avoids confusing content maintenance with access. A French translation that is published but outdated needs a review of changed meaning; a complete French draft that is not visible needs a publication decision; a published current translation that cannot be navigated needs a hierarchy or permission investigation. Correct classification reduces rework and prevents support agents from accidentally promising that an unavailable page is ready.
Source-locale changes require caution
Every translated knowledge-base article has a source language relationship, and Zendesk provides functionality for changing the source locale under appropriate permissions. This is more consequential than correcting a typo: the original source determines the base from which translated variants are organized. Zendesk’s API documentation warns that deleting the article in its source locale can delete the article and its translations, whereas deleting a non-source translation has a narrower meaning.
Do not change the source locale to solve a missing translated title unless the content owner has explicitly approved that structural decision. If the French version is intended to become the authoritative original, review the impact on translation maintenance, redirects and other language variants first. In ordinary cases, it is safer to diagnose the missing French parent, publication or access state than to move the source designation. Keep destructive operations outside routine localization triage.
Worked example: the direct Spanish URL returns a different language
A public link intended for Spanish points to the English version of a help article. The article does have an approved Spanish translation, but the application’s link builder omitted or mis-specified the locale segment. The customer sees a functioning page in the wrong language and assumes the translation is absent. The source text itself is not the problem; the route requested the wrong language.
Inspect the URL that the language selector emits and the locale recognized by Zendesk. Compare the target translation’s locale property with the actual route. Open the correct Spanish article URL using the platform’s supported link generation, and check navigation back to English. Do not hard-code a guessed country suffix into every link. The chosen code must match the help center’s enabled locale scheme. A language selector should preserve both article identity and intended language.
Worked example: French article visible to agents only
A tutoring organization creates a French article explaining its parent contact policy. A reviewer signs in as an administrator, opens the translation and declares it published. A parent browsing anonymously cannot access it because the article or its parent context is restricted to a user segment. That outcome might be intentional for internal support content, or it might be a permissions mistake. Only the content owner can authorize changing the audience.
Reproduce using the intended reader role, then inspect article access and relevant section visibility. If the document contains internal process information, keep it restricted and correct any public link that suggests it is available. If it was intended as a public policy page, use the approved permission-change process, then retest anonymously. Never solve an access problem by pasting the restricted article’s entire text onto a public page without authorization. Localization QA includes protecting the audience boundary.
Worked example: the French article is marked outdated
An English support article changes the deadline for requesting a lesson reschedule from twenty-four hours to forty-eight hours. Its French version remains fluent but still gives the old deadline. An editor marks the French translation outdated. The urgent issue is not the ability to find the page but whether the visible answer now contains an incorrect policy. The status flag is a signal for review, not a substitute for understanding the changed requirement.
Compare the current source policy with the target-language sentence, verify the effective date and obtain the approved French replacement. Then update the appropriate translation and confirm its public result. Record when the source change occurred and who approved the target. A full retranslation of the whole article is rarely needed if only one policy condition changed, but the team must still inspect surrounding sentences so the new value does not contradict another instruction.
Categories, sections and articles may change at different speeds
A company might rename a help-center category from Account Help to Profile and Access, update English navigation immediately and postpone translations of its other category titles. Existing foreign-language articles can still be accurate, but their navigation becomes semantically inconsistent. Conversely, an editor may update a category title in French while leaving old article links that use English wording. Managing translated knowledge content requires attention to both content and the labels that help users locate it.
Create a light change log for hierarchy edits. Record renamed categories, moved sections and reassigned articles, then review which localized versions or links need updates. Do not assume that a title edit in one language automatically propagates to all others. The content owner’s goal should be preserving findability and conceptual grouping across supported languages, not forcing identical word-for-word labels where natural target-language taxonomy differs.
Search visibility is different from browsing visibility
A help center article may appear in a search result while being difficult to locate through category navigation, or vice versa. Search behavior can depend on indexing, locale, access and relevance. Do not treat a successful search as proof that category and section translations are complete. Likewise, do not assume that an article absent from search has no published translation. Test the browsing path and the direct locale-specific URL first; then inspect search as a separate discovery layer.
For a practical check, use a distinctive phrase from the translated article and search while the help center is set to its target language. Record whether the relevant title appears and whether its link opens the correct localized article. If it does not, look at publication, permissions, indexing freshness and language selection before altering terminology. A search result can be stale after updates, so distinguish a temporary indexing delay from a durable configuration problem using timestamped observations.
The article body can contain untranslated components
A Zendesk help article may include screenshots, tables, downloadable files, links, video captions or reusable content blocks, depending on the site’s setup. Translating its title and main paragraphs is not enough if a screenshot still shows outdated English controls or a linked form belongs to another market. Some advanced content features also affect how the APIs expose or edit articles, so treat embedded components as first-class review surfaces rather than assuming the body is one simple text string.
Make a concise inventory of high-impact components. Check what the image actually shows, the accessibility text, downloadable instructions and any live destination. If an English screenshot is acceptable as an exact representation of the software interface, explain that choice clearly. If it depicts a different interface language or outdated navigation, consider replacing it through the content team’s normal media process. Translation QA should keep instructions usable, not mechanically translate labels that no longer match the software customers see.
Do not silently change support policy while translating
Support articles often describe eligibility, waiting periods, refunds, account verification or escalation paths. A translator may be tempted to simplify a complicated policy sentence or replace an unfamiliar administrative label with a convenient phrase. That can make the content more readable while changing the organization’s commitment. The proper objective is a clear target-language explanation of the same approved process, with explicit handling of any region-specific difference that business owners authorize.
Review high-consequence statements against the current source policy. Check numbers, deadline units, qualifications, exceptions and contact channels. Where the source is ambiguous, flag it and seek a content owner decision rather than guessing. A localized support article can influence real customer actions. Its accuracy is not a cosmetic language issue; it is part of the organization’s operational reliability. Publication should preserve the distinction between translation and policy change.
Create a parent-to-child translation ledger
Use a small table containing category ID, section ID, article ID and target locale. Add target titles and flags for translation present, published, outdated, access and verified public URL. The ledger should make it obvious when an otherwise complete French article lacks a translated parent. It also exposes whether several missing articles share one untranslated section, allowing the team to fix the common dependency once rather than asking multiple writers to redo work.
Keep the ledger focused on the help-center areas that matter for the release. A new public support section may need checks for all of its articles; a small correction in one published article usually needs a shorter regression test. The same structure is reusable across languages, but individual result rows should be based on actual reads, not optimistic assumptions. A useful status is “visible as ordinary customer on the French category path,” not simply “French text supplied.”
A ten-minute investigation for one missing article
Minute one: capture the customer-facing target URL, expected title, locale and time. Minutes two and three: confirm the language is enabled and identify the original article ID. Minutes four and five: verify that the intended translation exists and inspect its draft and outdated flags. Minutes six and seven: inspect the translated parent category and section in the same locale. Minute eight: check access with the intended reader role. Minutes nine and ten: open both the direct translated article URL and the full category-to-article browsing path.
This is a triage sequence, not a promise that every help center can be audited in exactly ten minutes. Its advantage is the order: eliminate configuration, structure and visibility explanations before repeating translation. End with a one-sentence diagnosis that names the first failed layer. “French translation exists and is published, but the parent section lacks a French translation” is actionable. “Zendesk forgot French” is not.
A separate checklist for translation editors
An editor should confirm the target title, body, locale and relationship to the intended article, then check that important claims match the latest approved source. Mark the translation’s review state according to the team’s process. Verify links, screenshots, downloads and placeholders. Before requesting publication, note whether the parent category and section already support the same language. If not, send a concrete parent-translation task to the knowledge-base administrator.
The editor need not have unrestricted API or security permissions. Their job is to provide the correct message, identify incomplete related surfaces and report precise references. If they see a published translation in Studio but cannot confirm customer access, they should label that as an unverified release state rather than assuming a visitor can read it. This protects both the editor and the reader from an incorrect “ready” declaration.
A separate checklist for knowledge administrators
A knowledge administrator should confirm enabled languages, parent translations, article placement and audience permissions. They should identify whether the target translation is approved for publication and ensure the correct supported workflow is used. Where the help center has team-publishing features, respect the account’s actual stages and permissions. A content editor’s request to “make it visible” should not automatically override an intentional restricted audience or an incomplete approval.
After any authorized change, the administrator should test the same page as the intended visitor. Check the localized category, section, article and search route where relevant. Keep a record of the exact URL and result. The role is to connect correct content with the right visibility rules, not to substitute for a language reviewer or change the support policy. A simple division of responsibility makes large multilingual libraries easier to maintain.
API reads can help, but editing through APIs needs special care
Zendesk’s Help Center API distinguishes article-level metadata from language-specific translation records. Its documentation provides endpoints to list an article’s translations and inspect their fields, including locale and review status. Read-only inspection can make a confusing editor report precise. However, an API integration that updates translations is a write operation with potentially immediate effects, and its behavior may differ from the editorial workflow a team expects. Do not use a production write merely to investigate visibility.
When scripting audits, begin with safe reads and log only permitted information. Record IDs, locale, status and a minimal excerpt or checksum where appropriate, rather than exporting private support content broadly. Before any API update, review the specific endpoint, permissions and publication consequences against current documentation and the organization’s change controls. A rushed bulk update can overwrite reviewed content or publish unintended text. The speed advantage comes from targeted diagnosis, not bypassing governance.
Zendesk supplies translations for many default help-center interface strings. A visitor may see search labels and buttons in French even when the organization has not supplied French versions of its articles. That can make the site look multilingual at the navigation level while offering little actual knowledge content in the selected language. Platform interface translation and authored support content have different sources and maintenance responsibilities.
Test them separately. First confirm that a French-speaking visitor can use the interface controls. Next confirm that categories, sections and the intended article exist in French. Then verify whether custom messages or forms introduce source-language text through another feature. A translated search button is not evidence that a knowledge article has been translated, and a correct French article does not guarantee that all custom site messages are localized. Distinguishing those surfaces prevents false completion reports.
Custom navigation text may live outside article translations
A help center can include custom welcome messages, banners, disclaimers or theme snippets that are not part of the article translation object. Support teams often discover an English paragraph at the top of a French article and assume the article’s body is wrong. The text may instead come from the help-center theme or a separate dynamic-content configuration. Editing the article will not change a globally rendered banner.
Identify where the visible text originates before editing it. Inspect whether it appears across several unrelated articles, which suggests shared ownership. Then route the issue to the team responsible for templates or reusable content. Verify the fix on at least two pages and languages because a global change may affect all visitors. This is a direct application of the central lesson: locate the correct source object before translating anything again.
Common failure: source-language links survive in translated articles
A French article may correctly explain how to request a lesson change but point to an English booking form. If the form is a necessary step, the reader journey is only partially localized. Other links might point to outdated course information or a policy relevant to another market. Literal link-text translation does not guarantee destination equivalence. The page’s usefulness depends on where readers go after following its instructions.
Follow each essential link in the target-language article. Check whether it reaches the right service, form, support route or policy, and whether the destination is available in the promised language. If a translated endpoint does not exist, make the limitation explicit and seek an approved alternative rather than fabricating one. The correct action may involve another team or platform. The article should not promise a language experience that its linked service cannot provide.
Common failure: an article is moved to an untranslated section
A knowledge manager reorganizes English help content and moves an article from General Questions to a new section called Exams and Assessment. The article’s French translation remains intact, but the new section has no French title or translated parent pathway. The French article may stop appearing where users expect it. Because the move happened in English, translators may not receive any notification and understandably believe their completed article is still ready.
Before reorganizing multilingual knowledge content, review the target-language readiness of the destination category and section. After the move, test at least one article through each affected language hierarchy. Document the old and new placement so existing links and reader habits can be considered. A structural update is a localization event even when no prose changes. Treating it that way avoids sudden gaps in otherwise mature multilingual help libraries.
Common failure: a locale value looks familiar but is different
A support team works with language labels such as French and English, while APIs and routes use more precise codes. A translation might be recorded under one French regional code and requested under another. The body exists, yet the exact locale request does not resolve it as expected. The visible language selector may hide this difference because it presents a friendly label rather than a raw identifier.
Use the supported codes from the help center’s actual configuration and compare them with the article translation’s locale property. Do not guess a code from geography or change it casually on a live translation. Validate any conversion or mapping used by external translation software. After correcting an approved mapping, test a direct public URL and a browse path. Regional code mismatches are easier to catch with a small locale inventory than with repeated searches for missing paragraphs.
Common failure: copied articles become duplicates
An editor wants a French version and creates a new article with the same topic rather than adding a translation to the existing source article. The new page may be published and found by search, but it does not share the expected translation relationship. Language navigation and maintenance now operate on two unrelated articles. The next English policy update may not reach the French copy because the team does not recognize it as the corresponding version.
Inspect article IDs and translation listings before deciding how to resolve duplicates. Do not delete a live article simply because it seems redundant; customer bookmarks, search results and internal support macros may point to it. Establish the intended source article and migration plan, using authorized workflows and redirects where available. A correct translation relationship reduces future maintenance effort and makes the library easier to navigate, but it must be repaired without creating broken destinations.
A complete worked walkthrough: French help content launch
A new help-center section covers tuition schedule adjustments. The organization supports English and French. The English category and section are approved, and the French article body is ready. First verify that French is enabled for the help center. Then create or verify the French translations for the category and section under their existing identities. Confirm the article translation is attached to the intended source article, contains approved French policy wording and has the correct publication state. Check audience permissions for the article and its parent context.
Now browse as a customer: open the French help-center landing area, select the translated category, open the translated section and click the French article. Compare the resulting URL, title and body with the approved target. Test a direct link in a private window and follow important instructions to their actual destinations. Then search for a distinctive French topic phrase. The browse path proves structural visibility; the direct link proves route access; search tests discovery. Record each outcome separately.
Release-day priorities for a growing multilingual library
A help center with hundreds of articles cannot always translate everything at once. Prioritize content that enables readers to act safely and successfully: access problems, payment terms, booking changes, eligibility rules, cancellation policy and urgent support. Ensure parent categories and sections are ready before releasing clusters of translated articles. A partial language launch is not inherently misleading if the available scope is clear and the pages do not falsely imply that all documentation exists in that language.
Use an explicit coverage map: which categories are localized, which key articles are available, which translations need review, and which high-risk gaps remain. Avoid measuring only the total number of translated paragraphs. A library with many low-value translated articles and no localized path to reset an account can still be frustrating. Organization-level usefulness depends on the categories, sections and actions that help real users solve real problems.
Source updates should create targeted translation tasks
A translated support article can become wrong after the source policy changes, even though it remains published and navigable. Establish a maintenance signal when high-impact source content is edited. Record the changed requirement, effective date, affected translations and approving owner. Review only the necessary target sections when a change is small, but compare the surrounding instruction flow to ensure that revised claims still make sense.
Zendesk’s outdated flags can be part of this workflow, but a flag without a responsible person and a correction plan is not enough. Ask whether the stale target version creates a risk that warrants temporary withdrawal or a clear notice. The decision should reflect the importance of the instruction and the site’s publishing controls. The goal is accurate support, not merely a dashboard showing that a translation exists and was once reviewed.
An acceptance test that closes the loop
Before closing a missing-translation ticket, state the expected reader behavior in observable terms. For example: “A public French visitor can open the translated Classes and Scheduling category, navigate to the French Lesson Changes section, open article 12345 and read the approved rescheduling rule without logging in.” This statement identifies language, hierarchy, specific article, content and access. It is precise enough for another person to retest.
Then provide evidence of the outcome: the public URL, test role, target locale, observed title and whether the critical instruction matched policy. If a direct URL works but the category path is still broken, keep the ticket open with that narrower remaining issue. If publication is pending approval, report it as pending rather than secretly making the article public. A clear closure criterion prevents the same missing-page report from circulating among translators, support agents and web administrators.
Transfer exercise: three missing-article scenarios
Scenario one: the French article is complete and publicly accessible by direct link, but it is absent from the French section listing. Check the French parent category and section translations first. Scenario two: an administrator can open the Japanese translation but a customer cannot. Check draft, publication and access permissions under the customer’s role. Scenario three: the Spanish selector opens the English article. Check the exact locale code and URL mapping before revising text. Each calls for a different owner.
Now imagine a fourth case: the page is visible, searchable and structurally correct, but its French refund deadline is obsolete. This is not a visibility defect at all. It is a content-maintenance problem requiring source comparison and approved target revision. Being able to classify that fourth scenario is as important as diagnosing the first three. Translation work becomes quicker when teams stop treating all missing, stale and inaccessible content as the same defect.
Summary: visibility is a chain, not a translation checkbox
Zendesk Guide localization works for readers when the intended language is enabled, the category and section are translated, the article’s target version is approved and visible, and the full public route functions under the correct reader permissions. A completed translation file is only one part of that chain. Check the hierarchy before rewriting prose; check publication and access before sharing preview links; and verify content accuracy after the page becomes reachable. That approach turns a frustrating “French article missing” complaint into a small set of testable decisions.
Frequently asked questions
Why is my translated Zendesk article not showing?
Check whether the language is enabled, the article’s target translation is published and visible, its parent section and category have translations in the same locale, and the visitor has appropriate access.
Must Zendesk categories and sections be translated too?
Zendesk’s official help-center localization documentation explains that translated articles require translated parent pages in the same language to be displayed through the relevant hierarchy.
Can a draft translation be visible to an administrator but not customers?
Yes. Editorial access and public access are different. Test the intended customer role instead of treating administrator preview as proof that a translated article is publicly released.
What does the outdated flag mean for a translation?
It indicates that the translation requires review or has been marked stale. It is not synonymous with the draft property and should be considered separately from public visibility.
Should I create a new article for every language?
Normally a translated language version should be associated with the intended source article under the help center’s translation model. Creating unrelated copies can complicate navigation and updates.
Why does my language selector open the wrong article?
Verify the exact locale code, target translation association and generated public URL. A language label alone does not prove the link points to the intended article variation.
Can I fix missing visibility by updating the translation via API?
A write may affect published content and does not necessarily fix untranslated parent categories or access settings. Begin with read-only diagnosis and use approved update workflows only after identifying the actual defect.
Official sources and further reading
