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 | RO-Crate 1.3 Translation QA: Make Research Packages Multilingual Without Splitting Their Evidence

—

by

eduKate Asia

How People Translate Quickly | RO-Crate 1.3 Translation QA: Make Research Packages Multilingual Without Splitting Their Evidence

To translate an RO-Crate research package quickly, first locate the human-readable descriptions in its ro-crate-metadata.json graph, then separate those descriptions from the identifiers, file paths, relationships, licenses and provenance that make the package reproducible. Localize a reviewed presentation of the dataset’s name and description, attach clear language information where the chosen metadata profile supports it, and verify that the translated description points to exactly the same research assets. A new language is another way to understand the crate, not a new experiment, dataset, licence or scientific result.

This guide explains a practical RO-Crate 1.3 multilingual metadata workflow for researchers, librarians, teachers and data stewards. It addresses the question that often causes trouble: which strings are safe to translate, and which strings operate as machine contracts? The answer depends on the property and the profile. A descriptive sentence may have a natural Chinese or Malay rendering, whereas @id, @type, dataset file names, checksums and citation references need deliberate preservation. The job is to make a research collection findable to more readers without compromising its evidence trail.

The RO-Crate 1.3 specification was published on 22 June 2026 by the RO-Crate community. It uses JSON-LD metadata, commonly combining schema.org vocabulary with a crate profile. A crate can describe datasets, files, people, software, instruments, licences and related research objects. The standard is not a universal localization service: language-tag representation and multilingual display rules should be tested against the actual JSON-LD context, profile, consuming repository and validation tool. Treat the examples below as illustrative fixtures, not certified research deposits.

The reader’s job: explain one package in several languages

Imagine a Singapore student group sharing a rainfall experiment. It includes a table of observations, a method note, a photograph of the instrument and a short README. The team wants researchers overseas to discover the package without asking a student to translate every explanation personally. The tempting shortcut is to duplicate the entire ZIP package for each language, then translate anything that looks like text. That creates multiple identities, inconsistent revision histories and uncertainty about which dataset is the original.

A safer reader job has two parts. First, a user in each language must understand what the dataset measures, when the measurements were taken and what limitations affect their interpretation. Second, every reader must land on the same underlying files, authorship record and permitted reuse conditions. Success is not simply matching translated sentences across pages. Success means a search result, landing page and downloadable package agree about the research object and do not create accidental rival versions.

Begin with an editorial acceptance statement that can be checked. For example: a Mandarin reader should understand that the measurements were taken during one school project, that the device was not calibrated to a professional standard, and that missing observations remain missing. The Mandarin description must not imply official weather-station certification. The English and Mandarin views should name the same file inventory and cite the same research object. This statement guides translation, technical validation and scientific review together.

Understand the graph before editing any text

The metadata document is a JSON-LD graph, not a collection of independent paragraphs. The root data entity is commonly represented by @id equal to ./, while a metadata file descriptor commonly uses @id equal to ro-crate-metadata.json. Other entities describe files, authors and contextual resources. A string’s meaning comes partly from the property that contains it and partly from the entity it describes. Translating the wrong field can alter the graph itself even when the JSON still parses.

Make a property inventory before extracting content. A dataset description is usually human-readable narrative; a name can be a display label, but it might also be the exact title used in a citation. A license commonly identifies an external licence resource rather than carrying a paragraph of prose. An author relationship identifies a person or organization, not a free-text signature. A hasPart relation links files. The translator needs role labels in a worksheet so that each type of string receives the correct treatment.

View the graph as a set of edges that must survive translation. If the root dataset points to a CSV and a method file, preserve those edges. If the metadata descriptor points to the root using about, preserve that relation too. Translate a display sentence through a controlled multilingual metadata convention or publication layer, not by creating new @id values for each locale. A graph that parses but silently loses one edge is a damaged crate, not a harmless text change.

A minimal illustrative metadata specimen

The following JSON shows a small invented crate with an English title, an explanatory description, and one data file. It is deliberately modest so that each relationship can be inspected. The fixture demonstrates the stable parts of the metadata; the precise requirements for a deployable crate, language variants and profiles must still be checked against the official 1.3 specification and chosen implementation.

{
  "@context": "https://w3id.org/ro/crate/1.3/context",
  "@graph": [
    {"@id": "ro-crate-metadata.json", "@type": "CreativeWork", "about": {"@id": "./"}, "conformsTo": {"@id": "https://w3id.org/ro/crate/1.3"}},
    {"@id": "./", "@type": "Dataset", "name": "School rainfall observations", "description": "Uncalibrated school measurements with two missing dates.", "hasPart": [{"@id": "data/rainfall.csv"}]},
    {"@id": "data/rainfall.csv", "@type": "File", "name": "Daily rainfall readings", "encodingFormat": "text/csv"}
  ]
}

In a real workflow, the bilingual descriptions might be stored in a separate approved localization catalogue keyed by the dataset’s stable @id, or in a tested metadata language representation that the repository and profile understand. Do not assume that placing an arbitrary JSON object with language keys in a property will automatically have the intended JSON-LD meaning. JSON-LD interprets strings according to its context and property definitions. A rendering application may support language maps that a generic crate importer does not.

Validate the source JSON for syntax, then inspect its JSON-LD interpretation with a compliant processor if the metadata structure has been modified. Verify that ./ still refers to the crate root and that the file path resolves in the unpacked folder. A syntactically valid JSON file can still be semantically wrong or contain broken file links. Keep a copy of the original graph so that comparisons can reveal any unauthorized change in identifiers, types or relationships.

Decide where translated strings will live

There are several legitimate publishing models, but none should be chosen by reflex. A repository may keep one canonical crate metadata file and supply multilingual descriptions on its landing page. Another may support language-tagged literals through a documented profile. A third may distribute translated README files alongside an unchanged metadata graph. Each can serve readers, but they differ in interoperability and in what downstream software will extract automatically.

A translation stored only in a web interface may disappear when someone downloads the crate. Conversely, embedding an unsupported language-map shape in JSON-LD may make the crate awkward for other systems even though a custom website displays it beautifully. Choose the storage model by naming actual consumers: the institutional repository, a local file browser, a research portal, a DOI landing page and a teaching site. Test each consumer on a representative multilingual sample before standardizing the convention.

Record the decisions in a language plan. Identify the authoritative source language, target languages, editorial owner, version of the crate profile, approved language syntax, location of translated strings and fallback policy. State whether translated text is inside the crate, published beside it or generated at runtime. That plan prevents later editors from appending ad hoc properties or replacing original descriptions because they cannot find the established pathway.

Protect @id as an identity, not a phrase

The JSON-LD @id value identifies an entity in the graph. It may be a relative path, fragment identifier or external URI. Its role is different from a natural-language title. A translator who changes data/rainfall.csv into a Chinese file name inside only the metadata graph may break the link to the physical asset. Someone who rewrites an external research identifier to make it readable may disconnect the package from its citation record.

Suppose a school folder contains methods/calibration-note.pdf. The target-language interface can call the file “calibration note” in a local language, but the @id path must still resolve to the actual file. Renaming a file is a repository maintenance operation that requires a synchronized change to the package, backlinks and checksums; it is not simply translation. Keep the display label and the resolved target separate. This also applies to nested crates and external dataset references.

Make a deterministic comparison of source and target graphs. Extract all entity identifiers and relationship targets, sort them and compare the sets. Any new or missing identifier deserves explanation. A team may intentionally add a localized document as a new file, but that change should appear in a controlled release record with a real file and metadata entry. Merely changing the text shown to a reader should not create unexplained graph nodes.

Preserve types, vocabulary names and schema meaning

@type defines the conceptual type of an entity, such as Dataset, File, Person or CreativeWork in a compatible context. These terms have technical meaning and should not be translated as if they were labels in a brochure. The same is true of property names such as hasPart, author, license and encodingFormat. They are part of the graph’s vocabulary, even when their English words seem invitingly familiar.

An instructive failure occurs when a translator changes File to the local-language word for file and the receiving software no longer recognizes the type. The JSON parser reports no syntax error: it accepts the new string. The actual fault appears when an RO-Crate tool cannot identify the file entity or when an RDF consumer resolves the wrong term. This difference between syntax validation and semantic validation is one of the main reasons for an allowlist of translatable fields.

Provide translators with a prepared extraction containing only fields that have been approved as textual descriptions. Protect keys, types, linked identifiers, media types, dates and controlled codes. A preview should label these hidden contracts rather than omit them entirely; reviewers need enough context to know whether a description belongs to the dataset, a file, a person or a software tool. When a new property appears, stop and classify it instead of guessing from its spelling.

Translate the research claim, not just the vocabulary

A description often compresses the research method, sample, scope and limitation into a sentence. Literal translation can lose distinctions that matter to future reuse. “A school survey of rainfall” does not automatically mean a government-calibrated climatological series; “daily observations” does not mean complete coverage on every day. The translator must preserve these qualifications even if the target language needs more space or a different sentence order.

Use a four-part claim inventory: what was measured, how it was measured, where and when it was collected, and what is uncertain. For the rainfall example, the source description reports simple school measurements and two missing dates. The translation must not convert missing dates into zero rainfall, or a basic container into a calibrated instrument. Reviewers should read the translated claim independently, then compare it with the data dictionary and method note. A fluent but scientifically inflated sentence is a failed translation.

Where the metadata is concise, allow an optional localized explanatory note without changing the canonical description into an essay. The note can explain terminology to teachers or students while clearly marking interpretation and limitations. This separation helps the academic publisher preserve a precise core claim while offering richer accessibility for different audiences. Do not silently add analysis, conclusions or policy recommendations to a metadata field that readers will treat as the researcher’s own statement.

Keep dates, sizes, types and checksums outside translation

Machine-readable properties such as creation dates, file sizes, media types and checksums are evidence about assets. They should not be converted into localized prose inside the metadata. A date may be displayed to readers in local order, but its stored representation has to remain parseable according to the relevant property’s expected format. The same principle applies to a content type such as text/csv, which is not a phrase requiring translation.

A checksum creates a stronger integrity test because its value depends on the exact file bytes. If a translated README is added to a package, that is a genuine file change and may require updated manifests, checksums and release identifiers. By contrast, translating a landing-page description should not change the archived CSV. Treat each change according to its actual effect on the repository rather than assuming all translation changes are invisible to provenance systems.

A useful release report lists which descriptive properties changed and confirms which technical properties remained stable. It can include the count and hashes of unchanged data files, normalized graph comparisons, and a review note for any newly added language-specific document. This evidence helps later researchers distinguish a new language presentation from a modified experimental result. It also makes rollback possible if a multilingual field causes a repository importer to behave unexpectedly.

Maintain authorship and contributor roles

Research packages often describe authors, contributors, software creators and institutions as contextual entities. Their identities may be linked by external identifiers or stable organization records. Translate the descriptions of roles when the publishing platform supports them, but do not replace a person’s identity with a guessed transliteration or alter contributor relationships. A Latin-script name may have an established local-language form, yet identity resolution remains separate from display preference.

Suppose a person contributed instrument setup but did not write the paper. A target-language summary should not call that person the principal investigator merely because a general word for “contributor” sounds informal. The relationship is evidence of responsibility and credit. Preserve the original association in the graph, then choose a well-reviewed local-language phrase for the role. If the crate profiles role details through another vocabulary, follow that vocabulary’s published definition rather than improvising a free-text status.

For institutional names, check whether an official translation exists. Do not invent an acronym that could resemble another university or laboratory. If the organization’s name remains in its registered language, a localized descriptive gloss can be added for readers without changing the organization identifier. Review the rendered credits in every target language and ensure that citations generated from the crate continue to point to the intended authors and dataset.

Distinguish licences from friendly permission summaries

A licence is a legal condition of reuse, not just a sentence on a download page. A license relation may point to a recognized licence URL with specific rights and obligations. Translators can explain the licence in accessible language, but that explanation should not replace the authoritative licence reference or broaden permissions. “Open for teaching” is not equivalent to unrestricted redistribution, and “free to read” is not automatically permission to remix or sell.

Consider a school dataset with a published licence and photographs owned by a different contributor. A target-language page that says “all files are free to use” may overstate what the crate actually permits. A precise translation must distinguish the dataset’s licence from separate restrictions on images, sensitive records or third-party materials. The result may be less catchy than a promotional slogan, but it prevents users from making decisions on a false premise.

Route legally significant phrases to the rights owner or competent reviewer. Retain the exact licence URI, and provide an explicitly labelled explanatory summary where helpful. If the licence itself has an official translation, cite its official source rather than translating its conditions as new legal text. The release checklist should compare licence and rights statements across languages and confirm that each summary is aligned with the actual permission record.

Translate file descriptions without changing file provenance

File-level name and description can help readers decide which asset to open. The rainfall CSV may be described as raw daily readings, while a methods PDF explains a collection procedure. Translating these labels improves discovery, but it must not hide which file is primary evidence and which is commentary. A translated name should still identify the same file even if the target language uses a different word order.

A common mistake is to label a processed table as “original observations” because the source description used “data” loosely. Another is to translate a file with a unit-bearing name as though it measured a different quantity. Review file descriptions alongside headers, units and a small sample of records. If the asset itself is an image or table, inspect it rather than extrapolating from the filename. The translator’s evidence should come from the actual file and the steward’s explanation.

Where the package contains localized copies of user-facing documentation, give the copies their own real paths and coherent metadata. Do not attach translated README text to the identifier of the untranslated original. Readers should be able to tell which file they will receive. If the README’s translation adds commentary, record that it is a translation or adaptation rather than substituting it for the original methods record without notice.

Avoid manufacturing a second dataset from a translated summary

Multilingual portals often create separate URLs for each locale. A different web URL does not necessarily represent a different research dataset. If the landing pages each mint an unrelated dataset identity, citation tools and search engines may split references to one intellectual object. A publication strategy should distinguish a localized presentation URL from the canonical dataset identifier. The relationship should be consistent with the repository’s metadata architecture and citation policy.

Do not assume that a language code in a URL is enough to maintain identity. The portal might expose a localized description but continue to use the same DOI or repository identifier. Check the language switcher, canonical metadata output, download link and citation export. A user who switches languages should not suddenly see a different file count, new authorship claim or mismatched publication date. Identity consistency is a practical accessibility feature as well as a technical requirement.

If the research actually has revised datasets for different countries, those may be legitimate distinct packages. The correct test is scientific and archival identity, not simply whether the titles look similar. A translation-only change preserves research content and provenance. A filtered or transformed dataset may require a new version or derived object with explicit links. Teach editors to ask which kind of change occurred before creating URLs or new graph entities.

Build language fallback intentionally

Fallback happens when the preferred translation is unavailable. A sensible system might show a reviewed English description with a clear language label rather than an incomplete or invented target-language text. But fallback is a product decision, not something every RO-Crate consumer implements identically. A portal may support language tags, a local JSON catalogue and alternate HTML pages; a command-line tool may display only the primary field. Document behavior rather than relying on a presumed universal convention.

Test missing-language cases at several levels. What happens if the dataset title is translated but the file-level description is not? Does the interface mix languages visibly or silently? Does it preserve the original claim and uncertainty, or create a machine-generated summary? Does search index the intended target-language text? Each outcome has consequences for user trust and for reproducibility when someone cites a description captured at a specific time.

Avoid silent fallback that makes readers believe all information was independently reviewed in their language. A small indication such as “Description available in English” may be more honest than pretending a partial localization is complete. If automatic translation is used as a temporary aid, distinguish it from approved scientific metadata. Reviewers should never assume that machine-generated prose carries the same evidential status as a signed-off description from the data steward.

Check JSON syntax and JSON-LD semantics separately

JSON syntax validation catches malformed quotes, commas and brackets. It does not guarantee that a crate uses recognized vocabulary terms or that a linked entity still resolves. JSON-LD expansion can expose unexpected interpretation when a property receives a new object structure, a context is altered or a language-tag convention is unsupported. RO-Crate validation adds its own profile expectations. Use these checks as successive layers, not substitutes for each other.

A successful test sequence begins with a fixed copy of the source package. Parse JSON. Resolve the crate’s local file paths. Run the appropriate RO-Crate validator or profile checks supported by the target repository. Compare graph identifiers, types and relationships before and after translation. Render the localized dataset title and descriptions in the actual interface. Finally, have a domain reviewer confirm scientific equivalence, uncertainty and licence boundaries.

Be cautious about what a test proves. A valid JSON string can contain a scientifically false sentence. A valid graph may link to an obsolete external URL. An RO-Crate validator may not inspect every rendered translation or every repository-specific display fallback. Record which tools ran, versions used and which checks were manual. Do not claim full conformance from a syntax-only script, and do not treat screenshots as proof that the linked data has remained intact.

A translated description may look perfect while a file reference is broken because someone renamed a directory during packaging. The resulting error is often misclassified as a localization bug, but the fundamental issue is the mismatch between a graph identifier and the actual asset location. Search for the referenced path in the unpacked crate and compare it with the source archive. Do not repair the link by guessing a similar filename.

For a missing file, identify whether the asset was omitted, moved, renamed or replaced. Each scenario has a different repair. An omitted file should be restored from the authoritative package; an intentional rename requires coordinated metadata and release updates; a replaced file may need new provenance. Translators should not be given authority to invent replacement observations or reconstructed methods merely to make a portal preview work. Escalate technical asset changes to the steward.

A useful regression test computes the set of file @id values and checks their existence within the permitted package structure. Also inspect case sensitivity, Unicode normalization and URL encoding in paths, because a file can appear to work on one operating system but fail on another. Repeat the test after the ZIP is reassembled. Readers judge the quality of a translated package partly by whether every advertised supporting file can actually be opened.

Handle cultural context without adding scientific conclusions

A school project might include local place names, community terminology or educational explanations that do not have one exact counterpart in another language. Translators need room for concise context while preserving what the original research claims. A brief explanatory phrase can help a reader understand a location or method, but it should be distinguished from an observed result. Annotations or localized landing-page notes can supply context without modifying measured facts.

If an instrument is described using an informal local name, the translation should identify its physical function and any limitations rather than choosing a more sophisticated term. For example, a homemade rain gauge should not be described as a calibrated meteorological station merely because the target language commonly uses a formal word for measuring device. The difference affects how readers evaluate the evidence and whether they can reproduce the classroom activity.

Ask a target-language subject reviewer to paraphrase the method and caution from the translated description, then compare that paraphrase with the original. This is a stronger check than comparing word counts or asking whether the translation sounds natural. If the reviewer infers a different sampling interval, measurement unit, population or level of certainty, revise the local text. The objective is transferable understanding, not identical sentence structure.

Preserve relations to software and workflows

An RO-Crate may describe the software that generated a figure, the workflow that processed data or the instrument that collected measurements. Such entities often have stable names, versions or identifiers that should not be translated. A software label can be explained to readers, but its exact version remains important for reproducibility. Changing “version 2.1” to a local numeral style in machine data can confuse automated matching or instructions for replication.

Consider a rainfall analysis performed with a notebook. A translated description can explain that the notebook calculates monthly totals and marks missing readings. It must not state that the notebook fills missing values unless the code actually does so. Review the dependency and software references against the actual files. When a translation corrects an inaccurate source sentence, record the factual correction through the appropriate metadata workflow, not merely as a quiet localized rewrite.

A clear release checklist identifies which claims are backed by executable workflow files and which are editorial summaries. Reviewers should be able to reproduce the essential processing steps or see why reproduction is limited. The translated presentation may improve navigability, but it should not erase software versions or uncertainty about instrument calibration. Those details explain what the data can and cannot support.

Manage revisions and translated text as separate change histories

A crate may acquire a new data file, correct a CSV value or update its licence. Each is a meaningful research-package change. Translated prose can also be revised for clarity without any data change. Combining both into one opaque “updated” stamp makes it difficult for readers to know whether a scientific result changed. Keep a content revision ledger and a localization revision ledger, with links between them when needed.

Suppose the English description is corrected from “thirty daily measurements” to “twenty-eight observed days and two missing dates.” The Mandarin description must be reviewed because the source claim changed. By contrast, if a translator merely replaces an awkward synonym with a more idiomatic equivalent, the dataset files may remain unchanged. The change record should distinguish these cases and explain whether additional domain review was required.

Before shipping, compare the metadata of the current package against the previous approved crate, not only against today’s translation draft. That historical comparison can reveal a forgotten language that still describes an old methods version. It also helps teams avoid assigning new intellectual object identifiers for cosmetic edits. Versioning policies vary by repository, so document the rules actually in use and do not pretend that one universal DOI policy governs every crate.

A practical diagnostic sequence for a failed multilingual release

Start with the user’s symptom. If a localized title displays in the wrong language, inspect language selection and fallback before touching identifiers. If a download yields a missing file, inspect the graph-to-package path. If a repository rejects the crate, separate JSON syntax errors from profile and relationship problems. If a citation is inconsistent, compare dataset identity, creator metadata and revision history. Diagnosis is faster when each symptom maps to a small set of likely causes.

Reproduce the failure with a minimal synthetic crate. Keep the same graph structure but remove sensitive real data and unrelated assets. Confirm that the defect occurs without the full research dataset. This gives technical reviewers a controlled fixture and prevents publishing private participant information during debugging. Change one factor at a time: translated field location, JSON-LD context, graph link, language selector or import tool version.

After repair, rerun the complete route from metadata to user display and file download. A locale fix that appears correct in the website may still fail in an exported archive. A graph repair may change citations even while every file link resolves. Record results by consumer rather than writing “passed” without evidence. Include at least the repository importer, local crate validator, citation export and public display when those are part of the intended release.

Worked transfer exercise: a school climate dataset becomes a museum collection

A museum now wants to publish a crate about photographs of historical measuring instruments. The English root description says: “Teaching images of three instruments; dates are approximate; reproduction rights vary by photograph.” A translator proposes a target-language text that says: “Three nineteenth-century instruments, fully documented, all images free to reuse.” The crate still contains the same photograph files and the translated page looks polished. Identify the defects and propose a safer release workflow.

The proposed description adds an unverified century, asserts complete documentation despite approximate dates, and grants universal reuse despite variable photograph rights. These are not stylistic differences: they materially change provenance, certainty and permission. Restore the approximate-date and rights qualifications, check image-level creator and licence metadata, and keep the same file identifiers. If the museum has evidence that an instrument dates from a specific century, document the curatorial correction separately from translation. Use a localized explanation for readers rather than overwriting the rights graph.

The changed context demonstrates a general principle. Moving from a numerical school dataset to a cultural heritage package changes the domain review questions, but not the graph-integrity method. The team still protects @id links, types, licence references, evidence relationships and revision history. It still tests the crate and presentation independently. What changes is the domain-specific proof: now a curator reviews object dates and image permissions instead of a science teacher checking measurement limitations.

A production review checklist that can actually reject a release

Review scope before checking prose. Confirm the target language, audience and repository display behavior; identify which descriptions may change and where translations are stored. Verify the approved source package and expected file inventory. Confirm that each localized text refers to the correct graph entity. If a language variant is missing, follow the documented fallback rule. Do not quietly fill the gap with unreviewed content simply to make a dashboard show green.

Review meaning with real evidence. Compare research aim, sample, methods, units, dates, limitations, authorship and rights across languages. Confirm that uncertain claims stay uncertain and that no translated sentence claims certification, ownership or public reuse the original does not support. Ask a subject expert to review any scientific or legal ambiguity. Treat a change to an identifier or a licence as a blocking defect unless there is an explicit authorized data-steward change record.

Review technical integrity last, then repeat the end-to-end path. Parse JSON, test JSON-LD representation as applicable, check graph references, run the intended profile validator, inspect the localized landing page and download a fresh package. Confirm that citation exports point to the canonical research object and that protected information does not leak through translated summaries. Publish only after the repository owner signs off both readability and reproducibility; passing a checker alone is not permission to release.

Limits: what this translation method cannot guarantee

This workflow does not establish that the underlying research is correct. It also cannot convert a weak sampling method into a robust one or infer missing provenance from a neat description. A RO-Crate may validate structurally while containing misleading claims. Domain review, ethical clearance, data-rights assessment and appropriate citation practices remain separate responsibilities. Translation adds accessibility, not scientific certification.

Language-tagged JSON-LD representations require careful compatibility testing. An example that renders in a custom website may not be valid for the chosen RO-Crate profile or recognized by a different repository. Use officially supported property structures and processor behavior. Similarly, a localized HTML landing page does not prove that exported crate metadata will retain translations. The deployment architecture must be tested in the form readers will actually use.

Finally, translation may expose cultural or political disagreements about place names, ownership and indigenous knowledge. Those questions should not be resolved by a machine translation shortcut. Seek appropriate authority, document choices and retain original source evidence. The durable goal is that more people can understand the same research package while still seeing where its evidence, limits and rights begin and end.

Summary: translate the explanation, keep the research object

The fastest safe RO-Crate translation starts with a property inventory and a protected copy of the source metadata. Translate approved descriptive material through a documented language pathway; preserve graph identity, files, licence links, authorship and scientific claims. Validate JSON, graph semantics, package integrity, repository behavior and expert meaning in separate stages. Where a problem is found, repair the affected layer rather than silently changing research evidence. A successful multilingual crate lets each reader understand the package and follow exactly the same chain of proof.

Frequently asked questions

Can I translate every string in ro-crate-metadata.json?

No. Strings can be identifiers, vocabulary terms, resource paths, controlled values or prose. Classify each property first. Translation is appropriate only where the intended profile and publishing workflow support a human-language value; technical strings must remain stable unless a separate authorized metadata change occurs.

Does RO-Crate 1.3 automatically provide multilingual display pages?

No. RO-Crate provides a metadata packaging approach based on JSON-LD. Multilingual display depends on language representation, repository support and rendering software. Test the exact target consumers; do not assume that an arbitrary language-key object will be interpreted as a standard language map.

Should every language have its own dataset DOI?

Not merely because a description has been translated. The citation and identifier policy belongs to the repository and data steward. A localized landing page can describe the same intellectual research object. New data or materially derived datasets may need different version or relationship handling.

What if the original English metadata contains a factual mistake?

Record the correction with the dataset owner and update the source of truth through the repository’s change process. A translator should not quietly correct only one language. Re-review all variants whose scientific claims depend on the corrected statement.

Can translated filenames replace the original file paths?

A localized display name can help readers. Renaming a packaged asset changes a path used by graph links and potentially checksums, manifests or scripts. Do that only as a coordinated packaging operation, not as an incidental text edit.

How are licence statements handled in a bilingual crate?

Keep the authoritative licence reference and rights distinctions intact. A language-specific summary may explain what that licence means, but should be clearly subordinate to the actual terms and should receive appropriate rights review. Do not invent broader permission from a friendly translation.

What validation is enough before distributing a crate?

Use layered validation: JSON parsing, graph and link checks, RO-Crate profile checks supported by the target service, language rendering, citation tests and subject-matter review. Each layer catches different failures; no one test certifies research truth and multilingual quality simultaneously.

Why should the original language description remain available?

It provides an auditable source for revisions and preserves the researcher’s original claim. A later translator or curator can compare wording and identify whether differences reflect clearer language or a change in evidence. The source language also supports transparent fallback when a localized field is missing.

Does a translated README count as the same file?

No. It is a new file containing a translation or adaptation, even if it explains the same method. Give it a real path and, when appropriate, its own metadata entry and relation to the original. Distinguish additions to the package from presentation-only text changes.

What should a teacher ask students to test?

Give students a synthetic crate with a description, file link and licence reference. Have them translate only the description, verify that its uncertainty survives and compare graph identifiers before and after. Then introduce a deliberately broken file path so they learn that translation quality and package integrity are different checks.