How People Translate Quickly | DCAT 3 Multilingual Dataset Metadata QA: Translate Catalog Descriptions Without Changing Dataset Identity

To translate a DCAT 3 dataset catalog quickly, identify the dataset and distribution resources first, keep their identifiers and access links unchanged, then add reviewed language-tagged titles and descriptions. Run two checks before release: the RDF graph must still describe the same resources, and people searching in the target language must understand what the dataset actually contains. This separation between readable words and stable data relationships is the central rule of multilingual DCAT metadata quality assurance.

A search for DCAT 3 translation, multilingual dataset metadata, or language-tagged data catalog descriptions usually leads to the same practical problem. A catalog manager wants residents, students or researchers to discover a resource in another language without copying the resource into a second, confusing identity. The right solution is normally to retain one dataset IRI and add text literals with appropriate language tags, rather than translating identifiers, download paths, license references or controlled vocabulary concept URIs.

This guide uses the W3C DCAT version 3 Recommendation of 22 August 2024 and JSON-LD 1.1 to explain a reproducible translation workflow. It covers the difference between catalog, dataset and distribution, explicit examples, reviews of subject vocabulary and rights statements, damaged-record diagnosis, a changed-context transfer problem with an answer, and ten detailed questions. The examples are intentionally small educational fixtures: parsing their JSON does not establish full RDF vocabulary or national portal conformance.

Define the exact job before touching the catalog

Imagine a public-school research team publishing monthly counts of cycling journeys around its campus. The original English metadata tells readers the observation period, approximate coverage, collection method and downloadable format. A Mandarin version should let families find and interpret the same counts, not create a new monthly survey, a separate statistical claim or an unapproved translation of the underlying data. The work product is a set of additional human-readable metadata values attached to existing resources.

A translation request that simply says “translate the dataset” hides several possible jobs. One team might want the catalog listing translated; another wants column names in a CSV; a third wants a full explanatory research report translated. DCAT describes metadata and relationships, not necessarily the contents of a distribution. Put those deliverables in different rows of the task brief. Otherwise a translator may finish an excellent Chinese summary while the download remains incomprehensible, or may rename CSV fields that downstream applications expect to stay fixed.

Write an acceptance criterion that can be tested independently by a catalog maintainer. A suitable example is: the dataset page offers approved English and Chinese title and description values; all original resource IRIs and distribution links remain identical; the English listing still appears to English-language visitors; the Chinese listing correctly states collection dates, geographic scope, limitations and license. This is more useful than asking whether the translation sounds fluent, because it includes the evidence needed to demonstrate that nothing important changed.

Understand the three resources that users confuse

A dcat:Catalog organizes entries for discovery. A dcat:Dataset represents an identified collection of data. A dcat:Distribution describes a particular accessible representation of a dataset, such as a CSV download or an API endpoint. These are linked but not interchangeable resources. A bilingual label for the parent catalog cannot automatically substitute for a dataset title, and a distribution’s file-format statement is not a marketing sentence that the translator can freely rewrite.

Use this model to spot a common error before it spreads. If the English catalog is called “School Transport Data,” someone may translate every child dataset title as “School Transport Data” too. A search result then contains several indistinguishable records although one describes bicycle counts, another bus arrivals and another walking routes. A local reviewer needs to see the records in their hierarchy and restore the distinction. The goal is retrieval that remains accurate at every level, not apparent consistency through repetitive wording.

DCAT’s resources may participate in other systems. A data portal indexes them, a statistics report cites their persistent identifiers, and a school research project may store a dataset IRI alongside its results. Changing a URI because its English words appear awkward in the target language can silently disconnect those systems. A translator’s edit permissions should therefore be restricted to specifically approved literals; the data owner reviews any proposed change to identifiers, structural triples or distribution locations through a separate change-control process.

Distinguish literals from identifiers

An RDF literal can carry written text such as a title or description. In a multilingual record, language tags can distinguish English from Simplified Chinese, French or Tamil strings. The tag is part of the data representation: it tells software which natural language the literal belongs to. By contrast, an IRI names a resource or concept. Its spelling may look like English, but its function is identity, not a sentence for translation. Treat those two classes as different columns in the translation inventory.

Suppose a concept URI ends in /transport/bicycle. A translator might reasonably prefer a local term for bicycle in the user-facing interface. That does not make it reasonable to rewrite the IRI to /transport/translated-word. The original URI may be recognized across catalogs and analytical pipelines. Add a translated display label for that concept using the vocabulary’s proper mechanism, or arrange for a maintained local terminology record. Preserve the IRI in the exported graph so all software still refers to the same concept.

Likewise, the words “CSV download” in a portal button are potentially translatable interface text. The value of dcat:downloadURL is not. A user can receive a translated explanation of the file without the link becoming a different address. The MIME type, byte count, checksum, identifier, temporal boundaries and controlled vocabulary codes also need deliberate handling. Their role is to represent technical facts; changing them for linguistic appearance would be data alteration, not localization.

Build a safe bilingual JSON-LD fixture

The following miniature JSON-LD record demonstrates the difference between stable identity and language-specific descriptions. It declares a dataset and one distribution. The illustrative IRI, dates and example.org URLs are fictitious; they must not be copied into a live catalog. Notice that two dct:title values can refer to the same dataset while the @id and distribution relationship remain stable. JSON-LD permits expanded language-value objects like those shown here.

{
  "@context": {
    "dcat": "http://www.w3.org/ns/dcat#",
    "dct": "http://purl.org/dc/terms/"
  },
  "@id": "https://example.org/datasets/cycle-counts-2026",
  "@type": "dcat:Dataset",
  "dct:title": [
    {"@value": "Campus cycle counts, May 2026", "@language": "en"},
    {"@value": "2026年5月校园自行车计数", "@language": "zh-Hans"}
  ],
  "dct:description": [
    {"@value": "Observed cycle passages at two campus gates; not a census of riders.", "@language": "en"},
    {"@value": "在校园两个入口观察到的自行车通行次数；并非骑行人数普查。", "@language": "zh-Hans"}
  ],
  "dcat:distribution": {
    "@id": "https://example.org/distributions/cycle-counts-csv",
    "@type": "dcat:Distribution",
    "dcat:downloadURL": {"@id": "https://example.org/files/cycle-counts-2026-05.csv"}
  }
}

The quality test has more than one layer. A JSON parser can confirm commas, quotation marks and brackets. A JSON-LD processor can inspect the resulting RDF triples and language tags. A domain reviewer must still check that the Chinese phrase means recorded passages rather than distinct cyclists. The source explicitly says that one person could pass twice; losing that limitation would make the translation seem more informative while actually making it misleading. Machine syntax and scientific meaning are complementary, not substitutes for each other.

A useful baseline is to save a canonical list of resource identities and nonlanguage object values before editing. After adding translations, compare the lists and investigate every difference. Separately compare the set of language-tagged title and description values, since those are supposed to change. This dual comparison avoids the mistake of demanding that the whole JSON document remain byte-for-byte identical while also making it harder for an accidental identifier rewrite to hide among legitimate edits.

Apply language tags according to content, not audience assumptions

Use a language tag to describe the actual language of each literal. en may be suitable for English text; zh-Hans indicates Simplified Chinese script; a project requiring Singapore-specific wording may choose a more specific tag if its pipeline supports that distinction. Do not tag English text as Chinese simply because the record appears on the Chinese interface. A mislabeled value can defeat language negotiation, search filtering, accessibility behavior and import routines long after the catalog page looks acceptable.

A language tag is also not a replacement for writing a correct translation. Two strings can both carry zh-Hans while one is understandable and the other quietly reverses a statistical qualification. Build a review fixture that presents source and target text beside the original data dictionary, along with the selected tag. Ask a bilingual reviewer to describe the meaning without seeing the source, then reveal the source and compare. Differences involving dates, counts, units or study limitations should block approval.

Fallback deserves an explicit policy. A catalog may lack a Tamil translation for one field but have an English value. The display layer can choose to show English, mark that field as untranslated or omit it, depending on product requirements. The translation file should not invent a Tamil literal that merely repeats English without acknowledgment. That false sense of completeness can mislead users and prevent teams from noticing unfinished coverage. Define and test fallback behavior at the application layer rather than assuming DCAT itself decides the interface language.

Work from a field-level inventory

Prepare a spreadsheet or structured queue with the resource IRI, RDF property, source language, target language, exact source literal, proposed translation, reviewer, approval timestamp and evidence reference. Keep one row per translation unit. For a catalog containing fifty datasets and three target languages, this may sound bureaucratic, but it is much faster than searching through pages after a user finds one wrong number. It also allows parallel review without giving translators permission to modify identifiers or technical links.

Classify each field by risk before assigning work. A decorative catalog heading is relatively low risk. A description of a dataset’s sampling method, missing values, confidentiality threshold or license is higher risk because it influences how readers use data. A field explaining that small cells were suppressed should receive a subject-matter review, not merely a spelling check. The inventory can also mark values derived from controlled vocabularies, which may have approved multilingual labels already available from authoritative terminology services.

Record why a translation uses a particular term. In public health, “case” might mean a reported event rather than a legal matter; in education, “level” may mean year of schooling rather than difficulty. A terminology note should include the actual dataset definition and the reader’s expected context. If another department later adds an English variant, the translators can decide whether the prior target term still applies. This is a practical way to maintain meaning across catalog updates without rewriting old records blindly.

Preserve collection dates, measures and sampling claims

Metadata often contains facts that appear in prose rather than typed fields: “surveyed on weekday mornings,” “collected at two gates,” or “estimated from a sample.” These details govern interpretation. The first draft may read naturally but accidentally shift an observation period from May to the whole year. Build a source-fact ledger before translation, then check each fact against the target. A correct title should not imply that a monthly extract represents all of 2026 merely because the underlying filename contains that year.

Distinguish measurement units from the words that explain them. A dataset about air temperature in degrees Celsius should not suddenly become a Fahrenheit dataset because the target audience uses another convention. Converting units is possible, but that is data transformation with calculation and rounding implications. Keep the published distribution’s units consistent and translate the explanatory words. If a separate converted distribution is commissioned, give it a controlled release process, a clear relationship to the original and an independently checked numerical conversion.

Beware of qualifiers such as “approximately,” “at least,” “at most,” “provisional” and “excluding.” These words carry decision-making significance. A target title that states “All Schools” when the source means “Selected Schools” changes the apparent coverage of the dataset. An efficient reviewer can compare a short checklist of these qualifiers, but the checklist must refer to the real text, not just count matching keywords. The strongest review asks whether a reader using only the translated listing would reach the same cautious conclusion as a reader using English.

Keep dataset and distribution records distinct

A dataset may have several distributions: a machine-readable CSV, a spreadsheet, and an API service. Translating one shared summary does not ensure each distribution’s constraints are understandable. The downloadable file might contain anonymized rows while the API offers aggregated counts; the spreadsheet might carry an older update date. Check metadata at the distribution level and keep format labels, license statements and availability notes tied to the correct access method. Do not describe every link as “download data” if one requires registration or exposes a query service.

The distinction matters to people with limited connectivity or assistive technology. A user might want a small CSV instead of a large archive. If a localized button promises a direct CSV but opens an HTML API documentation page, the translation is functionally wrong even if every word is grammatical. Test each clickable link in the translated interface, inspect the content type where appropriate, and verify that the promised file is actually reachable. A broken distribution path is an operations defect, not something the translator should quietly repair by changing metadata pointers.

When formats differ, maintain corresponding technical records rather than forcing all labels to match. One distribution could be “machine-readable table” and another “human-readable methodology notes.” A catalog reader should know what is obtained before clicking. The phrase can be translated for clarity, but metadata about dcat:mediaType, licensing and access links must remain grounded in the actual artifact. A translation that hides a paywall, access restriction or unavailable historical version erodes trust even when the catalog remains structurally valid.

Treat controlled vocabulary concepts as shared references

Many catalogs organize datasets using themes, geographic places, publisher identities and standard classifications. These references often use controlled vocabularies, where a concept IRI has a stable identity and one or more labels. The correct pattern is to preserve the concept relationship and localize the label in the vocabulary or presentation layer. Creating an unregistered translated URI by changing its final word can fragment search facets, make datasets appear uncategorized and break cross-catalog aggregation.

Imagine three catalogs using the same theme identifier for public transport. The local English label is “Transport,” while another jurisdiction displays a different-language equivalent. If all three retain the identifier, a federated search can aggregate records under the same concept while giving readers familiar labels. If each catalog invents a new identifier based on translated text, the shared category disappears unless expensive reconciliation is performed. The invariant is the reference to the concept; the variable is the label shown to a person.

Do not assume a translated label exists simply because a controlled vocabulary is multilingual. Some concepts have uneven coverage, outdated terminology or regional variants. A reviewer should inspect the original concept, its definition and the authority maintaining it. Where an approved target label is missing, record a local display translation with provenance and an update plan rather than silently publishing it as an official authority label. This prevents a convenient workshop translation from acquiring false institutional status when copied into later research reports.

Make versioning intelligible without forging a new resource

DCAT 3 includes richer support for version relationships and dataset series. A catalog may represent successive releases of school enrolment statistics through distinct dataset resources linked by appropriate version properties. Translation is not a reason to change those version edges. If English calls a file “Preliminary 2025 release,” the target must retain that provisional status and year while keeping the version IRI intact. A translated title cannot turn a preliminary release into the definitive series endpoint.

Versioning errors are especially hard to notice because both labels might sound plausible. A translator may interpret “current” as “most recent school year,” while the record means “current version of this resource.” A reviewer should examine the actual graph relationship and update chronology. If a superseded dataset is still accessible for reproducibility, its translated description should clearly identify the historical release. Users conducting comparisons need stable references across time, not attractive headings that disguise which evidence they downloaded.

Change detection should operate at both the graph and language layers. When the publisher adds a new month of data, the English summary may change, and every target language version becomes a candidate for review. A translation memory match against last month’s sentence is not enough if the date or coverage changes. Associate approved target text with a fingerprint of its exact source and resource identity. A changed source should trigger a visible stale-translation state until a bilingual reviewer confirms the update.

Capture provenance, publisher and ownership accurately

Metadata may state who collected observations, who published the dataset and who is responsible for corrections. These roles are not interchangeable. A public agency publishing a dataset supplied by a school cannot automatically be described as the organization that performed the study. Translators should identify the semantics of each relationship before choosing words for “publisher,” “creator,” “contact point” or “rights holder.” Incorrect attribution can make a translated listing seem authoritative for claims its publisher did not originate.

Names are a separate decision from descriptions. Some institutions publish official names in several languages; others require their legal name to remain unchanged. A reviewer should follow the organization’s naming policy, not improvise a translation that could be confused with a different body. Keep stable organization references even when localized display names are provided. Where the official name is missing in the target language, an explanatory phrase can help readers, but it should not claim to be a registered legal translation.

Provenance also covers the translation itself. Store the translator’s source document revision, target language, review state and any external terminology decisions. This record may live outside the DCAT graph in editorial infrastructure. It enables a new maintainer to distinguish an approved label from a rough machine draft. Without provenance, an update team might trust an old string because it was visible in production, although it never passed domain review. Editorial history protects users, not just the organization.

Translate rights and access notes with special care

A dataset license may be represented by a resource IRI. That reference is an important machine-readable part of the record. A human-facing sentence describing reuse conditions can be translated, but the target text must not expand or restrict the actual permissions. For example, changing “attribution required” into “free for any use without conditions” is not merely loose wording: it could lead users to infringe the license. Retain the canonical license link, refer to official translations where available, and distinguish explanation from legal text.

Restrictions also have practical consequences. The source listing may say that an API requires an account or has usage limits. The translated description should not promise unrestricted download. Likewise, privacy warnings about suppressed records or aggregation thresholds must remain visible. A student using the data for a class project needs to know which inferences are safe. If the target audience cannot understand a material restriction, the localization has failed even when the data file opens successfully.

Technical links should remain readable without inventing equivalence. If the original license page is available only in English, the translated catalog can state that the authoritative terms are in English and offer a reviewed plain-language explanation. Do not point to an unrelated translated license document as though it governed the same dataset. A useful release test is to ask someone unfamiliar with the project what they are permitted to do, where the data came from and whom to contact about errors. Compare their answers across languages.

A catalog may store correct translations yet never display them where people need them. Search indexing could still use only English title fields, or the result page could show an untranslated excerpt despite a Chinese title. Test representative queries in each target language from the same public interface. Check not only whether the record appears but whether the snippet distinguishes it from neighboring datasets. Retrieval is part of translation quality because catalog metadata exists to help people find useful data.

Facets introduce another layer. A theme label, publisher filter or date range might be translated differently in search results and inside the dataset detail page. Users then appear to select one topic but reach another. Test a selected facet all the way through to the final record and inspect the underlying concept identifier. If the visible labels vary for legitimate grammatical reasons, verify the meaning rather than demanding identical strings. Consistency should preserve navigation, not force unnatural language.

Mobile and accessibility checks matter because long translations can break metadata cards. A description that was readable in an English desktop grid may be truncated before its crucial limitation in a narrower target-language layout. Open the result card, listen to its accessible name where possible, and check the full detail view. Do not solve overflow by removing warnings or qualifiers. Adjust the presentation or provide a properly authored short summary that remains faithful to the full description.

Diagnose an apparently complete but incorrect localization

Suppose a bilingual catalog passes a basic smoke test: both language buttons work and all pages load. A researcher then reports that the Chinese portal contains two “2026 school transport” entries with different totals. Start with the resource IRIs. If the entries share an IRI, inspect the chosen language literals and retrieval logic; if they have different IRIs, inspect whether one is a new version or a mistakenly duplicated resource. This first separation prevents a translation team from changing titles to conceal a catalog-identity problem.

Next inspect the distribution relationships, reporting periods and provenance. Two datasets could legitimately describe different months while their target titles omit the month. The repair is a precise title and summary, not merging their identities. Alternatively, a single dataset may list a CSV updated in June and an API refreshed daily; the target interface might be flattening both into one ambiguous “latest data” button. Record the exact property/value responsible and assign the fix to the correct owner. A language team should not silently alter publication architecture.

Finally test regression in both directions. When the Chinese title is corrected, search in Chinese and English, inspect the dataset detail page, follow every distribution and compare original identifiers. A fix that improves target-language clarity but causes the English page to select the wrong literal is not complete. Log the incident with the offending source, the misleading target, user impact and chosen repair. Such incident records make future translation reviews faster because they teach reviewers what a superficially good catalog can still get wrong.

A deliberate QA method for translators and data engineers

Begin with a frozen export of the source graph and a signed-off list of translatable properties. A data engineer can provide a report of resource IRIs and all predicates whose values are IRIs or typed literals. A language reviewer receives just the descriptions, titles, plain-language access notes and any approved vocabulary labels. This division is not meant to prevent collaboration; it makes each person’s responsibility visible. A defect can then be traced to language selection, data linkage or publisher policy without guesswork.

Run a syntax test followed by semantic invariants. Parse JSON-LD if the export uses that syntax, check that every target string has the intended language tag, and inspect the RDF graph with an RDF-aware tool. Compare resource identifiers, dataset–distribution links, license identifiers, versions and access URLs to the baseline. The string-level difference report should allow approved new language literals but flag unexpected deleted source values. A human reviewer then checks claims about scope, collection methods and limits against the source and data dictionary.

Test on real catalog surfaces rather than stopping at a passing script. The sample should include a dataset with one distribution, a dataset with multiple formats, a versioned record, an absent target translation and a controlled-vocabulary theme. For each case, check search results, detail pages, download links, language fallback, mobile truncation and accessibility. Store screenshots or structured test evidence without embedding personal data. A result like “five cases passed” is meaningful only when the conditions and expected results are documented.

A changed-context transfer exercise

A city library uses DCAT to publish an annual dataset of public-computer sessions. The English description states that a session is counted whenever a terminal login begins, so one patron may create several sessions. A new Tamil interface is requested. At the same time, the IT team adds a second distribution containing monthly aggregates rather than the original annual row-level extract. Your task is to identify exactly what should change in language metadata and what must be escalated as a data-model change.

The safest solution first preserves the original dataset IRI and every existing technical relation. Add a reviewed Tamil title and description for the existing dataset, including the fact that logins are sessions rather than unique people. The new monthly aggregate may deserve its own distribution resource and an accurately described format and frequency; the data publisher must decide the precise model and linkage. The translator must not replace the annual download URL with the monthly URL merely because it appears newer, nor imply that both files expose the same measurement granularity.

For the final test, ask two readers to answer whether the numbers represent unique patrons, whether the monthly aggregate can substitute for annual individual rows, and which link they would choose for a project. Both language versions should communicate the same uncertainty and access differences. If a Tamil reader claims the figures count unique people, repair the definition before release. This exercise transfers the core principle from transport counting to library use: fluent labels are useful only when identity, measurements and access remain truthful.

Practical review checklist and release decision

Before approving a multilingual DCAT record, verify that source and target entries point to one intended dataset identity; all original IRIs and technical object values are protected; distribution formats and URLs are correct; language tags reflect the literal’s language; title and description agree about dates, coverage, units and sampling limits; vocabulary concepts remain linked; source-version changes trigger review; and a real reader can find the record through target-language search. Record every check as evidence rather than a decorative tick.

Assign distinct review roles. The language specialist checks readability, terminology and register. The data steward checks what the dataset measures, what is missing and which release is current. A technical reviewer checks graph syntax, identifiers, distribution links and display fallback. A site editor verifies actual cards, headings, mobile layout and accessible descriptions. For small catalogs one person may fill several roles, but the checks themselves should remain explicit. This is a practical compromise between speed and assurance.

Release only after blocking defects are closed. Blocking defects include a wrong resource identity, invented access rights, changed measurement scope, unavailable file links presented as working and target-language claims that contradict the source. Minor stylistic preferences can be recorded for later improvement without delaying an otherwise accurate listing. Publish the translation with its source revision and reviewer record in the editorial system, monitor search and user feedback, and reopen QA when data or underlying terminology changes. The finish line is responsible discovery, not a word-count target.

Limits and final summary

DCAT is a vocabulary for exchanging data-catalog metadata, not a universal specification for how every website should select a language, design a card or rank multilingual results. Local portals, profiles and downstream catalogs can impose further requirements. JSON-LD syntax checks alone cannot prove that a national data portal will index the intended language. Nor does a language tag certify correct scientific interpretation. Be explicit about what the test suite proves and what depends on a particular implementation or a human reviewer.

A second limit is that not every translation request should be fulfilled by adding another title literal. A translated data dictionary, readme, dataset column or methodology report may be necessary for meaningful reuse. These are separate deliverables with their own version control and QA. Presenting a bilingual metadata card without telling users that the downloaded data remains in English can be useful, but it should not imply complete multilingual accessibility. Honest scope statements build confidence better than expansive promises.

The reusable lesson is simple: translate the explanation, preserve the evidence. In DCAT 3, that means language-tagged human-readable values accompanied by stable dataset, distribution, concept and licensing references. With a frozen baseline, targeted review and actual search-and-download tests, multilingual catalogs can become easier to use without fragmenting the resources they describe. The workflow scales because it makes the variable parts deliberately small and leaves machine identity under careful ownership.

Two final test cases that catch deceptively good translations

Consider a flood-risk dataset whose English summary says the model estimates exposure under one rainfall scenario, not observed flooded properties. A target-language review focused only on technical vocabulary might produce a fluent headline that describes actual homes damaged in a flood. The source, model and file links remain unchanged, yet the description becomes dangerously false. Ask the reviewer to classify every assertion as observation, estimate, projection or recommendation. Then compare the classification across languages and against the data publisher’s methodology. If the translated title must be shorter for a search card, retain an unmistakable indication that the figures are modeled rather than observed; do not make a false claim merely to save space.

Now consider a public budget dataset whose catalog includes a resource marked as a previous version. The localized portal searches both current and historical releases, but the results show the same translated title because the version suffix was dropped as ‘technical clutter.’ A citizen might compare a superseded table with this year’s press release and conclude that the figures conflict. The repair requires checking dataset IRIs, version relationships, reporting dates and visible labels together. Add a precise translated release indicator, test sorting and ensure the historical result remains discoverable for reproducibility without being mistaken for the latest evidence.

Neither case can be solved by relying on language-model fluency scores alone. A translation may be grammatical, accessible and well indexed while misclassifying the evidence. The final release review should therefore contain at least one question that forces the tester to interpret the data’s status and one question that forces the tester to choose the correct version or distribution. These are outcome tests: they show whether translated metadata helps a person make the same responsible decision as the source-language listing.

Frequently asked questions

1. Does a second language need a second dataset IRI?

Normally no. A dataset can have several language-tagged titles or descriptions while maintaining one identity. A separate IRI is appropriate when a genuinely different resource is created, not just because a description has been translated.

2. Can I translate the value of `dcat:downloadURL`?

No. It is a link to a resource, not a phrase. Keep the URL intact and translate the text of any user-facing button or explanatory note separately. If the link is broken, escalate an operational issue.

3. Are Chinese language tags interchangeable?

No. Language and script distinctions can matter for search, display and editorial review. Choose tags appropriate to the actual string and the portal’s policy, and make fallback rules explicit rather than guessing from a reader’s country.

4. Must every distribution be translated?

Every distribution should be accurately explained, but the content of each file may require its own translation project. A bilingual metadata page is not evidence that a CSV’s column names or an API’s payload are multilingual.

5. What if the English source description is wrong?

Escalate it to the data owner. Do not silently fix a scientific claim only in the target language. The record should be corrected through an authorized source process, then all language variants reviewed against the accepted meaning.

6. Should controlled-vocabulary URIs be replaced with translated slugs?

No. Stable concept references support grouping and interoperability. Prefer official multilingual labels for the same concept or clearly attributed local display labels if authoritative translations are unavailable.

7. What is the difference between parsing JSON and verifying DCAT?

Parsing confirms basic JSON syntax. RDF-aware validation checks how JSON-LD maps into resources and properties. Domain review checks whether titles and descriptions accurately describe the underlying data. All three have distinct purposes.

8. How do I handle missing Tamil metadata?

Mark the translation as incomplete and follow a documented display fallback. Showing an English value may be acceptable, but labeling an English string as Tamil creates misleading coverage and can interfere with language selection.

9. Does DCAT 3 require all portals to expose a language switcher?

No. DCAT standardizes vocabulary and relationships. Each portal must implement the display, search, fallback and accessibility behavior appropriate to its users, possibly under a local application profile.

10. What should trigger another language QA pass?

A changed source literal, dataset coverage, distribution link, license, version relationship, controlled vocabulary definition or display implementation can trigger review. Compare the change with stored editorial provenance rather than assuming a previous translation still applies.