How do you translate an XWiki knowledge base without confusing the language of a page with the language of the interface? This practical XWiki multilingual pages guide explains wiki language settings, translated page titles and bodies, default-language fallback, shared XWiki Objects, links, permissions and real-reader quality assurance. It is for teams maintaining multilingual documentation, internal procedures, public help centres and international community wikis.
An XWiki page can have several language versions while retaining an original default page. That design is helpful, but a translated title does not prove that embedded forms, object properties, notification messages or linked documentation have been translated. A reader may see their preferred language for one paragraph and a source-language instruction for the next. An incomplete translation can be more dangerous than an honestly labelled missing one when the page describes eligibility, safety or a time-critical workflow.
This XWiki translation tutorial follows a fictional international equipment-lending cooperative with English documentation and French, German and Japanese contributors. It separates the documented XWiki features from local editorial policy and shows how to test an ordinary visitor’s entire journey. By the end, you should be able to plan your source and target pages, record what is shared between translations, and decide whether each language version is genuinely ready for publication.
Quick answer: a safe XWiki translation sequence
Confirm supported languages and the multilingual setting; identify the default Page Content; translate the title and body; inspect the Information tab for language coverage; inventory XWiki Objects and embedded surfaces; test the target language and deliberately missing translations; secure language and subject-matter approval; and publish only after a signed-out reader can complete the task.
The real mechanics of multilingual XWiki
Understand the page as one identity with several readings
The starting point is to distinguish a wiki page from its translations. XWiki documents that one Page can be read in several languages; translations share the page identity rather than becoming arbitrary unrelated pages. The original is its Default Page Content, recorded in the language it was first written. This matters when another team modifies the source while a translator works on a target.
Write a page inventory keyed by page identity, source language, source revision and intended target locales. Record the purpose of each page in one sentence. The inventory prevents a French safety instruction from drifting away from the equipment it describes.
Open the source and a translated version in separate browser sessions. Verify that the information panel reports the expected language and that both versions refer to the same underlying page. If a contributor created an unrelated page instead, the translation controls will not automatically fix that editorial decision.
Separate wiki default language from a page’s default language
The wiki’s default language is an administrative preference; the default language of a particular page is the language of that page’s original content. A large multilingual wiki can contain pages originally drafted in several languages. Treating the installation’s default locale as proof of each page’s source language creates false assumptions about review responsibility.
For every important page, record its page default language explicitly. An English-language site can have a procedure first drafted in French by a regional coordinator. Translate from the reviewed original, not automatically from whichever language appears in the editor’s menu.
Inspect the page information and source provenance before approving a translation. Compare the critical numbers, named services and dates against the actual authoritative draft. Do not infer source authority solely from the language switcher or an English-looking URL.
Enable multilingual support deliberately
XWiki’s administration allows a default wiki language, supported languages and a multilingual setting. An administrator should confirm the actual installed version and its language configuration before inviting translators. Locale selection and page translation are related but not identical settings; one controls the reader interface and the other makes content translations possible.
Choose a small pilot: one noncritical page, two target locales, one administrator and one reader who has no edit rights. Document the current default, the supported-language list and expected fallback before changing any settings. A backup and staging copy are sensible for busy production wikis.
Test a new reader, a signed-in reader and a page editor. If the system displays French interface labels but the English body remains, do not count that as a completed French translation. Record which layer worked and which still needs authoring.
Understand language resolution without guessing
XWiki documentation describes language selection rules and administrative settings. A reader’s current interface language influences the translation they see, but installed configurations can differ in how strongly user preferences, request parameters and defaults are applied. The exact behavior should be tested rather than inferred from one administrator session.
Write a short resolution table with a reader’s preference, requested page, translations available, translation delivered and evidence. Cover an anonymous browser, a signed-in member and a person arriving through a shared direct link.
A successful test does not merely show a French heading. It records the actual rendered language for title and body, identifies the page language and explains what happens when the requested translation is missing. Repeat after upgrades and configuration changes.
Make fallback a truthful user experience
The XWiki page-translation guide states that when a target translation is not available, XWiki displays the page’s Default Page Content. This is valuable because a reader may still obtain the information, but the content is not translated simply because it was displayed on a multilingual wiki.
For a German reader requesting a French-only procedure, decide how the site communicates the fallback. Consider visible language labels, contact details and the ability to request a translation. A policy must not promise an automatic translation where none exists.
Visit a deliberately untranslated page while using the target interface language. Verify which title and body appear. The test passes only if the team has anticipated that experience and does not quietly present source-language text as approved target-language guidance.
Use the page information panel as a control
XWiki describes an Information tab that exposes the current page language, default language and available or missing translations. This can serve as a useful editorial checkpoint. A page may have three supported translations, while several others are still absent; the difference should remain visible to maintainers.
Train reviewers to capture the current-language status at the beginning and end of a translation job. The status is not an accuracy score. It establishes which versions exist; a human still has to verify facts and natural wording.
When a contributor claims a page has been translated, inspect the panel and the actual body. Check whether it is a real target-language version or only an interface-locale switch. Save a compact sign-off record with reviewer, date and source revision.
Preserve the difference between strings and content
A wiki interface includes navigation, menus and editor controls, while page content includes instructions, tables, FAQs and examples. These surfaces can be localized separately. A translated interface can make a wiki seem ready when the reader-facing material is still in the wrong language.
Build a surface map: site navigation, page heading, body, table text, file names, forms, search results, notification emails and extension-generated widgets. Put each surface beside the team or system that owns it.
For the equipment cooperative, ‘Return by Friday’ on a page and ‘Return deadline’ in an application form may come from different sources. Test the page and the action, not only the visible article.
Treat XWiki Objects as a shared-data boundary
Current XWiki documentation makes an important distinction: translations of a Page share the same XWiki Objects. The Object editor opens the Default Page Content even when the reader is viewing a translation. As documented in October 2026, per-translation structured Object data is not currently a general capability.
Before localizing a page that contains custom classes or objects, ask where the visible text actually resides. Do not assume a translated page body provides isolated per-language object fields. A field like membership status may rightly be shared; a long explanatory label may need a separate localization design.
Open two translations of the same object-bearing page. Change only a safe test object property in staging, then check whether both languages reflect the result. If they do, document the shared nature and avoid treating the same property as two independent translations.
Design multilingual structured data without inventing a feature
If a cooperative stores product model numbers, quantities and loan status as XWiki Objects, those values may be language-independent. Descriptive text such as instructions or warning labels is different. Because objects are shared, teams should plan an explicit structure for language-specific descriptions instead of expecting the page translator to replicate object properties.
Possible designs include localizable content in the page body, an approved extension that supports language-specific records, or an application-level dictionary with explicit locale keys. The right choice depends on the wiki model, integration requirements and editorial permissions.
Write a test for every localized field: where is the French version stored, what happens when it is absent, who can edit it and how will an API consumer choose the intended value? A plan that cannot answer those questions is not ready for production.
Avoid accidental content rewriting through object editing
A translator may open a French version, switch into an object-editing view and assume they are modifying only French metadata. The documented editor behavior contradicts that assumption. Shared object edits may change what readers in every language experience, even when the translator intended a harmless localized improvement.
Provide translators with a clear boundary between page translation and structured object administration. Reserve shared object edits for owners who understand the cross-language effects. Use staging data when teaching the distinction.
After an authorized shared edit, test two target languages and the default page. Record not just that the object value saved but where it is displayed, whether labels are accurate and whether the change altered decisions readers make.
Translate page titles as navigation promises
A page title often appears in search results, breadcrumbs, navigation lists and copied links. Translating it well requires understanding what task the page solves. A literal translation of ‘Issue a loan’ might be mistaken for a financial transaction in a community-equipment setting.
Use a glossary to disambiguate terms before approving titles. Have a native-language reviewer ask what they expect to find after clicking. A concise title should agree with the page’s actual procedure and not overpromise a service.
Test the translated title in a search-result snippet and in the page itself. If the title promises reservations but the instructions cover pickup only, revise the wording; the error harms navigation even if every sentence is grammatical.
Respect page links as functional references
Links connect procedures into a useful knowledge system. A French page that sends readers to an unrelated German policy breaks the experience. Some destinations may not yet have French translations; the right response is to keep the destination accurate and disclose its language rather than fabricate a target page.
Create a link map for the most-used tasks. Label the destination language when it differs. Check that new language versions do not introduce circular routes, lost attachments or redirected pages with unrelated meanings.
Walk the entire journey from ‘Borrow equipment’ to ‘Check eligibility’, ‘Reserve’, ‘Collect’ and ‘Return’. Record the first wrong-language or dead-end destination. That point is often more valuable than another round of isolated proofreading.
Keep numbers, units and obligations stable
Many localization mistakes are factual, not lexical. ‘Seven calendar days’ must not become ‘one week after pickup’ if pickup and approval dates can differ. A capacity of two items per account cannot become two items per transaction. This kind of drift creates unequal access across languages.
Create a controlled facts table: source statement, meaning, owner, permitted regional variation, current evidence and languages affected. Require explicit approval before changing rules for a local audience.
Test a bilingual example. Give two reviewers the same loan scenario in different languages and ask them to calculate the last return day, allowed quantity and next action. If the answers differ, the translation is not functionally equivalent.
Preserve placeholders, macros and generated blocks
Wiki pages can contain macros, embedded views, dynamic values and formatted blocks. A translator sees the resulting phrase but may not control the source of the variable. Editing syntax inside a translation can break rendering or silently change a live value.
Make translatable text distinct from functional syntax. Protect identifiers, macro names and trusted link targets. For any code-like example, decide whether it is an executable instruction, illustrative quotation or natural-language explanation.
Render each translation as a reader rather than inspecting only the editor view. A code block that looks correct in source may overflow at mobile width, and a date macro may show a locale the editor never requested.
Plan permissions before distributing translation work
International contributors often need permission to translate particular knowledge pages but not to edit shared global configuration or sensitive records. A multilingual launch is an opportunity to review privileges, not to grant every translator broad administrative control.
Create a permission matrix by role: source author, translator, regional reviewer, technical owner and release approver. Include who can update shared XWiki Objects and who can modify wiki-wide language settings.
Run an account-level acceptance test. Sign in as a translator and attempt only the authorized tasks. Confirm that the contributor can submit an intended translation and cannot change unrelated shared data. Record any permissions that need adjustment.
Create a source revision that reviewers can trust
Translations become stale as soon as an original procedure changes. A revision date matters only when readers can tell which source revision a translation reflects. Cosmetic edits should not have the same urgency as a change to refund policy, eligibility or safety instructions.
Attach source revision, translated revision, reviewer and change category to every active target language. Distinguish minor phrasing, substantive process changes and urgent corrections. A good ledger makes an overdue translation obvious before a customer encounters it.
Change one noncritical sentence in staging and observe how contributors learn about it. Then simulate a major rule change. The two cases should not have identical publishing urgency or the same sign-off threshold.
Support revision-specific translation review
When a page is substantially rewritten, polishing the old translation may be wasted effort. Translators need to see what changed in the source, especially when a date, name or eligibility condition is embedded in a long paragraph.
Use a diff-based review: extract changed sentences, explain why they changed and tell reviewers which related pages depend on them. Do not retranslate untouched content merely to make a whole document appear newer.
A reviewer should be able to say: ‘French version checked against source revision B; quantity limit unchanged, pickup point updated, deadline now explicit.’ This statement is more meaningful than ‘French translation complete’ without provenance.
Localize the reading journey, not just the article
A help centre succeeds when a reader can finish a task. The most important user experience may happen outside the page body: downloading a form, finding a contact, understanding a confirmation email or reaching an accessible support channel.
Choose three reader tasks and map every step from arrival to completion. For each step, note which language the reader sees, what decision they make and how they recover from a problem.
Ask a tester to complete the journey using only the target language. Watching the tester hesitate at a partially translated confirmation can expose a higher-priority problem than finding an awkward adjective on the opening page.
Make search work for the actual target vocabulary
A translation can be accurate yet undiscoverable because readers use different words from the ones the editorial team expected. In XWiki knowledge bases, people may search for ‘return an item’, ‘check equipment in’ or a local synonym. Internal search behavior can vary with configuration and indexing.
Compile a small search-intent vocabulary for each language. Record the common question, the title the reader expects and alternative terms. Use descriptive headings and explanatory text naturally, not lists of repeated keywords.
Test searches as anonymous users. Compare whether the correct localized article appears and whether snippets actually match the query. A successful title search alone does not prove that ordinary problem wording finds the page.
Manage multilingual screenshots and attachments
A screenshot of an English form may conflict with a translated French instruction. An attachment may be the actual binding policy while the on-page introduction is only a summary. Readers must know what language and version apply to the file they download.
Inventory every attached PDF, chart, spreadsheet and screenshot. Identify whether a local-language edition exists, the date it was approved and whether a single shared attachment is intentional.
Open each file on mobile and desktop. Check not only that it downloads, but that its title, language, content, revision and links are consistent with the translated page. If a translation is absent, label the available file honestly.
Avoid machine translation as unreviewed publication
Machine translation can help produce a starting draft, but it does not know the cooperative’s actual policy. It may change a conditional approval into a guarantee, confuse equipment names or turn a deliberate technical term into a familiar but wrong one.
Separate draft generation from approval. Protect numerical facts, terminology and link destinations; then have an accountable reviewer compare the target with the source and test the task in context.
A useful test asks the reviewer to explain what a reader would do after reading the translated sentence. If the answer differs from the source procedure, revise the content even if a language tool scores the grammar highly.
Handle regional variations without pretending they are translations
A German-speaking branch may have a different collection address, operating hours or loan policy. That is localization, not merely converting English words to German. The authority for a regional rule must be established separately.
Use shared core facts plus approved local exceptions. Mark the origin of every regional detail and the date it was verified. A translator should not invent local delivery times or change legal eligibility on stylistic grounds.
Test cross-region traffic. A visitor selecting German because it is their language should not automatically be treated as living in Germany. Language, residence and service region are three different concepts.
Check accessibility in every language
Longer translated labels can be cut off in navigation. Screen readers may announce content with the wrong pronunciation if the page or component language is not correctly indicated. Instructions that depend on colour or an image become harder to understand in every language.
Include keyboard navigation, heading order, link names, form labels, error announcements, zoom, mobile layout and language metadata in your QA plan. Invite testers who rely on assistive technology when possible.
When evaluating a language selector, ask whether its options are understandable without colour flags and whether keyboard users can return to the same content. A language switch is part of navigation, not a decorative widget.
Make publication and rollback distinct decisions
A translation might be linguistically approved but technically broken. Conversely a page may render beautifully with an unapproved rule. Neither is ready to go live. Release management needs content approval and delivery approval as separate decisions.
Create a gate requiring language reviewer, subject-matter owner and technical verifier. Document the page identity, exact target language, revision, test URLs and known limitations. Allow a release to be blocked for a single serious discrepancy.
Simulate rollback in staging. Ask who can withdraw an unsafe translation, what language readers see afterward and how the team notifies the right owners. A measured fallback is safer than leaving a misleading translation visible.
Measure maintenance as an ongoing editorial responsibility
After launch, translated pages receive uneven attention. A frequently edited English source may outrun its translations; a low-traffic target may still be crucial to a specific reader group. Page view counts alone are therefore an incomplete maintenance signal.
Track active translated pages, outdated revisions, broken target-language links, unresolved reader reports and the time taken to correct critical issues. Review the measures periodically with the same owners who approve source changes.
A dashboard should lead to action, not just reassuring percentages. If the French return policy is old, name the person who will review it and block risky instructions if needed. Keep an audit trail of what changed and why.
Ten practical cases that reveal common translation failures
Case 1: The absent translation
A Japanese-speaking reader selects Japanese, opens the equipment eligibility page and sees the English default. This is a documented type of fallback, not evidence of a Japanese translation. The team adds an honest language notice and a contact path; the reviewer verifies that the default page remains factually current and the reader is not misled about language coverage.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 2: The shared object hazard
An editor views a French translation and opens Object editing to adjust a local message. Because objects are shared across XWiki page translations, the resulting change may affect English and German readers. The resolution is to restore the approved shared value, move localized explanatory text to a suitable translation-aware location and retest all affected languages.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 3: A deadline interpreted differently
The source says a return is required within seven calendar days after collection. A translation says within a week of booking. The test constructs a booking on Monday and a pickup on Wednesday; two language readers calculate different deadlines. The error is corrected by explicitly preserving the collection event and the calendar-day unit.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 4: The title that promises the wrong action
An English page titled Request Equipment is translated as Reserve Equipment. Readers expect an instant booking, but the workflow requires manual eligibility review. A local reviewer selects a title that expresses application rather than confirmation and confirms the on-page button and automated email match that promise.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 5: The untranslated attachment
The translated borrowing page links to an English-only signed agreement. An editor had assumed the language switcher would localize the file automatically. The team labels the file’s language, creates an approved version if required, records the agreement’s revision and tests the target-language download.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 6: A mobile link loop
A translated help page links to the translated FAQ, which redirects the reader back to the start through a language-dependent route. Desktop editors miss the loop because they are signed in. An anonymous mobile test reveals it. The release test now includes direct links and back-navigation from every target locale.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 7: A regional rule mistaken for a language choice
A French-speaking visitor in Canada sees the France branch’s pickup address after choosing French. The translation is linguistically correct but regionally wrong. The page separates language preference from service-region selection and asks for location only where it materially changes the procedure.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 8: The hidden search vocabulary
Spanish users search for an everyday phrase meaning return an item, while the page uses a technical inventory expression. Reviewers preserve the accurate term but introduce natural task wording in the heading and introduction. Search results improve without stuffing keywords or creating a duplicate article.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 9: An urgent source edit
A source owner changes a hazardous-equipment handling instruction. The German translation still shows the old procedure. The team flags the translation, notifies its reviewer and uses a documented fallback or withdrawal decision until a verified target version is available. Cosmetic source edits follow a lighter review path.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Case 10: The misleading completion metric
A team reports three of three languages complete because translations exist in XWiki. A task walkthrough finds the Japanese confirmation email and French embedded widget still in English. The scorecard changes from page existence to verified reader task completion, with exceptions named rather than hidden.
To make this case measurable, write down the source-language statement, the target-language action a reader is expected to take, the rendered page language and the outcome of a signed-out test. Compare outcomes rather than only comparing word choices. If the test exposes a contradiction, correct the responsible content layer and repeat the same task with the same assumptions. Preserve a short result note so another editor can reproduce the issue after the next source revision or platform upgrade.
Tools for editors, reviewers and administrators
A practical multilingual release inventory
For every critical page, record a stable page identifier, default page language, supported target languages, owner, last meaningful source change, translated body status, shared object dependencies, files, outgoing links, expected search terms and test accounts. This is not bureaucratic excess. It turns a vague statement such as ‘the help centre has been translated’ into a list of checkable claims. Columns can be maintained in any approved tracker; their purpose is to show what a reader can actually use. Start with the ten most visited task pages, not a heroic inventory of every historical draft. Once the first ten work properly, extend the same method to less active content. Never mark a language complete because a translator opened a page or entered one sentence. Require tested evidence that the essential task works.
A worked editorial decision for multilingual labels
Suppose the English interface says ‘Request loan’, the page explains an equipment borrowing programme, and the underlying object contains a field named loanStatus. The system identifier can remain stable while the visible label changes with language. Translate the reader-facing instruction in the page and check any application-specific localization mechanism for labels, rather than editing a shared technical field as if it were language-specific. If a German reviewer recommends wording that implies the item is reserved, ask whether that promise is correct. If approval is manual, reject the misleading translation. The vocabulary should communicate the same state transition, not copy a dictionary equivalent. In the reviewer notes, preserve the canonical field meaning so future contributors do not repeat the mistake.
An acceptance test with deliberately missing material
Create a staging page containing a short paragraph, an image with meaningful alternative text, a link to another page, a table with a date and an XWiki Object-backed field. Translate only the paragraph and title into French. Switch to French as an anonymous reader and document each rendered surface. Then inspect German, for which no translation exists. This one test demonstrates that the presence of one translated paragraph cannot be equated with complete localization. Now fix only the surfaces controlled by page translation, and document how the other surfaces must be owned. Repeat in narrow mobile layout, with keyboard navigation, and while the browser’s preferred language differs from the user account’s preference. Preserve screenshots or a concise observation log for future version comparisons.
A governance pattern for distributed wikis
The source author understands the service rule; the translator understands the target language; a regional reviewer knows local usage; a technical owner understands objects, macros and rendering; a release approver knows what level of risk can be accepted. These responsibilities may belong to the same person on a small site, but the distinctions still matter. Separate an issue about a misspelt label from an issue about an altered deadline, and assign each to someone who can resolve the actual cause. When an emergency correction is needed, the owner can suppress an unsafe instruction temporarily without pretending a new translation has been approved. This structure keeps international participation possible without giving away control of shared business logic.
A realistic maintenance calendar
A multilingual knowledge base benefits from scheduled review, but not all pages need identical intervals. A stable explanatory article may be checked when its source changes, while an operational rule about opening hours should be checked before relevant seasonal changes. Build a simple review rhythm: weekly triage for reader reports, monthly checks of high-impact translation gaps, and event-driven reviews after policy or software changes. Include obsolete links and missing attachments in the same queue. Report exceptions plainly. If a translation has not been reviewed since a major source revision, its status should say so. Do not hide a known risk behind ‘translation complete’ percentages that measure file count rather than current meaning.
How to train a new translator using one page
Give the trainee one small document and ask them to identify the page’s default language, available translations, untranslatable identifiers, any shared object fields and three statements that readers must interpret exactly. Next, let them translate the body in staging. Have a reviewer walk through a fictional request in the target language, not just proofread the text. Finally, ask the trainee to explain what would happen if a new reader requested a missing language. A good answer notes fallback to default page content and distinguishes it from automatic translation. This exercise teaches platform boundaries and communication responsibility at the same time, without requiring a huge documentation project.
Questions to ask before choosing any automation
Does the proposed language tool preserve links, macro syntax and identifiers? Does it distinguish the page body from shared XWiki Objects? Can it disclose confidence or review status? Where is private documentation sent, and who may access it? Does the organization have permission to use that service? What happens when the source is revised? Does publishing require a human sign-off? These questions matter more than the advertised speed of draft generation. For protected customer records or confidential knowledge bases, apply the organization’s privacy and security requirements before exporting any content to a translation service. Even an excellent translation tool cannot authorize a change to a policy it has never verified.
Reader questions and direct answers
Can XWiki show a default page when a translation is missing? Yes: its documented page translation behavior falls back to Default Page Content. Are page translations and interface translation identical? No: menus and editor labels are different surfaces from a wiki page’s title and body. Can every XWiki Object have independent translated values by default? The current object-translation documentation says page translations share Objects; do not design as though separate object instances exist per language. Does a translated page guarantee translated attachments? No: files and embedded content need their own checks. Is human review always needed? For high-impact instructions, accountable subject-matter and language review are essential because apparent fluency does not prove functional correctness. What should be tested first? Choose one actual reader task with at least one missing translation and a shared-data surface.
Reference documentation and next reading
The official XWiki documentation describes language configuration, page translations, fallback to Default Page Content and the current boundary for shared Objects. Check documentation against the installed version before treating a UI label or feature as universal.
XWiki: Page Translations · XWiki: Language Configuration · XWiki: Objects in Page Translations · Master Art of Translation · Translate Like a Pro series index.
Final release decision
A reliable XWiki translation is not a second-language paragraph pasted into a page. It is a reader-usable version with truthful fallback, accurate shared data, correctly scoped permissions, working links and a documented revision. Translate where the platform supports translation, design explicitly for the surfaces it does not isolate, and test the actual journey before promising a multilingual service.