To translate a Common Workflow Language (CWL) workflow quickly, localize its human-readable label and doc values while protecting the ports, step identifiers, types, executable commands, input bindings and data links that make the workflow run. A CWL file is both documentation and an executable contract. The fastest safe translation touches the explanatory surface without unintentionally editing that contract.
This guide explains how to translate CWL v1.2 tool and workflow descriptions, including command-line tool labels, input help, output explanations and step documentation. It distinguishes prose from id, run, source, outputSource, baseCommand, arguments, inputBinding and type declarations. It also demonstrates a structure comparison, realistic failure modes, runnable-file validation boundaries, a changed-context exercise and a practical sign-off method for teams sharing scientific and data-processing workflows across languages.
Start by copying the authoritative workflow, identifying exactly which label and doc paths are allowed to change, preparing a small terminology sheet, and generating an annotated localized copy or companion documentation. Then validate YAML syntax, compare all protected fields, resolve referenced tools, and run the workflow on a controlled sample when a compatible CWL runner is available. The translation must not replace a command, move an input to a different port, or change what data is sent into an analysis step.
The quick answer is to translate descriptions, not wiring
CWL describes how a command-line tool or multi-step workflow consumes inputs and produces outputs. A tool can have a readable label that a researcher sees in a workflow browser, plus identifiers and bindings that an engine uses to execute the task. The label can become natural in another language. The identifier must still refer to the same object. A fluent translation is useful only when the data flowing through that object remains identical.
Consider an input port called reads with the English label “FASTQ reads”. A French description can explain that this input expects the original sequencing read files. Yet the port still needs to be named reads if the workflow references it by that identifier. Renaming it to a target-language noun without updating and verifying every reference can break the workflow. Updating every reference is also an unnecessary code migration when the reader’s real need is documentation in French.
The same principle applies to run locations and command-line options. A word such as sort may be a command, an argument or a step label depending on context. A translator who treats all English-looking strings as natural language can modify the program that will be executed. The correct classification starts with where the string lives in the CWL data model, not how translatable the characters appear.
What CWL adds beyond an ordinary translation document
A scientific workflow file is often passed among several parties: the researcher who defines the method, the engineer who maintains the environment, the reviewer who inspects reproducibility, and the student who learns the steps. The audience rarely shares identical terminology. A local-language description can remove a major barrier for students while the original machine definitions continue to support reproducible research across laboratories.
CWL has explicitly documented fields such as label and doc on relevant objects. The standard treats label as a short human-readable name and doc as documentation text, or sometimes an array of text strings, depending on the object. This is a useful separation, but it is not an automatic internationalization framework. CWL does not imply that adding arbitrary language-object values to every label will work. A new representation must follow the schema the actual field accepts.
This distinction gives the translation team a practical division of labor. The workflow maintainer defines the protected executable structure; the subject expert confirms technical meaning; the translator makes the explanation readable; and the runner or validator checks that the localized delivery still conforms to the specified workflow. No one role alone certifies the whole result. The bilingual reviewer should understand enough of the experiment to recognize whether a translated instruction changes a step’s scientific purpose.
Inventory the dependency graph before extracting words
A CWL project may include a top-level Workflow, one or more CommandLineTool files, an ExpressionTool, input job files, container requirements and auxiliary scripts. A reader may see only the top-level YAML document, yet the label that causes confusion lives in a separate tool file loaded through run. Translating only the first file can leave mixed-language descriptions or contradict a tool’s actual behavior.
Begin by mapping all referenced files, imports and included fragments. Record each run target, tool class, tool version, input and output port name, and the relationship between workflow-level inputs and step-level inputs. Keep a dependency list of whether a particular human label is defined in the top-level workflow or in the underlying tool. Avoid maintaining two divergent translations for the same port unless they deliberately address different audiences.
A practical inventory should name who uses each piece of text. A workflow title displayed in a catalog must identify the whole process; an input doc helps a user supply a valid value; an output doc describes the meaning and location of an artifact; and a step label helps a reviewer understand the sequence. These are not interchangeable writing tasks. A beautiful label that obscures the required input type is worse than a plain, precise one.
Recognize the protected parts of a tool definition
A CWL CommandLineTool can specify baseCommand, arguments, inputs, outputs, requirements, hints and bindings. The executable command and its flags are not translation strings. An input with inputBinding.position controls where its value appears on the command line; a prefix may need to be emitted byte for byte. A glob determines which output files are collected. Changing these to sound more natural can change execution even if the YAML remains syntactically valid.
Other protected elements may encode data type contracts such as File, Directory, string, int and array schemas. A translator should not replace File with a target-language term inside a type declaration because the runner interprets that token as a type. Display documentation can say “input file” in a local language while the actual schema retains type: File. Treat logical expressions and JavaScript expressions similarly: their identifiers and operators are code, not prose.
Compile a protection table for the workflow. For each field path, mark whether it is explanation, identifier, executable data, file reference, source connection or scientific input value. If the field belongs to a machine-controlled category, freeze it. The author may separately choose to refactor the workflow, but that is a code change with its own review, testing and versioning, not something a translation project should quietly absorb.
Read a compact command-line tool example
The example below illustrates translatable documentation beside protected tool configuration. It is a teaching specimen; use the official schema and a CWL runner for production validation.
cwlVersion: v1.2
class: CommandLineTool
baseCommand: echo
label: Display a supplied message
doc: Shows one text value; intended for a classroom demonstration.
inputs:
message:
type: string
label: Message to display
doc: The text passed as the first command-line argument.
inputBinding:
position: 1
outputs: []
A localized version can translate both label values and both doc strings while leaving baseCommand: echo, the input identifier message, type: string, inputBinding and its numeric position unchanged. A student using a Spanish interface can see the equivalent of “Message to display”, while the runner still recognizes the port named message. This is how a translation can improve teaching without changing the result of a small computation.
The example is intentionally modest. It does not prove that every runner will accept every surrounding environment or that a workflow which imports it can resolve the tool path. A meaningful test records the exact tool definition, its input object and the runner version, then compares the command line and output behavior before and after localization. Static YAML parsing catches syntax but cannot prove the behavior of an external executable.
Preserve workflow input and step connections
At workflow level, steps define tasks and the way they receive data. A step input may have a source that points to a workflow input or a previous step’s output. A workflow output may have an outputSource pointing back into the graph. Those strings are references. They are not sentences, even when they use English words and underscores. Changing source: reads to a translated noun without changing the definition it references can disconnect the graph.
A clean translation pass has a graph invariance test. Extract the set of steps, input identifiers, output identifiers, source references, outputSource references and run targets before translation. Extract them again afterward. The sets and their edges should agree exactly when the project claims to be documentation-only. If a difference exists, investigate whether the translator accidentally changed a key, an exporter reordered or rewrote references, or a code migration has been mixed into the task.
This method becomes especially valuable when workflows contain many steps that appear similar. A preprocessing task and a quality-control task may both accept file lists, yet their ports lead to different tools and artifacts. A translator who changes the name of one step for readability must not create a label that implies the wrong function. A scientific reviewer should be able to follow the same input through the localized graph and describe its destination accurately.
Distinguish labels from identifiers in the user interface
A workflow editor often presents a friendly title while storing a stable underlying identifier. The UI may place the two side by side, encouraging an editor to assume both are changeable. Teach translators to read the schema or extraction path instead of relying on visual proximity. A localized label can appear in a browser panel, but the YAML key or id that binds the object must remain stable during a language-only revision.
The distinction also matters when users search for a tool. A title such as “Filter low-quality reads” conveys a scientific task; an identifier such as trim_reads might be deliberately short and stable for scripts. A target language may require a longer explanation to distinguish trimming from filtering. That should be handled in doc rather than by attempting to encode every nuance into a machine ID. A concise label and a precise explanation serve different cognitive jobs.
Where a runner ignores labels, the documentation is still useful to catalogs, graphical editors, repository pages and human reviewers. Do not promise that changing label will switch every CWL interface to a chosen locale. An application needs its own language selection or an explicitly chosen localized workflow representation. This is a distribution question, not something the CWL field definition resolves automatically.
Translate doc as scientific instruction, not marketing copy
A good doc tells users what a value means, how to supply it and what to expect. It may state a file format, a threshold convention, the direction of a score or the limitations of a step. The translation needs to preserve those details even when the target language would normally favor shorter phrasing. A translator should simplify ambiguity where authorized, but cannot introduce an undocumented default or replace a technical constraint with a reassuring slogan.
For example, “expects paired-end reads in two separate FASTQ files” is not equivalent to “accepts sequencing data”. The latter is shorter but removes the pairing and file-count requirements. If a runner will reject a single file, a local-language student must be warned before submission. Similarly, “minimum mapping quality” should not be reduced to “quality score” when several different scores are available in the pipeline.
Reviewers can test documentation with sample inputs. Show the target-language doc to someone unfamiliar with the workflow and ask them to select the correct file and predict the resulting output. If they supply the wrong type or misunderstand which threshold is inclusive, the translation has failed its task even if all words are conventional. This practical test often catches missing context that a purely sentence-level review misses.
Protect shell commands, placeholders and environment variables
CWL workflows may include placeholders, environment names, script filenames, regular expressions and embedded expressions. The literal string --threads might look like an English phrase to an automated translator, but it is an executable option. The path reference.fa is an asset reference. A JavaScript expression using $(inputs.reads.path) contains property names that a runner expects. Translating the interior of those expressions is likely to break execution or silently change the selected value.
Use extraction rules that exclude command arguments and code blocks entirely, unless a technical maintainer explicitly designs a separate translation mechanism for an embedded human message. If the executable prints user-visible prose, translating that prose is a different software localization job and may require changing a script, tests and message catalogs. Do not claim that a doc pass has localized every message the command itself might emit.
Machine-generated content can also contain scientific terms. A FASTQ name, output basename or reference assembly name may look descriptive but be part of provenance. A translator should explain such values beside them instead of replacing them. Verify that all environment and container references remain equal before and after the localization pass, including digests when the workflow pins an image to a specific version.
Treat input help as an error-prevention tool
The most valuable translated input descriptions often prevent invalid or misleading runs. A parameter called threshold needs context: threshold of what, in which units, inclusive or exclusive, before or after normalization? If the original supplies that context, preserve it completely. If it does not, ask the workflow owner instead of inventing an answer based on a familiar tool with the same parameter name.
A local-language word may carry an unexpected implication. Translating “reference” as a citation when the port expects a reference genome can mislead a learner even though the dictionary equivalence looks defensible. Similarly, “reads” in a sequencing workflow means sequencing reads, not a count of how many times a person read a document. A terminology sheet should include a short domain definition and an example input type, not just a pair of equivalent words.
A useful review organizes mistakes by consequence. Some cause immediate validation errors, such as a missing file. Others may produce scientifically plausible output from the wrong reference or wrong threshold. Prioritize review of input descriptions that could make a bad execution appear valid. That risk-based allocation is more effective than giving every adjective the same amount of attention.
Preserve what output artifacts actually mean
Output descriptions support interpretation long after a workflow has run. A file called counts.tsv might contain raw feature counts, normalized counts or a particular aggregation. A label such as “Results” is not sufficient when a downstream analyst needs to know what can be compared. Translators must preserve definitions of columns, coordinate systems, reference assemblies and filtering conditions found in the source doc or linked workflow documentation.
Do not rename files or output glob patterns for cosmetic language reasons. The collection rule may match a particular suffix, and a downstream step may expect it. If the team wants a human-friendly output title in a report, use a separate display name and document the mapping to the canonical artifact. Testing a translated workflow should include whether the same files are collected and made available to later steps.
Think of output documentation as a compact chain-of-custody statement. It should help readers answer which tool made the file, what inputs and parameters influenced it, and what claims can be made from its contents. Translation cannot substitute for missing provenance. If a source description conflates preliminary and validated results, the correct response is an author query and, if agreed, a coordinated source correction.
Handle arrays and schema-defined text shapes correctly
Some CWL doc fields can accept a string or an array of strings. That does not mean any multilingual JSON object is valid in that position. In a schema allowing an array of documentation strings, an array may represent pieces of one document, not parallel language alternatives with a language tag. Switching from a string to an object keyed by en and fr because it looks tidy can make the workflow invalid under the applicable specification.
Keep the expected schema shape for the chosen localized artifact. If an authoring system stores several languages, let that system manage a language-to-string catalog outside the CWL document and render one approved text representation when necessary. Record which language is being emitted and avoid letting two versions silently overwrite each other at the canonical file path. A repository can provide a readable overview in several languages without making the executable definition itself ambiguous.
JSON and YAML also have different quoting considerations. A translated colon, apostrophe, multiline passage or special character may alter parsing if inserted without correct YAML serialization. Rather than hand-replacing quoted substrings, parse the data, update approved paths, then serialize with a trusted library. Review the serialized output for readability and use a CWL validator because a general YAML parser checks grammar but not the workflow schema.
Use language tags in publication records, not imaginary CWL fields
A cross-border lab needs to know which text is French, Spanish or Japanese, and whether it is a reviewed human translation. That does not justify inventing a top-level locale or translations field inside CWL and assuming a runner will understand it. Keep locale metadata in the repository, a manifest or an external translation catalog unless an application documents a specific supported extension.
Use a recognized language tag such as fr or ja-JP in the catalog and link the translated documentation to the exact CWL revision. A review sheet should also identify terminology decisions and the subject expert who approved them. The language tag should be treated as a routing label, not as a mathematical parameter. If a tool’s scientific behavior depends on locale, such as reading locale-dependent decimal separators, that is a new runtime issue requiring explicit testing.
Multilingual publication needs a fallback policy. When a new version introduces an untranslated doc, the system might show the canonical English explanation with a visible fallback note, rather than silently displaying an old target-language description. Fallback behavior must be documented so a user does not mistake mixed-language content for a fully reviewed translation of the current workflow.
Make structure invariance machine-checkable
A practical check parses the source and localized YAML documents into objects. A function walks both trees, masking only approved label and doc paths. It then compares the remaining tree, including identifiers, types, references, command fields and requirements. The comparison should not ignore entire subtrees just because they contain a human label. It should fail on newly added, missing or type-changed fields outside the allowlist.
Object-key order in YAML is not usually semantic, so compare parsed structures rather than raw text bytes for the invariant check. At the same time, keep a plain textual diff for human reviewers. The diff can reveal an unexpectedly reformatted source or unreadable wrapping even if parsed equality passes. Consider checksums for external tool files, container references and sample job data so a translation process cannot accidentally substitute a different dependency.
This structural test is a guardrail, not a complete proof. A changed doc might falsely state that a threshold is inclusive while the code uses a strict comparison. A preserved baseCommand might call a different executable installed on another machine. Combine static invariance with a controlled execution using the same runner and environment wherever possible, then compare outputs or appropriate scientific invariants.
Diagnose common failures without hiding behind a passing parser
The first failure class is structural: a translated key breaks a reference, a YAML colon changes the tree, or an array becomes an object. A YAML parser or CWL validator often catches these problems. The second class is operational: the tool still parses but invokes a different command, uses an altered argument, or resolves a path to a different file. Catch it through protected-field comparisons and controlled runs.
The third class is semantic: everything executes as before, but translated documentation tells a human the wrong story. The output may be described as normalized when it is raw, a reference is described as optional when it is required, or a filtering threshold is explained in the wrong direction. These problems require a bilingual domain reviewer and sometimes task-based testing with representative users.
A fourth class is version drift. The translated doc was correct for workflow version 1.0 but the source has since changed a tool or parameter. A package can pass validation and still show stale guidance. Compare a translation’s recorded source commit with the current workflow before release. If the source revision has changed, either re-review the affected paths or visibly mark the localized text as tied to the old version.
Explain why step order is not always execution order
A translated workflow diagram may encourage readers to infer that steps run from top to bottom. In CWL, data dependencies determine readiness, and independent steps may execute concurrently depending on the runner. The ordering of entries in a YAML file should not automatically be explained as an enforced chronological schedule. A translator must preserve the distinction between dependency order and visual arrangement.
For example, two separate preprocessing tasks may consume the same input without depending on each other, while a downstream analysis waits for both outputs. Describing one preprocessing task as occurring “after” the other can misrepresent the workflow. The correct target-language text may explain that both feed the final analysis. This is a conceptual translation problem: nothing in the data structure changed, yet an imprecise word can give users the wrong understanding of execution.
The review should therefore include a graph reading, not merely a file reading. Ask the subject expert to identify dependencies, optional branches and scatter behavior when present. If the workflow uses conditional steps, explain the conditions according to the actual CWL version and implementation, rather than making an unsupported universal statement about all runners.
Review the relationship between workflow and research method
A lab’s workflow often encodes one stage of a larger experiment. Labels and docs should not imply that running a tool alone reproduces an entire study. A sequence alignment workflow cannot by itself validate the source samples or the ethics of recruitment. Similarly, a classification step might produce predicted labels, not measured ground truth. Preserve those distinctions in translations that will be read by students and collaborators.
The author should decide which explanations belong next to inputs and which belong in a linked methods guide. Short doc fields can prevent frequent errors, but they may not carry every caveat of the scientific procedure. Use concise text with references to the canonical method and keep those references stable. Translated documents can improve accessibility while retaining an exact route back to the approved analysis description.
A powerful test asks whether a reader can state the inputs, computational operation, output meaning and limits of interpretation after reading the localized workflow. A translation that passes only a terminology quiz but cannot support those four answers remains incomplete for educational use.
Changed-context transfer: from sequencing to environmental mapping
Suppose a research team adapts a CWL workflow originally used for sequencing to a new environmental data-processing course. It includes a tool clean_samples that accepts a source_table and a numeric missing_limit, then produces a cleaned_table. A translator proposes turning missing_limit into a target-language YAML key, changing source: raw_table to a translated phrase, and converting the limit from a fraction to a percentage because students usually speak in percentages.
That proposal crosses three distinct boundaries. The field key and source are machine references that must stay stable during localization. The numeric scale is part of the computation: changing it from 0.10 to 10 would require a deliberate code and data transformation. The appropriate translation instead explains the limit in natural language, explicitly saying whether it is a fraction and whether the comparison includes the boundary value if the implementation defines that behavior.
The answer illustrates portability of the method. CWL users may analyze sequencing reads, climate data or school assessment records; the linguistic treatment still begins by separating execution contracts from explanation. Test the connection graph and protected structure first, then test whether a novice can supply the correct type of sample and interpret the output under the new domain.
Plan validation at three levels
At the first level, parse the YAML or JSON and check for data-structure changes. This detects broken quoting, indentation and accidental type changes. At the second level, use a CWL-specific validator or runner in the project’s target environment; resolve references, inspect requirements and test that the workflow can be loaded. At the third level, run representative inputs and compare the same scientifically meaningful results and output artifacts against the canonical workflow where such a comparison is appropriate.
Validation should not be presented as stronger than it is. A static schema check cannot prove that a container image is reachable, that network permissions are available or that the installed command matches the expected version. A single test run cannot prove every possible conditional branch works. State which tools were used, what was actually executed and what remains untested. The manuscript’s example can be syntax-checked without claiming a full CWL runtime certification.
To keep the review fast, define explicit exit criteria. There should be zero unapproved protected-field differences, zero unresolved YAML parsing errors, no broken references introduced by localization, and no open high-risk semantic queries. A project with limited computing resources can still ship reviewed human documentation, but should be honest about the scope of runtime testing rather than recording a misleading pass.
Practical checklist for reviewers and maintainers
Before approval, confirm that every label and doc edit corresponds to an approved path; all id, run, source, outputSource, command, binding, type and requirement values remain unchanged; and every imported file has been considered. Check terminology for file formats, scientific roles, thresholds, units and output interpretations. Validate UTF-8 characters and multiline YAML serialization. Confirm that the translated artifact is clearly identified as a specific language and source revision.
Then have the workflow owner verify the graph and executable diff, and have a bilingual domain reader perform two realistic tasks: supply valid inputs based only on target-language help, and interpret a representative output without seeing the English explanation. If either task fails, repair the documentation and repeat the relevant test. The goal is not to maximize the number of translated strings, but to remove barriers to correct, reproducible use.
Maintain an audit trail of decisions. If the next workflow release changes a port or scientific assumption, the team should know exactly which descriptions require re-review. Localized text is a maintained interface to a living workflow, not a document that can be translated once and forgotten.
Limits and summary
A documentation-only CWL translation cannot fix a faulty pipeline, guarantee reproducibility across compute environments or substitute for validating a research method. Nor does CWL itself promise automatic language selection for every tool browser. Those limitations matter because a polished local-language description can make a workflow appear more mature than its implementation actually is.
The dependable strategy is simple: translate human help, freeze machine wiring, verify the dependency graph, test the actual workflow where possible and review the scientific meaning with its intended readers. Done well, localization makes a computational procedure teachable across languages while preserving the identities and relationships that make its output traceable.
Worked diagnostic: a label that becomes a false guarantee
Take a tool with an input named reference and documentation saying it must point to the same reference assembly used to create the accompanying index. A translator shortens that to “Choose a genome reference” because the phrase looks clearer in the target language. Users can now choose an arbitrary assembly and index pair, possibly producing an immediate error or an invalid comparison. Nothing in the CWL graph changed, but the translated doc removed an essential coupling rule. The precise repair is to state the requirement in natural language and show the relationship between the two files.
The test should use deliberately mismatched synthetic input names and ask a reader whether the pair is valid. If the documentation does not cause the reader to reject the mismatch, improve it. This is a better measure of correctness than checking that the target sentence contains the same number of technical nouns as the English one. The important content is a constraint between inputs, which may be expressed in very different grammar across languages.
Distinguish documentation QA from scientific output equivalence
Two localized descriptions can be semantically equivalent even if their words differ considerably. Conversely, two CWL files can be byte-identical in protected fields while their descriptions imply different scientific outcomes. Record these as separate QA tracks: structural invariance and explanatory fidelity. One tracks the parsed workflow, and the other uses tasks, examples and subject review to establish whether readers understand the same procedure.
For a workflow with a nondeterministic tool, comparing output file hashes may be inappropriate; use agreed outcome properties instead, such as schema shape, valid row counts, output type and accepted scientific tolerances. This nuance matters when a translation review is coupled to a controlled execution. The test must demonstrate that no change attributable to localization altered the workflow, not demand universal byte-for-byte identity from a pipeline that is not deterministic even before translation.
What a small laboratory can automate safely
A modest local script can list every field path, compare the protected structure and report added or removed label and doc entries. This reduces repetitive reviewer work without trying to automate scientific understanding. Add checks for malformed language exports, duplicate extraction IDs and accidentally unfilled target strings. For referenced files, report their path and checksum, then ask a maintainer to verify that imports are deliberate and secure.
What the script cannot safely decide is whether a localized technical phrase has the right scientific meaning. Keep the reviewer focused on disputed domain terms, ambiguous input requirements and output claims while machinery checks the boring invariants. This division lets a small team reach reliable results faster than either a completely manual inspection of every YAML token or an unreviewed automated translation of the entire project.
Avoid confusing an executable example with a safe production recipe
Educational CWL snippets often omit installation requirements, container references, input fixtures or access controls to focus on one concept. Translators should preserve that teaching boundary. If an illustrative example is introduced as “minimal”, do not rephrase the target-language caption as “production ready”. Such a change can encourage users to copy a classroom tool into a real pipeline without the safeguards the original author expected them to add. Documentation fidelity includes the source’s stated limitations and confidence level.
When a lab publishes a translated quick-start guide, put the tested runner version, dependency assumptions and command invocation beside the example if those facts are known. Link to the maintained canonical workflow rather than presenting a static screenshot as a reproducible artifact. A successful localized guide should make it easier to ask the next correct technical question, not conceal uncertainty about whether the described program will work unchanged on a different cluster or operating system.
Frequently asked questions
Which CWL fields are usually safe to translate?
Relevant label and doc values are the first candidates. Confirm each actual schema path and whether it is used only for human explanation before editing.
Can I translate port identifiers if I update the references too?
That becomes a workflow refactor rather than documentation-only localization. It requires a separate change request, complete dependency review and execution tests.
Why not translate baseCommand when it is an English word?
Because it identifies an executable or command token. Replacing it can change or break the task even when the new word is a correct translation.
Does CWL provide automatic runtime locale switching for doc?
Not simply by placing multiple arbitrary language objects in the field. Use an application-supported localization layer or an explicitly chosen localized documentation artifact.
Is a YAML parser enough for verification?
No. It checks YAML syntax, not necessarily CWL schema conformance, external tool resolution, command behavior or scientific meaning.
What should happen when the original workflow is updated?
Compare the translation against the exact new source revision, re-review affected explanations and record which version each locale represents.
Can a translated output label change a generated filename?
It should not. File names and output collection expressions are part of the contract; localize a display description instead.
How do I know whether a word is an identifier or help text?
Inspect its actual parsed path and relevant CWL schema field. Surface appearance alone is unreliable because executable options can resemble ordinary English.
What if a scientific term lacks a natural local equivalent?
Prefer a clear definition, stable glossary and approved term rather than improvising. Domain review should decide when a borrowing is safer than a misleading literal translation.
Does running one sample prove the translation is safe?
It is valuable evidence but not comprehensive proof. Combine protected-field diffs, schema validation, representative execution and bilingual semantic review.
Authoritative sources
- Common Workflow Language v1.2.1, Command Line Tool Description: https://www.commonwl.org/v1.2/CommandLineTool.html
- Common Workflow Language v1.2.1, Workflow Description: https://www.commonwl.org/v1.2/Workflow.html
- CWL User Guide: https://www.commonwl.org/user_guide/
- CWL project repository: https://github.com/common-workflow-language