For many developers, globalization is an afterthought. The unfortunate reality is that many of us have not considered it. It would have been nice to consider language as an abstraction from the beginning. Most mature frameworks have already considered and implemented tools to handle their wide variety of users, which should prompt us to do the same.
However, it isn’t always simple to flip this switch for the large projects that we work on today. Products need to have a methodology for storing and retrieving strings of parameterized text that does not rely on specific inflections, pluralization, or grammatical structures. We need to provide culturally accurate display formats of data types such as dates, numbers, and currency. Timestamp storage and retrieval needs to be standardized so time zones can display correctly. There are also concerns with languages, such as Hebrew and Arabic, that have bidirectional text that must be accounted for in user-interface elements. Our applications can provide sensible defaults based on regional data, but to deliver a globalized product, control of these abstractions needs to be exposed to the users of our applications. Finally, designing sound testing practices surrounding these abstractions is key to being able to rest peacefully once we have addressed all of these concerns.
During this presentation, I will walk through the experience of converting a Ruby on Rails web application that didn’t account for globalization needs at its inception, and I will use real code to illustrate how to best address these topics of globalization.
