Internationalisation — easier done than said
Building modern web applications involves many challenges, for instance displaying the data in a way that the users are familiar with it. Apart from the most obvious aspect — providing translations — developers have to keep in mind how different countries present dates, numbers, etc. Lack thereof can result in forfeiture of clients, insulted that they’re not perceived as a group substantial enough to support.
This requires applying a tool that has a broad community support, vast documentation and is backed by a meaningful organisation. An example of such tool is react-intl, created by Yahoo, that builds over the built-in Intl API.
We won’t focus on the configuration too much, as the documents already describe it in a very detailed and comprehensive way. Instead, we’ll present some real world use cases that will show you how easy it is to implement internationalisation in your projects.
Supporting the internationalisation of messages is the most crucial, and sometimes, troublesome task. Each language requires a separate JSON file consisting of a unique ID and corresponding text pairs.
In case of a necessary pair not being present, the default message will be used:
There are two approaches when it comes to default messages: they can either not be specified at all — in such case, if no translation is provided, then the id will be shown instead. This is a great way to identify missing translations, but demands very strict testing.
The other one requires filling the messages in a language of choice. This will make sure that if an ID is missing in a JSON file, a fallback will be returned instead, as in the first example. Finding missing translations in the selected language will be almost impossible, though. It’s up to the development team to choose their approach.
Undoubtedly, it’s a good practice to sort the JSON files alphabetically by IDs and visually separate translations of respective components — it facilitates the analysis of potential mistakes.
Once everything is set up, it’s only a matter of introducing a language altering mechanism and the translation will proceed seamlessly.
The library provides two components for text translation: FormattedMessage, which creates a HTML paragraph tag with its own styling, and formatMessage that returns a string. The latter will be more useful in situations when passing a full tag would impair the presentation — e.g. when passed to a header in a card.
Since providing translations is often the duty of non-technical employees, it should be noted that it’s easy to introduce them to internationalisation. Once a developer inserts the component into DOM, the only thing left is to fill the JSON. The business team needs to be provided with an IDE that applies the styling used by the developer team, a Git account and they’re ready to go.
Bear in mind that following the aforementioned approach might as well be beneficial to projects that don’t demand internationalisation. Hard-coded text will not only make code appear cluttered, but can also create inconsistencies across the application. One example would be a message that is shared across many components — updating its content would mean having to update it everywhere it’s featured. Fetching them from one place means smooth changes, and furthermore, can be performed by non-technical people.
One of the most confusing aspects of American culture is their manner of displaying dates, that start with month, proceeded by day and year. The question then arises: how do we present the dates to American users, if the default format is a day-month-year one? That’s where the second component — FormattedDate — comes in handy.
Just merely passing a locale as a parameter converts the date automatically. Bear in mind to always provide specified locales — instead of en distinguish en-GB and en-US! There’s also a possibility to use a relative date format — rather than exact dates, we can use phrases like yesterday, 15 minutes ago, in 2 hours. It definitely helps with presenting them in a more common, less automatic way.
Enterprise projects will definitely admire the rich number formatting possibilities that FormattedNumber provides. It’s absolutely crucial to use locale here — the decimal and thousand separators vary greatly in different regions. Otherwise, there’s a risk of customers misunderstanding numbers provided to them.
Supporting internationalisation is not a trivial matter and should always be given enough emphasis. Absence of such could result in a dissatisfaction of groups of customers, which in consequence can put the whole business at stake. With the growing popularity of accessibility, providing translations might be regarded as such in the future.
Hopefully, this article will persuade its readers that the transition to a multilingual page is completely effortless and shouldn’t be a burden on developers, once they’re briefed on the advantages.
