When we began adding internationalization (I18N) support for Intervals, we didn’t really have much experience working with international locales to draw upon. We could, however, see the writing on the wall: Intervals was getting more international customers day by day, and we knew they weren’t all working with US dollars. For Intervals to become a truly international time tracking and project management application, adding robust I18N support was imperative.
Open source PHP libraries for full I18N support were few, and of those that we could find, comprehensive locale support was limited and in many cases incorrect. The package we integrated into Intervals (PEAR I18Nv2) suffered from many limitations, the most glaring of which was frequently incorrect date, time, or currency formats for many locales. Often times, we had to do our own research when adding new locales. But often we were fortunate to get great support from our customers in ironing out locale inconsistencies and ensuring all our locale data was correct.
Initially, we began supporting Western locales: from the Americas, Europe, Russia, Australia, and Africa. Gradually, though, we began to receive a chorus of requests for Eastern locales. From a technical standpoint, Eastern locales are much more difficult than Western locales, primarily because of their use of non-Latin characters and unconventional number groupings (for example, to express the time in Chinese Simplified Han is 下午6:52; another interesting example occurs with India, in which the number 1,234,567 would be expressed as 12,34,567). Each time a date, time, or currency appears within your browser, in a PDF or in a CSV, those values must be converted to the proper locale.
The biggest difficult with locale support, however, is not with how to display times, dates, and currencies. The biggest difficulty is knowing what sort of input to expect from the person using your application. Whenever you want to compare two dates, add or subtract time or currency, or store dates or numbers in a database, these inputs have to be converted to a common style or representation. You need to know that when someone enters the date “03. 06. 12,” one part represents the day, another the month, and the other the year (the example I cited is the Korean locale, ko-KR, which represents the date June 12, 2003).
That sort of conversion is easy. It’s just a matter of Intervals knowing what the anticipated date format is for a particular locale. Our first Eastern locale, Japanese (ja-JP), was similar to this, involving no non-Latin characters in date, time or currency representations.
But as we move forward, more difficult challenges arise. As our customer base grows, we are looking forward to adding many more locales to Intervals, and each one presents new challenges. In Hong Kong, a date may be represented as 2003年6月13日. In Saudi Arabia, it might appear as ١٣/٠٦/٢٠٠٣. As we add these new locales, we’re lucky to have the support and help of our customers to ensure that all inputs and outputs are correct. We couldn’t have added the Japanese locale without the help of one of our customers in Japan and a former sensei of one of our project managers. If you have questions about a particular locale or would like to see one added, please contact support@myintervals.com.
You mentioned that the current open source solutions where lacking- do you have any plans to release the code you’ve written as under an open source license?
That’s a good question. Since most of what we did was update the formatting of the existing locale files, and added a few of our own, it would make sense for us to release those back out as part of the I18Nv2 Pear library. I’m certain we’ll do that in the next few weeks. Thanks for the reminder :)