This post is for Day 8 of Mercari Advent Calendar 2023, brought to you by @wills from the Mercari Cross Border Team.
Introduction
The magic of websites lies in their ability to connect with users globally. However, not everyone speaks the same language, and misunderstandings can lead users to bid farewell to your site. To avoid this, it’s crucial to embrace multi-language support. In this article, we’ll explore the world of internationalization and localization on the web and peek into how Mercari is currently managing it all.
Decoding the Abbreviations
Ever stumbled upon abbreviations like t9n, i18n, l10n, and g11n? Let’s demystify them together:
- Translation (t9n): The simple act of converting text from one language to another. Like turning English "hello!" into Japanese "こんにちは！".
- Internationalization (i18n): As a web developer, i18n is probably the most common abbreviation you will encounter among this list. i18n is the process of designing software which can handle different languages, e.g., using an i18n library to manage and display the appropriate language strings instead of hard coding strings in the UI.
// i18n using i18next library for React
import { useTranslation } from 'next-i18next'
export const Footer = () => {
const { t } = useTranslation('common')
return (
<footer>
<p>{t('common:footer.menu.about.label')}</p>
</footer>
)
}
// VS no i18n
export const Footer = () => {
return (
<footer>
<p>About Mercari</p>
</footer>
)
}- Localization (l10n): This step uses i18n to display content in a way that meets users’ language preferences. Translators play a vital role here, translating phrases like "About Mercari" to "メルカリについて."
- Globalization (g11n): The fusion of i18n and l10n, ensuring your website caters to a global audience seamlessly.
i18n on web
Language Preferences
Determining a user’s language preference is key to enabling localization. Websites achieve this through settings, either integrated directly or relying on the user’s browser settings.
Caption: Language setting in chromium based browsers
Language Codes
We can access users’ preferred language preference in JS through navigator
window.navigator.language // 'en-US'
window.navigator.languages // ['en-US', 'ja']Notice the language code’s two parts, with the secondary indicating the region. For instance, en-US refers to English used in the United States as opposed to en-GB which is English used in the Commonwealth.
Browser page level translation
Most modern browsers boast built-in translation capabilities, making your content accessible to a broader audience.
Chrome
Caption: Original Mercari website in Japanese. https://jp.mercari.com/
Caption: Chrome browser page translation Chrome has page translation built in. It uses Google translation engine, which produces very good translations.
Edge
Caption: Edge browser page translation Edge similarly has page translation built in.
Safari
Caption: Safari browser page translation. Safari browser page translation goes a step further by recognizing and translating texts inside images.
Firefox
Caption: Firefox browser page translation. https://www.amazon.co.jp/
Firefox browser requires an extension (in beta). It also does not support many languages. Though it has a positive side that all you translations are done locally, perfect if you are strict about privacy
How Companies Handle Localization
There are various ways companies can implement locations. Roughly speaking we can divide text into 2 types: static and dynamic. Texts in menus, header, and footer are common examples of static texts. They are known beforehand and allow translators to take their time to translate it before releasing it. Dynamic contents are trickier, texts such as product names and descriptions keep changing and are simply too large for translators to handle.
Caption: Stripe website in Japanese and English. https://stripe.com/
Caption: Amazon website in Japanese and English. https://www.amazon.co.jp/. So how does companies like Stripe and Amazon enable localization?
In-House Translators
Various companies handle l10n internally. Internally, companies have translators that translate the texts and store it in databases or content management systems.
Dealing with Dynamic Content
The downside with in-house translations is when there is dynamic content. When there are large amounts of texts that keeps changing, translators have no time to translate the string manually. With the rise of AI some websites choose AI to help with the translation.
Caption: Toshima city has modal on the bottom left side to switch languages powered by AI. https://www.city.toshima.lg.jp/index.html.
Fetching Data
Regardless of translation method, the client will need to get the translations. The client can request these translations directly from their content management system, usually in json format. The client can also request it through the server. Clients communicate their preferred language through Accept-Language request http header.
Accept-Language: jal10n in Mercari
Dev only
At Mercari, with an international team of engineers, English pages are crucial for effective development. Most of our target audience are Japanese users. Because of this, we have only enabled English pages in development for a couple of years.
Flow and integration with Memsource
Mercari Frontend relies on the i18next library to manage localized strings. The workflow involves designers creating projects with Japanese text, engineers implementing both Japanese and English texts, and in-house translators managing translations through phrase. Once ready, engineers pull English translations from Phrase.
End
There are a lot to consider when implementing localisation. From which framework to use to whether to implement it yourself or simply rely on the browser. The whole i18n/l10n problem is far from being solved, and we are working hard everyday trying to figure it out ourselves.
Thank you so much for reading. I hope this article teaches you something new <3.
Tomorrow’s article will be by Osari. Look forward to it!
