How People Translate Quickly | Apache Arrow Field Metadata: Translate Column Help Without Renaming Data Fields

Translating Apache Arrow schema and field documentation quickly means putting language-specific display labels or explanations in governed application metadata while keeping physical field names, data types, nullability, nested structure and extension semantics unchanged. Apache Arrow’s columnar format supports custom metadata at schema and field levels, but it does not itself promise a universal translation system or an automatic multilingual display convention. Your application must define which metadata keys carry language-specific help and which consumers will read them.

If a dataset contains a column named net_amount, a French user may benefit from an interface label such as ‘Montant net’. Renaming the underlying Arrow field to that label could break queries, joins, transformations and models that expect net_amount. A safer localization keeps net_amount as the technical name, stores an approved translated label under an application-owned metadata key, and has the viewer select the right text at render time. That division preserves interoperability while improving comprehension.

This guide shows how to localize Arrow field metadata with controlled custom keys, validate schema invariants, keep UTF-8 and byte encodings straight, avoid extension-type collisions and diagnose lost labels after conversion or transport. Examples use fictional education and library datasets. A valid Python syntax check is not equivalent to running the example with a particular PyArrow version, and an Arrow IPC round-trip does not certify preservation through unrelated file systems or analytics products.

What a field name does that a translated label cannot

A field name participates in the technical schema that software uses to find columns. Downstream code may select it exactly, map it to a database column or use it as a join key in a transformation. A translated label serves a person reading a table, chart or documentation page. Those purposes are different even when the original English name happens to look like an ordinary phrase. The most reliable localization never asks a display phrase to carry the operational responsibility of a stable data key.

Think of a school finance dashboard that stores paid_amount and approved_amount. Translating these as ‘amount received’ and ‘amount requested’ without checking the source definitions could misrepresent the dataset. The metadata translator needs not only the field name but also the authoritative column description, unit, scope, provenance and calculation rules. The display label can be short; the help text can carry the distinction between a payment already made and an amount authorized but not yet disbursed. Language clarity starts with data semantics, not dictionary substitution.

The narrow reader job here is to add helpful multilingual text around Arrow’s existing schema, not to standardize every organization’s metadata vocabulary. Teams must define their own portable convention or adopt a documented existing contract across their applications. Other tools may ignore unknown custom metadata. That is acceptable if the main schema remains usable and the localized viewer has a tested fallback. It is not acceptable to silently imply that Arrow itself knows which locale to display or guarantees that every consumer preserves custom keys.

The Apache Arrow schema model in plain English

The Arrow columnar format defines a schema as an ordered sequence of fields. Each field has a name, a data type, nullable information and potentially nested child fields. The format also supports dictionary and extension-related metadata in relevant contexts. These properties describe how columns should be interpreted and exchanged by software. An application changing field order, name or type during a translation-only operation may cause code to read the wrong data or reject a table as incompatible.

The Arrow documentation separately describes custom metadata at field, schema and message levels. These are key-value structures where applications can attach additional information. The format reserves the ARROW namespace pattern for Arrow’s own use, including keys associated with extension types. Applications should choose their own namespaced keys to reduce the chance of collisions. That is the opening for multilingual labels: a viewer can agree to interpret keys such as example.org:label:fr or a structured value under a custom namespace, but only if its data contract explicitly defines them.

There is no magic in the chosen key string. An application-defined convention needs rules for language tags, text normalization, duplicate keys, versioning, maximum lengths, privacy and fallback behaviour. It must also state how metadata is stored in the implementation’s language bindings. In PyArrow, metadata interfaces commonly use byte-oriented keys and values even though caller conveniences may accept strings in some contexts. The integration should encode and decode consistently, test round trips and avoid confusing a byte representation with the intended human-language content.

Separate schema invariants from helpful prose

Create an immutable schema manifest before translation. Record each field’s technical path, name, data type, nullable status, child structure and any recognized extension metadata. Include field order when it matters to your consumers. Record existing application metadata as a baseline and classify keys by ownership. The translation team should receive only approved source-label and help-text slots. It should not edit type information, dictionary settings, extension identifiers or schema evolution policies.

The distinction becomes especially important for nested data. A structure might contain a student field with nested grade_level and assessment_score children. A translated display for student.grade_level needs to remain attached to that particular child, not to another field with the same short name in a different branch. Use full field paths or stable application IDs in the translation ledger. Do not match translations by displayed text alone; two fields called ‘Status’ may represent very different concepts.

Some metadata keys are not merely descriptive. An Arrow extension type may use reserved key-value pairs that tell readers how to interpret logical data beyond the physical storage type. Treating these as translatable text can destroy the intended interpretation. The same principle applies to custom metadata that drives validation, joins or privacy controls in an application. A key is not safe to edit because its value contains English words. Verify whether it is presentation metadata or operational configuration, then enforce that classification in the extraction layer.

Choose an explicit application namespace

A team might propose an application convention such as edu.example:label:en, edu.example:label:fr and edu.example:description:fr. Those are illustrative names, not standardized Arrow localization keys. The contract must define whether values are UTF-8 text, what language tags are allowed, which field paths use them and how the renderer chooses among variants. It should prohibit other programs from interpreting them as schema identity or numeric units. Keep the namespace distinct from Arrow’s reserved internal patterns.

When several applications share a dataset, a short contract matters more than clever key design. A business intelligence viewer needs to know that label is safe to show, description is longer help text and technical Field.name remains the query key. A training-data pipeline may ignore the labels entirely. A glossary service might store translations externally and only add an opaque glossary reference to metadata. These are legitimate different choices. Decide based on actual consumer requirements and verify them instead of claiming that Arrow’s custom-metadata flexibility automatically creates cross-platform internationalization.

A multilingual label should not conceal missing data definitions. If the field means ‘number of absent days during the reporting term’, a target-language label that just says ‘Absence’ can leave the denominator, unit and aggregation unclear. Store a concise label and a fuller localized description when supported. The label should identify the concept quickly, while the description states the period, unit, inclusion rules and source. Both must refer to one authoritative definition. If the definition changes, every language is due for review.

Preserve technical names even when they are ugly

Legacy field names are not always readable. A column called amt_net_v2 might frustrate a nontechnical user, but renaming it during localization can disrupt contractual queries. Display labels offer a useful separation: users see ‘Net paid amount’ in English or its reviewed equivalent in another language, while software continues using amt_net_v2. If the organization eventually wants to rename the schema field, that should be a separately versioned migration with compatibility tests and consumer communication.

Avoid the tempting intermediate solution of duplicating one column under translated names. It increases storage and creates ambiguity about which copy is authoritative. If one value is corrected and another is not, the data appears inconsistent. In some systems duplicate column labels can also collide after normalization or case folding. Instead, keep a single stable field and map several human labels to it. A view layer can render translated headers without materializing new source columns.

Technical names sometimes encode units or stages, such as temperature_c or budget_committed. A translation must not turn a Celsius measure into Fahrenheit simply by changing a suffix in the visible label. If a consumer wants a unit conversion, that is a data transformation requiring an explicit calculation, validation and provenance. The label should reveal the original unit or the approved transformed unit. Never describe a changed unit without checking that the underlying values were transformed accordingly.

Understand PyArrow field metadata operations

In Python, PyArrow exposes Schema.metadata for schema-level metadata and Field.metadata for field-level metadata, with helpers such as Field.with_metadata() to make a field definition with modified metadata. A common mistake is to assume that changing a local Field object automatically changes every existing table that used an earlier schema. A field is part of a schema; modifying a field definition requires constructing or replacing the relevant schema and ensuring data is associated with it correctly. Test the actual application flow, not merely the isolated field object.

A second mistake is to use a schema-level metadata operation when the intended information belongs to one particular field. Table.replace_schema_metadata() works at the table schema’s metadata level. It does not, by itself, attach per-field labels to a specific field. This matters when an application lists hundreds of columns: a loose dictionary of labels at schema level needs its own stable field-path mapping, whereas field metadata travels with a field in supporting Arrow operations. Choose consciously and document the expected behaviour.

A third mistake is overwriting existing metadata instead of merging with it. If a field already holds an extension-related key or an application identifier, replacing the entire metadata dictionary with only a French label may drop essential information. A safe transformation begins with an existing metadata copy, adds or updates only the approved application keys and creates a new field or schema while preserving unrelated pairs. Automated tests should assert that protected metadata keys remain exactly the same.

A narrowly scoped Python example

The following example is illustrative PyArrow code demonstrating how an application might attach its own French label metadata to an existing field while retaining its name and type. It is not executed here because the required PyArrow runtime has not been established in this working environment. The syntax can be checked, but actual metadata and table behaviour should be tested with the supported PyArrow version and representative data before a production conversion.

import pyarrow as pa

original = pa.field(
    "net_amount", pa.decimal128(12, 2), nullable=True,
    metadata={b"edu.example:label:en": "Net amount".encode("utf-8")}
)
metadata = dict(original.metadata or {})
metadata[b"edu.example:label:fr"] = "Montant net".encode("utf-8")
translated_field = original.with_metadata(metadata)

assert translated_field.name == original.name
assert translated_field.type == original.type
assert translated_field.nullable == original.nullable
assert translated_field.metadata[b"edu.example:label:fr"].decode("utf-8") == "Montant net"

The assertion intentionally checks the changed field definition, not a complete table or IPC file. In a real dataset, build and verify the relevant schema, attach it to the table through a supported operation, and test serialization and consumer behaviour. An application should also check the field’s full metadata map for protected keys and consider nested children. An isolated Field.with_metadata example teaches one API concept; it does not certify that every conversion path preserves field-level metadata.

The custom prefix edu.example is an invented illustrative namespace. Its use in this example does not mean Arrow recognizes those keys as language labels. A renderer must explicitly decode the value, choose among language variants and apply a fallback policy. Without such a renderer, a translated label may remain invisible while the technical schema operates normally. That separation is a feature, not a flaw: it prevents untrusted presentation strings from silently changing data semantics.

UTF-8, byte values and visually similar characters

Human labels can contain accents, non-Latin scripts and combining characters. When Arrow metadata moves through Python and other language bindings, consistent encoding is essential. Agree to UTF-8 for application-defined human text, encode it deliberately and decode strictly in readers. Avoid silently replacing invalid bytes with a question mark or replacement character, because that can hide the original source of corruption. Keep a test fixture with realistic accented and non-Latin labels, not just ASCII English.

Unicode normalization can also affect comparisons. Two strings may look identical while having different underlying code-point sequences. Normalization is a policy choice; it should not modify technical field keys or confidential evidence without careful review. For display labels, choose a consistent normalization approach and test search, sorting and truncation in the consuming interface. Do not assume a character count predicts visual width. A short label in one script may occupy more pixels or line breaks than a longer English phrase.

Typography is another layer entirely. Arrow data does not guarantee which fonts a reporting tool uses, and the metadata does not define visual direction or layout. Right-to-left languages require attention to punctuation, mixed-direction numbers and embedded technical codes in the viewer. If the application lacks proper bidirectional text handling, a correct UTF-8 metadata string may still display confusingly. The repair belongs to the presentation component, not to the Arrow field name or numeric values.

Protect data definitions, not merely strings

Field labels can be more consequential than ordinary interface decoration. A translated term ‘average score’ could wrongly imply a student-level mean when the data actually contains a group median. A label ‘attendance rate’ could mislead if the denominator excludes excused absences. The translator needs a definition maintained by the data owner, not just the current dashboard heading. Build a glossary of concepts, calculation formulas, denominators, units, reporting periods and applicable exclusions before the first multilingual release.

A useful quality test asks a domain reviewer to infer from the translated label and description what quantity they would compute. If the answer differs from the source definition, the translation is inadequate. This test is not a computational schema test, because the raw Arrow type could remain a 64-bit floating-point number in both cases. It is a semantic test that prevents a technically valid dataset from becoming an unreliable information product for its readers.

For sensitive datasets, do not include private values or explanatory notes containing personal information in metadata intended for wide distribution. Descriptions can inadvertently expose internal programme names, student categories or data-quality incidents. Assess metadata visibility under the organization’s privacy rules. A translation workflow may need a public-facing glossary that omits internal operational notes while retaining the correct definition. Localizing the label is not permission to publish the full private data dictionary.

Build an extraction ledger for nested schemas

A robust extraction program traverses the Arrow schema recursively and gives each translatable metadata slot a stable locator. For a simple field, the locator may be its technical name plus schema version. For nested structures, include the path through parent fields and, where your system supports it, a stable application field identifier. Avoid relying only on numeric field positions because adding a column can shift positions without changing field meaning. Store a source hash and metadata revision so stale translations can be detected.

Each extracted record should identify the human-language source, the allowed target locale, the original definition, the protected technical properties and the publication owner. The translator edits only the target-language label and description. The integration program then attaches those values to the exact field location in a copy of the schema. If a field has been renamed or deleted since extraction, the reinsertion must stop instead of guessing based on similar-looking columns. A good refusal here prevents subtle statistical mislabelling later.

Version the glossary along with the schema. A term may keep its English label while its business definition changes, for example when a finance dataset switches from gross to net reporting. That is a semantic breaking change for translations, even if the Arrow physical type stays decimal. The review workflow should detect definition revisions and reopen affected locales. A field-level label that was once accurate can become misleading when the underlying computation changes silently.

Compare immutable schema properties after localization

The automated invariant check should compare technical field paths, names, types, nullable states, child structures and protected metadata before and after localization. It should explicitly allow only new or updated keys within the application-approved translation namespace. If schema-level application metadata changes, apply an equivalent allowlist there too. A useful report identifies each changed key and the field it belongs to so reviewers can distinguish an expected French label addition from an unexpected extension-type change.

Check the ordered schema when consumers depend on order. A table export may produce a different sequence if someone builds a new schema by sorting translated labels. That error can affect positional readers and human interpretation even when individual field names survive. Do not order the underlying data by locale-specific display names. Sort the rendered column headers in a viewer only if the interface intentionally offers that behavior and preserves the mapping back to the correct data fields.

If the application uses dictionary-encoded columns or extension types, include targeted tests for those configurations. Ordinary text label insertion should not change dictionary identifiers or extension metadata. Even an apparently benign copy of metadata can be dangerous when reserved keys are omitted. Treat any difference outside the authorized application namespace as a potential schema migration. Escalate rather than letting translation code decide whether a technical change is safe.

Check preservation across the actual transport path

Arrow IPC can carry schema and field metadata within its defined format, but workflows often convert data into CSV, database tables, Parquet files or third-party dataframes. Not every conversion preserves every custom metadata key. You must test the specific versions and connectors in use. A quick in-memory assertion is useful, but it does not establish preservation after uploading to cloud storage, reading through a query engine and rendering in a dashboard. This distinction is one of the most important practical limits of metadata-based localization.

Make a round-trip fixture with several columns, two languages, one nested field and a protected metadata key. Write through each production path, read it back and compare. Record whether the keys survive intact, are normalized, are moved to a sidecar or disappear. If a tool strips custom metadata, you can keep translations in a separate dictionary keyed to stable technical names or application IDs. Then the viewer joins them at runtime. That fallback may be more portable than insisting every intermediate tool retain a custom Arrow key.

Beware of serialized schema fingerprints or caches. Some systems treat metadata as part of a schema fingerprint while others ignore it. Adding localized keys could therefore change cache identifiers or compatibility checks even though physical types are unchanged. Test the real consumer contract and decide whether a metadata-only revision needs cache invalidation. Do not declare a schema change ‘nonbreaking’ for every product simply because the arrays are identical. Operational compatibility depends on each consumer’s implementation.

When the label vanishes after conversion

Suppose a bilingual report displays the correct French label in a PyArrow preview but switches back to the technical field name after a data warehouse import. The first question is whether the metadata survived the conversion. Inspect the schema and field metadata at each stage using the supported API. If the custom key disappears at a particular boundary, the translator’s wording is not the problem. The repair may be to configure a supported metadata-preserving path or to use a separate localization catalog for the reporting layer.

If the metadata survives, inspect the renderer. Does it read the correct namespace? Does it decode UTF-8? Does it select the requested language or fall back to English? A viewer can ignore correctly attached metadata if the locale selection is implemented incorrectly. Test with an explicit language selector rather than assuming the operating system locale flows through all layers. Keep logs that record which metadata key was selected without exposing sensitive dataset contents.

If only one nested field loses its label, compare the path used in the extraction ledger with the actual nested schema. Perhaps the field moved under a different parent, or the reinsertion matched by a short name that appeared twice. The repair requires a stable locator and a complete schema traversal. Copying the label to every field named ‘Status’ would be a dangerous shortcut. The viewer should display a technical fallback and a warning rather than a confident but incorrect label.

When a localized column gives the wrong answer

Imagine a school dataset containing final_grade and predicted_grade, both integer-coded. In English the labels differ clearly; in another language they were both shortened to ‘Grade’. The underlying Arrow values and types remain intact, so schema validation passes. Yet a parent reading the dashboard cannot distinguish a measured result from a forecast. This is a semantic translation error. Fix the labels and descriptions to preserve the distinction, and test the two columns side by side in their real context.

Another example concerns percentages. A field rate may hold a fraction such as 0.85 that the viewer displays as 85%. If the translated label adds ‘percent’ but the viewer shows the raw fraction without formatting, readers could interpret 0.85 as 0.85%. Do not change data to make the text look better. Coordinate label, unit metadata and display formatting with the data owner. A localized dashboard needs a consistent agreement about numerical representation, separate from the Arrow storage type.

The review should ask what decision a reader might make based on the field. For a tuition analytics report, confusing ‘practice completion’ with ‘assessment mastery’ could lead to inappropriate teaching interventions. The translated description must retain caveats about what is measured and what is not. This is especially important when a label is short enough to appear alone on a mobile chart. Provide contextual help or accessible details where the full definition cannot fit in the header.

When custom metadata collides with an extension type

An Arrow field may include internal metadata associated with an extension type. A careless integration might rebuild the metadata dictionary using only translation keys, deleting recognized extension keys. The data can still look physically plausible while a reader loses information about its intended logical type. Stop the localization release when protected keys are missing. Restore them from the original field definition and change the transformation to merge allowlisted keys, not replace unrelated metadata.

A second collision occurs when the application invents keys under a reserved prefix such as ARROW:. That prefix has defined significance in the Arrow ecosystem, and a custom localization project should not claim it. Use a distinct application namespace. Document the key-owner boundaries so future developers know which values are internal, which are operational application data and which are user-facing translations. A short namespace specification saves considerable debugging time when two systems later exchange the same dataset.

A third failure is metadata duplication or inconsistent encoding. If two values use different byte encodings for what should be the same locale key, the viewer may select one unpredictably or fail to decode either. Normalize key conventions at the integration boundary, reject duplicate semantic locales and test that values decode cleanly. Resolve conflicts through the content owner rather than guessing which label is newer from filesystem order. Deterministic metadata processing is a prerequisite for dependable multilingual display.

Fictional case study: library lending data

A public library shares a table with borrower_category, loan_duration_days and renewal_count. A multilingual portal wants Malay and Chinese labels. The library first documents each field: borrower category refers to a defined circulation class, loan duration is measured in days and renewal count excludes automatically extended loans. The translator receives those definitions and approved label roles. The data team locks technical field names, types and the policy behind each code value.

During review, someone suggests translating borrower_category into a phrase meaning ‘age group’ because many classes are age-related. The librarian rejects it: categories may also reflect membership schemes or access arrangements. The correct label preserves the broader membership meaning. Another translation describes renewal_count as ‘additional borrowed books’ rather than the number of renewals. That is also rejected because it changes the unit of measurement. The glossary and claim review catch these errors without needing access to any actual patron records.

The IT team attaches language-specific labels in an application namespace and tests the Arrow IPC path used by its reporting application. The labels survive that path, but a CSV export drops them. Rather than renaming columns in the CSV, the team exports a matching public glossary keyed by the original technical field names. The receiving portal applies the correct language at display time. The result keeps one authoritative dataset while supporting several reader groups without inventing duplicate data fields.

Changed-context transfer exercise: a hospital occupancy table

A hospital analytics team stores occupied_beds, available_beds and licensed_beds. A translator is asked to produce a new language version of the dashboard. The translated label for available_beds is shortened to a phrase meaning ‘vacant beds’, while the source definition says that the field excludes beds closed for staffing reasons and includes only clinically deployable capacity. During conversion, the field metadata also disappears. What are the two independent defects, and how should the team repair them without changing the medical statistics?

Answer: The first defect is semantic: ‘vacant’ may imply any physically empty bed, while the source field counts beds ready for clinical use under specific operational rules. The translator must preserve that distinction and obtain a clinical definition review. The second defect is technical: the selected conversion path did not preserve application metadata, so the localized viewer cannot retrieve its label. The team should use a tested metadata-preserving path or a separate localized glossary keyed to stable field identity. Neither repair requires changing occupancy counts or renaming Arrow fields.

For the transfer test, verify the label meaning in context, compare schema invariants before and after localization, test the real transport path and inspect what the dashboard displays with and without a matching locale. Add a fallback that uses an approved default label instead of a misleading guess. The example shows why a strong workflow needs domain experts and systems engineers: one protects the interpretation of the number, while the other protects the delivery mechanism for its explanation.

A practical schema-localization release checklist

Confirm that the physical field names, types, nullability, child fields, ordering requirements, dictionary properties and protected extension metadata have been captured. Define which custom keys belong to the application and prohibit translators from changing anything else. Give reviewers the authoritative field definitions, source and target locales, units and formulas. Check long labels and scripts in the actual UI. Ensure the label and description agree with how values are calculated and displayed.

Run syntax checks on any code, then execute realistic tests in the supported Arrow implementation. Compare invariant schema properties and metadata key ownership before and after translation. Round-trip through each relevant transport and conversion path, including known metadata-stripping boundaries. Test fallback when a language is missing. Check that metadata-only changes do not break schema caches or consumer compatibility. Record the exact library versions and connectors used, because another version may behave differently.

Finally, publish through the application’s authorized data-governance process with revisioned glossaries and an explicit ownership check. Store original labels and translated variants together so future source-definition changes can reopen the correct segments. The offline article does not create a new Arrow standard or authorize modification of a production dataset. Its examples are teaching aids, and specialist verification remains required for any application that uses field metadata in operational decisions.

Limits and summary

Custom Arrow metadata is flexible, but flexibility is not interoperability by itself. An application can define multilingual keys, yet another application may ignore or remove them. No amount of perfect translation can fix a consumer that loses metadata, and no schema parser can detect every misleading label. A sustainable workflow therefore has a documented namespace, immutable schema comparison, domain definition review, explicit consumer selection and a fallback when metadata does not travel.

The winning idea is to let technical fields remain stable while people see the language they understand. Keep one authoritative value column, attach language-specific explanations through a governed application contract and validate both the data path and the human interpretation. Once those responsibilities are separated, teams can translate faster without sacrificing query compatibility or falsely promising that every Arrow consumer is automatically multilingual.

Frequently asked questions

1. Does Apache Arrow include an official `label_fr` localization field?

Not as a universal built-in localization contract. Arrow supports custom field and schema metadata, and applications can define their own language-specific keys. Those keys require an agreed convention and a reader that knows how to interpret them.

2. Why not rename the column for each language?

A field name is a technical schema identifier used by code, queries and transformations. Renaming it can break consumers or create multiple inconsistent copies of a column. Use display metadata or a separate glossary while retaining the stable name.

3. Does `Field.with_metadata()` change an existing table automatically?

No. It produces a field definition with metadata; a containing schema or table workflow must then be handled explicitly. Test the actual supported API path for the PyArrow version in use rather than assuming an isolated field edit propagates everywhere.

4. Can translation metadata disappear during conversion?

Yes. Custom metadata can be lost through formats or connectors that do not preserve it. Test the exact round trip. Where preservation is unreliable, use a separate localization catalog keyed by stable field identifiers.

5. Are keys beginning with `ARROW:` safe for application labels?

No. The Arrow format reserves that namespace pattern for internal uses such as extension metadata. Choose an application-owned prefix and document it so other consumers can distinguish translation from operational schema information.

6. Is UTF-8 encoding enough for correct multilingual display?

It is necessary for the application convention but not sufficient. Readers must decode correctly and handle fonts, bidirectional text, fallback, truncation and search. A text value can survive bytes perfectly and still appear incorrectly in the interface.

7. What should be protected in a schema-diff test?

At minimum, field paths, technical names, types, nullability, nested structure, relevant order and protected metadata, especially extension-related keys. Only explicitly approved application language keys should change in a translation-only operation.

8. Why does a good label need the data definition?

Similar-looking names can represent different measures. ‘Average score’ and ‘median score’ are not equivalent, and ‘available beds’ may have a specific operational definition. Translation must preserve units, denominators, timeframes and exclusions where those determine meaning.

9. Can metadata contain private or sensitive descriptions?

It can, so visibility needs governance. A schema may travel farther than the data steward expects. Do not embed personal information or internal notes in public labels; create an approved public glossary where necessary and follow the applicable privacy rules.

10. How should a viewer behave when a translation is missing?

Use a documented fallback to an approved available label and keep the mapping to the correct technical field. Do not invent a translation from the field name or silently borrow an unrelated label. Make missing coverage visible to maintainers and reopen the translation task.