The fastest way to damage a multilingual content database is to treat translations as copies of entire records. Directus translations interface QA starts with a different model: one primary item holds shared identity, while related language records hold text that changes by locale. When people search for Directus multilingual content, Directus translations field, Directus languages collection, or Directus translation API filtering, they often need to determine whether that relationship has actually been built and used correctly.
A Directus editor may show attractive tabs for English and German while a public website requests every translation row, displays the wrong title, or exposes draft text. Another team may translate a shared product identifier by mistake because it placed the field in a language-specific child collection. These are not simply wording errors. They are failures to distinguish the central record from its localizations. A useful QA method must inspect the data model, one example record, access rights and the response seen by the reader.
This article has one dominant reader job: validate an existing Directus content-translation structure so each language’s text is attached to the correct primary item and retrieved without corrupting shared fields. It does not attempt to translate the Directus Data Studio interface, recommend an AI provider or replace a general guide to translation quality. Examples use a hypothetical education resource catalogue and invented records; nothing here should be applied to a live database without appropriate backup, review and access control.
The quick answer: check three linked collections and one consumer
For the common Directus content-translation pattern, begin with a primary collection such as courses, a languages collection and a translation junction such as courses_translations. The primary collection contains the identity and shared attributes of each course. A related translation row contains a language reference and the fields that must change, such as title, description or learner-facing instructions. The translations alias field exposes this relationship in the editing interface. A working UI is only the first test; the public consumer must retrieve exactly the language record it wants.
Take one course that is easy to identify. Record its stable primary key, its language-independent duration and the approved English and German titles. Then check that the related translation rows are associated with that primary key, have distinct valid language references and carry only the intended localizable fields. Finally query them through the same API pattern that the website uses. If the data model and API agree, language review can focus on meaning; if they disagree, changing sentences will only conceal the underlying structural defect.
Why Directus multilingual content is relational content
Directus exposes the structure of a database. This is a strength when a multilingual project needs different teams to maintain shared facts and local-language presentation, but it also makes the data model part of the translation workflow. A course number, room location and unique reference may have one meaning across regions. Its title, synopsis and registration explanation may need several language versions. Putting all fields into separate full copies of the course makes updates hard: a room change could be made in English and forgotten in German, even though it is not a linguistic difference.
The translation interface provides a way to keep those responsibilities apart. The primary record answers “which thing is this?” The language row answers “how should this thing be described to this audience?” A translation is therefore not just a string but a relationship: parent item, language key and localized fields. QA must verify all three. A beautifully translated child row linked to the wrong parent is operationally incorrect, while a perfectly linked row with a mistranslated deadline is linguistically incorrect. The checks complement one another.
Distinguish content translations from Studio translation strings
The Directus documentation describes more than one translation mechanism. Data Studio translation strings help localize configuration labels, placeholders, field notes and similar administrative interface copy. Content translations, by contrast, concern the data in your collections and the text ultimately served to readers. These mechanisms can coexist. Changing a Studio label from “Duration” to a German equivalent does not translate the public description stored in a courses_translations row.
This separation prevents one of the most common troubleshooting detours. An editor changes the app language preference and sees German menus. The lesson catalogue remains English, so they think the translations feature is broken. In reality, the interface preference is not the same as choosing a target-language content row for a frontend request. Establish which string the complaint refers to: a setting label, a content field, a frontend component or a browser translation. Only then decide which system owns it. Translation work speeds up when labels and content are not mixed together.
Understand what the Generate Translations wizard creates
Current Directus documentation describes a Generate Translations setup in the collection’s Data Model settings. The wizard can create a languages collection, a translations junction, relationships and a translations alias field. It can also take selected fields that should be translated. In a new project this reduces the risk of wiring a many-to-one reference incorrectly, though the operator must still choose the right fields and review the resulting schema. Existing projects may use a manually constructed equivalent with different names.
A cautious audit does not assume all sites follow the example names. Open the actual project schema and note the collection identifiers, key field types, relation directions and translated columns. If the junction is named training_locales rather than courses_translations, use its real name. If a business has an established language table with codes such as en-GB and de-DE, verify its primary keys before changing anything. The wizard reduces setup labor; it does not decide which business values must be shared or which locale convention the publication system requires.
Use a field-placement test before importing translated copy
Every field should answer one question: does changing the language change the value’s meaning or only its presentation? A title normally belongs in a translation row. A numeric internal ID normally stays on the parent. Some fields require judgment. A URL slug might be localized if the website has locale-specific routes, but a permanent system identifier should not be. A price can be shared as a base value while a frontend formats the currency differently, or market-specific prices may require a separate pricing model. Do not use translation rows as an unexamined substitute for regional business logic.
Draw two columns on a page: shared and localized. Put the real fields from the project into those columns. Ask the person responsible for the business meaning to approve ambiguous items. If staff can change the campus address without editing every language row, that suggests the address is shared structured data. If people in different languages need different instructions to reach the same campus, the explanatory text can be localized. A field-placement decision made once can prevent hundreds of inconsistent edits later.
Language codes are data keys, not cosmetic labels
A language row might display “German” while its stored key is de-DE. A filter using de will not necessarily match that key. Never infer the exact value from the friendly label in a dropdown; inspect the project’s language collection. Some organizations use regional variants because spelling, school terminology, consumer law or product availability varies. Others deliberately use language-only codes. Neither strategy works if translators use one convention, API developers use another and the frontend selector displays a third.
Build a small registry of supported language codes and their intended audiences. Include examples of how each code should be passed to the API and how missing coverage is handled. If an article has en-US and de-DE translations but none for fr-FR, the website must not invent a French child record simply because the languages table contains French. Language availability in the schema and translation availability for one particular item are different facts. QA should test the specific item, not only the project’s global language list.
Verify parent identity before judging the translation
Suppose a catalogue contains two courses titled “Introduction to Algebra,” one for Primary learners and another for Secondary learners. Their English titles resemble each other, and translators may receive a spreadsheet with only titles. Without the primary key and programme context, the German rows can be attached to the wrong course. The words might be perfectly grammatical but direct families to unsuitable lessons. A comparison based only on visible titles may miss this because the wrong course still has plausible metadata.
For every sample, compare the primary item ID, school level, duration and related translation rows. The translation junction should point to the intended parent. Test with deliberately contrasting records so an accidental cross-link is obvious: one forty-five-minute beginner workshop and one ninety-minute advanced session. Then verify that both English and German responses keep the shared facts of the correct parent. This is a structural equivalent of checking a name against the correct examination paper before marking it.
Prevent duplicate child rows for the same language
In a multilingual data model, two translation rows for the same parent and language can create ambiguity. A frontend may choose the first, the last, or a result that varies with sorting; an editor may update one while the site reads another. The right uniqueness rule depends on the project’s schema, but QA should establish whether each intended item-language combination resolves to one authoritative translation. If duplicate rows exist, investigate rather than deleting them reflexively. One may be a pending migration or an abandoned draft whose content needs recovery.
A useful audit groups translation rows by parent key and language key, then reports combinations with unexpected counts. It also identifies a missing language row separately from an empty translated field. These two defects have different remedies: creating a language record versus editing a specific attribute inside an existing record. A report with clear parent and language keys lets the responsible editor repair exactly the affected object while leaving the shared course untouched.
Check that the alias field really exposes the intended junction
The translations field shown in Directus is commonly an alias over an underlying relationship, not a plain text column that contains all translations. That distinction matters when a team exports data or writes a frontend query. A flat export may omit the nested relation unless requested, leading someone to conclude that no translations exist. A query may fetch the parent item successfully but return no child text because it asked only for default fields. The failure is retrieval shape, not necessarily content absence.
Read the project’s data model and API field-selection behavior. When testing, request the parent key and a minimal subset of translation data, including the language code and translated title. Do not fetch every relation and every private attribute to save a few seconds of planning. A deliberately small response is easier to compare and reduces the chance of exposing information that a public website should not receive. If the relationship is wrong, fix the schema or query at its source instead of copying text into a convenient unrelated field.
A read-only API comparison that avoids hidden assumptions
Use two requests for one parent item: one that fetches the shared fields and another that deliberately includes the relevant translation relationship. The exact URL, field names and nested filtering syntax must match your Directus version and schema. In Directus APIs, relational filters and selected fields can be used to narrow results, but selecting parent items that have a translation is not the same as narrowing the child rows returned. Confirm the documented fields, filter and deep behaviors rather than guessing that one condition applies everywhere.
The test response should make four claims observable. The parent ID is unchanged between languages; each child row declares its language; its text matches the approved translation; and the public consumer selects only the intended child for display. If the response contains both German and English children, that may be perfectly correct at the API level. The frontend still has a responsibility to choose. A page that displays the first child found is not reliably multilingual; it is relying on incidental array order.
Worked example: the German course has the right title and wrong duration
A parent sees a German title for a Secondary Mathematics tutorial but a duration of thirty minutes, although the English record states ninety minutes. Investigate where the duration lives. If it exists as a duplicated column in every translation child, one copy may have drifted. If it lives once on the primary course, inspect whether the frontend combined the German title with the wrong parent. Both can produce the same visual symptom, but the fixes are different.
A good relational model keeps the canonical duration in a shared field unless regional delivery truly differs. In the QA sheet, compare the parent key and duration first, then the German language row. Do not “translate” thirty to ninety merely to make the display agree; that could mask a data linkage error and leave other languages broken. When the stored data is correct but the page is wrong, trace the frontend’s mapping step. Correctly separating shared and localizable information makes these faults much easier to isolate.
Worked example: the language tab exists but is empty
A content editor opens a course and sees tabs for English, German and French. The French tab is blank. There are several possible explanations: no child record exists, required French fields have not been entered, the editor lacks permission to read a relevant relation, or the selected language code does not match the stored translation. The presence of a language tab only indicates that the project recognizes the language as an editing option. It does not prove the content has been translated.
Inspect the child collection directly with an authorized read-only view if available. Check whether the parent-language combination has a row and whether its intended fields contain reviewed content. Then confirm the editor’s role can see those fields. If permissions are the cause, do not widen access indiscriminately. Adjust the workflow with the administrator to preserve the least-privilege policy. The result should be a precise status such as “German complete, French not created,” not “the translation feature is unreliable.”
Worked example: English text leaks into a German card
A catalogue tile shows its German course title but an English summary. The direct page is fully German. Because the card and page may use different queries, the first diagnostic step is to inspect the tile’s input. It may request title from the child row while taking summary from a shared parent column. Or the translated summary field may never have been added to the junction when the system was built. Some applications also use an older cached card response than the direct page.
Name the visible fields and their owners separately. Ask whether the German summary is present in the child row, accessible to the query and correctly mapped to the component. Each answer narrows the failure. If the field does not exist in the model, a schema and content migration is required; if the row contains German copy but the page uses English, the frontend mapping or cache requires correction. Telling translators to rewrite the whole article would waste effort and perhaps produce new inconsistencies.
Worked example: a language filter returns no children
A developer expects the French translation but an API query returns an empty translations array. The source records show a French row, so someone suspects data loss. First compare the actual stored language key with the filter value. fr-FR and fr are not automatically the same string. Next check whether the filtering rule is aimed at the correct nested relation and whether the role running the request can read it. Finally inspect whether the child record is linked to the same parent ID queried by the frontend.
A query that yields no children should be treated as diagnostic evidence, not an instruction to create a duplicate record. Recreating the translation without understanding the mismatch can compound the problem. Write a tiny expected-versus-actual test: primary item 27, target code fr-FR, one authorized translation row expected, zero returned. That report gives a developer an actionable starting point and keeps the content editor from changing unrelated copy.
Worked example: a CSV import scrambles the translation ownership
A team exports course translations for review, but a spreadsheet contains title, language name and body without the parent primary key. When the translated rows are re-imported, similar titles cause records to be matched incorrectly. Such an import can appear successful because valid rows were inserted, yet the published catalogue now pairs the wrong description with the wrong course. The important lesson is that spreadsheets must preserve relational keys, not merely human-readable titles.
Design an import review file with a stable parent identifier, stable language identifier, translatable columns and perhaps a read-only context column such as course level. Protect identifier columns from translation. After a test import into a safe environment, spot-check the relationship graph, not just the number of inserted rows. Include two courses with similar titles to catch accidental matching by name. A record count alone proves that data moved; it does not prove that translations are attached to the correct objects.
Decide how draft and publication status actually work
Directus is highly configurable, so a project may represent publication through a status field, workflow rules, roles or another approved process. Do not assume that merely saving a translation row makes it available to every public API consumer, nor that an editor-visible translated row is already published. Inspect how this particular website filters public items and translated children. The data model and permission policy together determine what users can retrieve.
A release matrix can have separate columns for translation completeness and publication eligibility. German copy may be reviewed but withheld because its parent course is not yet open for enrolment. French copy may be live while Spanish remains in review. The frontend should not present the presence of a language row as proof that the relevant service is available in that language. A well-designed workflow describes exactly who may approve the text and who controls the public visibility of the parent item.
Permissions: why an administrator’s successful test is not enough
A Directus administrator may see all translation rows while an anonymous visitor’s API request retrieves none. This is often a correct permission boundary rather than a translation failure. When troubleshooting a public page, reproduce the request with permissions equivalent to the intended consumer. Check read access to the primary collection, translations junction, language relation and specific fields. An API can return the parent title or ID without granting access to the related private content.
Avoid the tempting shortcut of making every field public. The child collection may contain unpublished text, reviewer notes, internal notes or information that should not be exposed. Decide which fields the public site needs and restrict the consumer accordingly. In a school context, no real learner personal information should be stored in example datasets or exposed to prove that localization works. A useful QA result states the role, requested fields and observed permissions outcome without printing credentials.
Avoid accidental language drift after parent edits
A shared course duration may change from ninety to sixty minutes; the explanatory wording in several languages may still refer to ninety minutes. Strict normalization of structured data reduces duplication, but it cannot eliminate all facts repeated inside prose. Editors therefore need an impact rule: when a shared fact changes, identify dependent translated text and request review. Not every language version must be republished in the same minute, but differences must be tracked rather than discovered by visitors.
A simple content inventory can associate translation rows with factual checkpoints such as date, campus, session length and qualification. When one changes, mark the dependent language rows for verification. The reviewer should check the intended source of truth before translating again. If the source course has an invalid duration, faithfully rewriting it in another language will only spread the mistake. Content governance is the quiet half of accurate localization: it keeps the facts stable while language remains adaptable.
Keep regional variation separate from translation
A German-language course description might serve families in Germany and Austria, but the same text may not always be suitable for both. Qualifications, school terms and registration rules can vary. A multilingual data model should not pretend that language and market are identical concepts. It may need region-specific copy, business availability rules or content references. The structure depends on the product, but the question should be asked before editors create many almost-identical translation rows.
For every target language code, record the intended audience and any country-specific constraints. A price or legal requirement should not be moved into a translation field merely because different markets use different values. Those differences may deserve their own structured model. Test a regional variant with a clear business-rule difference so the team can see whether the API returns the right factual data alongside the right language. The objective is an informed user, not simply a high number of translated fields.
Media and alternative text need distinct ownership rules
An education guide might use the same photograph in several languages while changing the image caption and alternative text. If the image itself contains instructions, a localized asset or accessible accompanying explanation may be needed. In a relational CMS, media assets may be referenced from the parent, while their language-specific descriptions live elsewhere. That is acceptable if the frontend can render the intended text. It fails when a German page uses an English caption simply because the image is shared.
Audit the rendered component: asset identity, caption source, alternative text source and any embedded words. Confirm that replacements respect media licensing and that accessibility descriptions match the actual image. A screenshot alone cannot reveal whether the accessible name is translated, so inspect the relevant markup or accessibility tree. Avoid duplicating large media records solely to translate a small label when the project supports a cleaner separation of shared asset and localized description.
Translating nested references without confusing the reader
A course may reference a tutor profile, category, location and related resource. Each relation may be shared or separately localized. The translations junction for the course does not automatically solve every relation’s reader-facing labels. Consider a German course page with a tutor name, subject category and “Read more” card. The tutor’s proper name may remain the same; the category should probably use a German display label; the related article should lead to a suitable target-language page when available.
Trace the data owner for each element. Do not make a translated copy of the tutor solely to preserve the same person’s identity unless the wider model requires it. Check whether a related article’s target-language variant exists before constructing a destination URL. If only English material is available, be transparent. This layered review prevents a common user experience in which the first screen is localized but every onward click returns to an unrelated language or, worse, the wrong information resource.
Design fallback at the consumer boundary
A Directus collection may store every available language row; a frontend decides what to do when the requested language is missing. That choice should not be hidden inside an accidental “take the first result” rule. Define an explicit policy. Some teams use a default language with a visible notice; others omit the item from translated listings until coverage is complete. High-stakes material may require withholding a localized route entirely rather than showing a partial translation without explanation.
Test the decision with a record that has English and German but no French. The API should make the absence observable. The frontend should respond according to the written policy, not to array order or assumptions about the languages collection. If the app displays a German title on a French page, inspect whether this is an intended fallback or a selection bug. A reader needs to know which language they are reading, especially when the page describes contracts, educational requirements or deadlines.
How to audit a translation after schema changes
Projects evolve. A content owner adds a registration_note field to the course collection and expects it to appear in all languages. If the field is put on the parent, it may render identically everywhere. If it should be localized, it belongs in the translation model and the editor needs a process to fill existing language rows. A new field can therefore expose a preexisting lack of clarity about shared and translated content. Document the decision before deploying it.
Test both new and old records. A newly created course may contain complete translations because the editor sees the field immediately, while older German records silently lack it. Review the field’s null behavior, required status, permissions and frontend fallback. If the field conveys a safety instruction, a missing translation may be a release blocker. If it is an optional decorative subtitle, the website may legitimately omit it. The severity follows the reader’s use of the information, not just whether a database cell is empty.
Audit language-display settings without changing content
Directus may display a preferred language based on interface settings and the project’s language collection order. The current documentation notes that a translation interface without an explicit default may show the first language in that collection. This is a user-interface default, not proof that the first language is the desired public fallback. A content editor’s personal interface language is another separate choice. Confusing those three settings creates reports such as “French always wins” when the source of the observation was a dashboard tab order.
Write down the editor’s selected display language, the translation field’s default behavior and the consumer’s requested language independently. Then inspect the actual API response. If a reviewer expects English to open first, change the suitable configuration only with administrator approval rather than rearranging stored translations as a workaround. The aim of QA is to establish what the product does and why, not to alter production data until the cause is clear.
Use a release checklist that reflects the relationship graph
For one sample parent item, verify: the primary record exists, its shared fields are correct, the languages collection contains the intended code, the translations junction contains one appropriate row per covered language, child rows point to the correct parent, localized fields contain reviewed text, field permissions match the reader role, the public API selects the intended language, fallback behavior is documented, and the visible page keeps related links and facts consistent. These checks can fit on a one-page release sheet.
Record failures as precise states: wrong parent key, unknown language code, duplicate child row, missing localized field, inaccessible relation, wrong query, stale cached response or language-quality issue. For each state, identify the responsible team. A translator should not be asked to repair a relation; a database administrator should not be asked to decide whether a deadline is faithful in another language. The checklist works because it respects different expertise while keeping one shared picture of the public result.
Scenario: a bilingual parent handbook in Directus
Imagine a handbook item with shared ID handbook-042, source language English and target language Malay. The parent stores publication year, school level and a canonical downloadable file reference. The translation rows store the handbook title, short introduction and instructions for navigating the material. QA begins by checking that both language rows reference the same handbook and use the project’s exact language codes. It then compares the headline and action description with the source facts.
The next step is a public consumer test. Does the Malay page retrieve the Malay title? Is the file it links to actually a Malay-language file, or merely the shared English original? If the file is English, the interface must not describe it as fully translated. This example reveals why a related download can require its own translation-status field or language-specific asset strategy. A polished content row does not automatically localize everything downstream of the link.
Scenario: two campuses with similarly named programmes
A tuition provider offers “Mathematics Foundations” at two campuses. One programme is for Primary pupils; the other is for Secondary pupils. A German translation is attached to the wrong parent because its title looks right in a CSV export. A reliable QA sample includes the campus and level as read-only context. It checks that the translation child belongs to the intended parent key, then verifies that the visible CTA selects the corresponding consultation or registration route.
The fix should not involve changing the German title to disguise the mismatch. The relationship must be corrected under an authorized data-maintenance procedure, with a backup or change log where appropriate. After the fix, retest both campuses because one mistaken move can leave the other programme with missing text. This is a powerful teaching example: language correctness and data identity are two independent axes, and success requires both.
Scenario: a reviewer sees a translation but readers cannot
A multilingual health and safety notice is visible to editors but absent on the public site. The child’s language row contains approved text, so the editorial team assumes publication is complete. Yet the public API role has no read permission for the translated field, or the parent item is filtered out under its status rule. The right test uses the same access level as a reader, rather than an administrator’s broad permissions. It should establish exactly which collection or field is inaccessible.
Permissions are a design boundary, not an obstacle to defeat by exposing everything. The administrator can evaluate a narrowly scoped policy that supplies only approved public data, or the frontend can fetch through an appropriate server-side integration. The content team can mark translation complete while deployment remains blocked. This distinction keeps an urgent notice from being mislabeled as linguistically unfinished and prevents insecure fixes made under pressure.
Scenario: a translated value is technically present but unusable
A French course title exists, yet it is sixty words long and overwhelms a card designed for short titles. The data model is healthy and the language code is correct; the issue lies in the interaction between message and display constraint. A reviewer should know the field’s real purpose and the visual space available. Do not arbitrarily shorten the translation if it changes the promise, level or eligibility. The editorial team may need a separate localized short_title field with its own approved meaning.
The strongest check uses real examples from the target language and the actual narrowest display, including mobile layouts. A long title may fit in a desktop detail page and fail in navigation. This is one reason that returning a valid JSON response is only a midpoint in localization QA. The final reader job—recognizing a programme and choosing the correct next action—must survive the layout as well as the database join.
Practical transfer: teach the invariant-versus-variable distinction
A student can learn from the Directus pattern without needing to administer a live CMS. Write a mock timetable with one stable programme ID and three translations of its description. Highlight which facts cannot change when the language changes: time, venue, price and student level. Then identify words that must adapt so each language communicates those facts clearly. This separates invariants from variables, a useful idea in Mathematics, computing, science and language learning.
For a tutor, the exercise also teaches evidence-based debugging. If a German description points to the wrong timetable, compare the key rather than debate the grammar. If the right timetable displays an English button, locate the field owner rather than rewriting the entire item. Students begin to understand systems as connected decisions. That perspective is more transferable than memorizing a particular software screen, and it prepares them to reason about databases, web services and translation with greater independence.
Summary: prove the relationship before praising the wording
Directus translation quality has a structural foundation. Shared facts belong to a correctly identified parent item; language-specific text belongs to associated records with reliable language keys; permissions and queries expose only what the intended reader should see; and the final interface selects the appropriate child without guesswork. A mistake at any one of these layers can make good translation appear broken or make an incorrect translation appear valid.
For fast, reliable QA, start with one controlled record, confirm the parent, language keys and child rows, then test the consumer route with the intended permissions. Only after those checks pass should a language reviewer concentrate on clarity, tone and factual faithfulness. This ordering saves time, reduces accidental data edits and gives everyone a common definition of what “translated” means in a relational CMS.
Frequently asked questions
Does changing my Directus Studio language translate the site content?
No. Studio interface translation and multilingual content rows are different features. Check the translations relationship on the specific content collection and the frontend’s language selection.
What does the Directus Generate Translations wizard do?
It can create a languages collection, a junction collection, needed relationships and a translations alias field for selected content fields. Teams still need to review schema choices and the actual rows.
Why is a translation missing even though its language tab exists?
The language can be configured without a child content row, or the row’s fields can be empty or hidden by permissions. Inspect the junction rather than assuming a tab proves the translation exists.
Should I store a price in every language record?
Only if the pricing model explicitly requires that structure. Language differences and market-specific commercial rules are not identical concepts. Preserve one trustworthy source for each shared fact.
Can a public API return all language rows?
It can be configured to return relational data according to the requested fields and permissions. The frontend should deliberately select the intended language, not blindly use the first result.
Are AI translations always safe to publish immediately?
No. Verify language keys, parent identity, structured facts, permissions and contextual meaning. Automated text can be a draft rather than a final approved public statement.
Suggested internal reading routes
For related narrow checks, see eduKateSG’s duplicate localization key QA, missing localization keys, and resource file paths. Those articles own key- and path-level integrity; this guide focuses on Directus’s relational content translations.
Official documentation and verification
- Directus: Content Translations
- Directus: Translation configuration
- Directus: Relationships
- Directus: Filter rules
- Directus: Directus SDK
Editorial verification date: 25 October 2026. Illustrative collection names, keys and school examples are fictional. Apply changes to live data only through an authorized, backed-up workflow.