More to Localization

When we talk about localizing or internationalizing an application, we often focus on just the wording of labels and other text. However, there is more to it than just “what is the translation of this word”. Take for example this real world story.

Years ago when my son was in preschool he received a birthday party invitation from a classmate for 1/2/{year}. I emailed the Mom and told her that my son was very excited to come to the party and jokingly added that I was excited to have an activity for him on the school break. She wrote back asking if there was a school break other than President’s Day in February.

At this point I realized the issue. While she had lived in the US for years she had written her date in the day/month/year format instead of the typical US month/day/year. We had ourselves a real-life internationalization problem. Thankfully, having realized the confusion she was able to correct it before anyone showed up a month early.

Recently I was asked to add some localization support to a .NET/C# application we have here. In this case, the application itself is outputting data that is used as input to another process. Therefore we did not want the dates, etc to be in different formats based on locale. The focus here was the labeling. Or was it?

Remembering the birthday party incident, I made sure to verify that our code was being explicit in how it formatted the dates. I verified the code had “$“{resultSet.Date:yyyy.MM.dd}“. Perfect, right?

In C# there are two different values for the locale. CurrentCulture controls how dates, numbers, etc are formatted. CurrentUICulture controls the labeling, etc that is used. Since I was now sure that my focus was labeling, I added unit tests to verify the data and the labeling for US English, Germany German, and Argentina Spanish. All passed and I committed the code for PR review.

It was during the review process that I realized that I was wrong. There was still more to the localization process even when I wanted the data to be static in how it was created. Thankfully the person that picked up my PR to review was on a computer set to Canadian English. As it turns out the data format of “yyyy.MM.dd” did not do what my initial instinct told me. The period in that pattern in C# actually represents the CurrentCulture’s default date separator. So in the US it was creating “yyyy/MM/dd” while in Canada it was creating “yyyy-MM-dd”.

As we worked on coming up with a solution to make sure the data was always the same regardless of culture, I added more cultures to my unit tests and realized that we had also forgotten about the difference in numeric formatting. Some cultures use periods where others use commas and vice versa.

But try as hard as we might, it is really hard to know every possible culture and how it handles every possible variation. So, I created a little mini-application to help with the analysis. If you need help, give this repo a try: https://github.com/corgibytes/CultureInformation. While it is .NET specific, it can help with general cultural knowledge.

Using that I was able to better evaluate what data we needed to consider for internationalization and what cultures I should use to test. And I have once again learned my lesson: There is a lot more to localization than just words.