How do you translate FITS astronomy documentation, localize telescope data labels and explain FITS headers without changing the sky coordinates of an observation? You must separate the human description from the scientific record. A FITS file carries images, spectra or tables together with a strict header-and-data structure. The words around that structure can be explained in another language, but keywords, pixel types, axis metadata and coordinate transformations cannot be rewritten casually.
For astronomers, educators and science communicators searching for a FITS header translation guide, the highest-risk misunderstandings are often not grammatical. They concern the meaning of BITPIX and NAXIS, how Header/Data Units are ordered, how BSCALE and BZERO affect values, and how a World Coordinate System maps pixels to positions or spectral coordinates. A fluent but technically incorrect translation can shift an object on a sky map or misrepresent a measurement.
This guide teaches the FITS standard through practical examples: required header cards, 2880-byte records, primary and extension HDUs, image arrays, binary tables, units, observation dates, WCS, provenance and checksum conventions. It explains which identifiers must remain literal, which captions can be localized, and how to test translated documentation with an actual astronomy data product.
The quick, useful answer
Translate what people need to understand, while preserving the FITS structural keywords, byte layout, measurement values and coordinate definitions. A different language should not change the sky location of a pixel or turn an upper limit into a measurement. A strong localized guide explains the actual observation and provides an independent method to verify it.
1. Begin with the observation, not the file extension
A FITS file exists to preserve scientific information about an observation or result. The first question should be what was measured: an image of a star field, a spectrum, a time series or a catalog table. Only then should a reader investigate the physical data format. The same file extension may hold quite different scientific structures, so translating FITS as if it simply meant a picture is misleading. FITS is a container for quantitative data and interpretation metadata.
A school astronomy lesson may display a colorful image generated from a FITS array. The colors are usually a visualization choice, not necessarily the measured pixel values. A translated explanation should separate the scientific image, the visualization stretch and the caption. Ask learners to compare one numeric pixel before and after changing language or color palette.
2. FITS means more than a JPEG-style image
Unlike an ordinary image viewed purely for appearance, a FITS product may retain physical units, world coordinates, provenance, bit depths and multi-dimensional data. Its pixels can represent flux, counts or other measured quantities rather than display brightness. Describing it simply as a photograph removes those distinctions. A reader-focused translation can use everyday analogies, but it must return promptly to the fact that the array is scientific evidence.
Imagine two images that look nearly identical on screen, one rendered from FITS and another saved as a compressed presentation image. They may not support the same quantitative analysis. A good localized guide says which product is suitable for measurement and which is meant for communication. Do not infer precision from visual similarity.
3. Header/Data Units structure the file
FITS organizes content into Header/Data Units, usually abbreviated HDUs. An HDU has a header and may have an associated data unit. The first is the primary HDU; subsequent HDUs are extensions. This arrangement allows one file to contain an image, catalog tables or several related observations. A translator should preserve the term HDU and explain it clearly, because calling every unit a separate file would produce incorrect instructions.
A stellar observation may contain a primary image and a binary table extension with source detections. A user interface can translate the labels ‘image’ and ‘sources’, while the HDU order and extension identities remain unchanged. Test selection by HDU index and by declared extension name where used.
4. The 2880-byte logical record has a purpose
The FITS format defines a blocking structure in which header and data units are padded to multiples of 2880 bytes. This is a file-format requirement, not a page size chosen for typography. Some readers are tempted to remove apparent blank padding or insert newlines while editing headers as text. That can invalidate the byte structure. Documentation translation must say explicitly that FITS headers are not ordinary editable paragraphs.
A translator opens a raw FITS file and sees a long stream of uppercase keywords and spaces. The safe response is to use a FITS-aware library or viewer. Do not reflow cards, trim padding or save the file through a word processor. A localized manual should show approved inspection steps rather than encourage direct text editing.
5. Header cards are eighty characters
Traditional FITS headers are sequences of fixed-length 80-character card images, and their arrangement matters. Some cards hold keyword-value pairs; others hold commentary. A translated guide should distinguish the visible descriptive text from the constrained header syntax. Many natural languages require more characters or different scripts than the standard header permits, which is another reason not to store translated prose directly in an original header without a defined convention.
A long translated comment may not fit into the original card layout. Prefer a separate localized documentation layer where appropriate. If headers must be modified, use software that understands FITS syntax and character restrictions, and validate the resulting file. An attractive translated comment is not worth breaking every scientific reader.
6. SIMPLE, BITPIX and NAXIS are structural keys
The primary header begins with required keywords including SIMPLE, BITPIX and NAXIS in the prescribed order. SIMPLE indicates conformity, BITPIX describes array element representation, and NAXIS states the number of data axes. These are machine-readable identifiers rather than prose. Translating their spelling or changing numerical values to make them easier to read can alter or invalidate the scientific file.
Explain SIMPLE in your target language while leaving SIMPLE as the literal keyword in code examples. Likewise, say what BITPIX means but do not replace it with a translated abbreviation. Ask the reviewer to inspect an actual header and identify the same keyword and value in both language versions.
7. BITPIX is not image brightness
BITPIX identifies the storage representation of values in an image array, including defined integer and floating-point forms. A negative BITPIX is a standard way of distinguishing floating-point forms; it does not mean the image contains negative brightness values. Nor does a larger magnitude automatically mean the observation is scientifically better. Precision, calibration and noise are separate questions.
For example, BITPIX=-32 indicates a floating-point representation. A translated label saying ‘minus thirty-two intensity’ would be wrong. Show the literal keyword and explain its data-type role. If a tutorial uses a viewer to compare arrays, have the user inspect the actual type rather than guessing from the display stretch.
8. NAXIS and NAXISn describe dimensions
NAXIS records how many axes are present, while NAXIS1, NAXIS2 and subsequent keywords describe the length along each axis. These numerical values determine the logical shape of a data array. Translating them into narrative terms requires care because the first and second axes may have conventions that differ from how an image is drawn on a screen. Dimension order should be verified, not inferred from a chart.
A 1024 by 2048 image can be described as width and height only after checking the axis interpretation in the reader. A spectrum might use one axis and a data cube may use more. Preserve the header numbers and make the explanatory diagram match the actual indexing conventions.
9. The END card is not optional punctuation
The END keyword marks the end of a FITS header, and the remaining header block is padded as required. A translator might think END is a word that should be rendered into the target language, but inside the file it is syntax. Any localized explanatory sentence belongs outside the machine card. A malformed header may cause every following byte to be interpreted incorrectly, so this small distinction has large consequences.
A guide can state that END terminates the header; it cannot advise replacing the literal card with a translated phrase. Validate the data offset after a planned header edit. Correct file structure is not a matter of visual tidiness: it controls where the scientific arrays begin.
10. Primary HDU and extensions have different roles
The primary HDU appears first and may contain an array or just a header depending on the product. Extensions add more structured data. A primary image does not guarantee that all meaningful science resides in the first HDU. A translation should avoid calling later HDUs ‘attachments’ if that implies they are optional or irrelevant. Each can contain essential measurements and metadata.
An astronomical catalog file may have little primary image data but a rich binary table extension. In a localized viewer, teach users to inspect the extension list. Verify the same table and column contents across languages. A reader who never opens the extensions may miss the data entirely.
11. XTENSION identifies an extension type
An extension header uses structural keywords such as XTENSION to identify the extension class, alongside other required fields. Standard types include image and table extensions. Translators should explain these values but leave the literal extension-type identifiers in the file and programming examples. A friendly interface might say ‘table of detected objects’; a parser still expects the proper extension declaration.
Suppose XTENSION identifies a binary table. A translated document should not change that to ‘binary spreadsheet’ inside the FITS header. It may explain the concept in everyday language elsewhere. Check examples against a FITS library, because a visually plausible header string can be invalid.
12. Image data are measured arrays
An image HDU may contain one- or multi-dimensional numerical values rather than a ready-made color scene. Scientific interpretation depends on units, calibration, exposure, selection and context. A translator should resist assigning physical meaning to pixel values without checking metadata. Terms like counts, counts per second and calibrated flux are not interchangeable, even if they produce similar-looking image displays.
A detector records raw counts, then software generates a calibrated science image. The localized caption should say which stage the viewer shows. Test a known pixel against the raw and calibrated products; the two may legitimately differ because of processing, not language. Preserve the processing distinction in every version of the document.
13. BSCALE and BZERO affect the physical value
FITS supports linear scaling conventions that allow stored array values to be interpreted through factors such as BSCALE and BZERO. A common relationship is physical value = BZERO + BSCALE times stored array value, under the applicable image convention. Describing raw stored integers as already calibrated physical quantities can be wrong. Translation should clearly distinguish stored representation from computed physical interpretation.
An unsigned-style image representation may use an offset in the header. If a local-language tutorial skips that step, a user could report the wrong numerical values. Compare the same pixel through a FITS-aware library that applies the header interpretation, and document whether the example displays stored or scaled values.
14. Blank values and NaN are not ordinary zeros
Missing or undefined data may be represented using defined mechanisms that depend on the array type, such as the BLANK convention for integer images or floating-point NaN values. A translator should not rewrite missing as zero or promise all blank pixels are physically dark. The precise rule depends on the product and datatype. A scientific chart can look smooth while mishandling these gaps, so testing must include nonvalid data.
When presenting a star image with excluded pixels, use wording such as ‘undefined measurement’ where appropriate rather than ‘zero light’. Verify masks and counts of nonvalid samples in both locales. If a conversion to a simple image format collapses missing values, document the loss.
15. WCS ties pixels to world coordinates
A World Coordinate System, or WCS, can associate pixel coordinates with celestial, spectral, time or other world coordinates. It is more than a pair of labels on the axes. Reference pixels, reference values, projection types and transformation coefficients work together to determine the mapping. A translation that misstates which numbers belong to which axis may move an apparent source in a sky chart or misrepresent a wavelength.
A star at one pixel can be assigned a sky position using the header WCS. Changing the caption from English to Spanish must not change that result. Compare the coordinate of the same test pixel in both versions. If it moves, investigate the calculation or axis mapping rather than merely rewording the caption.
16. CRPIX and CRVAL define reference relationships
WCS keywords such as CRPIX and CRVAL help describe a reference pixel and its corresponding world value. Their numerical contents are part of the transformation. Do not translate them as ‘center’ without checking whether the reference point is actually at the center of the image. A simple explanatory example can make their relationship understandable, but should avoid implying all images share one reference convention.
A reference pixel may be offset from the visual center. If a target-language page states otherwise, a student may draw the wrong coordinate grid. Preserve the literal keyword spellings, units and indexed axis numbers. Test the declared reference location using a trusted WCS implementation.
17. CTYPE names a coordinate type
In WCS metadata, CTYPE values identify coordinate types and, for some axes, projection-related algorithms. These strings are format conventions and should not be translated into ordinary words inside the header. A written guide can explain that a celestial axis corresponds to right ascension or declination, but changing the machine value may change the computation or cause a parser failure.
A header using a celestial projection code should be described accurately in every language. Distinguish axis name, physical coordinate system and projection. If a glossary uses a local phrase for right ascension, record it as explanatory text while preserving the code required by the scientific tools.
18. CDELT, PC and CD describe transformation pieces
FITS WCS can use scale and matrix conventions to describe how pixel coordinates relate to intermediate coordinates. The details vary with the WCS representation and axes. A translation must not call every coefficient a ‘pixel size’ or assume all transformations are independent and axis aligned. Rotation and coupling matter. A useful guide explains the role of scaling and matrices without inventing a simplified model that the actual header does not satisfy.
An image may be rotated relative to the coordinate grid. If a local-language example omits the rotation, its sky directions may be wrong. Work through one test position using a standard library. Keep the coefficient keywords and indices literal and clearly distinguish illustration from the actual data model.
19. CUNIT gives units, not permission to convert
WCS keywords can declare units for coordinate axes. Their values are not arbitrary prose. A translated guide should distinguish the symbol stored in the header from the localized way of saying that unit aloud. A display may offer conversion to another unit, but that is a transformation requiring a correct numerical conversion and consistent metadata. It cannot be achieved by changing the word printed next to values.
A wavelength axis might be displayed in nanometers or another appropriate unit according to an explicit conversion. A translated caption should never imply that unchanged numerical coordinates suddenly have a different unit. Validate at least two known coordinates and preserve the source units in the technical reference.
20. Spectral coordinates require domain knowledge
A spectrum can be represented in wavelength, frequency, velocity or other spectral coordinates depending on the convention. These quantities are related but not interchangeable without definitions and reference frames. Translating ‘redshift’, ‘radial velocity’, ‘observed wavelength’ and ‘rest wavelength’ as casual synonyms can mislead readers. Scientific localization should identify the chosen physical interpretation before selecting words.
A teacher may show a line shift from an astronomical spectrum. The target-language explanation should say whether the plotted x-axis is measured wavelength or a derived velocity. Compare the labels and units with the WCS metadata. A correct linguistic phrase matters only when it denotes the actual quantity.
21. Time coordinates and observation timestamps
Astronomical metadata may express observation times using particular time scales and date conventions. UTC, TAI, TT and other astronomical time references are not synonymous. A localized date display must not casually switch them or remove an offset. The choice can matter for precise timing and reproducibility. A guide should identify the stored representation and the time reference before explaining it in natural language.
If a telescope observation started near midnight UTC, a localized civil-date display could show a different date in another timezone. That is a presentation change, not a different observation. Preserve the original reference time and document any conversion. Test a boundary time to ensure chronology is maintained.
22. Coordinates are not the same as positions on the screen
Many astronomy viewers let users pan, rotate, crop and flip an image. These display operations can change visual orientation without changing the original FITS data or WCS. Translation should clarify whether an instruction concerns the displayed viewport, the data array or a coordinate transform. Otherwise a reader may believe a change of language or orientation has altered the astronomical observation itself.
A localized button might say ‘flip east-west’. Verify whether it changes only the view or creates a transformed output file. If exported data change, document that behavior explicitly. Inspect a known sky position before and after any export to avoid silent coordinate mistakes.
23. Binary tables hold structured records
A FITS binary table extension stores rows and typed columns with defined formats and metadata. It is not simply text pasted into a grid. Column names, representations, units and null conventions help applications interpret the records. A translator may localize the column descriptions in a separate layer, but should treat machine-readable column identifiers and types as contracts until a deliberate migration is planned.
A star catalog table may include an object identifier, position, brightness measurement and uncertainty. Translate each explanatory caption carefully, while preserving source IDs and numerical columns. Compare row counts and sample records in both language viewers. A change in sort order should be labeled as presentation, not hidden as translation.
24. TTYPEn, TFORMn and TUNITn have distinct functions
In table headers, indexed keywords specify column names, storage formats and units. TTYPE and its index can name a column, TFORM specifies its representation, and TUNIT can give its unit. These fields answer different questions. Replacing a machine column name with a target-language phrase may break scripts, while modifying the unit without transforming values misrepresents measurements. The written guide must separate naming, representation and physical meaning.
Suppose a table has column FLUX, a numeric format and a stated unit. A French interface may show ‘flux mesuré’ while keeping the literal column identifier. Test a query that selects FLUX by name. Then verify sample values and units to show that localization did not alter the catalog.
25. Uncertainty columns deserve accurate words
Astronomical measurements often include uncertainties, flags, upper limits and quality indicators. A translation that turns an upper limit into an exact measurement or a confidence interval into a standard deviation can change the scientific conclusion. The metadata may use terse column names, so the translator must consult the associated science documentation. A fluent explanation should express the uncertainty model as carefully as the central value.
A source catalog may list a faint object with only an upper limit. Do not translate that entry into ‘brightness equals X’. Explain the limit and what it means for inference. Review examples that cover detections, nondetections and flagged measurements, not just easy valid rows.
26. Object IDs are evidence, not descriptions
Catalog source identifiers, observation IDs and instrument serials may look like text but behave as keys that link datasets and publications. Translating or reformatting them can break cross-references. User-facing descriptions can explain a source type, yet identifiers should remain exact. This includes punctuation, letter case and leading zeros where those are meaningful. A file may have many similar names that represent distinct observations.
If a target-language report cites an object called J1234+5678, preserve the identifier instead of approximating it with a prose location. Check that copy-and-paste searches still find the same record. When designing bilingual tables, put the stable ID beside the translated description.
27. COMMENT and HISTORY are useful but constrained
FITS headers can include commentary cards, including COMMENT and HISTORY. These may document processing steps and observations. However, the traditional card format and character restrictions do not make them an unrestricted multilingual text area. Editing these records may alter file structure or integrity metadata. A multilingual narrative can instead be maintained in accompanying documentation or a supported metadata convention, depending on project needs.
An observation’s HISTORY may record that calibration was applied. Preserve that provenance and explain it in a translated user guide. If the organization chooses to add comments to the file, validate character encoding and header layout with FITS-aware tools. Never replace source evidence merely because the original wording is awkward.
28. Checksums detect some changes
FITS has a widely used CHECKSUM and DATASUM keyword convention for verifying integrity of HDUs. The presence of these values provides a mechanism for detecting certain modifications or corruption. They are not ordinary descriptive text and should not be translated. Even a header-only edit may require checksum updates. Also, an apparently valid checksum does not prove a scientific interpretation is correct; it addresses a different assurance question.
A team changes a human-facing caption outside the FITS file and the original checksum stays valid. If it edits header cards inside the FITS product, verify the integrity metadata afterward. Use a recognized FITS verifier. Explain that byte integrity and semantic correctness are separate checks.
29. Compression is a technical convention
Some FITS products use recognized compression conventions and specialized software support. Translation should not imply that every reader understands every compression arrangement or that compression changes the telescope’s measured resolution. Describe the specific format and reader requirements. If a workflow decompresses or converts data, document whether any numerical precision or metadata is transformed rather than assuming a lossless scientific equivalence.
A colleague may open a compressed image with one astronomy package and fail with another. The localized troubleshooting note should identify feature support, not label the file ‘translated incorrectly’. Test representative pixels before and after any conversion, including missing-value handling and coordinate integrity.
30. FITS versus display images
A rendered PNG or JPEG may be useful for outreach, but it typically omits rich FITS metadata and may apply nonlinear stretches or color maps. A translation project may legitimately create a localized graphic with captions, yet should not call the graphic a complete substitute for the scientific FITS product. This is a question of evidence preservation rather than file size or visual quality.
For a public article about a nebula, show an accessible image and link to the underlying data archive where permitted. State that colors may be chosen for visualization and need not match human-eye appearance. The translated caption should distinguish observed measurements, processed display and any artistic rendering.
31. Archive provenance and reproducibility
Observation date, instrument configuration, processing pipeline, calibration file version and archive identifier can all be essential to reproducing a result. The translator must keep these distinctions intact. A description such as ‘raw’ or ‘calibrated’ should follow the source product’s true processing stage. Never make an uncertainty statement disappear merely because it sounds less polished in the target language.
A researcher compares an original exposure with a background-subtracted image. If the localized page calls both ‘raw exposures’, users may draw the wrong conclusion about noise or signal. Keep the processing history visible and use the same archive identifiers in all translations. Ask whether a reader can recover the same scientific source from the cited information.
32. File verification and meaning verification differ
A FITS verifier can check structural compliance, while a scientific reviewer asks whether the header and data mean what the documentation says. Both matter. A file can be syntactically valid yet describe a measurement incorrectly; a translated explanation can be elegant yet contradict a header. Build a review that checks header structure, array dimensions, WCS test positions, table fields, units and explanatory text separately.
A quality test can start with a known image and one standard sky coordinate. Verify the file, read the pixel and calculate its world position with trusted software. Then read the explanation in each language. If the numbers agree but the prose says ‘east’ where it should say ‘west’, the language test has caught a real scientific error.
33. Use a small teaching fixture
A minimal FITS example can include a primary two-dimensional image with recognizable pixel values, a few WCS keywords and one simple table extension. This is sufficient to demonstrate why the container has multiple layers. Students can inspect a header, identify a data type, find an HDU and verify one coordinate. The test should remain independent of the language of the instruction sheet.
Ask learners to locate BITPIX, NAXIS and a table column in the same sample file under two locales. The values should remain identical. Then have them explain the role of each term in their own language. This combines reading comprehension with scientific reproducibility rather than reducing the lesson to memorizing acronyms.
34. A bilingual FITS terminology sheet
A practical terminology sheet gives each FITS keyword its literal spelling, a plain-language meaning, an example and a warning about whether its value may be changed. It also holds accepted translations for observation, exposure, calibration, flux, spectral axis, pixel, WCS and measurement uncertainty. This prevents a UI designer from translating structural tokens and helps authors use consistent vocabulary across tutorials, catalogs and research summaries.
Place FITS keyword labels in a protected column and explanatory phrases in another. Review each entry with a scientist who uses the relevant data. For internationally distributed projects, record which convention or instrument document defines ambiguous field meanings. The glossary should improve comprehension without becoming an unofficial reinterpretation of the standard.
35. A safe review order for multilingual FITS projects
Start with the source file’s integrity and a trusted reading tool. Inspect the HDUs, required header cards and shapes. Identify the science variables, coordinate system, units and provenance. Separate technical identifiers from editable captions. Translate the human content, then compare numeric samples, header parsing, WCS positions and table row meanings across locales. Only after these tests should an international article or viewer be published.
A good acceptance record includes the input file identifier, tested software, example pixel position, computed sky coordinate and sample table row. It also records any known limitations. This evidence makes it easier to correct a later translation without guessing how the original product was interpreted.
Frequently asked questions
Can I translate FITS header keywords?
Do not translate mandatory machine keywords such as BITPIX or NAXIS inside a FITS file. Translate the explanation of those keywords in documentation.
Does BITPIX=-32 mean negative brightness?
No. The negative keyword value identifies a floating-point storage representation. It does not state the physical sign of the measured brightness.
Can a translated image caption change WCS?
A caption alone should not. Changing WCS metadata or coordinate-processing logic can change mapped positions and requires scientific testing.
What does HDU stand for?
Header/Data Unit. A FITS file has a primary HDU and may contain additional image or table extensions.
Can I freely insert Unicode translations into header cards?
Traditional FITS headers have strict card and character rules. Use a FITS-aware approach and supported conventions; separate localized documentation is often safer.
What is the role of BSCALE and BZERO?
They support linear interpretation of stored array values under the applicable FITS image convention. Do not conflate stored and scaled values.
Do CHECKSUM and DATASUM prove an explanation is correct?
No. They help check integrity of the HDU bytes under a convention. Scientific and linguistic interpretation needs additional review.
How can I test a FITS translation?
Use a known file and compare HDU counts, selected pixel values, types, table rows, units and one or more WCS coordinate calculations between language versions.
Primary references and technical verification
The references below are from the FITS standards and scientific software documentation. Some older pages discuss previous versions; use the current official standard as the deciding authority and verify the behavior of the software actually used.
NASA Science Data Portal: FITS Standard and primer
NASA GSFC: FITS Support Office
NASA: Official FITS Standard Version 4 reference page
NASA: FITS checksum convention
Astropy: FITS verification guide
Final perspective
A better translation should let more people explore the same universe, not create a different one. Preserve the observation, its coordinate mathematics and its chain of evidence. Then write the clearest possible explanation of what the reader is actually seeing.