To translate netCDF metadata quickly, distinguish the descriptive label a learner reads from the standardized metadata that lets scientific software understand a measurement. A CF-aware climate dataset may contain a friendly long_name, a controlled standard_name, formal units, coordinates, time calendars and numeric data arrays. Translating a display label can help a pupil understand a graph. Translating a controlled variable name or changing a unit token can make the same dataset misleading or unreadable to analysis tools.
A safe CF conventions localization workflow starts by freezing the scientific data, identifying user-facing labels, recording the exact physical quantity, then adding a language-specific presentation layer without disturbing units, standard names, dimensions or coordinate meaning. The target language should explain whether a graph shows air temperature, precipitation rate or a time mean. It must not quietly turn one measurement into another because a familiar target-language word seems close enough.
This guide uses fictional classroom climate data to demonstrate the difference between long_name and standard_name, explain why numerical values and units are not prose, and show how to test both metadata and graphs. The dominant reader job is deliberately precise: localize readable scientific metadata for one dataset while protecting the physical relationships that make the dataset useful for education and research.
1. Scientific translation begins with the quantity, not the label
Imagine a teacher downloading a climate dataset for a secondary-school lesson. The file contains time, latitude, longitude and an air-temperature variable. The teacher wants pupils who read Mandarin to see a graph with a clear local-language label. The obvious approach is to replace “air temperature” wherever it appears. But a netCDF file is more than a collection of captions. The same phrase can appear in a plot title, a free-text description and a controlled attribute whose exact spelling carries machine-readable scientific meaning.
NetCDF files can store multidimensional arrays together with metadata describing their values. The Climate and Forecast metadata conventions, usually called CF, provide shared rules that help software interpret coordinates, units, cell statistics and other aspects of scientific data. A learner may never see those internal attributes, yet graphing and analysis programs depend on them. Localizing a human-readable label while preserving the underlying metadata is therefore an exercise in scientific integrity.
Consider a variable whose standard_name is air_temperature and whose units are K. The word “temperature” is a familiar noun, but air_temperature is a controlled standard-name token and K is a unit expression. Neither should be translated into free prose inside those standardized attributes. A suitable display label might be written in Mandarin, Malay or another target language, with a separate presentation decision about how to show the unit. That label helps readers without changing what the data means.
The risk is not only technical failure. A translated plot can be aesthetically convincing while scientifically wrong. If a label says “daily maximum air temperature” but the data represent a daily mean, the chart encourages an incorrect conclusion. If a value stored in Kelvin is labelled as Celsius, the numbers look extreme and pupils may believe the climate is impossible. For science education, preserving the measurement’s identity is more important than smoothing every source phrase.
A good translation brief therefore records four linked facts for every displayed variable: the physical quantity, the unit, the statistical treatment and the coordinate context. Only then should the writer choose a target-language label. This makes a science translation auditable even when the target reviewer is not the person who prepared the original dataset.
2. What CF standard_name and long_name actually do
The CF conventions distinguish a descriptive long_name from a controlled standard_name. A long_name is free text intended to communicate what a variable represents; software may use it as a plot label. The standardized standard_name comes from a published table and has an agreed scientific definition. Its spelling, underscores and case are part of that definition, so it is not a natural-language phrase available for editorial rewriting.
A variable called tas might have standard_name="air_temperature", long_name="Air temperature" and units="K". The short variable name tas can be an implementation choice, while the standard name states the kind of physical quantity. The friendly long name can support display. A target-language caption can also be supplied by a separate localization layer. But replacing the standard name with translated text would make the value fail lookup against the CF standard-name table.
The CF 1.13 reference explains that some standardized attribute names and standardized values remain in English for portability. It explicitly permits non-English descriptions in appropriate free-text contexts, including a long_name whose content is not prescribed by the standard. That is an important nuance. The conventions do not require every descriptive word in a netCDF file to remain English; they require controlled scientific tokens to remain controlled. Translators need to know which field they are touching.
Because the long name is free text, it can be too vague. A variable labelled merely “Temperature” might refer to air, sea surface, soil or a model layer. Translation should not invent specificity absent from the available metadata. Before choosing a precise target-language term, look at the standard_name, coordinates, attributes and documentation. If the field is genuinely underdescribed, ask the data producer to improve the source description. Do not let a translation paper over a scientific documentation defect.
There is also a common misconception about bilingual storage. CF does not provide a universal, interoperable standard for storing a full set of locale-keyed variants of every long_name in one netCDF file. A project may create extension attributes or a separate locale dictionary, but the implementation should state that it is a local convention and preserve a standards-compliant base view. A downstream CF reader should not need to understand the project’s custom language fields to interpret the science.
3. Freeze scientific invariants before touching words
Start with the original file and an immutable copy. Record its filename, version, producer and checksum. Then inventory dimensions, variables, shapes, data types, coordinate relationships, standardized metadata and numerical arrays. This establishes what must not change in a translation-only task. A file that becomes unreadable after localization has already failed, even if its new descriptions are excellent.
The highest-priority invariants include variable names used by analysis scripts, dimension names, coordinate values, standard_name, units, calendar, grid_mapping, cell_methods, missing-data attributes and any relationships to ancillary variables or bounds. Some of these attributes are strings, which makes them tempting targets for a generic text replacement. But being stored as text does not make an attribute natural-language prose. The semantics depend on the field definition.
For example, the time coordinate may use a unit like days since 2000-01-01 00:00:00 and a supported calendar token. These are machine-readable expressions, not captions for a reader. Translating “days” into another language or changing a decimal delimiter can break time decoding. Similarly, a grid mapping describes coordinate reference semantics, not the cartographic label a teacher wants on an axis. Protect such metadata at the schema level.
Numerical integrity needs its own evidence. Compare data variables before and after any localization packaging, using exact array equality where appropriate or cryptographic hashes of a canonical representation. Be cautious with compressed files, file ordering or metadata rewriting because the whole-file hash may change even when arrays remain equal. A targeted comparison can establish that measurements were untouched while still allowing approved descriptive metadata to differ.
If the workflow merely creates a separate localized plotting configuration, the safest outcome may be no change to the netCDF file at all. The display layer can map a stable standard_name or variable key to a reviewed target-language label. That keeps the scientific archive clean and makes multilingual presentation easier to maintain. Only embed localized free-text attributes when there is a documented interoperability reason and a compatible client profile.
4. A worked example: air temperature in a classroom plot
Consider a fictional daily air-temperature dataset covering a small coastal study area. The variable’s internal key is tas, its CF standard name is air_temperature, and its stored unit is kelvin, written K. The file describes time and geographic coordinates. A teacher wants to show pupils a graph of the daily mean air temperature. The English chart title says “Daily mean air temperature,” and the target-language chart should express that same statistical quantity.
Here is a simplified CDL-style illustration of relevant metadata. It is a teaching excerpt, not a complete netCDF file; the array dimensions and coordinate variables would need to be defined for a real dataset. The key point is which strings are controlled and which words are candidates for a reader-facing label.
float tas(time, lat, lon) ;
tas:standard_name = "air_temperature" ;
tas:long_name = "Air temperature" ;
tas:units = "K" ;
tas:cell_methods = "time: mean" ;In this example, the CF standard name identifies air temperature; the units express kelvin; the cell-method attribute indicates a mean over time in the defined context. The translated chart title should mention the daily mean only when the time sampling and aggregation really support that interpretation. The label “daily maximum temperature” would be wrong even if the target-language words were grammatical. A mean and a maximum can differ substantially in weather interpretation.
The teacher may want to display degrees Celsius to make the chart easier for a class. That is a separate numerical transformation or unit-conversion step in the visualization layer. For absolute temperature, a value of 300 K corresponds to 26.85 °C, not 300 °C. Merely changing the axis suffix from K to °C would be scientifically dishonest. The transformation must be applied deliberately, documented and tested, while the archived dataset may remain in its original units.
Ask pupils to explain the graph in their own words. If they say the line tracks the hottest temperature each day, the title may have failed to communicate mean temperature. If they think the numbers are in Celsius when the axis still shows Kelvin, the label and visual presentation are inconsistent. This is a productive classroom test because it checks scientific interpretation rather than dictionary equivalence.
5. Units have grammar, but standardized unit strings have rules
Measurement words can be translated when they appear in explanatory prose. The scientific unit token inside a standards-aware attribute is a different matter. CF units are expected to follow recognised conventions and associated software parsing expectations, including the relevant UDUNITS framework. Changing K to a translated word or replacing decimal punctuation in the data is not an acceptable way to localize a chart. A reader-facing legend can provide a natural-language explanation while the source attribute retains its interoperable unit representation.
Pay special attention to rate versus amount. Precipitation rate, total precipitation amount and accumulated precipitation over a period may all be described casually as “rainfall,” but they are not equivalent. Their units and temporal treatment differ. A target-language label that collapses those distinctions can change the learner’s inference about whether the chart shows how fast rain falls or how much rain fell over a period. Consult standard names, units and cell_methods together before selecting a term.
Relative humidity provides another useful example. A variable may store a dimensionless fraction while the chart displays a percentage after multiplication by one hundred. Translating the label is not enough to make the percentage correct. The axis must reflect the numerical transformation. Conversely, if the source values already represent percent, multiplying again would create impossible readings. A scientist should verify the measurement representation; a translator should preserve the verified meaning in the target language.
Scientific notation and significant figures deserve attention too. A number written with an exponent may be pronounced differently in another language, but the exponent still has the same mathematical meaning. A unit might include a negative exponent that means “per square metre.” The translated explanation should preserve the denominator and the dimensional relationship. Avoid replacing compact standardized expressions in the file with natural-language sentences that software can no longer parse.
In a lesson about energy flux, for example, confusing a per-area quantity with total energy could change the scale of the result. A careful locale-aware presentation may explain the unit in a caption while keeping the standard token on the axis or in a tooltip. The right choice depends on the curriculum and audience, but the invariant is the physical dimension of the measured quantity.
6. Coordinates, calendars and time averages are not decorative metadata
A scientific variable gains meaning from its coordinates. Two measurements of air temperature may refer to different altitudes, places or moments. A teacher translating “surface air temperature” must check which vertical level the data represents rather than inferring “ground temperature” from everyday language. Coordinate variables and grid mappings can distinguish geographical dimensions and model positions that the free-text label does not fully explain.
Time coordinates can be particularly deceptive. Daily observations, daily averages, monthly means and climatological reference periods may be displayed with similar date labels. A target-language caption that says “temperature on Monday” might hide the fact that the value is an average over a longer interval. CF attributes such as cell_methods and time bounds can clarify how values relate to intervals. The translator should consult them before choosing temporal words like daily, hourly, peak or average.
Calendars also matter in climate model datasets. Some model calendars do not map to ordinary civil dates in the way a classroom calendar does. Translating a calendar token as if it were a sentence can interfere with decoding, and representing model dates as ordinary civil dates without explanation can mislead. The localized display may need a short note stating that values are modelled under a particular time convention. This is a scientific annotation, not a reason to rewrite the core coordinate data.
Spatial terms also carry risk. An axis labelled “longitude” should not be translated as a horizontal distance, and latitude should not be treated as a directional bearing. A map may use projected coordinates rather than latitudes and longitudes. A chart title should not claim coverage of Singapore simply because a map window currently displays Singapore, unless the source data selection and bounding coordinates support that claim.
The fastest review method is to use a context panel that displays the quantity, units, dimensions, coordinate labels, aggregation and bounds alongside the proposed target-language phrase. This makes domain errors visible without requiring the translator to inspect thousands of numerical samples. It also lets a subject specialist review the same evidence and approve the label efficiently.
7. Free-text attributes and the danger of changing definitions
The long_name attribute is often a good source for a human-readable plot label, but it may be inconsistent across files. One producer writes “2 m air temperature,” another writes “temperature at two metres,” and a third uses “T2m.” If they all refer to the same scientific quantity at the same height, a local-language display can choose a consistent expression. However, the translator must verify the underlying equivalence rather than assume that the abbreviations prove it.
A short long_name might deliberately omit a statistical qualifier that appears elsewhere. A careful translated label can include information already verified in cell_methods, but any enrichment should be documented as derived presentation metadata. Do not claim the source long name contained words it did not. This matters when labels are generated automatically: if the chart concatenates a localized variable description and an aggregation phrase, the translator should avoid duplicating “average” in both parts.
Custom attributes present a more complicated decision. A data producer may have added a description, comment or institution field with free text. Those can contain language candidates, but some may be provenance statements rather than reader-facing descriptions. Translate or expose them only where the target product genuinely needs them, and preserve attribution and licensing statements accurately. Do not assume that all free-text attributes should be changed during a label-localization task.
A provenance attribute naming a research institution should preserve that institution’s official identity. A model name or version string may be a product identifier rather than translatable prose. If a sentence contains a website, DOI or dataset code, those references must remain valid. A translator who changes their spelling to fit the target language can sever the path back to the original science. Mark structured references and proper names distinctly in the export.
Finally, distinguish a translated source label from a newly authored explanation for learners. A teacher might add “warmer colours mean higher temperatures” as an instructional caption. That is useful, but it is not simply a translation of long_name. Keep the educational explanation in a separate authored text field or lesson layer, with its own review. Otherwise the file’s metadata can accumulate claims that belong to the curriculum rather than the underlying dataset.
8. One multilingual dataset or one base dataset plus locale files?
There are several legitimate ways to deliver localized science labels, and each has trade-offs. A project can distribute language-specific display configurations that refer to stable variable keys. It can maintain a metadata catalog outside the netCDF file. It can also create distinct copies with reviewed free-text descriptions for particular environments. The important condition is that scientific measurements and standardized attributes remain interpretable and that every local extension is documented.
A separate locale dictionary is attractive for teaching applications. The app reads tas, knows it corresponds to an air-temperature variable, and selects a reviewed Mandarin label for display. The original file does not need to change. If a target label is corrected, the team can update a small language resource rather than republishing a large scientific archive. The risk is mismatched versions: a dictionary for one dataset may attach a label to another variable with the same short key but a different scientific meaning. Scope each mapping to a stable dataset schema or standard-name context.
A language-specific copy may be simpler for a classroom tool that only reads long_name. But copying the entire dataset increases storage and raises the risk of divergent numerical arrays. If this route is chosen, compare data arrays and standard attributes across editions. Document that the localized value is a presentation variant rather than a different scientific dataset. Avoid introducing hidden changes to missing-value encodings or coordinate ordering while writing the copy.
Embedding several custom language fields in one file can work inside a controlled system, but those fields are not automatically understood by other CF tools. Names like long_name_zh may be convenient local conventions, not attributes specified by CF 1.13 for multilingual behavior. If you use them, document the convention and ensure that ordinary CF readers can still interpret the base metadata. Never present a local naming convention as an official standard.
The choice should be made by the teams that own the science archive and its user interface together. Translators can supply reviewed language, but cannot alone decide the best storage architecture. The right solution is the one that preserves scientific fidelity, supports real target users, survives version updates and has a maintainable ownership model.
9. Worked case: rainfall rate mistaken for rainfall total
A fictional classroom dataset provides a precipitation flux, and the source app labels it loosely as “Rainfall.” A teacher preparing a Malay-language graph assumes it shows the total amount of rain in a day. They translate the title accordingly. A subject specialist then inspects the variable’s standard name, units and temporal metadata and sees that the quantity is a rate rather than a daily accumulated amount. The translation was fluent but scientifically misleading.
The repair begins with the measurement, not the phrasing. Determine whether the data express mass or depth per unit area and time, how any averaging was performed, and whether the chart is showing original values or an aggregation. If the lesson needs a daily total, compute that quantity through an approved transformation and label it as a derived product. If it needs the original rate, choose the appropriate target-language term for rate. The dataset itself should not be silently reinterpreted through a caption.
A second trap appears with a time average. Suppose a graph displays a monthly mean precipitation rate. The target title says “monthly rainfall amount.” That sounds reasonable in everyday conversation, but the displayed unit is still a rate. The chart might represent a mean flux over the month, not an accumulated monthly amount. A tutor can use the example to show pupils why scientific labels carry mathematics inside their wording. The word “amount” should correspond to an amount, not merely a time-averaged rate.
A useful testing exercise gives pupils two similar charts, one showing precipitation rate and the other showing accumulated rainfall over an interval. Ask which chart answers “how intensely was it raining?” and which answers “how much fell in total?” If the translated labels cannot support that distinction, the terminology needs revision. This behavioural test reveals whether language is helping learners reason about the science.
The generalisable insight is that translation accuracy in scientific data depends on dimensional analysis. A glossary can offer preferred words, but the units and data derivation determine which words are valid. A smart localization workflow places that evidence near the translator rather than expecting them to infer it from a vague chart title.
10. Worked case: a tempting Celsius shortcut
Another fictional study file stores near-surface air temperature values around 298 to 305 K. A designer knows that local pupils are comfortable with degrees Celsius, so they replace the unit label K with °C in a localized graph without changing the values. The chart now appears to show temperatures near three hundred degrees Celsius. The label change is superficially small but has transformed a meaningful observation into a false scientific claim.
The correct repair is a deliberate unit conversion at the presentation or analysis stage, with a verified formula appropriate for absolute temperature. For example, 300 K is 26.85 °C. The software must update displayed values and units together. If the source dataset remains in kelvin, its units attribute should remain K; the derived chart can clearly state that it displays converted degrees Celsius. Keep a record of the transformation so a student or teacher can reproduce it.
This case also involves precision. A graph using a fixed number of decimal places should not imply that the source measurements are more precise than they are. Converting temperature does not automatically add measurement accuracy. A label or note may need to explain rounding for a classroom audience. The translation should preserve any caution about uncertainty rather than make the visual appear more exact through polished wording.
If a multilingual app supports automatic unit preferences, test each locale and preference combination. A user could select Mandarin but retain kelvin, or English with Celsius. Language choice and unit choice should be modeled as separate options rather than collapsed into one hidden rule. This prevents a translation update from unexpectedly changing the mathematical value of the chart.
The practical lesson extends far beyond climate data. Localising a display often involves words, numbers and cultural conventions at once. Handle each transformation explicitly and ensure the resulting representation can still be traced to the original values. Scientific correctness should survive a language switch.
11. Build a translation inventory that a scientist can approve
An efficient export lists the source dataset, variable name, standard name, long name, units, dimensions, cell methods, available descriptions and proposed target label. Include whether the label will appear in a chart title, axis, tooltip or lesson paragraph. Those display roles may require different lengths and grammatical forms, but they should describe the same physical quantity. Do not send a translator a spreadsheet containing only tas → Air temperature and assume it is sufficient.
Add an “evidence” field explaining how each label was verified. For common CF standard names, link to the official standard-name entry or a qualified data dictionary. For custom variables, identify the responsible scientist or accompanying documentation. A question about whether a temperature is at two metres or at the land surface cannot be settled by bilingual fluency alone. Route such questions to domain review before approving the wording.
Keep a controlled multilingual terminology sheet for units, averages, anomalies, percentiles, observations, projections and coordinate directions. Include explanatory examples rather than bare word pairs. Terms such as “anomaly” have precise meanings in climate analysis that differ from casual use. A translator might otherwise choose a target-language word suggesting a mistake or abnormal event, while the dataset means deviation from a reference value. The glossary should teach the concept and cite the approved context.
Flag source defects. If a variable has no long name, a surprising unit or conflicting statistical descriptions, do not invent certainty to keep the batch moving. Mark the item for the producer’s review. In many data projects, an uncertainty logged early costs less than a mistranslated figure that later appears in dozens of lessons. A fast workflow makes unresolved scientific questions visible so editors can continue with safer items.
After translation, have a bilingual subject expert review the most consequential labels. They need not inspect every punctuation mark, but they should verify quantity identity, unit meaning, aggregation and any conclusion implied by the wording. A separate language reviewer can refine naturalness and classroom readability. Splitting these tasks preserves the complementary strengths of science and language specialists.
12. Structural validation and rendered-chart QA
First compare the localized artifact with the baseline. If the project uses external locale files, ensure the original netCDF data are unchanged and the dictionary keys resolve to the intended variables. If it writes a new netCDF copy, compare numeric arrays and standardized metadata field by field. A broad “file still opens” test is not enough; a dimension reorder or changed missing-value marker can silently alter analysis even when plotting software produces an image.
Second, run a CF-aware checker appropriate for the source file and its declared convention version. Check units, standard names and coordinate relationships independently of translation. A successful checker report supports structural compatibility, not the correctness of the localized scientific explanation. Also inspect custom extension attributes, because validators may legitimately ignore project-specific multilingual fields.
Third, render representative visualizations in each target language. A long translated term may clip an axis, wrap awkwardly across a legend or overlap a scale label. Use actual font coverage for non-Latin scripts. A replacement square or missing combining character can make a label unintelligible even when the stored Unicode string is correct. Inspect exports as well as interactive dashboards if teachers will print worksheets or project slides.
Fourth, test content comprehension. Ask a learner to identify the quantity, unit, period and geographical coverage from the chart alone. If the chart shows a temporal mean, can they distinguish it from a maximum or total? If it has been converted to Celsius, can they identify that unit? Ask them to explain one conclusion in their own words and compare it with the data. This exposes labels that are grammatically correct but scientifically vague.
Finally, preserve the review evidence. Keep dataset version, locale file version, checker output, array comparison results, reviewer sign-off and screenshots for representative graphs. When a new data release changes standard names or statistical methods, use those records to determine which translations must be rechecked. Quality is a repeatable process, not a one-off assertion that the labels sound good.
13. Common failure modes and how to repair them
The first failure is replacing a controlled standard_name with a target-language phrase. A downstream tool no longer finds the expected entry in the CF standard-name table. Restore the official token, validate the file, and put the translated phrase in a permitted free-text or external presentation layer. Teach editors that machine-readable vocabularies are not prose, even when their English words look familiar.
The second failure is changing standardized unit strings as though they were captions. A dataset becomes difficult to parse or a chart displays physically incorrect values. Restore the original valid units and handle localized unit explanations in the interface. If numerical conversion is intended, perform and document it separately with tests. Do not claim a conversion occurred just because the unit label changed.
The third failure is losing statistical qualifiers. A label says “daily high” for a time mean or “total” for a rate. Inspect cell_methods, time bounds, relevant attributes and data documentation, then rewrite the target label to match the quantity. Review with a domain expert. A sentence-level bilingual check cannot reliably detect a change in statistical operation if the reviewer never sees the metadata.
The fourth failure is mismatched locale dictionaries. A label prepared for one dataset is reused under a short variable name that means something else in a new project. Scope translations to verified schema identities and review changes in standard names, units and dimensions across versions. A mapping keyed only by a short name is often too weak for long-term reuse.
The fifth failure is inconsistent source and rendered values. The original netCDF data remain in kelvin, but an application says Celsius, or a chart displays a converted value while its tooltip reports the raw one. Test all surfaces using the same sample points and conversion logic. Learners should not have to infer why the axis, tooltip and worksheet disagree.
14. Transfer exercise: a coastal research lesson
A school prepares a bilingual activity using two variables: sea surface temperature and near-surface air temperature. Both have numeric values stored in kelvin. The teacher wants to show temperature in degrees Celsius and compare the two variables over several months. A junior editor proposes to translate every attribute containing the word “temperature,” replace all K symbols with °C, and rename internal variables to Chinese words so pupils can read the file more easily.
Your task is to reject or accept each part of that plan with reasons. Decide which words belong in the learner-facing layer, which scientific identifiers should stay unchanged, and how to present unit conversion. The two temperatures have similar names, so explain how to prevent their target labels from collapsing into one generic word. Consider what to do if one variable is a monthly mean and the other is a single observation sampled at a particular time.
A defensible answer preserves CF standard names, dimension keys, valid unit expressions, coordinates and numeric source arrays. It creates reviewed target-language display labels that clearly distinguish sea surface from air temperature. The visualization performs an explicit kelvin-to-Celsius conversion if the lesson requires it, and the derived values and displayed units are checked together. Temporal qualifiers are selected only after confirming the statistical representation of each series.
The answer should also propose a learner test. Give pupils two charts with target-language labels and ask which shows the sea surface and which shows air temperature, which unit is displayed, and whether comparing them at the same date is scientifically justified. If one series is a monthly mean and the other a point observation, the translation or lesson note should not imply they are identical measurement types. This transfer exercise reveals that science localization is about preserving the meaning of comparison, not simply the words in a legend.
15. Final practical checks and summary
For a translation-only release, confirm that the base data arrays, coordinates, controlled standard names, units, calendars, missing-value semantics and relevant statistical attributes remain scientifically consistent. Confirm that target-language labels were derived from verified quantities and approved by someone able to read both the language and the scientific context. Keep locale-specific presentation rules distinct from transformations such as unit conversion or aggregation.
Check the packaging route. A separate dictionary should use stable keys and have version control; an embedded free-text description should not overwrite controlled values; and any nonstandard multilingual attributes should be clearly documented as project conventions. Validate with CF-aware tools and review the actual exported graphs. A plot that reads well but changes the variable’s identity has failed, while a standards-perfect file with unreadable labels has not yet met the educational goal.
The scope matters. This article does not teach climate modelling, create new datasets or guarantee the behaviour of every netCDF library. It gives a method for translating reader-facing scientific metadata while protecting the meaning carried by machine-readable structures. A local project still needs to decide which language resources and plotting software it supports, and a scientist still needs to approve ambiguous quantities.
The essential sequence is clear: freeze the science, identify each physical quantity and its context, translate only the reader-facing description, preserve the standardized metadata, and test the result in a real chart with a real learner. The translation has succeeded when the pupil understands the same measurement in another language and the data remain trustworthy to scientific software.
Frequently asked questions
Can I translate the CF standard_name value into Chinese or Malay?
No. The standard_name must match the controlled CF standard-name table. Provide a localized display label in an appropriate free-text or application layer instead.
Is long_name translatable?
Its value is free-form descriptive text and may be non-English under CF conventions. But changing it should follow the intended product’s language strategy, and a multi-language bundle in custom attributes is not automatically a CF-standard mechanism.
Can I simply replace K with °C in a translated graph?
No. Kelvin and Celsius express different numerical scales for absolute temperatures. Convert the values correctly and update the displayed units together, or retain Kelvin.
Does translating a variable name change the physical measurement?
Changing the display label should not. Renaming an internal variable used by software can break scripts and relationships; preserve internal keys unless there is a separately controlled data-model migration.
How do I know whether a variable describes an average or a maximum?
Inspect available cell_methods, time bounds, relevant attributes and documentation. Do not infer aggregation solely from a vague source label or chart shape.
Why might an accurate target label still mislead pupils?
A graph may show the wrong units, unsupported time assumptions, mismatched tooltips or a clipped qualifier. Test the complete visual presentation and ask learners to explain what it measures.
Do CF conventions define a standard long_name_zh attribute?
Not as a general interoperable multilingual long-name mechanism in CF 1.13. Projects may use documented extensions, but they should not present them as universally understood CF attributes.
Must I translate all metadata comments and provenance descriptions?
No. Translate only what the reader needs, preserve official names and references, and distinguish descriptive text from controlled scientific or provenance data. Check reuse rights and local metadata policy.
How should I verify that numerical data were not changed?
Compare relevant arrays and standardized metadata against a frozen baseline, using robust equality or canonical hashes where appropriate. Whole-file checksums may change when metadata or compression changes.
Should a data scientist or a translator approve the final label?
Ideally both for consequential scientific claims. A language specialist checks clarity and audience fit; a subject specialist checks physical quantity, units, aggregation and coordinate meaning.
Authoritative sources and specification checks
- CF Conventions Version 1.13 (17 December 2025; checked 27 October 2026).
- CF Conventions Community (standard-name tables, discussion and current guidance).
- Unidata netCDF Documentation (file model and attribute handling background; check library-specific implementation behaviour).
Relevant eduKateSG internal-link opportunities (editorial; verified published URLs)
- The Translation Quality System — error severity and test evidence — complementary context, not a duplicate of this article’s specific reader job.
- The Localization System — locale data and product context — complementary context, not a duplicate of this article’s specific reader job.