At the end of 2020 when we decided to rebuild our flagship CRM product, we also made a decision to correctly internationalize it. At the time it seemed like the obvious decision and approach, but did we underestimate the workload? Yes we did, even with a fairly good understanding of what that entailed. Looking back, the amount of work it takes to truly build an international product still surprises me.
To make this article as useful of a read as possible, I will include some of the items I learned after helping build the localization process for Snapforce. Keep in mind, internationalization is hard, and is not something to try and undertake as a quick project.
Must Do Items
Do not circle back later when it comes to internationalizing your application. This is something that is never a good idea when building software, but especially true when internationalizing your application. Since we completely re-built our product, we were lucky that we did not need to cut corners for speed or fear of affecting existing customers with major overhauls to the code base.
There are too many pieces to consider when fully internationalizing an application, that trying to circle back to something later due to time, will only lead to major headaches down the road. Adding right-to-left support out of the gate for your middle east user base is a good example. I had many people tell me it wasn't necessary to do right away since we have yet to launch any middle east markets. We built in right-to-left support from the start, and are very happy we did.
How to store data? Use UTF-8 for all character data, with a utf8mb4 collation. Do not use utf8, you must use utf8mb4 for the character encoding part. Keep in mind this collation requires more space in your database because it correctly supports the full UTF-8 character set.
Plan with variable substitution in mind, build your translation dictionary with full strings. Basically don't break them down into small chunks of text, instead save it like "You are about to delete $x deals", then replace the "$x" variable with the number.
Choosing your locale
Locale what...? Here is a question, do you let your users choose their locale, or automatically set it based on their browser settings? Well both options have positives and negatives in my opinion, I think this really depends on the details of your application. What your application needs to do with that information. At Snapforce we decided to let the user decide, then based on their selection that will automatically set the date format, time format, currency, and a few other things. The user can choose a different default currency overriding their locale if needed.
One of the choices we made while adding multiple languages is if it was necessary to add many at once, and the answer is no. What we did (which I feel is a good solution), is add the languages we need now, and growing the language base as we launch different markets. We can do that easily since we built out the underlying functionality for language support. Now when we are ready to add a new language, the only thing to do is add to our translation dictionaries for that new language. There is no new code that needs to be written or more functionality to add. All of the development is already finished.
Supporting multiple languages is not something to rush, especially for a CRM software like Snapforce. It is important that the translations are correct, one of the things we do not want is to have foreign speakers begin using the CRM and have phrases or words translate incorrectly. That happens often when companies try to use google translate to add to their language dictionaries, many times the translations do not make sense and it is clear someone just copy pasted the translations.
As you expand and launch different markets you can launch that new language and add it to the available list of languages your app supports. In the interim your users can select from the list of available languages.
Plan for your titles to need additional space, especially if you are going to support asian languages. Chinese language for example can be more than twice the length of the english translation.
Around the World we go
Timezone's are easy, UTC! Okay timezone's are done.
In our opinion that is the only way to go. With so many timezones the only way that makes sense to us is to handle everything in UTC time, regardless where you are, everything is stored in UTC. Then depending on the user's location, they see the data in their timezone.
I really don't understand how there is so much debate and articles on the web around programming timezones (for example this video from Computerphile almost made my head explode).
Money, Money, Money
Building a web application that stores and tracks money data, like in our case with sales software, means we must discuss currencies.
Currencies are simple, Snapforce offers all known currencies, and you can even add your own custom currencies. Considering all of the new types of digital currencies we thought it made sense, so you can add to the list of 183 currencies that are available by default.
If your application needs to handle totaling currency values it gets more complicated, viewing data in multiple currencies is easy enough, but how do you run reports and give users accurate totals if each deal, or invoice has a different currency? Good question, this was a problem we ran into also, considering currencies constantly fluctuate against one another. There is a simple solution to this, maybe I will discuss it in a part 2 article.
Snapforce is a simple yet robust CRM software. Built to be easily customizable and flexible for any size business.