In our previous post, we discussed how naming the keys for our strings can improve the quality of our product internationally. In this post, we will continue exploring best practices in the usage of numbers, dates, and currencies.
Usage of numbers, dates, and currencies
When working on resource files, developers might be tempted to directly include numbers, dates, or currencies in the source string. Some basic examples include:
- Our system has a 98.9% uptime
- On 03/10/2024 we reached 1,000 users
- Enroll to obtain 5 days as an administrator
- Obtain a $5 discount by clicking here
The main issue here is that if these numbers change, the content will need to be re-localized, costing time and money.
However, there are other aspects to consider:
- Decimal separators do not depend on the language but on the region. For example, Mexico uses the period “.” as a decimal separator, while Colombia uses the comma “,”. Similarly, thousand separators vary by region (e.g., 1.000,99 vs 1,000.99).
- Date formats also differ by region (e.g., the UK format is day–month–year, vs. the US format of month–day–year).
- The usage of currencies is complex from the localization perspective. Questions arise such as which number format to use, what exchange rate to apply, and how to ensure accuracy depending on the region where the string is displayed (e.g., a German user in Germany vs. Switzerland, or a Spanish user in the US vs. Mexico vs. Peru).
For these reasons, it’s always a good idea to use placeholders, the tools and internationalization libraries that your internal globalization team will likely have prepared for you. These examples should look something like:
- Our system has a {{percentage_uptime}} uptime
- On {{date}} we reached {{number_users}} users
- Enroll to obtain {{number_days}} days as an administrator
- Obtain a {{amount_discount}} discount by clicking here
This approach allows you to generate a specific string depending on the particular scenario, ensuring it is correct and can be easily updated if needed. Moreover, if you use the same language in different markets, these issues can lead to legal challenges (a good example here). It’s crucial to ensure that local conventions and legal standards are adhered to, avoiding potential compliance issues.
The only concern left is for the string:
- Enroll to obtain {{number_days}} days as an administrator
Some languages have complex pluralization rules that require different translations depending on the actual number. For this case, we need to define the pluralization cases. Something like:
"days_to_enroll_as_administrator": {
"zero": "Enroll to obtain {{count}} days as an administrator",
"one": "Enroll to obtain {{count}} day as an administrator",
"two": "Enroll to obtain {{count}} days as an administrator",
"few": "Enroll to obtain {{count}} days as an administrator",
"many": "Enroll to obtain {{count}} days as an administrator",
"other": "Enroll to obtain {{count}} days as an administrator"
}
This can be overwhelming and error-prone for developers. For this particular case, I recommend using pre-processing and post-processing steps by the internationalization library so the English file can look like this:
"days_to_enroll_as_administrator": {
"one": "Enroll to obtain {{count}} day as an administrator",
"other": "Enroll to obtain {{count}} days as an administrator"
}
From there, it is easy for the globalization team to generate all the use cases depending on the different languages. If we want to generate a particular case for zero that differs than “Enroll to obtain 0 days as an administrator”, that’s possible:
"days_to_enroll_as_administrator": {
"zero": "You don’t have any days to enroll as an administrator",
"one": "Enroll to obtain {{count}} day as an administrator",
"other": "Enroll to obtain {{count}} days as an administrator"
}
I have to mention, though, that developers might be tempted to remove the placeholder for the “singular” case and do something like:
"days_to_enroll_as_administrator": {
"one": "Enroll to obtain one day as an administrator",
"other": "Enroll to obtain {{count}} days as an administrator"
}
Which is problematic. One of the main advantages of this structure is that the internationalization library can generate the particular plural cases depending on the language and those will be added to the resource file of the particular language. Even though the case “one” is used in English only when the count equals 1, there are languages like Japanese that don’t have plural forms and use the singular form for all counts. In that case the globalization team would generate a structure similar to this (but in Japanese, I am doing it in English so it is understandable for you):
"days_to_enroll_as_administrator": {
"one": "Enroll to obtain one day as an administrator"
}
In such cases, we would be incorrectly generating the string “Enroll to obtain one day as an administrator” for plural counts. To address this, a special case configuration might look like:
"days_to_enroll_as_administrator": {
"=1": "Enroll to obtain one day as an administrator",
"one": "Enroll to obtain {{count}} day as an administrator",
"other": "Enroll to obtain {{count}} days as an administrator"
}
In that case, Japanese would be generated something like (again this would be in Japanese in the resource file but I am doing it in English to be easy to understand):
"days_to_enroll_as_administrator": {
"=1": "Enroll to obtain one day as an administrator",
"one": "Enroll to obtain {{count}} day as an administrator"
}
This configuration ensures that the correct form is used based on the count, accommodating the linguistic nuances of different languages.
Thank you very much for taking the time to read this. I hope you found it informative. As you’ve seen today, placeholders play a crucial role in our resource files. For that reason, we’ll soon return with the next topic: the proper usage of placeholders, ensuring they are correctly respected and named, and how instructions can be associated with a particular string!
Leave a Reply