§ Make Source Content Easier to Localize

1. The sentence is read late at night by a person trying to make a trade in a 2nd language. The phrase "hit it out of the park" or "set it and forget it" needs to be cut from the copy as a translator will either not know what to do with the phrase or it will be "flattened" and all of the warmth that was put into the copy will be lost. In addition to cutting out humor and puns first, stacked clauses in long sentences need to be split up into separate sentences as many languages including German and Japanese change the word order of the sentences and thus long complicated sentences with stacked clauses get all "tangled up".

2. We've decided to cease creation of feature-based copy in metaphors and switch to writing based on the customer's pain points. Thus, "Your platform never sleeps" has become "Your trading platform keeps running even when your computer is off." Such writing is even more plain in English, but now translators don't come to us with questions on clarification and customers from outside of English-speaking countries immediately grasp our offers on the first reading. Maintaining the website also became much easier. Now, when we change some feature, we simply update one plain line instead of rephrasing an entire clever passage in all languages in which we publish. Plain language is the most respectful thing to offer to your international audience.

Cut anything that only works in the original language. Idioms, puns, sports metaphors, jokes built on wordplay. If a sentence needs a footnote to survive translation, rewrite it before it goes to the translator. 'Hit it out of the park' becomes 'exceeded the target.' Less charming, far easier to carry into five languages.

We write web content in both French and English, and the biggest lesson is that translation and search don't line up. People in each language search with different words for the same thing. A literal translation of a page can be perfect grammar and still miss what people actually type. So we keep the source simple and the structure clear, then let each language version choose its own key terms.

The one change that made the biggest difference: one idea per sentence. Long sentences with three clauses get rearranged differently in every language, and meaning drifts. Short sentences translate cleanly, update easily and read better anyway.

Legal text doesn't get simplified before translation. It gets finished.

I run a template site for European markets that publishes in German, French, Italian and Swedish. I write English and French, so most of those versions are languages I can't check myself. The privacy policy is the clearest example of how I handle that: drafted in English, signed off, and only then translated into all four. That sign-off step is the change that made it maintainable. Every edit made after translation begins becomes four edits, three of them in languages I can't read.

What deserves simplifying is anything that leans on a concept from one legal system. A common-law term with no clean civil-law equivalent shouldn't be translated word for word. The source sentence should describe what the clause does, so whoever translates it has a meaning to carry rather than a word to match. Idioms go too, though in legal drafting there shouldn't be many to begin with.

The source is the only version I can fully read. It had better be the one that's right.

Deciding which elements to simplify for global translation requires a ruthless audit of functional utility, specifically targeting any phrasing that relies on cultural context rather than literal meaning. When managing technical documentation across international delivery hubs, the decision to simplify hinges on identifying text that lacks a direct equivalent in the target languages. The most significant change you can make to improve multilingual communication is enforcing a strict standard of active-voice, single-clause sentences supported by a locked glossary of technical terms.

Content must be broken down into direct subject-verb-object instructions rather than multi-clause descriptions that lean on figurative language. Replacing an idiom like "compliance needs to be built in from day one" with the literal "the system must comply with regulatory standards upon deployment" removes the risk of distortion. This shift to structured, literal source documentation drastically reduces localization turnaround and ensures core requirements remain uniform across all markets. Efficiency in global communication is only possible when you treat source text as a structured system, keeping it direct and entirely free of localized dependencies.

When content will be translated, we simplify the parts that historically caused confusion when delivered as written materials alone, especially insurance jargon and long, passive explanations that needed in-person clarification. We prioritize turning technical terms into practical, concrete descriptions and removing language that assumes deep prior knowledge. One change that made multilingual communication clearer was replacing insurance language with real examples and plain descriptions of deductibles and out-of-pocket exposure. That approach made translations easier to maintain and reduced the need for repeated clarification during enrollment sessions.

I'm Charles Liu, founder and Marketing Director of Cubic Promote, a Sydney-based business employing around 30 people across Australia, the Philippines, Vietnam, and India.

Working with people across different countries has taught me that even when everyone speaks English, the same sentence can be understood differently.

When preparing content for different languages, I look for expressions that only make sense to Australians, vague instructions and sentences that try to explain too many things at once. Phrases like "we'll get the ball rolling" or "get this sorted by arvo" might sound perfectly normal here, although they're not particularly helpful when someone has to translate them.

I also pay attention to dates, deadlines and technical terms. In our business, there's a difference between receiving an artwork proof, approving it and actually starting production. Those details need to stay accurate regardless of the language. I prefer short sentences that explain who needs to do what and when.

One practical change has been making our artwork approval instructions more specific. Instead of informal wording like "Please sign off ASAP so we can get things moving", we use clearer instructions along the lines of "Please check the logo, spelling, colours and placement. Once you approve the artwork proof, we can begin production."

It's a small change, although it removes quite a bit of guesswork. The customer knows what they're approving, and our team has a clearer understanding of what needs to happen next.

We also try to use consistent wording for the same stages of an order rather than switching between different expressions. When content needs updating or translating, having one agreed term makes it easier to keep the information consistent.

I've found it's much easier to get the English right first, before translating anything. We try to keep the important details, cut out expressions that might confuse someone overseas and make sure the instructions are straightforward.

You don't need to strip all the personality out of your writing. You just need to make sure the meaning survives when someone reads it in another language.

One change that made our multilingual text easier to maintain was about characters, not idioms.

At Streamrise, the interface text for our ordering panel lives in a translations table and is rendered through vue-i18n, a common JavaScript translation library. In that library, a few ordinary characters have special meaning inside a message: @ links to another message, curly braces mark a variable, and | separates plural forms.

We learned that the hard way. A short product description added to the table included a plain link in the form youtube.com/@name. The library tried to read the @ as a reference, failed to compile the message, and the whole YouTube order form rendered empty. One description broke a working page.

The rule we adopted: source text for translation never contains those characters in raw form. An @ is written as a placeholder that is swapped back after translation, braces and pipes are avoided, and every new string is run through the library's message compiler before it goes into the table. It's a small change to the source, but it means a translator can't accidentally break the page, and a broken string fails in a check instead of in front of a customer.

For anyone deciding what to simplify before localization: start with anything your software treats as syntax, not just language. Idioms confuse readers. Special characters can take a page down. The second is easier to prevent, because you can check it automatically before a single translator touches the text.

When content will be translated, I simplify any wording that fails to communicate the main idea quickly and favor phrasing that places the key concept or keyword near the start of the sentence. I apply the same test I use for social captions: if a line is not descriptive enough for a reader or search to grasp the topic immediately, it gets rewritten. I also review which searches our social accounts appear for and use that data to decide what to trim or reword before localization. One concrete change that has helped is making captions more descriptive and moving the target keyword or core topic to the beginning of the sentence, which gives translators a clear, intent-focused source to work from.

Simplify anything the translator would have to guess at, and keep anything that carries the meaning.

The test I use: if a sentence needs a footnote for a reader in another country, it gets rewritten before it goes out, not patched in each language afterwards. That catches idioms ("hit it out of the park"), culture-bound references (holidays, sports, store names), stacked noun phrases ("creator ad performance review flow"), and pronouns that point back two sentences. Product names, numbers, units and legal wording stay exactly as they are.

The single change that helped most was splitting the copy from the claim. Each source line gets one short, literal version of what it must say ("free for 7 days, then billed monthly"), and the persuasive phrasing sits on top of it. Translators adapt the phrasing freely but never touch the literal line, so every language says the same thing even when the wording is completely different. It also makes updates cheap: when the offer changes, you edit one literal line instead of re-translating a marketing paragraph in twelve languages.

Joey Tang, Founder, AdsTurbo

Before translating, I would simplify anything that asks the reader to guess what a service includes. Keep the operating facts precise, even if the surrounding promotional language becomes shorter.

One useful change to our Hebrew customer copy at Elvis Loft & Karaoke was to explain that the entire venue is reserved for one group at a time. 'Private karaoke' can leave room for different interpretations. The fuller statement tells a translator exactly what must survive in the other language: the group has exclusive use of the venue. Our website has Hebrew and English pages, and the English page also describes exclusive use by one group.

Local shorthand needs a separate check. For example, the Hebrew abbreviation for Saturday night is familiar to Israeli customers but needs to be written out for an international reader. I would give the day and the relevant opening time explicitly rather than expect a translator to infer the schedule.

For content maintained in several languages, I would keep a short reference list of the facts that can change, such as capacity and booking conditions. Review those against every language version after an update. There is more room for freedom in an invitation to celebrate than in a sentence explaining when a reservation becomes confirmed.