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 | FMI 3.0.2 Model Help: Translate Simulation Labels Without Repacking FMUs

—

by

eduKate Asia

To translate a Functional Mock-up Interface (FMI) 3.0.2 simulation model quickly, make an external, language-specific explanation of its variables and keep the distributed Functional Mock-up Unit (FMU) unchanged. An FMU packages a model description, executable components or source code, and related resources. Its modelDescription.xml includes human-readable descriptions alongside names, units, value references and the metadata an importing simulator needs. The standard specifically prohibits changing that file within an FMU because it must remain consistent with the implementation.

The safe method is therefore a companion help overlay, not a repacked translated FMU. Inventory the FMI version, model identity and variable definitions; extract explanatory descriptions for review; translate them into a separate map keyed by stable variable references and names; then confirm that the original FMU bytes, numerical units, causality, variability and execution behavior are identical. The resulting language-specific interface can explain “measured inlet temperature” to a technician without renaming the input that a co-simulation platform reads.

This article shows how people translate quickly by splitting scientific explanation from executable simulation contracts. It covers model-description parsing, unit interpretation, warnings about sign and direction, variables with similar names, documentation lookup, safe ZIP handling, overlay mapping, diagnostics, transfer exercises and practical QA. It is different from translating a biological SBML equation model or an ONNX inference description: the central rule here is that an FMU remains a fixed distributed artifact while a translation layer describes its exposed interface.

Understand what is inside an FMU

An FMU is delivered as an archive with a .fmu extension and a defined internal layout. The model description is XML; depending on the FMU interface type and distribution it may be accompanied by binaries, C sources, resources and documentation. FMI describes Model Exchange, Co-Simulation and Scheduled Execution as different interface arrangements. A technical translator does not need to rewrite these mechanisms, but should understand that the XML is part of an executable interoperability agreement rather than a simple document attachment.

An importing tool uses the model description to discover variables, unit information, capabilities and dependencies. It may call compiled code using value references, set inputs and read outputs according to the FMU interface. A friendly phrase displayed by a dashboard may be derived from the XML description, yet the byte-level model remains responsible for actual numerical behavior. If a translator changes a variable’s identifier, the importer and underlying model may disagree, leaving an apparently clear interface that sends values to the wrong target.

Start by asking what the audience needs to do. A simulation researcher may need precise physical meanings and unit conversions. A classroom teacher may want a short description of an output graph. A plant technician may need to distinguish a controlled setpoint from a measured process value. The same original FMU can support those readers through different external explanations. The model’s API should not be silently redesigned to make one language feel more familiar.

Use the released specification, not a changing draft

The FMI website lists the 3.0.2 maintenance release, announced in November 2024, as an official 3.0.x version. A live development branch may have newer explanatory material or planned changes, but it is not interchangeable with the released behavior of a particular FMU. Read the applicable release of the specification and inspect the fmiVersion declared by the actual package. Do not infer that every FMU marked 3.0 was generated using the exact patch release you happen to be reading.

Record the modelName, instantiation token where present, exporter details, version string and relevant descriptions in the model XML. The instantiation token has special significance because an importer may pass it when constructing model instances. It is not a slogan or an arbitrary human-facing identifier. Altering it, even to change a perceived spelling error, could make the file inconsistent with its compiled implementation. This is one of several reasons a “translate the XML and zip it again” workflow is unsafe.

Keep the FMU’s original checksum and, when relevant, its provider signature or release artifact reference. An unsigned local copy can sometimes be mistaken for a vendor-supplied model after someone repacks it for documentation reasons. Provenance matters in engineering simulations because a numeric result can influence a design or operational decision. An external overlay should be clearly identified as documentation owned by the translator or organization, not as a newly certified binary from the model author.

Distinguish descriptions from executable metadata

The optional description attribute of a model or variable is human-facing explanatory text. A variable name is used to identify the variable, while a valueReference is part of the FMU’s interface to get and set values. unit, displayUnit, start, causality, variability, initial and declaration relationships carry computational or interpretive meaning. Some may look like everyday words, but they must not be translated in the distributed model.

Suppose a thermal model declares inletTemp with unit="K" and a description “Inlet coolant temperature.” A translated caption can explain that the variable measures the coolant temperature at the entry point. It cannot turn the unit into degrees Celsius just because local users commonly discuss Celsius. A display interface may legitimately convert numerical values using an approved conversion while stating the target unit, but a mere language translation has no authority to alter the underlying numerical representation.

Similarly, changing causality="input" to a local-language word would not make the model more readable. It would corrupt the declared interface. Even the plain-looking word “input” has a specific role in FMI. Translate its explanation in a help panel while leaving the actual value untouched. The distinction helps new learners: the API term is what their simulation tool expects, and the translated phrase explains what that term means for the task at hand.

The standard’s prohibition on editing the packaged XML matters

FMI 3.0 explicitly states that modelDescription.xml must not be changed within an FMU. The rationale is consistency with binary or source-code implementations. A translator may think changing only a description field is harmless because the model still executes in a local test. That result does not overrule the package contract. A test might not explore a tool’s validation behavior, documentation assumptions or compatibility checks. The correct approach for an already distributed FMU is to leave it intact.

An exporter can of course produce a new model release, with the responsible model owner controlling the accompanying XML and implementation. That is a software release, not an offline translation-only operation. If a model vendor wants multilingual descriptions embedded in shipped artifacts, it should do so at the export/source level under its own verification process and release a new authenticated FMU. A third-party writer should not create a superficially identical binary by modifying archive contents and presenting it as vendor-approved.

For a quick translation project, build a companion language file. A viewer can look up a variable’s help text using a stable, verified mapping, while the simulator opens the original FMU. This avoids a conflict between accessibility and scientific reproducibility. The new documentation can be tested, corrected and rolled back without rebuilding or modifying a model that might participate in a larger co-simulation system.

Inventory every variable with its context

A variable inventory should capture the declared name, value reference, type, unit information, causality, variability, any declared type, description and version of the FMU. Where the specification allows arrays, structural information and dimensions also matter. Two variables may both have the short source description “pressure” yet refer to different compartments, absolute versus relative pressure, or input versus output. Do not let a translation-memory tool merge them simply because the English string matches.

Use a clear row key such as FMU checksum plus variable name and type, retaining the value reference as a verification attribute. One identifier alone may not be sufficient across model versions or different FMUs. valueReference=7 is not a global identity; another FMU may legitimately use the same number for an unrelated variable. A localized glossary should therefore be scoped to the exact source artifact or an explicitly certified compatibility family.

Read the model’s own documentation to understand quantities and signs. A negative torque, for example, can mean braking or reverse rotation depending on the coordinate convention. Translating “load torque” as “motor torque” could invert the physical interpretation. If the XML description is too vague to distinguish them, ask the model developer for a definition. A translator should never fill the gap with a plausible engineering assumption and let a student learn the wrong physics.

Separate model identity, variable identity and displayed label

A model might be called HeatExchanger.TestBench while a presentation layer shows a natural-language title such as “Heat-exchanger training model.” These serve different audiences. The model name may be used for identification and tool interoperability; the displayed title helps users find it. A multilingual UI can store a translated title in an external catalogue while continuing to load the same FMU. The title must not be used as a substitute for the exact file and model identity in logs or test reports.

Variable identity deserves similar care. A label shown in the interface may include units, subsystem name and a short explanation. For example, display “Coolant inlet temperature (K)” while retaining inletTemp as the machine key. In a secondary note, explain why Kelvin is used and when a chart may optionally display Celsius. That is a better learning experience than hiding the original variable name, because it allows users to read scientific publications, compare solver logs and troubleshoot with developers.

Where two variables have nearly identical labels, add contextual qualifiers to the translated display. T_in_primary and T_in_secondary may be distinct inlet temperatures in two loops. If both appear simply as “inlet temperature,” an operator could connect the wrong signals. The localization team should not invent context; it should ask for the physical diagram or authoritative documentation and then apply consistent naming. Concise explanations become safer when they carry the distinctions that matter for connections.

Units are a hard boundary between words and numbers

FMI distinguishes unit definitions and display-unit relationships. A unit can be defined using SI base dimensions, and a display unit may provide an appropriate conversion. Units are not just annotations a translator may restyle freely. They control how an importing tool understands numeric quantities, and an invalid conversion can corrupt a simulation while leaving the prose grammatically perfect. A translation should describe the unit faithfully and never alter the unit definition or conversion factors as a side effect.

Consider a pressure input shown as 250000 Pa. A local audience may prefer kPa, but the number 250000 cannot simply be relabeled “250000 kPa.” The presentation layer must convert it to 250 kPa with the correct factor, if conversion is allowed and verified. Translators should not take responsibility for numerical conversions without a technical reviewer. The safer minimal deliverable is to retain the original unit in the localized sentence, even if it requires a short explanatory gloss.

Temperature introduces an additional complication because offsets matter. A description of a temperature difference should not be confused with an absolute temperature, and the conversion from Kelvin to Celsius behaves differently for absolute values versus differences. FMI’s unit semantics and the variable’s relativeQuantity interpretation matter here. The translator’s job is to preserve the physical quantity, not to guess a conversion from a casual example in a national textbook. A cross-language review should include numerical test cases for such fields.

Causality and variability must survive every explanation

The same engineering term can be used for a measured output, a controllable input or a fixed parameter. A technician who confuses them may attempt to set an output or read a value that is not meaningful before initialization. A localized description should reveal the variable’s practical role without altering the model metadata. “Desired outlet temperature” and “measured outlet temperature” are not synonyms even if both appear near the same pipe in a diagram.

Variability adds another layer. A parameter may be fixed, tunable under permitted conditions or subject to timing constraints. A translated note that says “change at any time” is dangerous when the model requires initialization or a particular simulation mode. Read the standard’s definitions and the model author’s usage notes; demonstrate a safe workflow with an approved importer in a controlled environment. A one-sentence description should not make promises broader than the interface allows.

When in doubt, separate the definition from the instruction. The external help file can include a short label, a technical description and a verified operator note with its own source citation. That prevents a translator from inserting an action instruction into a neutral source description just to make it seem useful. If the model developer has not documented when a value may be changed, flag the gap rather than approving an untested operational recommendation.

Use a companion map rather than a modified archive

An external JSON file can link model-specific keys to localized descriptions. The following teaching example is not part of the FMI schema, and the standard does not define this JSON mapping. It is an application-owned help overlay that a separate reader might load. A robust implementation should bind to the original FMU checksum or signed release identifier, use a documented field-mapping key, and reject mismatches. Never write this file back into the FMU ZIP while claiming that the original package is unchanged.

{
  "format": "example-fmu-help-overlay-v1",
  "language": "fr",
  "model_name": "HeatExchanger.TestBench",
  "source_sha256": "REPLACE_WITH_VERIFIED_FMU_DIGEST",
  "variables": {
    "inletTemp": {
      "label": "Température du fluide à l'entrée",
      "description": "Température du fluide de refroidissement à l'entrée, exprimée en kelvins."
    }
  }
}

A preview tool can parse this overlay and show translated text while maintaining access to the original variable name and units. It must not treat the example digest placeholder as a real integrity value. The full implementation should check model identity, expected variable type and perhaps value reference against the FMU before displaying a translation. Otherwise a cached overlay from a related model could attach the wrong physical meaning to a signal after a vendor update.

The map should include editorial metadata outside the per-variable content, such as target locale, translator, technical reviewer, reviewed source revision and date of approval. These fields do not make the translation scientifically correct, but they make mistakes traceable. A teaching interface can show a source-language toggle to help learners compare the original description and the new explanation. That transparency is often useful when engineers collaborate across languages and need to discuss a value using the exact model identifier.

Validate the package without executing untrusted code

An FMU can contain native binaries, so treat an unknown package as executable software rather than an innocent document. Do not run it merely to look up descriptions. A static check can open the ZIP structure, read modelDescription.xml and compute a checksum without extracting arbitrary paths or loading binaries. An XML parser can then collect names and descriptive fields. This is a valuable first stage, but it is not an assertion that the model is safe to execute or that it conforms to every FMI rule.

# Static illustration: reads an FMU archive without executing its binaries.
from pathlib import Path
from hashlib import sha256
from zipfile import ZipFile
import xml.etree.ElementTree as ET

fmu_path = Path("reference-model.fmu")
raw = fmu_path.read_bytes()
package_digest = sha256(raw).hexdigest()
with ZipFile(fmu_path) as archive:
    model_xml = archive.read("modelDescription.xml")
root = ET.fromstring(model_xml)
model_name = root.attrib.get("modelName")
variables = root.find("ModelVariables")
for var in list(variables) if variables is not None else []:
    print(var.tag, var.attrib.get("name"), var.attrib.get("description", ""))
print("FMU SHA-256:", package_digest, "model:", model_name)

This code illustrates archive access and XML parsing, not complete FMI conformance or security assessment. A hostile ZIP may be very large or structured to exhaust memory, and the snippet does not impose archive-size limits or validate the XML schema. A production pipeline should reject unexpectedly large files, avoid path extraction, use a hardened parser, inspect package provenance and run independent validators. The static inventory can support translation review without granting code execution, which is an important safeguard when accepting models from outside an institution.

A checksum comparison should occur before and after the documentation release. Because the overlay is separate, the FMU digest should remain exactly identical. If it does not, stop and find why. A packaging tool might have rewritten ZIP metadata or compressed files differently even if extracted contents appear similar. Under the no-repack policy, such a change is unnecessary and should be treated as an artifact-integrity failure rather than dismissed as cosmetic.

Review signs, coordinate systems and reference directions

Engineering models often use signed quantities with reference directions. A positive heat flow, for example, may be defined as flow into a component or out of it. The same English word “power” could mean mechanical shaft power or thermal transfer, and each carries different sign expectations. A translated label that drops “into” or “from” can reverse an operator’s understanding. Compare the variable definition with a physical schematic or a documented interface contract before approving the term.

A model with a rotating shaft might expose angular velocity in radians per second and a torque in newton-metres. A novice could infer that positive torque always increases speed, but coupling, reference frames and friction terms can complicate the relationship. The translation should not promise a mechanical effect merely because the variable is named torque. Explain the measurable quantity and the declared sign convention, then direct learners to the experiment for causal behavior. Clarity is not the same as replacing engineering nuance with an easy slogan.

In multiphysics co-simulation, inconsistent descriptions can propagate beyond one FMU. A control-system model may connect an output from one component to an input of another. If labels suggest incompatible units or reversed directions, users can create a plausible but incorrect coupling. Pair every translated interface term with the original variable name, units and a tested connection example. The purpose of the language layer is to reduce wiring mistakes, not to encourage interpretation without technical evidence.

Handle arrays, structures and named clocks carefully

Modern FMI 3.0 includes features such as arrays and clocks. A simple one-row-per-variable spreadsheet may not communicate all relevant dimensions, indexes or timing semantics. A variable that represents a vector of sensor readings needs an explanation of what each position means and whether the array shape is fixed or dependent on other dimensions. The translator must not rewrite dimension expressions or infer a different indexing convention because the target audience commonly starts counting from one.

Clocked behavior can also affect what it means to sample or update a variable. A description that merely says “every second” may be wrong if timing is driven by events or a scheduled execution partition. The localization reviewer should understand whether the source specifies time units, event intervals, or clock activation. If the model requires a specialist explanation, provide it as a separate reviewed note and avoid claiming that the original FMI description itself guarantees a particular schedule.

A robust overlay may have more than one level of detail. The short label fits a graph legend; a paragraph explains the variable’s physical meaning; a technical note covers sampling and constraints; and a reference links to the model’s approved documentation. These layers are separate human-facing aids. None requires changing the FMU model structure, and each can be revised independently when a user reports ambiguity.

Test a real operator or learner task

Prepare a small task using a known FMU in a sandboxed simulation environment. Ask a reader in the target language to identify the inlet and outlet temperatures, choose a correct display unit, and predict whether a selected variable can be set or only observed. Observe whether the overlay and original identifiers make the right action easy. Do not give hints while the reader is deciding, because that hides ambiguity in the translated material.

Compare the reader’s answer with a reference prepared by the model owner. A correct result needs more than the right variable label; it must preserve the physical role, unit and permitted operation. If a user chooses a correct variable but a wrong unit, note the distinction. The remedy might be a better unit label, an explanation of an offset conversion or a safer visual grouping. If the user misunderstands causality, the help should explicitly identify the source’s input/output classification.

Run numerical equivalence testing only in an authorized software environment with known safe models. The localization overlay should not change simulation values because it does not touch the FMU, but an application may accidentally feed converted display numbers back into an input. Test that separation. A dashboard that renders Celsius but sends the Celsius number as Kelvin is a presentation-to-control bug, not a translation syntax failure. The user-facing review must consider that integration boundary.

Diagnose a successful parse with the wrong physical meaning

Suppose a localized help panel calls flowRate “litres per minute”, while the source declaration and approved documentation specify kilograms per second. The JSON overlay parses and the interface renders without errors. Yet an engineer reading the label could calculate pipe capacity incorrectly. Inspect the quantity definition, unit attribute, conversion mapping and source documents. Repair the description to state mass flow in the correct unit, then retest with a reference value. Parser success cannot establish scientific equivalence.

Another failure arises when a reused translation maps tempIn to a different FMU revision in which the same name refers to another subsystem. A global string key is insufficient. Require the source digest and model identity to match, and optionally the declared type and value reference. If those fields disagree, show untranslated source help with a warning rather than silently applying the old caption. Fallback to the canonical text is safer than a confident but wrong label.

A third failure is a dangerously natural verb. An English source says a parameter is “fixed during simulation”; a local phrasing implies it can be changed while running. The test reviewer tries to update it and the importer rejects the operation, or the model enters an unexpected state. Repair the translated instruction using the exact permitted lifecycle, and document any importer-specific limitation separately. Language QA must check what an instruction leads a person to do, not only how the sentence sounds.

Changed-context exercise: a battery thermal model

An educator previously translated a heat-exchanger overlay. A new battery model exposes cellTemp, ambientTemp, maxChargeCurrent, and heatFluxOut. The UI team copies the old translation for “temperature,” converts every Kelvin number to Celsius in its display and wants to repack the FMU with translated descriptions to simplify distribution. The original package uses a fixed checksum in the school’s experiment repository. Identify the steps that can proceed quickly and the changes that must be stopped.

The correct approach is to keep the battery FMU byte-identical, compute or confirm its digest, and make a new external overlay scoped to that exact model and version. Translate the temperature explanations with explicit reference to cell versus ambient values. Verify any Kelvin-to-Celsius display conversion at the UI layer, including absolute temperatures and any differences. Preserve the original identifiers and the current limit’s declared unit. Explain heatFluxOut according to the source sign convention rather than assuming that “out” always means heat lost to the surrounding air.

Repacking must stop because it would modify the distributed FMU and breach the model-description consistency rule. The educational interface can instead bundle the original FMU and a separately identified documentation resource without modifying the FMU archive. A sandbox test should check that the same input values reach the model regardless of language selection, and that the user’s understanding of units and sign is correct. This exercise shows that a fast translation can be a valuable scientific teaching layer precisely because it is not allowed to alter the experiment.

Practical review checklist

  • Verify the source FMU, publisher, FMI release, version and SHA-256 digest.
  • Read modelDescription.xml statically and avoid executing untrusted binaries.
  • Inventory variable names, types, value references, units, causality and descriptions.
  • Keep the FMU and modelDescription.xml unchanged; use an external language overlay.
  • Scope each overlay to a verified model artifact and document its target locale.
  • Preserve physical sign conventions, units, reference directions and time semantics.
  • Separate translated labels from numerical conversions and execution controls.
  • Validate JSON/XML parsing and mapping completeness; use official FMI tooling where available.
  • Test comprehension and safe UI behavior in an approved nonproduction environment.
  • Keep source and target review evidence, specialist sign-off and rollback instructions.

Limits and responsible claims

FMI defines interoperability mechanisms, but it does not provide a universal standard for arbitrary third-party multilingual overlay files. The JSON format shown here is an example owned by an application, not a field defined by FMI. A real implementation must document its mapping and verify it against each exact model release. The guide is also not a certification of model accuracy, numerical solver results, FMU security or compliance with every FMI XSD rule. Those require independent model and software validation.

A simulation used in an educational lesson may be low stakes, but identical translation mistakes can become important in industrial planning, energy systems or control testing. Strong claims about units, safety limits or physical behavior require source evidence and qualified review. The safest wording is the wording a reader can verify against the model and its documentation. A translator can make that evidence accessible without assuming responsibility for designing or approving the underlying system.

The useful principle is simple: translate the explanation that surrounds the simulator, not the simulator’s identity or executable contract. When the FMU remains fixed, teams can collaborate across languages, compare the same numerical traces and correct unclear descriptions without destabilizing an engineering artifact. The time saved by a controlled overlay should be invested in the few definitions whose meaning could change an experiment’s conclusion.

Design a bilingual glossary that survives technical handoffs

The glossary should connect each approved display term to the original identifier, physical quantity, unit and responsible source. When an engineer reports a defect using pressureDrop, a translator should be able to locate the corresponding target-language label without searching manually through dozens of dashboards. A useful entry records why the chosen translation distinguishes a pressure loss from an absolute pressure reading. It may also record a rejected alternative and the reason for rejecting it. These explanations reduce repeated debate when staff members change and help reviewers avoid the temptation to translate according to sound alone.

An engineering handoff may cross three vocabularies: the naming convention of the model author, the terminology used by an importing simulation tool and the words taught to students. Each can be legitimate in its context. Do not force all three into one supposedly universal term. Instead show the original FMU variable name, an approved locale-specific label and a brief operational definition. For example, a user-facing chart can have a natural Chinese title while a diagnostic pane preserves the exact ASCII variable name needed to search logs. Consistency is achieved through a documented mapping, not by pretending technical languages never use different names.

Keep a record of abbreviations and dimensions, too. The letters rpm represent a familiar rotational speed unit but may be confused with radians per second in a hurried translation. deltaT may mean a temperature difference or a time step depending on the model. A glossary that maps the spelling without the physical quantity is incomplete. The reviewer should inspect the declared unit and accompanying calculations, identify the specific quantity, and write an explanatory sentence that a student can test against a numerical example. This is especially important where the language of the classroom and the language of the software differ.

Recover gracefully when coverage is incomplete

A localization overlay does not need to invent text for every variable on its first release. A safe renderer can show the original description for unmapped variables, mark it as source-language material and provide a way to request a reviewed translation. If a model update removes or adds variables, the overlay loader should report orphaned entries and missing entries separately. An orphaned translation must not be automatically attached to the nearest similarly named variable, even if a fuzzy-match algorithm assigns it a high score. A slight naming difference can reflect a genuine change of subsystem, units or lifecycle.

Rollback should be independent of the numerical model. Store the previous approved overlay, its checksum and the exact model artifact it matched. If a localization defect is discovered, the application can switch back to source descriptions or to the previous reviewed bundle while continuing to use the same original FMU. Record which users were exposed to the misleading guidance if the change could have affected experiments. In a school setting, the follow-up might be correcting a worksheet; in a regulated engineering setting, it may require a formal impact review. The language layer must not obscure the seriousness of a semantic error.

The workflow also needs a clear escalation path for translation disputes. A bilingual editor can decide whether a phrase sounds natural, but a model author or qualified engineer must determine what the signal physically represents. When two reviewers disagree about a term, ask which measurable behavior would distinguish the readings, locate evidence in the model documentation and test only with approved fixtures. An unresolved issue should be marked plainly, with the source term retained. Speed comes from resolving high-risk ambiguity early instead of polishing a misleading translation repeatedly.

Consider accessibility and teaching transfer

A dashboard label is not the only place a learner encounters a variable. It may appear in a chart legend, an audio description, a keyboard-navigable data table and an exported lesson report. A long natural-language translation can be excellent in an explanatory panel yet impractical in a narrow plotting legend. The overlay may therefore provide a short display label and a longer definition as separate reviewed strings. Both must map to the same underlying variable, and neither should alter what the numerical data represents. Testing should include zoom, screen readers and mobile displays, not only a desktop engineering workstation.

When teaching model interpretation, ask learners to move between language and symbols in both directions. Show a translated description and ask them to find its variable in the original model inventory; then show the technical name and ask them to explain its physical meaning and unit in their own words. This is a stronger test than memorizing translated labels. It demonstrates that the translation supports scientific reasoning and collaboration across documentation sources. The goal is for learners to interpret models correctly even when future software uses the original technical identifiers.

Frequently asked questions

1. May I directly edit modelDescription.xml inside a downloaded FMU to translate descriptions?

No. The FMI specification states that the packaged model description must not be changed because it must remain consistent with the implementation. Create an external help layer or ask the model owner for a properly generated new release.

2. Is the translated JSON overlay part of FMI 3.0.2?

No. It is an illustrative application-defined companion file. FMI does not standardize the example mapping or require any importer to understand it.

3. Why include both name and value reference in the inventory?

Names support human mapping, while value references participate in the model interface. Comparing several attributes against the exact model helps catch an overlay attached to a different version.

4. Can I translate unit symbols such as K and Pa?

Do not change the model’s unit identifiers. Explain symbols in the reader’s language and perform any numerical display conversion separately with verified factors and offsets.

5. Is a static ZIP/XML parse enough to certify an FMU?

No. It is only an initial inventory and syntax stage. FMI conformance, runtime behavior, numerical accuracy and the safety of executable components require separate tooling and review.

6. What if a source description is ambiguous?

Ask the model provider or domain specialist for clarification. Mark the translation as unresolved rather than inventing a confident engineering meaning.

7. Does an external overlay have to be translated for every variable?

No. It can use explicit fallback to the verified source text for missing entries. Show users that the language coverage is incomplete so they do not assume an unreviewed field is localized.

8. What should happen if the FMU digest changes?

Fail the mapping check and require review against the new artifact. Even if variable names seem identical, their units or behavior may have changed.

9. Why is the difference between an input and an output part of language QA?

The translated instruction influences what a user tries to set or observe. Confusing the role can produce errors or unsafe assumptions despite grammatically correct wording.

10. Can a school distribute an FMU together with translated teaching notes?

Yes, subject to the FMU’s licensing and distribution terms, a school can usually keep a model artifact distinct from its own explanatory document. Check the actual license and avoid implying the notes are an official model-author release.

Authoritative sources and further learning

Relevant verified eduKateSG reading