The Government Digital Service (GDS) strategy’s first mission is to maintain “GOV.UK as the single and trusted online destination for government information and services”. To do this, we need to make sure GOV.UK is accessible to all our users, including providing information in multiple languages to reflect that our users speak a variety of languages.
GOV.UK pages appear in more than 60 languages alongside English and Welsh. For example, British embassies’ pages, which are used to summarise their local work, are often translated into local languages.
Vital information on subjects like coronavirus (COVID-19) may be translated into languages spoken in the UK in order to be more accessible, for example we have the NHS COVID Pass letter in Nepali. Press releases are also sometimes translated into languages of interest, like this German-language page about the UK signing a Joint Declaration with Germany.
GOV.UK’s roster of languages has grown organically in our first decade. It’s been possible to add new languages fairly quickly when needed, without spending time developing too many formal processes or policies. However, over time this approach has led to some technical problems.
Issues with online page furniture
These problems are most acute in the translations of what we call page furniture: the headings, menus and other pieces of text that aren’t included in the main content of a GOV.UK page. While the main content of pages can be edited easily by publishers in GDS or across government, page furniture is stored in the codebase, so it’s harder to change.
Out of over 50 applications we use on GOV.UK, only 4 use translations. For these applications, we store the translations of page furniture in what are known as locale files. These are text files that store words which we want to use time and time again in translation. There is typically one locale file, per language, per application, and since GOV.UK has over 60 languages, and 4 applications using translations, we have several hundred locale files to manage. In the past, we haven’t done that very tidily.
Here’s an example of a locale file. This is part of the old Spanish locale file for our Whitehall Publisher application.
When a user visits a Spanish-language page produced by the Whitehall application, we use this set of translated words to find the correct Spanish translation. Each green piece of text is called a key, and corresponds to a piece of text that is used in multiple places on the site. These keys are consistent across different languages’ locale files.
For example, ‘announcement’ might appear next to an article on the site. On an English page, it will be labelled with ‘announcement’, but on a Spanish page we use the locale file to find the translation: ‘anuncio’. Every other language’s locale file will similarly have its own translation of ‘announcement’.
But as you can see, the translation for ‘blog_post’ is missing. As a result, if we tried to show the Spanish translation of ‘blog post’ on a page hosted by Whitehall, we would instead fall back on the English as a back-up. That would mean users seeing the English words ‘blog post’ on a Spanish page instead of ‘entrada de blog’, which is obviously a poor user experience.
However, other languages were in a worse state. This image shows how the equivalent locale file for Vietnamese used to look.
The Vietnamese locale file doesn’t contain any translations at all, which meant that lots of Vietnamese page furniture would have appeared in English on the site.
Furthermore, locale files should be formatted consistently, so the Vietnamese file should have exactly the same format as the Spanish. But as you can see, the list of words is very different.
This inconsistency was causing us several problems. It made the site harder to maintain, and made it harder to compare the state of translations in different languages. It also made it very complex to source translations.
Fixing our locale files
We therefore undertook a piece of work to standardise the format of all of our locale files. There were several stages.
First we needed to make sure that all of the necessary locale files actually existed in our codebase. Then we checked that each locale file contained the same lists of keys, in the same order. We also standardised how we stored plural forms of words.
Once all of the locale files were in the same format, we could extract all the words that hadn’t been translated before, and get them translated by an external agency. Finally, we added the newly translated words to our locale files.
As a result, for the first time all of our locale files are consistently formatted and fully translated. Moreover, many words that were incorrectly appearing in English on GOV.UK are now translated, which is a noticeable improvement for users.
For example, this Arabic article about the ambassador to Lebanon previously displayed the ‘World news story’ header in English instead of Arabic, and is now all in Arabic.
And this Kazakh-language biography of the deputy head of mission to Kazakhstan used to show its list of contents in English, but is now all in Kazakh.
Further improvements for users
As well as working on locale files, we also addressed some separate issues that were comparatively low-effort for us, yet high-impact for users.
For example, the featured links that appear at the top of many pages couldn’t previously be translated; when they could, the links would always lead to the English language content for the link, which was a jarring user experience.
It’s now possible for content designers to translate the links and to associate them with a translated page - another improvement for our users. This can be seen on the Welsh-language Companies House page which now has these links in Welsh, whereas for a long time they were in English.
We've also recently made it possible to add translations of social media accounts to organisation pages in other languages. This had been a long-standing problem for pages belonging to organisations like the Foreign, Commonwealth & Development Office.
What’s next
These changes have made using GOV.UK in other languages a better experience for users. They've also helped us identify further improvements to translations for the future.
In this coming quarter we’ll be working on which languages and content types we need to prioritise. Subscribe to the blog to keep up to date on our work.
6 comments
Comment by Clare, content designer at GDS posted on
Very interesting and thanks for sharing! Is there a policy to not transliterate proper nouns in headings into other alphabets or scripts? As seen in the Kazakh example.
Comment by GOV.UK team posted on
Thanks Clare! At the moment, we do not have a policy on translating proper nouns into different alphabets and scripts.
Comment by James Cheetham posted on
Brilliant work, well done team!! 👏👏👏
Comment by Manal Nakli posted on
Thank you, team, for this brilliand work.
I translate and publish centrally all Arabic translations, and I see there are still so many issues that need to be corrected: from alignment issues to wrong translations of page furniture that don't make sense in context.
I will be happy to go through all these issues with you, which I do raise from time to time.
Comment by GOV.UK team posted on
Thank you Manal! Please could you email govuk-enquiries@digital.cabinet-office.gov.uk with the information and I will pass it onto the relevant team.
Comment by Joe Smith posted on
Good read.