Multilingual internal communications for distributed workforces

TLDR: Multilingual internal communications usually break at the point of layout rather than the point of translation – text expands, the design does not, and someone shortens the call to action to make it fit. Translation is a production stage that has to be planned before design, not a service bought after the artwork is signed off. What changes the outcome is designing for the longest language and treating cultural context as a separate question from vocabulary.

An organisation with sites in three countries commissions a safety campaign. It is written in English, designed in English, approved in English, then sent for translation two days before launch. The Portuguese version comes back 30% longer. The designer, working at speed, reduces the type size and cuts a line. The line that goes is the one explaining what to do, because it was the longest.

The campaign runs. In two countries it works. In the third, people report that the posters were confusing. The conclusion drawn is usually that the translation was poor. It rarely was.

This sequence repeats across large organisations because multilingual internal communications are treated as a finishing step rather than a production constraint. The W3C, writing about the same problem in a different context, notes that text translated out of English is typically longer than the original, sometimes considerably, and that the fix is flexible layout rather than tighter editing. That advice was written for web pages. It applies with more force to print, which cannot reflow at all.

What are multilingual internal communications?

Multilingual internal communications are communications produced for a workforce that reads in more than one language, where each language version is planned as a parallel output rather than a derivative of an original.

The distinction between parallel and derivative is the whole argument. A derivative version inherits every constraint of the source language – its word lengths, its idioms, its reading direction, its assumptions about what needs explaining. A parallel version inherits only the message.

Most organisations run derivative multilingual internal communications and describe them as translated. The difference shows up under pressure: at speed, a derivative process degrades the non-source languages first, because they are produced last.

Language and culture are two different problems

In multilingual internal communications these are routinely merged, and merging them produces communications that are linguistically correct and locally meaningless.

Language is the vocabulary problem. Does this word exist in the target language, is it the right register, does the technical term have an agreed local equivalent, does the sentence make sense.

Culture is the interpretation problem. Does the example resonate. Is the tone appropriate to the relationship between employer and employee in this place. Does the photograph show something recognisable. Is directness read as clarity or as rudeness. Does a colour or gesture carry a meaning here that it does not carry there.

A message can be perfectly translated and still land wrong. The classic case in industrial settings is the recognition campaign designed around individual achievement, translated faithfully, and deployed in a workplace culture where singling one person out reads as a criticism of everyone else.

Colour behaves the same way. Associations vary by region and by context, which is one reason the safety colour conventions matter – they are standardised precisely because intuition is not reliable across borders. This overlaps with colour in internal communications more broadly.

The practical implication: translation solves the language problem. Only local review solves the culture problem, and local review is a different task requiring a different person.

Why multilingual internal communications fail

Five recurring causes, in rough order of frequency.

Translation is scheduled after design. The layout is fixed before anyone knows how long the text will be. Everything downstream is compromise.

One language is the “real” one. The English version is approved and the others are checked. This makes the non-English versions structurally second-class, which employees notice.

Technical terms are translated inconsistently. The same piece of equipment has three names across four documents because four translators worked without a glossary.

Local reviewers are asked to approve rather than adapt. A reviewer given a finished artefact and a deadline will correct spelling. A reviewer given a draft and permission will tell you the example does not work.

Verbal and printed channels are forgotten. Considerable effort goes into translating the intranet, and the toolbox talk – which is where most frontline employees actually receive information – is delivered by a supervisor working from an English printout. Multilingual internal communications that stop at the screen miss the channel most frontline people rely on.

That last one is the most consequential in mixed-access organisations and the least likely to appear in a translation budget.

How do you plan multilingual internal communications properly?

The sequence below front-loads the decisions that are expensive to reverse.

1. Establish the real language map

Not the official one. Which languages do people read comfortably, as opposed to which languages the organisation operates in. These differ more often than expected, particularly where a lingua franca is used for work but not for anything requiring nuance.

Note literacy levels honestly as well. In some workforces, a proportion of employees will rely on spoken briefing and visual instruction regardless of language. That is a design input, not a footnote.

2. Write the source text for translation

Short sentences. One idea per sentence. Active voice. No idiom, no wordplay, no cultural references, no puns in headlines. The W3C’s internationalisation quick tips reduce to much the same advice: keep text simple and concise.

This is a real constraint on English copy and it is worth naming to whoever is writing it. A headline that works because of a pun in English becomes untranslatable, and someone will have to invent a replacement under time pressure.

3. Build a glossary before the first campaign

Fifty to a hundred terms: equipment names, job titles, safety terminology, benefit scheme names, the organisation’s own coinages. Agree the equivalent in each language once, with local input, and reuse it. This single artefact prevents more inconsistency than any other intervention.

4. Design for the longest language

Take your longest target language and design the layout to fit that, then allow the shorter languages to sit in the same frame with more white space. The alternative – designing for English and compressing everything else – produces the type-size creep that makes translated materials visibly worse than the original.

Practical allowances: leave roughly 30% expansion room in text areas, avoid fixed-width boxes and tight columns, keep text out of images so it can be replaced without re-rendering artwork, and never set a headline in a space that only fits the English.

5. Separate translation from local adaptation

Two stages, two people, two purposes. Translation converts. Adaptation checks whether the converted thing makes sense here – the example, the image, the tone, the assumed knowledge. Give the local reviewer the draft, not the finished file, and give them explicit permission to change more than words.

6. Translate the spoken channels too

Supervisor briefing notes, toolbox talks, safety inductions, the script for a screen with audio. If a supervisor delivers in a local language from an English source, they are translating live, without a glossary, under time pressure. That is where terminology drift originates and it is entirely preventable.

7. Version-control every language equally

When the English is updated, every other language is now out of date. Without a system that flags this, sites run on superseded versions for months. This is one of the strongest arguments for a managed asset library, covered in internal communications asset management.

What about machine translation?

It has become good enough to be useful and is still not sufficient on its own. A workable position for most organisations:

• Reasonable for low-stakes, high-volume, short-life content where speed matters more than nuance – a shift notice, a canteen menu change, an internal FAQ
• Not appropriate unreviewed for anything safety-critical, contractual, disciplinary or emotionally sensitive
• Never appropriate as the only step for anything that will be printed and displayed for months
• Always better with a glossary supplied, which most systems now support

The failure mode is not gibberish – modern output rarely produces that. It is fluent text that is subtly wrong, which is harder to catch because it reads well. A native reviewer catches it. A spell check does not. The same caution applies to AI-assisted drafting generally, which we cover in AI workflow for internal comms.

Designing across cultures in a distributed workforce

Beyond language, a handful of design decisions carry disproportionate weight in multi-country organisations, and they sit outside the scope of translation entirely.

Photography. Images of workplaces that do not resemble the reader’s workplace read as being about someone else. Where possible, use images from the sites the communication is going to. Where that is not possible, choose neutral over aspirational.

Iconography. Icons are less universal than they appear. Hand gestures, animals, currency symbols, and anything derived from a specific alphabet all carry local meaning. Safety symbology is the exception, because it is standardised – another reason to align with the HSE’s guidance on safety signs rather than designing bespoke alternatives.

Names and forms of address. Name order, honorifics and the acceptability of first-name address vary. Getting this wrong in a personalised communication undermines everything else in it.

Hierarchy and attribution. Who a message comes from changes how it is read, and the appropriate signatory differs by culture. A message from a named site manager may carry more weight in one location than one from a group executive, and the reverse elsewhere.

Numbers, dates and units. Date formats and decimal separators cause real operational confusion. Write months as words in anything that crosses borders.

None of this is about avoiding offence, though it does that too. It is about whether the message is understood as intended by someone whose working day looks nothing like the one imagined in the room where it was written.

A working checklist

Before the next campaign involving multilingual internal communications:

• Real language map documented, including reading confidence rather than official language
• Source text written to translation standards – short, literal, no idiom
• Glossary agreed in every language, with an owner
• Longest target language identified and the layout designed to fit it
• 30% text expansion allowance built into templates
• Text kept out of image files
• Translation and local adaptation booked as two separate stages
• Local reviewers given drafts and explicit permission to adapt
• Supervisor briefing notes and toolbox talks included in scope
• Update process that flags every language when the source changes
• Machine translation policy agreed by content type
• One named owner per language

The structural point

Multilingual internal communications are not a translation budget. They are a production sequence, and the order of that sequence determines quality far more than the quality of the translator. Organisations that plan language at the start produce parallel versions of comparable standard. Organisations that plan it at the end produce one good version and several apologies.

Where a distributed workforce reads in several languages, that sequence needs to be designed once and reused. If it is currently reassembled campaign by campaign, then it might be a good time to consider a more structured approach with CommsKit.