eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How People Translate Quickly | CSVW Multilingual Metadata: Translate Column Titles Without Changing Dataset Meaning

—

by

eduKate Asia

A readable dataset can still be a broken dataset

How can people translate CSV column titles and descriptions quickly without breaking a dataset? Use W3C CSV on the Web (CSVW) metadata to attach language-aware titles and explanations to stable columns, rather than renaming technical headers or quietly recoding the observations. CSVW metadata localisation QA protects the separation between how people understand a dataset and how software finds, parses, validates and joins its rows. The immediate objective is a multilingual metadata file that readers can use while CSV-consuming programs still see the same column names, identifiers, datatypes and references.

Imagine a school publishing a CSV table of aggregate course enrolment. One column is called course_code, another student_count, and another reporting_period. For parents, these technical headers are not welcoming. A translator can supply meaningful Chinese or Malay column titles in metadata without changing the names expected by dashboards and quality checks. But if the translator replaces course_code with an attractive translated header in the actual CSV, a join to the course catalogue may fail. If they translate a date pattern without changing how dates are parsed, legitimate records may be rejected or interpreted as the wrong month.

The practical answer to searches such as ‘translate CSV metadata’, ‘CSVW multilingual titles’, ‘CSV on the Web language maps’ and ‘localise CSV column descriptions’ is to declare the intended language of prose, add approved language-tagged natural-language fields, and compare the machine-readable annotations before and after the edit. This article works through the W3C CSVW vocabulary, table schemas, column identities, datatype restrictions, language-bearing values, URI templates and publication checks. The goal is not to redesign the school dataset, translate every cell or build a different data warehouse; it is to make one dataset understandable across languages while preserving its original assertions.

What CSVW adds to an ordinary CSV file

A CSV file is a sequence of rows and cells. It usually carries little reliable information about the meaning of its headers, whether numbers are percentages, how dates are formatted, what constitutes a missing value, or which column is the primary key. Readers may infer such things from familiar conventions, but those guesses are fragile. CSVW adds machine-readable metadata, commonly a JSON document, that describes tables, columns, datatypes, dialects, keys and natural-language annotations. The W3C model allows consumers to interpret the same table more consistently and to connect it with other data.

A CSVW metadata description may contain a url for the CSV file and a tableSchema with columns. Each column can have a stable name and human-facing titles, among other properties. In the CSVW specification the name is a structural identifier used for matching and references; titles are natural-language labels. This distinction is exactly what localisation needs. Readers can encounter ‘Number of students’ or its approved target-language equivalent while validation tools continue to address the field named student_count.

The metadata format builds on a constrained JSON-LD dialect. Therefore not every JSON object in a metadata document is interchangeable with an ordinary translation dictionary. Some properties are natural-language values, some are URI templates, some control parsing, and others reference columns by name. A translator who understands this classification can edit the fields meant for people without touching the fields that give the data its structure. That boundary is more durable than guessing which strings ‘look translatable’ in an editor.

Decide whether the CSV is being translated or described

Start with the deliverable. If the task is multilingual documentation for an existing table, preserve the CSV bytes and publish additional language-tagged metadata. If the task is genuinely to publish a second CSV with values translated into another language, that is a new dataset transformation and needs its own rules, identifiers and versioning. The difference matters because code lists, names of organisations and narrative responses may be mixed in one column. Changing cell values can alter grouping, filtering and reproducibility even when the text sounds more accessible.

For example, a campus_id column might contain PG-01, which is an internal code and should remain exact. A campus_name column may contain the institution’s official name, which might have an established equivalent in another language. A comments column may contain free-form prose that needs translation in a separate analytical project. It would be misleading to treat all three as simple strings to replace. For a metadata-only job, explain what each field means and what the permitted values represent; do not change the values themselves unless a separately authorised transformation requires it.

Record the dataset URL, file checksum, header row, delimiter, encoding, known column names, datatypes, key constraints, source provenance and intended audience. If the dataset is updated daily, decide how metadata is versioned so readers do not apply descriptions from one schema to another. A snapshot and its metadata should be reproducible. A translation memory entry for ‘student count’ is not enough context if next month’s dataset introduces a new field with a similar label but a different denominator.

Distinguish a column’s identity from the title readers see

The name student_count may appear in a CSV header, in a CSVW schema, in a chart query and in a downstream API. Its spelling can be contractually significant. The title ‘Number of students’ is an explanatory label for humans. Translating only the title offers most of the communication benefit with far less risk to the data pipeline. If a team elects to change the underlying name, the resulting schema migration must update every consumer and related reference, which is beyond a metadata-localisation assignment.

The W3C metadata vocabulary allows a titles property for a column. Rather than replacing one source-language string, authors can express alternatives keyed by language. A map containing English and Chinese titles represents two descriptions of the same field, not two different fields. A processor may display an appropriate label for a reader while retaining the same structural column. However, CSVW does not require every viewer to render multilingual titles automatically. Check the particular publishing tool and, when necessary, build an accessible language selector around the metadata rather than assuming every generic CSV application understands it.

The preservation test is simple in principle but needs care in practice. Compare source and target metadata for the list of name values, their order, and all structural properties. Only approved language-bearing properties should differ. If a column named student_count becomes number_of_students_zh, something more than presentation has changed. A friendly target title can be added without such renaming. When there are multiple approved synonyms for a concept, the schema may contain multiple titles, but the editorial team should still designate a preferred label for consistent charts and supporting prose.

Use language maps for natural-language titles

CSVW’s titles property is a natural-language property. The W3C specification permits an object in which keys are BCP 47 language tags and values are strings or arrays of strings. This is a good fit for one column title presented in different languages. The object structure is not an instruction to translate the dataset’s observations. It is a way of saying that a label in one language and a label in another language refer to the same column description.

The language code itself matters. en, fr and zh refer to broad languages; more specific BCP 47 tags can distinguish relevant script or regional conventions where they are meaningful. Choose a tag that accurately describes the actual text, not the geographic location of the publisher. A university in Singapore could publish an English label, a simplified-Chinese label and a Malay label without declaring the entire table to have one spoken language. A wrong tag can make a correct string invisible to a viewer seeking a particular locale or cause a fallback to an unintended alternative.

Check the W3C vocabulary’s exact value shape instead of borrowing a JSON pattern from a different standard. In CSVW, a column’s language map for titles has the language code as a key. Other linked data vocabularies may represent a language literal as an object with @value and @language, or use a different context. A developer copying formats between standards can accidentally produce a JSON object that parses but is not interpreted as the intended column title. Specification-aware review looks at both valid syntax and the semantics assigned to each metadata property.

Declare the default language and preserve meaningful fallbacks

A CSVW metadata document can specify a default language through its @context, for instance using the CSVW context together with an object containing @language. This affects natural-language properties that are written as untagged strings. If a metadata file is mostly English, declaring English can reduce ambiguity about ordinary titles and descriptions. If the file contains multiple languages, explicit language maps may be easier to audit for fields that need full multilingual coverage. Do not insert a context value mechanically without checking the language actually used in the metadata.

A missing translation needs a defined fallback strategy. A viewer could show an English title when a Malay title is not available, but that should be a deliberate editorial choice. Otherwise readers may see mixed-language headers that imply a complete locale edition where none exists. A QA report can classify each title as approved, awaiting review, intentionally retained as a proper name, or missing. This transparency is especially important for datasets meant for families, community groups and nontechnical readers who may assume a displayed title was vetted for their language.

Keep und, meaning an undetermined language, in mind when reviewing source data without explicit language metadata. It does not mean ‘English’. Treating all untagged strings as English can hide an initial data-quality problem. Before adding translations, inventory the actual source language of each prose field. If two source titles are already in different languages, do not normalise them by deleting one as ‘duplicate’. The audience may rely on both, and the metadata specification has a place to express their relationship without erasing provenance.

A compact, valid example to compare

The following example is a small CSVW-style metadata description of a course-enrolment table. It uses a stable header name for every column and supplies two human-facing titles. The datatype values and primary key are illustrative, not a full operational governance policy. Before publishing a real dataset, run a CSVW-aware validator against the actual CSV, because syntax validation of JSON alone cannot verify header matching, primary-key uniqueness or date parsing.

{
  "@context": ["http://www.w3.org/ns/csvw", {"@language": "en"}],
  "url": "enrolment.csv",
  "tableSchema": {
    "columns": [
      {
        "name": "course_code",
        "titles": {"en": "Course code", "zh": "课程代码"},
        "datatype": "string",
        "required": true
      },
      {
        "name": "student_count",
        "titles": {"en": "Number of students", "zh": "学生人数"},
        "datatype": "integer"
      }
    ],
    "primaryKey": "course_code"
  }
}

The translation work changes the labels while preserving course_code, student_count and the key reference. The count remains an integer; translating a title does not transform 40 into a string containing a written-out number. The schema describes an exact table URL, so moving the CSV elsewhere without updating the metadata may break a client even if the labels are excellent. Similarly, if the CSV actually contains a different header, the metadata may be semantically clear but structurally invalid. This is why the change must be validated against the resource rather than examined as a standalone translation document.

A useful demonstration for students is to imagine replacing the student_count title with a target phrase that means ‘number of classes’. The JSON remains valid, the CSV headers still match, and a data validator might report no technical errors. Yet the metadata would be false because a count of students and a count of classes have different units and denominators. A bilingual domain reviewer must therefore check every translated quantity, not simply approve strings because the file parses. The structural and semantic gates are complementary.

Preserve datatypes, units and missing-value conventions

CSVW supports datatypes and dialect properties that affect how values become meaningful data. A column containing a percentage, an ISO-style date, a local formatted date or an integer may need precise parsing rules. Those rules are not prose decorations. A translator should not edit datatype, numeric format patterns or null conventions merely to match a country’s visual preferences. Changing how a file is parsed can alter numerical values or turn missing observations into apparently valid zeros.

Suppose the source table stores 0.25 as a ratio, meaning one quarter. A target-language description might say ‘share of respondents’ or an approved translation of that concept. It must not say ’25 percent’ as the general column unit if the source values remain stored as decimal ratios and consumers expect fractions, unless the distinction is clearly explained. Similarly, a field named reporting_year should not be described as a school academic year if its values are calendar years. The right translation communicates the existing unit, range and denominator; it does not change the data to make the phrase convenient.

Nulls need explicit explanation. Blank cells may mean not reported, not applicable, unknown or suppressed for privacy. These meanings are not interchangeable. A dataset that encodes suppression with a special marker should have an approved explanation for users without replacing that marker or disclosing information it protects. The metadata may document the coding convention, but it should not claim that absence means zero. A fluent but wrong label can lead to false conclusions in charts and comparisons, even if the raw numbers are untouched.

Keep primary keys, foreign keys and join fields stable

A primary key identifies records under the declared schema; a foreign key connects records across a table relationship. Both can reference column name values. A translator who renames a schema column to match a human-facing label can make those references unresolved. The problem is easy to miss when a simple CSV viewer still displays rows correctly. The join fails later, perhaps in a dashboard that combines course codes with subject names or locations. Structural preservation should therefore include relationships as well as the visible set of columns.

Translate explanations of relationships, not their identifiers. A field school_code might reference a separate lookup table containing official school identifiers. Tell readers that it represents a code from the maintained school directory; do not rewrite its values into local-language school names in the primary CSV. Names can change, have several official forms or be non-unique. Stable identifiers permit data from different languages to join on the same entity. A translation can make that design understandable while retaining the reason the identifier exists.

When a key itself is wrong or a record violates uniqueness, document the data-quality defect separately. Changing an ID to make it look more natural to readers is not a repair. If the school publishes a revised catalogue with new identifiers, that is a data governance and migration decision requiring cross-table checks. Language QA should flag the dependency and keep its work limited to descriptions, titles and other explicitly approved prose. This boundary makes multilingual presentation safer and protects traceable historical records.

Treat language-bearing values as a different project

A data column may actually contain names or free-form text in several languages. CSVW provides properties such as lang on column descriptions to indicate language of text values, and direction-related metadata when needed. These properties help a processor interpret or present the existing values. They do not automatically translate each value into another language. If a column of course descriptions is in English, tagging its language can be useful while a separate translated column or dataset may be necessary to serve a second audience.

Be especially careful with apparent vocabulary values such as ‘complete’, ‘pending’, ‘withdrawn’, ‘special needs’, ‘admitted’ and ‘not eligible’. A code list may use English-like values as enumerated machine statuses. Translating these within the same file changes the permitted values and may invalidate analytic rules. Prefer an explicit lookup table that maps stable codes to human labels for each supported language if the publishing architecture permits it. Then one status can be shown differently to different readers without losing the ability to compare records from different years.

Directionality matters for datasets that contain Arabic or other right-to-left scripts alongside numeric codes. A display application may need textDirection for a column or a table-level choice, while codes and measurements must remain readable in their intended order. Do not reverse strings in the CSV to compensate for a weak viewer; that corrupts the stored values. Test with a proper bidirectional-text display and consider punctuation, parentheses, mixed digits and copy-paste behaviour. The translation is successful only if readers can interpret and reuse the data, not merely if a screenshot appears attractive.

URI templates are not prose to translate

CSVW can use URI templates, including aboutUrl, propertyUrl and valueUrl, to associate table contents with web identifiers. These may contain variable names derived from columns and produce addresses that other systems dereference. Because the URI contains words, a translator may be tempted to rewrite its path or template variable. That would be a change in linked-data identity, not a linguistic improvement. Translate the accompanying explanation, but preserve the actual URI template unless a carefully designed identifier migration has been approved.

Consider a column named campus_code that supplies the variable in a URL for campus entities. If the template refers to that name, replacing the variable with its target-language title can break expansion. If the target title contains spaces, an unreviewed URL construction might produce a malformed address or a different resource. The metadata can display ‘Campus identifier’ in several languages while the template still uses campus_code. This is a useful general distinction for students: a label tells a person what something is, while an identifier tells a system which exact thing it is.

Even a harmless-looking suffix may carry meaning. A URI ending in a persistent code should not be changed because the code resembles an English word. The upstream authority may guarantee stability only for that original identifier. A sound QA diff compares the entire set of templates, prefixes and base URLs before and after localisation. If all such identifiers remain the same and only natural-language annotations change, the risk of disrupting linked-data consumers is substantially lower. Still validate template expansion on representative rows because a pre-existing mismatch between metadata and CSV headers can be discovered during translation.

Publication in two languages without cloning the data

A school or research group does not necessarily need two copies of its CSV to support two audiences. A single authoritative table plus multilingual metadata can reduce divergence when the underlying numbers are corrected. Both English and Chinese readers may consult the same student_count values while seeing different explanatory titles and notes. This architecture is especially helpful when the data is regularly refreshed. It prevents accidental inconsistencies caused by a translator editing a second copy a few weeks after the original file was revised.

There are limits. An ordinary browser’s CSV download view may show only the original machine headers, not the language-aware metadata. Some spreadsheet applications ignore CSVW completely. A publishing portal may need a separate HTML presentation layer that reads the metadata and chooses approved labels for the user. Do not promise that adding titles magically localises every software product that opens the CSV. The release plan should identify supported consumers: the data portal, an API client, the downloadable CSV, a screen-reader view and any analytics notebooks used by stakeholders.

When such a presentation layer is added, choose the fallback behavior carefully. A visitor who selects Malay should see available Malay labels, but the portal should make missing translations clear instead of silently inventing them. A user exporting data may want original technical headers for reproducible analysis, while a classroom handout may prefer translated titles. Both outputs can be useful when their purposes are labelled. The critical rule is to avoid presenting a translated display copy as if it were the canonical dataset with the same stable schema unless that relationship is actually maintained.

Worked example: data users mistake enrolment for attendance

Suppose a dataset reports the number of students registered for each course as of a stated date. A hurried translation changes the column label ‘Enrolment’ to a term meaning ‘Attendance’. The source numbers remain correct enrolment totals, yet charts now appear to report how many students came to class. A teacher might conclude that a course had an unexpectedly high attendance rate, while a parent might use the same chart to choose among programmes. The problem is not syntax or inaccurate arithmetic; it is a false concept assigned to a valid number.

The repair begins with the source data definition. Find the reporting period, the point at which a person counts as enrolled, and whether withdrawn students are included. Ask the original data owner what population and event the metric measures. Then use a target-language term that denotes registration status, not physical participation. If the target audience has no short everyday word matching the definition, provide a concise approved description. A title can remain compact while a dc:description or portal note explains the precise measure and how it differs from attendance.

Check the chart that consumes the metadata. If it previously showed ‘Enrolled students by course’, it should not suddenly show ‘Students attending today’. Compare labels to underlying query logic and sample source records. This test guards against a frequent failure in data translation: the dataset is structurally unchanged and technically valid, but the target audience draws a different conclusion because the explanatory language has drifted. In multilingual data work, a correct word is one that keeps the measurement’s meaning stable across readers.

A second failure: language tags hide an approved translation

A translator provides an excellent simplified-Chinese title but assigns an inappropriate language tag. The portal’s selector requests another tag and falls back to English. Users complain that translation was not delivered, even though the file visibly contains Chinese characters. The root cause is not the quality of the phrase; it is a mismatch between language metadata and the consumer’s fallback logic. The repair is to define target locales with the publisher, use valid appropriate BCP 47 tags and test real locale negotiation in the supported interface.

Regional and script distinctions should be guided by audience needs, not an assumption that every country must have a distinct vocabulary. A general zh tag may be adequate in one project, while another must distinguish written script conventions and terminology. Similarly, country names, grade labels and curriculum references may require local context rather than mechanical language-code substitution. Choose the smallest language specificity that truthfully describes the text and serves the product’s fallback design. Document it so subsequent translators do not vary tags inconsistently between tables.

Run a simple selection matrix. Request each supported locale, one close but not exact locale, and one unsupported locale. Record which title appears in each case. Check that the same structural field is used underneath, not a separate column that happens to have a related heading. A successful test shows that the intended translated title is available, missing translations are handled predictably, and no content changes when a reader switches the display language. This is the practical evidence behind a claim that metadata localisation works.

A third failure: formatting changes the observed values

A CSV column contains dates such as 10/11/2026, and its metadata declares how that pattern should be parsed. A translator rewrites the description for a different audience and assumes the slash-delimited dates now mean day/month rather than month/day. If the parsing pattern is unchanged, the translated note contradicts the actual machine interpretation. If the translator edits the pattern without transforming the data values, dates may move to different months or become invalid. Neither action is a legitimate part of translating a column title alone.

The repair has two paths. For a metadata-only localisation, preserve the original parsing rule and explain the actual stored pattern accurately in the target language. For a genuine data publication redesign, transform the date representation with a validated conversion process, adjust the metadata, and publish a new identified dataset or version. These paths should not be combined casually. Boundary dates such as the eleventh day of the tenth month are especially useful tests because they expose reversal errors; dates where both numbers are below twelve can conceal such mistakes.

Apply the same reasoning to decimal separators, percentages and geographic coordinates. An apparently friendly comma can be either a decimal mark or a field delimiter, depending on the file’s dialect. A translated description cannot override those technical conventions by implication. Check the actual field parser and display format separately. A user downloading the table should be able to reproduce the same observation regardless of which metadata language they read. Where conversion is required, that transformation needs a traceable specification and its own tests.

Make metadata useful for vocabulary and data literacy

CSVW provides a good way to teach the difference between data, labels and definitions. A Primary or Secondary student might see mean_score as a column name and ‘Average score’ as a title. The description can explain which scores are included, how missing values are treated and whether the average is rounded. In another language, those explanatory ideas must remain the same even if word order and phrasing change. This is vocabulary as a technology for interpreting quantities: precise words govern which comparisons a reader is entitled to make.

A practical classroom exercise can give students three proposed titles for the same field: ‘Number enrolled’, ‘Number attending’ and ‘Number passing’. Have them inspect the source definition and defend the correct choice. The exercise makes clear why translation cannot be evaluated solely by whether a phrase sounds natural. Students learn that data fields are claims with conditions. Preserving a field’s meaning across language makes evidence portable, while confusing nearby vocabulary can generate conclusions that the data does not support.

This approach is valuable for public-facing datasets as well. Residents comparing transport, education or local service figures need readable labels, but they also need consistent units, periods and denominators. A translation that simplifies terminology while retaining these distinctions can increase useful access to information. A translation that silently changes ‘requests received’ into ‘requests solved’ can mislead even when it was meant to make information friendlier. Good technical communication makes complex data more understandable without making its claims stronger or broader than they are.

A changed-context transfer exercise: neighbourhood transport data

A community website publishes a table with stop_id, service_date, scheduled_trips and completed_trips. It wants English, Chinese and Malay metadata without producing three independent copies of the table. One translator proposes renaming the CSV headers to match each language. Another leaves headers stable but accidentally describes scheduled trips as completed trips. A third modifies service_date parsing to match the target locale’s common display convention. Which changes are safe, and what evidence would show the multilingual edition preserves the data?

The safe solution keeps the original field names, schema references and stored values. Add language-tagged titles and approved explanations under each field, choosing distinct words for planned versus actually completed journeys. Preserve the date parsing rule and explain the meaning of the source date in each language. If the public interface wants to display dates in local convention, perform that formatting at the presentation layer without changing the underlying value or metadata semantics. The stop_id remains an identifier even when a separate lookup shows a translated stop name.

Validation should inspect row identity, data types, any primary or foreign keys, and summaries made from the two trip columns. Ask three reviewers what a row reports. Their answers should converge on the same distinction: trips planned for the service date versus trips recorded as completed. Run locale selection tests to ensure each language sees the intended labels. Finally, confirm that exporting and joining the data still works with the original keys. The transfer lesson is that multilingual access and structural stability reinforce each other when the design separates labels from observations.

Before release, inspect both the metadata and the consumer

First parse the JSON and validate the CSVW model with tooling that supports the relevant W3C vocabulary. Then check that the description actually matches the CSV file’s columns, headers, rows, keys and types. Verify that the same source files and links are referenced in the target edition. A valid JSON document can still refer to the wrong CSV URL or a column name that does not exist. The test must therefore cover the relationship between resource and metadata, not merely syntax inside the JSON container.

Next inspect the edited properties. Natural-language titles and explanatory fields may vary by locale; structural column names, datatype constraints, foreign keys, URI templates and dialect controls should remain identical unless explicitly scoped for a separately reviewed data change. If a diff shows many machine-facing edits, stop and explain why each is necessary. Prefer a small, readable diff where reviewers can concentrate on the translated concepts. Use a terminology ledger for ambiguous measures, status labels, time periods and personal-data categories so future editions stay consistent.

Finally examine the user experience in the supported portal or data tool. Check whether a target-language title appears, whether descriptions are accessible to keyboard and screen-reader users, whether mixed-direction text is legible, and whether data export preserves the canonical schema. Compare at least one chart’s axis labels with its underlying aggregation. Keep screenshots and a metadata validation report. These steps catch the important class of defect where a dataset still validates but a reader sees the wrong claim or cannot practically use the supplied multilingual description.

Boundaries and limitations

CSVW metadata cannot correct a misleading source statistic. If the source table fails to define its denominator or contains inconsistent dates, translators should flag the issue rather than invent a plausible meaning. Nor does CSVW guarantee a particular browser, spreadsheet application or API client will use language maps or default-language information. Consumer behaviour must be checked. Translation of data values, redesign of schemas, privacy review and data collection methodology are distinct tasks whose risk and approval requirements should not be hidden inside a request to translate labels.

Multilingual titles can also require continuing editorial care. Language changes, curricula evolve, dataset fields are renamed and new categories appear. A one-time translation can become stale while the English metadata is updated. Give each locale edition a reviewer and change history. Maintain a test that spots new or changed columns without approved target titles. That upkeep is usually less expensive than maintaining multiple independently edited data files because one source of numerical truth is preserved, but the benefit depends on real governance rather than the metadata format alone.

Summary: make meaning multilingual, not the keys unstable

A trustworthy CSVW translation changes how readers understand a column while preserving what that column actually measures and how software addresses it. Use language-aware titles and descriptions for prose, appropriate language tags for value interpretation, and validated fallbacks for unsupported locales. Keep name, parsing rules, key relationships, URI templates and data values intact during a metadata-only job. The fastest reliable result is a small, reviewed language diff plus evidence that the original dataset still validates and the target audience understands the same measurement.

Frequently asked questions

Should I translate the CSV header row itself?

Not for a metadata-only localisation unless a separately managed schema migration is approved. Use CSVW titles for reader-facing labels and keep machine-facing name values stable.

Does adding CSVW metadata translate the values in cells?

No. Metadata describes the table and may indicate a column’s language; it does not automatically translate its observations.

Can one column have titles in several languages?

Yes. The CSVW vocabulary supports a language map for the natural-language titles property.

Is @language required in every file?

No. It is useful for defining a default language of untagged natural-language values, but the correct approach depends on the metadata and supported consumers.

Can a translated column title change a field’s datatype?

It must not. The title expresses the same field meaning; datatype changes are schema changes requiring separate review.

Why did my CSVW document parse but still fail validation?

JSON syntax alone does not prove the schema matches the CSV headers, datatypes, keys or declared parsing dialect.

Will Excel or every web browser show CSVW multilingual titles?

No universal behaviour is guaranteed. Verify the specific consumer or provide a presentation layer that supports the metadata.

How should I handle missing locale text?

Use a documented fallback with a visible completion status rather than silently claiming the entire dataset is translated.

Can I translate technical status codes?

Normally preserve codes and provide a separate mapping to approved display labels. Replacing codes in the dataset changes its contract.

What is the most important domain review question?

Ask whether a target-language reader would infer the same unit, population, timeframe and event from each field as a source-language reader.

Authoritative technical sources