Docs · Reference

Encodings and byte-identical exports

A file should come back the way it went in. Localization OS reads legacy encodings by the source language, never guesses silently, and writes your file back in its own encoding wherever the translation fits.

Untouched files export byte-identical#

When a file has no translation for the language you export, you get back exactly the file you uploaded, byte for byte. No language attribute, header or stamp is added, quote styles and attribute order are not normalized, and line endings, byte-order marks and legacy encodings are left alone. The file is still checked by its own parser before it is returned.

Translated files keep their encoding#

A translated file is rebuilt from your original, and keeps:

  • its line endings (CRLF stays CRLF),
  • its byte-order mark, if it had one,
  • its legacy code page (for example Windows-1252), as long as every character of the translation exists in that code page.

When the translation needs characters the original code page cannot hold, for example Russian text written into a Windows-1252 file, the file is written as UTF-8 instead, and every charset label inside the file is changed to say UTF-8. A file never carries a label that names a different encoding from the one it is written in, and characters are never replaced with question marks.

Reading a file#

For text-based files, the encoding is decided in this order:

  1. A byte-order mark, or valid UTF-8.
  2. UTF-16 with a byte-order mark.
  3. A charset the file declares itself (HTML, SVG and PO files, for example).
  4. The Windows code page of the project's source language, for a file that is not UTF-8 and declares nothing.
  5. Windows-1252.

There is never a lossy decode. A file that cannot be read as any of these is refused with a request to re-save it as UTF-8, and the same message appears on the web, the API, the CLI and MCP. The code page that was used is recorded on the document, so later exports and repairs read the original the same way.

When the decoded letters look wrong, for example two scripts mixed inside one word, words made mostly of accented letters, or a file that is partly UTF-8, the upload still succeeds with a text encoding warning on the document page, in the upload response, in the CLI and in MCP results. If the source language's code page reads the file badly but Windows-1252 reads it cleanly (a Western file in a Greek project), it is read as Windows-1252 and the warning says so. A language's own accented letters never count as garbled. Check the source segments, and if they are garbled, re-save the file as UTF-8 and upload it again.

Code pages by language#

Source languageCode page used for an undeclared legacy file
Western European languages (English, French, German, Spanish and others)Windows-1252
Czech, Polish, Hungarian, Croatian, Slovak, Slovenian, Romanian and other Central European languagesWindows-1250
Russian, Ukrainian, Bulgarian and other Cyrillic languagesWindows-1251
GreekWindows-1253
Turkish, Azerbaijani, UzbekWindows-1254
Hebrew, YiddishWindows-1255
Arabic, Persian, UrduWindows-1256
Estonian, Latvian, LithuanianWindows-1257
VietnameseWindows-1258
ThaiWindows-874
JapaneseShift_JIS
Chinese, SimplifiedGBK (GB18030 when GBK cannot read it)
Chinese, TraditionalBig5
KoreanWindows-949

A language with no Windows code page (Hindi, for example) uses Windows-1252 for this step. Documents uploaded before this rule keep the encoding they were imported with.

Formats with their own rules#

  • gettext PO: a translated catalog is always UTF-8 with a UTF-8 header, and a catalog without a header gets one (charset and target Language). An untouched catalog still comes back byte-identical.
  • Java properties: stay ISO-8859-1 by the Java rule; characters outside it are written as \uXXXX escapes.
  • HTML Help (.hhc, .hhk, .hhp): written in the target language's Windows code page, because HTML Help 1.x shows its contents and index in that code page. A translation the code page cannot hold is refused with the character named, unless the operator allows a UTF-8 fallback. The code page is read from the .hhp project file when it is present.
  • Windows resource scripts (.rc): keep UTF-16, UTF-8 or the declared ANSI code page; a translation that does not fit is written as UTF-8 with a matching code-page pragma.
  • CSV and TSV: keep UTF-8 with or without a byte-order mark and UTF-16; a Windows-1252 file is exported as UTF-8 with a byte-order mark.
  • QuarkXPress Tags: written in the encoding the file header names, switching to UTF-8 (and updating the header) only when needed.
  • AutoCAD DXF: older drawings keep their declared code page; a character it cannot hold is written as a Unicode escape.
  • Email: a changed part keeps its charset and transfer encoding when the translation fits, and otherwise switches to UTF-8 and says so in its headers.
  • UTF-8 only: Mozilla DTD, Fluent, TOML and desktop entries; any other encoding is refused with a re-save message.

Current limits#

Current limits

Translated YAML and SSA/ASS files that started in a legacy code page or UTF-16, and translated Windows-1252 INI files, are still written as UTF-8.

A few very short files cannot be decided: one accented letter that also reads as one valid Chinese character stays silent in a Chinese project.

A container format (a zip package, for example) uses one code page for the whole parse.