Last time I mentioned that we all have biases ingrained into our subconscious by our cultures, but I didn’t address how we avoid being tripped up by those problems in the first place.
Unfortunately, it is difficult to be specific. I can say “did you know that some places tend toward a month/day date format and others lean toward day/month patterns?” But maybe you knew that already. I can then ask if you know that some cultures are a little more complicated than either of those? But who knows, your app could be doing dates perfectly, and maybe the slip-up is something completely different.
What I can say is that there are hundreds, thousands even, of languages being used in hundreds of countries. Within those countries there are smaller groups and cultures; regional preferences and immigrant/expatriate communities. How those may impact any particular application can be difficult to know. But what becomes obvious is that there are a lot of possibilities.
So, that’s a lot of complexity. The good news is that the industry has had a lot of experience with these issues. The platforms themselves have made missteps that were corrected in later years. One of the most obvious lessons is probably that code pages may have solved a problem in their time, but Unicode is a lot more portable, however most globalization and resource APIs have evolved over a half century, learning (or sometimes not) the lessons of other SDKs and previous versions.
Using the APIs provided by your platform and following the SDK’s best practices can go a long way towards avoiding missteps. “Newer” technologies may solve problems from older versions and are worth considering.
Using Unicode seems obvious, but some systems/situations still lean toward the national specific codepages and so many developers still haven’t really learned about Unicode.
Deviating from the defaults should be considered a warning that your plan may need special attention. Why wasn’t the platform doing what you wanted? Is there something that you were missing?
Being overly specific is another red flag for globalization. Many cultures have very interesting behaviors that not be quite as simple as they feel like. We all have limitations such as display space, but if your application feels like it needs to restrict things, then it probably needs special attention.
I remember one case when a day name was “too long” for the UX designer’s vision, so the developer truncated it. It was clear that this probably wouldn’t be best, but it was expected to at least be usable. What they didn’t realize is that in some languages, the words like “Monday, Tuesday”, etc., eg: something-day were more like day-something. DayMon, DayTues,… in effect. So by truncating them the application ended up with 6 of the 7 weekdays being effectively “day”, and all 7 being really confusing non-standard abbreviations to the users. Which eventually led to the platform providing “shortest day names” (which may be longer than you might expect or hope..)
So, whenever you start doing something “custom”, even if it seems very simple, take time to do a lot of research. That will help.
In closing, the biggest thing you can do to avoid unconscious problems with globalization is to be aware that you might have biases. Hopefully that will make you think and wonder during planning. “Oh, they’re formatting a string, I wonder if that works the same in all languages?” “We need a date here, but there isn’t very much room, which languages will that cause problems for?” “The UX designer wants a fancy time selection control. Do we have all the information we need to make that look good in all of our target locales?” “We’re sending/getting data from an internet server, is it going to be readable by machines or humans in another country?”
Hope that helps!
(or at least maybe keeps people thinking)