When someone uses mySociety software to report a street problem, or make a Freedom of Information request, it’s often in a language other than English, because our code is used to power sites all over the world.

That’s fine: we include a facility for people to add translations to the sites they deploy, so, job done, right?

Except, unfortunately, there’s more to it than that. However much we complain about the idiosyncrasies of our language, there’s one thing English has got going for it, and that’s conciseness. And that means that words and phrases which fit quite nicely into our designs suddenly become problematic.

A recent front-end design ticket in Alaveteli, our Freedom of Information platform, centred around improving the display of various standard elements (the navigation bar, language switcher, logged-in user links) when the Alaveteli site in question is displaying in a language other than English.

Here’s a picture which shows exactly why that was an issue:

It was enough to make a designer sob.

To put it bluntly: As soon as those carefully-crafted navigation bar links get translated, all bets are off as to whether they’ll continue to fit in the space provided. It’s an issue that’s faced by anyone creating software designed for international reuse.

So I figured I’d share a few things the mySociety design team has learned about internationalisation, and one quick trick that I recently started using to test international language lengths on our own websites.

The problem

Not only are some languages more verbose than others (ie: they use more words to convey the same concept), but many use more characters per word.

Then there are other languages which use fewer—but more complex—characters that need to be displayed larger to still remain legible.

The W3C (which sets standards for the web) suggests that front-end developers can expect the following ratio of increase/decrease in visual text width when translating from English into this handful of common languages:

Language	Translation	Ratio
Korean	조회	0.8
English	views	1
Chinese	次檢視	1.2
Portuguese	visualizações	2.6
French	consultations	2.6
German	-mal angesehen	2.8
Italian	visualizzazioni	3

That’s a 150–200% increase in space required to display words in the European / South American languages that we deal with quite a lot here at mySociety.

Often, you’re lucky, and the layout includes enough space to absorb the extra words. Headings and paragraphs of text are really good at this. Indeed, as the amount of text to be translated gets bigger, you notice that the translation has less effect on space, as the W3C, again, notes:

No. of characters in English source	Average expansion
Up to 10 characters	200–300%
11–20 characters	180–200%
21–30 characters	160–180%
31–50 characters	140–160%
51–70 characters	151-170%
Over 70 characters	130%

So—no need to worry—it’s just short little bits of text that hurt the most. Phew.

Hang on, short little bits of text… like all those buttons and links all over every single website mySociety makes?

Don’t panic!

That’s what mySociety has designers for 🙂

There are lots of tricks we can use to reinforce our layouts to better handle long strings. For instance, where possible, we avoid creating horizontally-constrained navigation bars.

And in some cases, we can use modern styling techniques like Flexbox to better handle overflowing text without harming legibility or the overall layout of the page.

But testing the effectiveness of these techniques can take time and, while we have a fantastic network of volunteers and international partners who translate our open source projects, we’re often working on the initial layout and styling before that has a chance to happen.

While I was working out fixes for the Alaveteli user links and language picker dropdown, I threw together a quick “pseudolocalize” function that temporarily makes the text longer, so we could preview how it’ll look once it gets translated.

Only later did I discover that “Pseudolocalization” is, apparently, a real thing, originating from the Windows developer community.

Typically existing Pseudolocalization functions would do all sorts of orthographic substitutions to test how weird characters are displayed, as well as padding the strings to make them longer. So, something like Account Settings would be transformed into [!!! Àççôûñţ Šéţţîñĝš !!!].

My little function skips the weird character substitutions, and instead just doubles the text content of any elements you tell it to.

So you can run…

pseudolocalize('.navigation a')

…in your browser console, to turn this…

…into this!

Yep, it’s useful and it’s ridiculous — our favourite combination.

Plus, it’s super fast, and it works with nested elements, so if you were totally crazy, you could just run it on the entire 'body' and be done with it!

pseudolocalize('body')

Now, we’re not saying we’ll be able to cope with, say, the longest word in Sanskrit, which is 431 letters long, but this approach does make us pretty confident that we’ve got a great basis for whatever most languages can throw at us.

If you’re a web developer with similarly ingenious tricks for improving the internationalization of your sites, share them in the comments box!

Photo of Nepalese prayer wheels by Greg Willis – CC BY-SA 2.0