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 | 3MF Core Translation QA: Localize 3D Model Metadata Without Changing the Print Job

—

by

eduKate Asia

How People Translate Quickly | 3MF Core Translation QA: Localize 3D Model Metadata Without Changing the Print Job

To translate a 3MF model quickly, edit only the approved human-readable metadata and display labels, such as a descriptive Title or Description, while protecting the XML model structure, resource identifiers, geometry, unit declarations, materials and build instructions. Keep vendor-specific metadata under its documented contract and do not convert manufacturing measurements simply because a target language uses different everyday units. A 3D model is a manufacturing instruction package, not a word-processing file: translation must not alter what the printer is asked to make.

This article explains a practical translation QA process for the 3D Manufacturing Format, or 3MF, with emphasis on the Core specification’s metadata and package relationships. It serves educators, engineering teams, designers and translators who need model titles or explanatory notes in another language while retaining a reliable printable object. The reader job is narrow but important: someone opening the translated package should understand what the model is, who designed it and what the usage cautions mean, without accidentally receiving a different shape, scale or print configuration.

The 3MF Consortium publishes the 3MF specification suite, including Core 1.3.0; the format was also recognized in ISO/IEC 25422:2025. A 3MF document is an Open Packaging Conventions-based ZIP package containing XML model data and related parts. The Core model can carry well-known metadata names such as Title, Description, Designer, Copyright, LicenseTerms, Application and dates. These metadata names are not free-form translatable tags; the text values require classification. The examples below illustrate metadata preservation and XML syntax but are not a substitute for a full 3MF package conformance test or a safe manufacturing review.

Define the job: readers understand the model, machines make the same object

Imagine a school designs a small tactile geometry aid and shares its 3MF file with teachers in several countries. The English metadata calls it a “Tactile triangular pyramid for classroom demonstration.” A translator wants to provide a natural Malay or Mandarin description. That helps teachers choose a suitable file, but it should not change the pyramid’s edge lengths, printable orientation or material assignments. The translated title is a human cue; the XML geometry is a technical commitment.

Write an acceptance statement that includes both audiences. Teachers should understand the model’s educational purpose and any safety or printing cautions. The slicer and printer should see the same build objects, units, vertices, triangle connectivity and required extensions. If the translated description says the model is 10 centimetres tall when its geometry is only 10 millimetres, the human interpretation is wrong even if the model file opens successfully. If the XML unit changes, the actual manufacturing job may become wrong.

A good translation workflow begins by extracting a controlled set of metadata values and protecting the rest of the archive. The source package should remain immutable during review. The release should include a structural comparison, a content review by someone who understands the object and a preview in the intended 3MF consumers. Do not judge success solely because the ZIP opens or a preview image appears; those checks may miss changed dimensions or material metadata.

Understand the 3MF ZIP package before editing

3MF is not just a single XML document renamed with a .3mf extension. It uses packaging conventions with relationship parts and a primary 3D model part. The ZIP container may also carry thumbnails, textures, materials, custom parts and print settings depending on extensions and application behavior. A casual unzip-edit-rezip action can inadvertently remove relationship files, change internal paths or break the package even when the edited model XML looks well formed.

Inspect the package inventory and record its actual parts. Identify the 3D Model part from relationships rather than assuming every application stores it at a hardcoded path. Note thumbnails and any required extension declarations. Record the exact files and their hashes before translation. If a translator needs only the root model’s Title, there is generally no reason to rewrite texture bytes or machine-oriented settings. Minimize the edit surface to reduce the number of possible failures.

A valid production test must re-open the assembled package using a parser or slicer that supports the relevant 3MF version and extensions. Some viewers ignore optional unsupported information, while required extensions demand appropriate handling. A consumer that silently drops important metadata may cause a later save to lose it. Keep the original archived and examine the model after round-tripping through the actual software used by teachers or engineers.

Read the model’s resources and build separately

A 3MF Core model contains resource definitions and build instructions. Resources can describe objects, materials and other ingredients of the geometry. The build section identifies items to manufacture, often referencing objects by resource ID and optionally applying transformations. Translating an object description must not change which resources are actually included in a build. A preview may display all resource objects even when the print job contains only selected items.

Suppose a design file has two alternative classroom shapes, but only one appears in the build. A translator sees both resources and assumes both should print, then adds a second build item. That is not localization; it is an unauthorized manufacturing change. Resource IDs and objectid references are machine contracts. Preserve them exactly unless a design engineer performs a versioned model revision with its own test and approval.

Build a baseline report containing resource counts, resource ID sets, build item references and transforms. Run the same report after metadata localization. Unexpected differences should block the release until explained. Compare previewed bounding boxes and volume where the toolchain can compute them. These checks are more meaningful than a visual thumbnail alone, particularly for small educational shapes whose proportions can look similar at different scales.

Recognize human-readable metadata names and values

The Core specification defines well-known metadata names associated with the model, including Title, Designer, Description, Copyright, LicenseTerms, Rating, CreationDate, ModificationDate and Application. The name attribute classifies the metadata entry. Its standardized spelling is not a sentence to translate. The text content may be descriptive or may represent an exact name, date or rights notice whose treatment is more constrained.

For example, the value inside <metadata name="Description"> may describe a geometry aid and be a candidate for translation. The value of Application identifies the source software, so it should not be reinvented as the target-language phrase for “application.” CreationDate and ModificationDate carry machine-relevant dates; changing their format inside the model may break expectations. The Designer value may be a person’s established professional name rather than ordinary prose.

Use a field classification table in the localization brief. Label each field as editable descriptive prose, official proper name, legal statement, typed value or technical metadata. Provide translators only the values they are authorized to change, along with the model’s intended use and physical dimensions. A reviewer should still see the protected fields in context. Without that context, a translator may make a plausible but harmful claim about a model’s material, ownership or printability.

A compact model XML fixture

The following is an illustrative model-part XML example showing a small tetrahedral object. It includes a human-readable title and description together with a resource and build instruction. A complete .3mf file also requires the appropriate packaging parts and relationships; this fragment alone is not a distributable 3MF document. The geometry is synthetic and must not be treated as a validated manufacturing file for a particular printer.

<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="http://schemas.microsoft.com/3dmanufacturing/core/2015/02"
       unit="millimeter" xml:lang="en-US">
  <metadata name="Title">Classroom tetrahedron</metadata>
  <metadata name="Description">Demonstration shape; check size before printing.</metadata>
  <resources>
    <object id="1" type="model">
      <mesh>
        <vertices>
          <vertex x="0" y="0" z="0"/>
          <vertex x="10" y="0" z="0"/>
          <vertex x="0" y="10" z="0"/>
          <vertex x="0" y="0" z="10"/>
        </vertices>
        <triangles>
          <triangle v1="0" v2="2" v3="1"/>
          <triangle v1="0" v2="1" v3="3"/>
          <triangle v1="1" v2="2" v3="3"/>
          <triangle v1="2" v2="0" v3="3"/>
        </triangles>
      </mesh>
    </object>
  </resources>
  <build><item objectid="1"/></build>
</model>

The translation team can produce a reviewed alternate description for its chosen distribution workflow. It must not translate metadata, Title, Description, resources, object, mesh, vertex, triangle, build or objectid as though they were labels. The attributes express a defined XML structure. The integer vertex indices identify geometry connectivity. Keep those values fixed while changing only approved text content and any deliberately governed language metadata.

A parser can confirm well-formed XML, and a 3MF-aware tool can check whether the model conforms to the selected specification and packaging rules. A structural checksum comparison can reveal changes outside metadata. But no parser can guarantee that the sentence “check size before printing” survives translation as an appropriately cautious instruction. A human reviewer must verify the wording against the actual object and intended printing conditions.

Handle xml:lang with clear scope and tested consumer behavior

The Core model can carry an xml:lang language declaration, as illustrated by official examples. That declaration is technical metadata about language, not a place to store a translated sentence. If a target-language model version is deliberately produced, its language declaration should be reviewed against the actual language of its textual metadata and the publishing system’s conventions. Do not change it merely because a designer’s name contains foreign letters.

A difficult case arises when one package must be discoverable in more than one language. The Core’s ordinary Title and Description entries are not automatically an unrestricted language-map structure. Adding repeated well-known metadata entries with the same name is not a safe shortcut: the specification prohibits producers from creating multiple metadata elements with the same name. A custom multilingual solution needs a documented namespace or external catalogue and confirmed support in the target software.

Test actual consumers before defining a language strategy. One slicer may show only the first title; another may ignore vendor-defined localized properties; a repository may use external descriptions instead. Keeping one stable package with multilingual landing-page text can be more interoperable than embedding unsupported repeated fields. Whatever approach is chosen, explain where translations live and what the consumer will display if a requested language is missing.

Keep model units immutable during translation

The unit attribute is essential to physical scale. A target language may prefer describing dimensions in centimetres or inches, but the model geometry remains numeric data in its specified model unit. Changing millimeter to a translated word will not produce a valid alternate unit; changing it to an actual different unit without transforming coordinates changes the physical size of the object. This can make a classroom piece unusable or create a manufacturing risk.

Imagine a description that says “10 mm demonstration pyramid.” A translator can explain 10 millimetres in the target language, perhaps adding a correctly calculated approximate equivalent for the audience. But the stored coordinates and unit should remain unchanged. If a teacher requests a larger model, that is a design or slicing adjustment with safety checks, not a translation decision. The translated description should not promise a size that the file does not deliver.

Compare the effective dimensions in the same engineering units before and after localization. Document the original unit and bounding box in the QA report. If a slicer applies additional scale settings, distinguish those from the 3MF model itself. A good test shows that the model’s physical interpretation remains stable, even when a human-facing page uses localized unit names or a region-specific display convention.

Protect vertex coordinates and triangle connectivity

Mesh vertices and triangle indices are the geometry of the printable object. They are not editable prose. A translator or generic XML substitution tool that changes decimal separators, minus signs or list order may corrupt shape geometry or create non-manifold surfaces. The XML may remain well formed while the model becomes invalid or physically different. This is a strong reason to extract text fields rather than run global search and replace across the model XML.

In the tetrahedron example, the vertex coordinates and triangle indices define a small closed surface. Translating the word “triangle” in the XML tag would break the model vocabulary. Altering v1, v2 and v3 values would modify face connectivity. A preview can sometimes mask these problems at a small thumbnail scale. The acceptance test should compare geometry and run an appropriate model validation in addition to checking XML syntax.

A conservative localization tool can preserve an XML subtree containing geometry byte-for-byte and serialize only approved metadata values. If the serialization changes whitespace or attribute order, normalize the comparison at the structural level rather than relying solely on raw hashes. Track whether any geometric number changed; if so, block the localization release and investigate. Engineering revisions must have separate ownership and version control.

Keep resource IDs, material references and build items exact

Resource identifiers link model objects, materials and potentially extension-defined properties. A build item often uses an objectid reference to decide which resource to manufacture. Translating a name into another language should not change the corresponding numeric identifier. If an ID is altered in one place but not another, the print job may reference the wrong object or fail to resolve its resource entirely.

Material and color definitions are also more complicated than their descriptive labels. A name such as “Green” may appear as an application-visible label, while color values and property references are technical data. Replacing a color code with the target-language word for a color would be a category error. A classroom model meant to distinguish two geometric regions could lose its visual contrast if materials were changed accidentally during translation.

Use a structural comparison of resources, property groups and build references. Confirm that the same object count and selected items survive. Where the project uses extensions, test those with a compatible consumer. If a material label is genuinely localizable under a particular extension, translate it through that extension’s supported mechanism rather than assuming all text-looking attributes are unrestricted. Physical output is governed by references, not by a translated caption.

Treat vendor metadata as a contract that must be discovered

3MF supports vendor-defined metadata in declared XML namespaces. Such metadata may contain human-readable notes, machine configuration, internal part numbers or proprietary instructions. Its namespace and local names are not automatically safe to modify. A translator should identify the owning application or extension and request its documented interpretation. If no specification is available, the conservative choice is to preserve the value and seek an engineering decision.

For example, a property whose value resembles “support level high” could be a UI label or a machine setting. Translating the word “high” might accidentally change a programmatic enum. Another value might be a serialized identifier rather than prose. Review the actual schema and examples, and test round-tripping in the software that created the 3MF. Do not infer semantics solely from a readable string; human legibility does not imply translation permission.

The Core metadata element also has a preserve attribute that signals an intent to keep values during editing. Treat this as a compatibility concern, not a blanket authorization to modify everything not so marked. Keep a change record for any vendor metadata translations and confirm that the intended consumer displays the translated value. If the software drops unknown extension data on save, avoid using it as the only storage for critical multilingual information.

Keep rights statements and designer identity accurate

3MF metadata can include copyright, license terms and designer information. These fields may carry legal or identity significance. Do not replace a copyright holder’s name with a guessed local equivalent or turn “educational use only” into “free for commercial production.” The distribution rights of a model may also depend on external documents, patents or embedded asset licences that a short metadata field cannot fully explain.

A school sharing a tactile geometry aid may want foreign teachers to understand whether printing copies for students is allowed. A translated rights summary can be helpful, but the authoritative licence and any specific restrictions must remain available. If there is an official translation of a licence, refer to it instead of composing new legal terms without review. Avoid translating the Copyright metadata name or altering dates and owner names during a prose-edit pass.

Separate plain-language guidance from legally operative text. A reviewer should compare permissions, attribution requirements and restrictions across languages. If metadata describes a third-party logo or a purchased design component, clarify whether that component has separate rights. A successfully printable 3MF model is not necessarily freely redistributable; translation should make that distinction clearer rather than bury it.

Protect creation and modification dates

The Core metadata’s creation and modification date values describe the history of the source document, not the time of translation in every case. A localization pass should not quietly reset them to today or change their syntax into a human-friendly date phrase. The reader may need to know whether they are using an old model revision even when the localized description was updated recently. Confusing these dates can conceal engineering changes or create inaccurate provenance.

Keep a separate localization revision timestamp in the publishing workflow if needed. That can tell readers when the translated explanation was reviewed without implying that the 3D geometry was created or modified on the same day. If the engineering team actually changes the model, follow its version and date procedures; a translation should not substitute for design release records. Traceability becomes especially valuable when multiple schools exchange files and adapt them over time.

Compare the approved source metadata against the new package. Flag any unplanned changes to CreationDate, ModificationDate, Application or designer fields. If the translation tool reserializes or updates them automatically, adjust the pipeline or document the change with the owner. Do not claim that a metadata date has no meaning simply because the model visually appears unchanged. Human and machine provenance both matter in reusable educational resources.

Translate safety cautions with their actual scope

A short description may include cautions such as “Check size before printing,” “Not suitable for load-bearing use” or “Requires adult supervision.” Such phrases are more important than decorative product names. A translator should preserve prohibitions, conditional wording and who is expected to act. If the source warns that a small printed part may pose a choking hazard, the translation should not soften it into a friendly suggestion. Equally, it should not invent a formal safety certification.

Review cautions with the designer or safety owner. The actual risk may depend on material, print process, sharp edges, intended audience and post-processing. The 3MF Core format alone does not certify that an object is safe for children, food contact or medical use. A translation can make risk communication clearer, but cannot independently authorize those applications. If the source lacks adequate safety guidance, escalate that deficiency instead of filling it with guesswork.

Test the caution as a task. Ask a target-language teacher to explain what must be checked before using the model. Compare that with the English source and the designer’s actual instructions. If the teacher thinks no supervision is required while the source demands it, the translation has changed behavior and must be repaired. Clear warnings are part of functional equivalence even when they live in a human-readable metadata field rather than a technical property.

Separate thumbnail appearance from manufacturing evidence

A 3MF package may contain a thumbnail that helps software and websites preview the object. A thumbnail is useful for human selection but does not prove that the underlying geometry or print instructions are correct. A screenshot may show a green cube while the build references a different resource, or the model may be too small to see defects at thumbnail resolution. Translation QA should inspect the model data and build output, not merely approve a picture.

If a thumbnail includes text baked into an image, it might require separate localization. That is a media-editing task and may change an actual package part. Do not overwrite the thumbnail without checking the package relationship, image dimensions and any rights restrictions. The text in a thumbnail should agree with the localized metadata but should not be treated as a substitute for accessible text. A repository may display the thumbnail at small size where words are unreadable.

Verify that the thumbnail points to the intended asset and that no unrelated imagery has replaced it. Also inspect a real slicer preview, including dimensions and orientation. A translated title may say “pyramid,” while the thumbnail could be an old cube; that mismatch is an editorial warning requiring investigation. Use separate checks for descriptive truth, relationship integrity and print geometry to identify the source of the conflict.

Consider localization outside the 3MF when interoperability is limited

A manufacturing package is often exchanged across vendors, and those vendors may support different subsets of metadata. If an application reliably displays only the original Title and ignores custom language variants, an external multilingual catalogue keyed to a stable package identity may serve readers better. This can live in a repository listing, education resource page or accompanying release note. It must still point to the exact same 3MF download.

The external catalogue approach has trade-offs. A user who saves the 3MF file offline may not receive the translated context. A package containing translated documentation can be more portable, but adding files requires manifest and relationship decisions, plus testing. Choose the strategy based on actual distribution needs. Do not smuggle language variants into repeated well-known metadata names and assume all slicers will understand them.

Document the fallback behavior. If the target-language description is unavailable, show an accurately labelled source-language description rather than a fabricated or outdated translation. A repository can display language-specific titles while keeping the same model package and content identity. If different translations are shipped as separate model packages, verify that their geometry and technical contracts are identical before calling them equivalent editions.

Test a round trip through real editing software

A common release mistake is to make a valid-looking metadata edit and then open and save the model in a slicer that strips unsupported fields or rewrites parts of the package. The change may go unnoticed until a downstream consumer needs the original rights notice or custom extension. Round-trip testing checks more than whether the file opens: it asks what information survives a real workflow.

Save a baseline copy, import the translated package into the chosen software, export it again and compare both the readable metadata and the model structure. Check units, object IDs, resource count, build items and known required extensions. If vendor-specific properties disappear, determine whether the tool was expected to preserve them. Do not treat the absence of a visible warning as proof that data survived intact.

Use a limited set of known tool versions and record the results. A model that passes in one slicer may need additional compatibility work for a school with different equipment. The goal is not to claim universal support but to identify supported combinations and clearly communicate limits. This is especially important if teachers are expected to print independently without an engineer reviewing the final job each time.

Diagnose failures by the layer that changed

When a translated 3MF fails to open, begin with ZIP/package integrity, relationships, XML encoding and schema compliance. If it opens but displays the wrong title, inspect metadata value handling and the consumer’s language behavior. If the printed object is the wrong size, compare unit, coordinates, transforms and slicer settings. If a material disappears, inspect extension support and resource references. Each symptom has a different likely cause; translation text is only one layer.

Use a minimal synthetic model to reproduce a technical failure. Start from a known valid baseline 3MF with one object and a simple description. Change exactly one allowed field and compare the result. If a repository’s uploader modifies the file, record its transformation separately. Avoid debugging on confidential industrial designs where careless sharing could expose intellectual property. A small classroom geometry aid can reveal the pipeline behavior without that risk.

After a repair, rerun geometry, metadata, rights and package checks. Restoring a missing relationship may affect thumbnails; correcting a language field may alter what the slicer displays; regenerating a ZIP may change compression without changing the model. Report which properties were invariant and which changes were intentional. A trustworthy QA process is explicit about what it did not test, including actual printer output when no machine was used.

Transfer exercise: a classroom pyramid becomes a replacement machine bracket

A school shares a tactile pyramid. A community workshop later adapts the workflow to a replacement bracket. The English model description says “Prototype bracket for fit testing only; not load-rated.” An enthusiastic translator changes the target-language version to “Certified strong replacement bracket for immediate installation.” The 3MF geometry, metadata title and build references are otherwise unchanged. Identify the problem and set a safe release condition for the translated file.

The new wording invents certification, strength and permission for an immediate operational use that the source explicitly denies. A viewer might trust the translated description and install a part that has never been load tested. Restore the prototype and non-load-rated limitations, have the responsible engineer review the target wording and keep the engineering status separate from translation. No language variant may upgrade a prototype into a certified component. If certification is later obtained, that is a new evidence-based design release with its own traceability.

The changed context exposes why the same workflow scales in importance. In a geometry classroom, misleading wording can waste material or confuse a lesson. In a machine bracket, misleading wording can cause physical harm. The invariant rules remain: protect model data, classify metadata, review safety claims and validate consumers. The engineering acceptance criteria become stricter because the intended use has changed, not because a different language itself changes the geometry.

Practical review checklist before distributing translated models

Confirm the source package and its owner. Inventory all ZIP parts, relationships, required extensions and model metadata. Identify which values are approved for translation and which are names, rights statements, typed dates or technical attributes. Record unit, model dimensions, resource IDs, build-item count and file hashes. Keep vendor-specific values unchanged unless their documented contract and application owner authorize a translation.

Check every translated description for physical accuracy, safety qualifications, material claims and reuse permissions. Ensure a title matches the previewed object and that any dimensions reflect the model’s actual units. Preserve copyright and licence meaning; never infer commercial permission from download availability. Confirm that xml:lang and any alternate language strategy are supported by the target consumer. If multilingual descriptions live outside the package, confirm they reference the correct canonical asset.

Run technical validation with the assembled 3MF, not only an isolated XML fragment. Check package relationships, XML syntax, resource/build references and extension requirements. Inspect the object in a compatible slicer and compare geometry and settings with the original. Test an actual print only under the normal safety process and if authorization exists; a QA script cannot certify safe manufacturing. Block release when a translation changes what the file claims to do or when the model changes unexpectedly.

Make translated model descriptions measurable

A useful model description gives a future teacher enough context to select the correct geometry aid without implying that the description itself controls the print. Begin with the model’s actual intended purpose, the source file’s unit, and any limitation that could change a classroom decision. For example, “Tetrahedron demonstration, approximately 10 mm per coordinate axis before slicer scaling” is a more verifiable description than “large triangular solid.” The exact wording will depend on the real object, but the translation should preserve the relationship between descriptive claims and measured geometry.

Review the translated claim against a model report generated independently of the prose. Check bounding dimensions, resource and build identifiers, and the application version that produced the file. A claim that a part fits a specific classroom apparatus must be tested against that apparatus, not accepted because its title includes a familiar product name. If the designer cannot verify a dimension or material recommendation, omit the unsupported claim or label it as a proposal requiring review. Metadata can help users make decisions, but it cannot safely replace inspection of the actual model.

If the file is marketed as a set of multiple objects, verify whether the package contains multiple resources, multiple build items or a single combined mesh. Those distinctions affect what the buyer or teacher receives. A translator who turns “components included for reference” into “three parts printed together” may create a false expectation about the job. Compare the natural-language count with the technical build report and the intended slicer output. This method is particularly important when a 3MF includes spare objects or alternate materials that are not all selected for manufacture.

Verify units and caution wording with a changed display context

Consider a repository that displays measurements in centimetres even though the 3MF model uses millimetres. It is reasonable for a localized webpage to show a correctly computed conversion, but the conversion should be produced from trusted numeric dimensions and labelled as a display convenience. Do not recalculate and overwrite model coordinates merely to synchronize the screen with a local convention. Test boundary cases such as very small objects and rounded values, where excessive rounding can hide a significant difference in fit.

Safety cautions also behave differently in a printed classroom label, a model repository and a mobile download card. A long warning may be truncated on a small screen, leaving only a reassuring first clause. Write the most important restriction early and test every real presentation. For instance, “Prototype only; not load-rated” should not become a tooltip that displays solely the word “prototype” while hiding the critical limitation. The full warning should remain accessible before anyone treats the file as a suitable production part.

Keep a review table for each distribution surface: source 3MF metadata, repository listing, downloadable instructions and slicer preview. Confirm that filenames, purpose, model version, limitations and rights do not contradict one another. If the model geometry is revised, reopen every localized description that mentions dimensions or fit. If only the wording changes, preserve geometry and document that the manufacturing job remains unchanged. This separation makes subsequent releases easier to audit and allows teachers to trust the translated information for the decision it is actually meant to support.

Limits: translation is not manufacturing certification

A structurally valid 3MF package may still contain an unprintable design, unsupported material requirements or a model unsuitable for its intended use. Translation cannot establish mechanical strength, food safety, electrical safety or medical suitability. It does not replace design review, slicer checks, printer qualification or product liability decisions. A human-readable metadata label is evidence of editorial intent, not a safety certificate.

The Core specification allows extensibility, and particular vendor ecosystems can add rich manufacturing settings outside a basic tutorial. Those settings require the corresponding extension standards and software support. A translator should not assert that unknown text is safe merely because the Core specification does not define it. The cautious path is to preserve unclassified values and consult the application owner. Every actual target toolchain needs its own compatibility test.

Finally, multilingual metadata behavior is not guaranteed across all consumers. An external language catalogue can improve discovery but may be unavailable offline; embedded custom properties may be ignored by some slicers. Document the chosen strategy and its trade-offs. The durable principle is consistent identity and physical output across language presentations, with clear disclosure where a display feature is unsupported.

Summary: translate the label, not the geometry

Safe 3MF translation isolates approved descriptive fields from the technical model and package. Keep Core metadata names, resource references, units, vertices, material properties, build items and file relationships unchanged unless an authorized engineering revision requires otherwise. Check the translated description against physical facts and rights, then validate the assembled package in real software. The strongest multilingual file explains the same printable object clearly to more readers while allowing machines to manufacture exactly what the source design intended.

Frequently asked questions

Is a 3MF file simply XML with a different extension?

No. A 3MF document uses ZIP packaging and Open Packaging Conventions relationships, with a primary model part and potentially other assets. Editing one XML part requires preserving the package’s full structure and retesting the assembled file.

Can I translate the metadata name Description?

No. The well-known name attribute values are defined by the Core specification. Translate approved human-readable text content, not the standardized metadata key or XML element names.

Can I add a separate Title entry for each language?

Not by simply duplicating the same well-known metadata name. Core specifies restrictions on duplicate metadata names. Use a documented multilingual extension or separate publishing catalogue that the target software actually supports.

Does changing xml:lang translate the model automatically?

No. It is a language declaration, not a translation engine. Update language metadata only as part of a deliberate language-release strategy and ensure the actual textual values and supported consumers match that declaration.

Why must the model unit stay the same?

The unit determines how numeric geometry is interpreted physically. Changing units without coordinated coordinate conversion changes scale. A human-facing description may use a localized unit name, but model-unit changes require engineering checks and explicit release ownership.

Can I rename objects to make them easier for foreign teachers?

Human-visible labels may be localizable under a defined field or application extension. Resource IDs and objectid references are not display labels and must be preserved. Test the actual slicer’s interpretation before editing any name-like attribute.

What if a slicer opens the model but drops custom metadata on save?

Treat that as a compatibility problem. Compare the round-tripped package against the baseline and determine whether the lost fields matter. Do not rely on unsupported vendor metadata as the only copy of required translation or rights information.

Does a translation review certify a printed part is safe?

No. It checks language accuracy and technical invariants. Manufacturing safety, strength, material suitability and intended-use approval require engineering and safety processes independent of localization.

A plain-language explanation may be useful, but do not alter the rights holder or invent permissions. Retain authoritative terms and obtain appropriate review for legally consequential wording. The visible text should not misrepresent reuse rights.

How should we test one multilingual 3MF across different printers?

Begin with package and geometry checks, then test compatible slicers and relevant extensions for each intended workflow. Record units, material requirements and tool versions. Actual print testing must follow authorized normal safety practice; opening a file successfully is not proof of print equivalence.

Authoritative references and relevant eduKateSG reading