Smartcat, a translation-automation platform, has been a global product from day one. The cloud-based platform includes a vendor marketplace, project management and payment systems, as well as an AI-enabled computer-aided translation (CAT) tool. It serves customers in over 100 countries.
For Smartcat’s development team, the foundation of a good user experience relies on skillfully managing an array of fields that vary based on location and, in some cases, user preference. The company’s engineers consider the browser a core component of this work, despite browsers limitations.
Smartcat is built on the ASP.NET framework, which, as they discovered early on, includes browser checks in its native API. (Note that if you’re using a framework that does not include native browser checks, there are JavaScript libraries built specifically for localization projects, such as Localize.js.) This allows the platform to pull a user’s location and preferred language from the browser.
Despite their value, Pavel Doronin, a product manager at Smartcat, explained in a phone interview that “there’s not a 100 percent reliability with browser checks.” Not only might the information you’re seeking be unavailable, but also, even when it is, a user’s preferred language and location won’t necessarily tell you everything you need to know.
Let’s take a look at the intricate and evolving way that Smartcat’s development team handles browser settings for their global customers and how what they’ve learned can help you more effectively localize your own products.
The language of landing pages
Before a visitor logs in, the only setting Smartcat developers need to worry about is the language to display on their public site. The public site appears in seven languages (English, Turkish, Russian, German, Chinese, Japanese, and Korean), but the rest of the platform—available once a user logs in—supports only five languages.
Their workflow for deciding which language to display is as follows:
If a user sets their preferred language in the browser to one of the available languages, the site automatically appears in that language.
If the language isn’t supported, an internal routing process determines whether Smartcat supports a closely related language. For instance, if a visitor wants to view a page in Ukrainian, Smartcat will show them the Russian version of the site. If a closely related language is not available, it uses English by default.
If a user hasn’t set their preferred language or it isn’t available, Smartcat looks for their location and starts the same routing process. For instance, if they’re in Germany, the user will see a German interface.
If neither the user’s language nor their location are available from the browser, Smartcat defaults to the site’s English version.
This workflow, although generally helpful and intended to be of service to users, is admittedly imperfect and can yield an imperfect experience. Why?
The preferred language and location information from a userʼs browser settings is not always available or may be incorrect.
“People love to hide their location. They share the language preferences—they’re okay with that. But they’re not always okay with the detection of location. So they use VPN services or restrict the browser from sharing this information. Or they use incognito modes,” Doronin said.
But the preferred language isn’t always available either. “The field can be empty, and users can restrict browser information as well. Or it can be an unsupported version of the browser or an unsupported browser.” What’s more, browser checks can produce faulty reads, albeit rarely.
Your assumptions about a countryʼs preferred language may be wrong.
Smartcat’s development team learned to pay attention to common changes visitors make that might signal their defaults are incorrect.
“We had an interesting case with the Baltic states: Estonia, Lithuania, and Latvia,” Doronin said. “At first we thought, as former USSR countries, let’s use Russian by default. But they are also a part of the European Union, and they’re working hard on language policies. They work hard to make local languages more present. And suddenly we had a [customer] complaint.”
The team investigated and found that around 70 percent of users in the Baltic states had their default language set to English. Now Smartcat routes all visitors from the Baltic states to the English version.
The internal user experience
Once logged in, Smartcat pulls the default language, date, and time settings from browser checks. Preferences such as a 24-hour clock versus a 12-hour clock can make a difference when you’re trying to provide clarity around a project, which is why Smartcat uses a customer’s location to adjust how it displays the date and time.
However, for developers relying on a user’s browser settings, it’s important to keep in mind that this small amount of information does not tell the whole story of how users prefer to interact with a site or application. For instance, Doronin noted that a user “may browse with English as their preferred language but, for whatever reason, use Smartcat in Turkish.” To accommodate this, Smartcat gives users the ability to change the language at will.
Of course, localizing the user experience extends beyond the language and time zone. Settings such as currency and payment options also come into play. These settings are managed by user-inputted data starting with country of residence, which users supply during the sign-up process.
“If you’re in Turkey, you can see the list of the payment systems available there. For instance, if a payment service is not used in Turkey, it does no good to show it as an option,” Doronin explained.
Smartcat does not customize the list of payment systems available for each country. Like many organizations, they don’t have the resources to accomplish this level of country-based localization. They concentrate their efforts in places where they have a large collection of customers. In such locations, they also tend to have partner organizations that help them remain compliant with local financial regulations.
Users may live and work in one country, but their location does not define them. Neither does the language they browse the web in, use during work hours, or speak at home.
A customer doesnʼt necessarily follow their countryʼs norms.
Just as they discovered that customers from the Baltic states preferred English over Russian, Smartcat learned similar lessons about setting a default currency based on the user’s country.
“We tried to guess the currency [a user would prefer], but we failed,” Doronin said. “Chinese agencies may calculate their budget in U.S. dollars because they have clients from the U.S. The same is true with Russia and Turkey.”
While it’s still necessary to set a default, they found it useful to allow users to set their own preferred currency.
“The main point is that the location is not equal to language, and the language does not equal the currency,” Doronin explained.
Information needs to be set per user, not per project.
In many larger applications or platforms, users don’t just interact with a website; they interact with each other, too. In these situations, should they see and experience the site in the same way?
On any given project on the Smartcat platform, three users—a customer, project manager, and translator—may be from three different countries with three different preferred languages, time zones, and ways of displaying monetary and date values.
When groups of users share information that varies based on location, it’s up to the developers to discern what will provide more clarity: for everyone to see the same data, or to convert it per user. Smartcat engineers prioritize an individual’s experience over the group’s collective experience.
This means that the solution, like so much in the realm of localization, can’t be one size fits all. They convert many fields automatically per user. “Managers are always afraid of what delivery date the translators will see,” Doronin explained, so they convert project deadlines based on the date and time set in a user’s browser. “If people use VPN services or something like that, there can be a difference—but generally we think that a user’s browser knows what time it is.”
On the Smartcat platform, the other major conversion happens after users complete a project—meaning it’s time to get paid. “A translation manager may have a budget in U.S. dollars and then hire a French translator, who sees the translation rates in Euros. To avoid manual calculation, we just implemented auto-conversion of the currencies with a sign that the rate has been converted using the publicly available exchange rate,” he explained. Smartcat uses the Open Exchange Rates API for these conversions.
An ideal localized experience is customizable
The Smartcat team’s experience illustrates that browser checks offer a workable start but, by themselves, they won’t create an ideal user experience. In the spirit of user-centered design, the more customizable a platform, the better the experience. This helps limit the assumptions you make on behalf of your users. They may live and work in one country, but their location does not define them. Neither does the language they browse the web in, use during work hours, or speak at home.