Escape sequences

An escape sequence starts with an escape character, usually a backslash (\), followed by one or more characters that define its meaning. For example, \n tells the program to insert a line break, \t inserts a tab, and \" represents a literal quotation mark inside a string. Rather than storing the actual character, the file stores this shorthand, and the application interprets it at runtime.

In localization, escape sequences sit inside the same string files that translators work with. That makes them a common source of errors. A translator who sees \n may not recognize it as functional code and either remove it, add a space after the backslash, or translate the letters themselves. Any of these changes can break the application.

🤔 Why escape sequences cause problems in translation #️⃣

The risk increases when teams work across multiple platforms, because different file formats use different escape sequence syntax. A translator familiar with JSON files, where \n means newline, may not know that iOS .strings files use \U00f1 for Unicode characters. The same backslash, different rules, and no visible indication of the difference in the string itself.

CAT tools handle this inconsistently too. Some hide escape sequences from translators entirely, others display them without explanation, and some offer no protection at all. Without clear instructions or automated checks, the burden falls on the translator to know what to leave untouched.

🔧 Common escape sequences across platforms #️⃣

• \n — newline
• \t — horizontal tab
• \r — carriage return
• \\ — literal backslash
• \" — double quote inside a string
• \uXXXX or \UXXXXXXXX — Unicode character by code point
• \xXX — character by hexadecimal value
• \0 — null character

📄 How file formats handle escape sequences #️⃣

• JSON — uses C-style backslash escaping. Quotes, backslashes, and control characters all require escaping inside string values.
• YAML — double-quoted strings support C-style sequences. Single-quoted strings only allow '' for a literal quote. Unquoted strings treat backslashes literally.
• Java .properties — uses \uXXXX (always 4 hex digits) for Unicode. Special characters in keys may need escaping; values are more lenient.
• iOS .strings — uses \U (capital U) followed by 4 hex digits, which differs from the standard C-style \u convention.
• XML — uses HTML entities (<, &, ") instead of backslash sequences. CDATA blocks allow raw text without escaping.
• Gettext .po files — uses C-style sequences in both msgid and msgstr. Translators must preserve them exactly.

⚠️ Common problems and how to address them #️⃣

• Translators modify or delete escape sequences — use CAT tools with escape sequence protection, provide explicit instructions, and run automated QA checks before deployment.
• Different formats use different syntax — document which format applies to each file and use format-aware parsers during import and export.
• Escape sequences appear as literal text in the app — check that the file encoding is correct and that the parser is configured to interpret escape sequences rather than treat them as plain text.
• Unicode escapes render incorrectly — where possible, replace Unicode escape sequences with actual UTF-8 characters. This is the recommended approach for modern systems.

How Localazy helps #️⃣

Localazy’s translation interface and built-in QA checks flag issues with placeholders and escape sequences before translations go live. Translators working inside the platform are less likely to encounter raw escape sequences directly, and validation runs automatically to catch missing or modified sequences early in the workflow.