With this post, we are wrapping up our series on how to generate a first-class resource file. We will go over different challenges that we can find when URLs, user names, and addresses are used in the UI, focusing on how often they are used in the resource files.
In the previous post of this series, we discussed how the proper use of placeholders is essential to generate a truly global experience for your customers and how reusing content for different contexts will generate a broken experience for your international customers.
Usage of URLs
One classical use case is that developers provide the URLs in the resource file and expect the URL to be delivered back “localized” in the target files. For example, if they provide:
“main_url”: “https://gilt-ninjas.com/”
and they want the “German” version. They expect to see:
“main_url”: “https://gilt-ninjas.de/”
in the de_DE file.
However, this is much more complex than this since many companies have main languages (for example, German or Spanish LATAM) that will be used in multiple regions, each with its own URLs.
For example, in the previous example, Gilt Ninjas might have just one version of German, de-DE, that is used in Germany and Austria, so if we follow this approach, it would be impossible for the developers or the localization team to point the Austrian customer to their site:
“main_url”: “https://gilt-ninjas.at/”
This is especially critical when we talk about legal content. Usually, the Terms and Conditions and the Privacy Notice are associated with a particular region, and there can be legal challenges if this is not properly done (see this case for TikTok that didn’t properly localize the terms and conditions for its Dutch customers).
Keep in mind that if you approach URL generation in this way, the localization team can only provide one URL per locale.
A different approach is to let the developers handle the URLs in their code. This also presents its challenges since if any URL is updated, they will need to go to their code and update all the URLs for all the different locales that are supported in their product.
The recommended way to approach this particular challenge is to have an internationalization library where the most important URLs are kept for all the different regions supported. In that way, if the developers provide the locale and the region where this should be displayed, the library will provide the proper URLs to use. Another big advantage is that if there are any updates to be done to any URL, you just need to update a centralized place, and it will be propagated to all the different areas where it is used. The downside of this approach is deciding the size of this library and when a URL is important enough to have it there since we want to ensure high performance.
If you are curious about how international URLs should be generated, I recommend this article where we go deep on that.
Usage of user names
A similar issue occurs with user names. When sending an email to a customer, what could be better than:
“greeting_reader”: “Hello {{user_firstname}}!”
?
Well, first of all, names are very complex. In fact, we will have a post just for them. However, focusing on the topic of this article, it is always better to provide a more generic placeholder. For example, {{customer_name}}.
The main reason to use a generic placeholder is that the first name shouldn’t be used for all international customers. For example, in Germany, it is recommended to use the full name of the customer. In certain Asian countries like Japan, only last names should be used, and honorifics should be added to the salutation. Additionally, in certain languages, names should be declined depending on the case to make them grammatically correct.
For that reason, it is quite important how your customers’ names are stored in your databases and how they are used. It is very important to coordinate with the globalization team at an early stage so this can be addressed soon enough. In that way, it can be as easy as using the globalization libraries for your developers. Otherwise, they will need to do a lot of work to go around it, or it might even be impossible to address.
You can find more information by reading the Unicode CLDR recommendations.
Usage of addresses
Addresses are another beast that is quite hard to manage through resource files. You can see the main reasons explained in this blog post. The general best practices are to try to keep them out of resource files. I am not saying that the localization team cannot take care of the translation of the different elements present in that particular form. However, if you want to have a format that is scalable and that adapts to the different markets where you want to move in, then you need to have a serious conversation with the design and globalization teams to generate a component for the addresses that can be easily used by the different dev teams in your company.
One special mention is for the usual list of countries that some companies include in forms. Since that list is quite extensive, it usually contains places with geopolitical issues (for example, Gibraltar) that are not considered countries, or certain countries don’t recognize them as such. For this reason, it is always a good idea to label them as something generic like Country/Region, or if necessary for length reasons, just Region.
Thank you very much for taking the time to read this. I hope you found it informative. As you could see, the considerations for proper localization go beyond the frontend and even get into the backend of how data models are generated. In that way, the proper information can be stored and used depending on the market or region your company is expanding into.
We talk about it in this post explaining the main reasons why this is an essential move and the benefits of doing it.