Encoding & BOM issues

Symptom: CSV opens with mojibake (garbled text) in Excel #

Cause: the file was opened or re-saved by a tool that stripped the UTF-8 BOM, or that converted to a legacy code page (e.g. Windows-1252).

Fix: re-export from the app via File → Export translations…. Daxlate’s CSV writer always emits UTF-8 with BOM, which is what Excel on Windows expects for double-click open. If you’re working with a file that came from another source, re-save it as UTF-8 with BOM in Notepad++ or VS Code before importing.

Symptom: import fails with “codepage mismatch” or a parse error #

Cause: the file was saved without UTF-8 encoding, so non-ASCII characters arrive corrupted before they even hit the parser.

Fix: open the file in a text editor that exposes encoding (Notepad++, VS Code, Sublime), re-save as UTF-8 with BOM, retry the import.

Symptom: emoji or rare CJK characters drop on round-trip #

Cause: the spreadsheet was opened in an editor that doesn’t fully support Unicode beyond the Basic Multilingual Plane, or it was saved as a legacy CSV via “Save As CSV” in some non-Excel tools.

Fix: prefer XLSX over CSV for content that uses supplementary-plane characters such as emoji, rare CJK, and historical scripts. XLSX storage is unambiguous; CSV depends on whichever encoding the producer chose.

Symptom: import preview shows “Ignored unknown column: …” #

Cause: the file has columns that don’t match Daxlate’s header pattern (Object ID, Type, Parent, Name, Caption ({culture}), Description ({culture})). Translators sometimes add notes columns, and the importer drops them with a warning rather than failing the whole import.

Fix: if the warning is expected, ignore it. If a culture you expected isn’t being detected, check the column header. It must be exactly Caption (xx-XX) or Description (xx-XX) with parentheses and a valid .NET culture code.