But what happens when that source file becomes blurred ?

A "blurred English language file" is not a technical file format error. It is a state of decay. It occurs when the master English text loses its clarity, precision, and context, leaving developers lost and translators guessing. You know you are dealing with blurred English strings when you see the following in your source code repository:

A string simply reads: "Save" . Is this a button to save a document? A dialog asking if the user wants to save their progress before quitting? Or a status indicator that the system is saving? Without context, the translator must guess. In German, the translation for "Save" as a command ( Speichern ) versus a noun ( Rettung ) are radically different. The blur is dangerous.

Many blurred files contain strings like: "You have " + count + " messages." While grammatically correct in English, this is a nightmare for other languages. In many languages, the adjective or verb changes based on the number (Polish, Russian), or the word order reverses entirely (Japanese, Irish). A sharp file uses plurals properly (e.g., {count, plural, =0 {No messages} =1 {One message} other {# messages}} ). A blurred file ignores this.

Treat the English string like an API. Use pseudocode for logic. Instead of "Files copied: 5" , use {filesCount, plural, one {File copied} other {Files copied}} .

In the world of software development, game design, and technical documentation, the English language file (usually a .json , .po , .properties , or .xliff file) is considered the "source of truth." It is the clean, sharp original from which all other translations—French, German, Japanese, Arabic—are derived.

Sharpen your source strings. Add context. Use plural rules. Your translators—and your international users—will thank you. Because in the end, a product is only as clear as its blurriest source file.