It is debatable what the hardest thing to get right for an enterprise application is, but localization is definitely up there. It not only means translating your app into different languages, but more importantly it also means correct date handling for users from different time zones and proper currency conversion and formatting for a multi-currency multi-locale environment. Fortunately, at Duetto we built in localization as part of our core very early, we didn’t have to experience the pain of retrofitting the localization after the app was already established. If I were to take a guess, it was well below 1,000 (or 1 000 if you are French) lines of code that we started building pieces for our localization infrastructure.
Why did we build localization into the app so early? The complexity and magnitude of this problem multiplies quickly. To give you a taste of our capabilities, we can have a user running the app in English under en-US locale (hey nothing fancy here), but managing properties across Asia and Central America. Each of those hotel runs in a different time zone and currency. The user can “view” those hotels in his perspective, meaning our app will localize everything including dates and currencies to those settings. It’s as if every user has his or her own colored lenses and the app will simply project the data through that lense. We give the user full control of how they want to adjust that lense. Now, to add icing on the cake, the user can also run aggregated reports across all those properties, and we will handle all the currency conversions and localize the final results according to the user’s setting. This aggregate report will return under seconds with literally real time result using the latest data, not pre-computed results that were generated from hours or even days ago. Powered by BigData!
When you build your application to run in this mode, even a simple question like “What is today?” is not so simple anymore. It may be July 7th for some countries in the Western Hemisphere but it is July 8th already for some countries in the Eastern Hemisphere. So the right question you also need to ask is “Whose date are you talking about?” One way to simplify this problem is by normalizing our dates to GMT time, the 0 time zone, so we can treat room nights from different hotels the same way and aggregate them under a single report. We also update our locales and time zone information regularly to reflect the latest political change. A similar question for currency would be “How much does it cost for one room night at hotel X?”, but you need to also ask “What currency are you talking about?”. It is especially important for currencies because
a) their conversion rate moves constantly. At Duetto we use a cloud service to refresh our conversion rates on a daily basis, to make sure our reports always respect the latest currency conversion set by international markets.
b) different currencies require different amount of precision. For example the US Dollar to Vietnamese Dong conversion rate is 1 to 21250 right now. For hotels selling in USD there is a 1% difference between selling a room at 99 vs 99.99, but a similar difference means much less for hotels selling in VND. While the user managing a hotel in the US cares deeply about those decimals, the user managing a hotel in Vietnam may find it less helpful. We will display different precision depending on the currency the user is viewing.
The last piece to the puzzle is display. We support a variety of display options for dates and currencies and many of them do not come standard with Java. Did you know that some locales display their currency symbol as a suffix instead of prefix? $20 vs 20 € Some locales use commas instead of periods for decimal separation? 20.10 vs 20,10. Other regions place a space before their percent sign and some even place their percent signs in front? 50% vs 50 % vs %50. These are all details we care about so that users from all over the world can use our app with ease.
Even though we are a cloud application and we cherish all things cloud, we also aim to integrate well with any existing technologies or processes that are in place. This means ftp, email imports, text based data ingestion, and Excel. Many of our users use Excel for various purposes, and to help them make a seamless transition, almost every one of our reports have a download button that allow the user to download the report right into Excel format. Displaying properly in Excel is a challenge because the users expect to take the downloaded file and plug it into their existing reports and formulas. That means $50 is no longer just a string that says “$50”, it has to be a currency with amount 50 that is in US Dollars. Localization is incredibly important for any application that plans to have a global reach. It takes a great deal of time and attention to detail to implement, but the results are well worth it. How does your company handle localization?