In internationalization, developers often refer to the term locale, which represents an audience for a particular region.
<aside> 📢 I am currently creating a 6 hours long crash course covering internationalization for ops, sales, technical and management roles, please contact me if you want to learn more about it and help me deliver this lesson sooner.
</aside>
<aside> 👩🏻💻 Are you a developer ?
Feel free to check Octree’s guidelines for internationalization in addition to this document.
</aside>
The biggest challenge when it comes to internationalization is to be able to localize the user and link him/her to a supported audience. It goes further than finding out the user’s location since this information is actually not reliable and is not enough to identify someone’s language, culture or even actual location.
What we try to define here is what developers call a locale, a term that represents an audience for a particular region. For example, you could have an “fr” locale that would represent all the French speakers. However, as you can imagine, Canadian French speakers and Belgian French speakers sometimes use different terms or you may want to address them differently.
🇨🇦🇫🇷🇨🇭🇧🇪If you define Belgian french speakers as “be”, you or your third party services may deliver them content written in dutch ! Why ? Cause there are 3 official languages there and I even experienced it when dealing with Belgian public services since some of their 3P translation APIs assumed people in Belgium were dutch speakers.
<aside> ✅ You should never assume someone’s locale based on a location, users may use a VPN in Romania and don’t speak Romanian, expats living in a place without speaking its native language, they may buy a device or subscribe a service in another country that the one they live in,… Many situations you cannot and should not anticipate, but you can still avoid to deal with if you follow this rule.
</aside>
Browsers translate your content wether you ask them or not, they will apply automatic, maybe inaccurate translations in the desired language of the user.
Doing so, the interface that you think they will see may be completely different and hardly usable.
If you didn’t follow the appropriate design practices (graphical, experience and technical), users may end up reading outboxed elements, clicking button that doesn’t work or even clicking an unexpected button (hitboxes are affected by translation)
People also translate it by themselves or using technologies such as google lens to read your interface, this as less chance to impact your development but you should keep it in mind for support purposes.
One may name a slide of your city hall terminal and inform you about an issue and you would never be able to understand which slide they are speaking about. What you code may not be what they get 🙂
Keep in mind that some languages are read from right to left and this behaviour is implemented in their browser and may affect your UI, what you see may not be what they get 🙂
When going online, public services agents often assume the users will be located in their country and able to connect the service as anyone currently inside the country.
This is indeed a misconception of their scope and it leads users abroad to be unable to access the service. In some case, they even blocked the use of their services abroad Let say you need to check your taxes, health and insurances, visas, or any administrative but necessary work you may perform as a citizen, would you travel back to your country only to access a web platform ?
Indeed you may use a VPN but then you’ll most probably face authentication issues, you may even not know what a VPN is…