FME Behind the Scenes: L10n and Learning Curves
When designing and developing technical software, it’s vital to put effort into minimizing the learning curve. For FME, we try to remove as many barriers as possible for the user. Some steps in the learning process can’t be removed, but we can certainly help with language and regional complexities. That’s where localization comes in.
Localization, or L10n in nerdspeak, means adapting software for another locale. More than translating language, it involves technical requirements and regional differences — changing interfaces, examples, logos, screenshots, numeric formats, keyboard usage, and so on.
con terra, a Safe Software Platinum Partner, creates the German and Spanish versions of FME. Led by Markus Bellinghoff, they’ve localized the German version of FME Desktop since 2004 and the Spanish version since 2010. They expanded to FME Server in 2015. Moving forward, they plan to round out the FME trio with a localized version of the FME Cloud console, and are also looking at expanding to other languages.
- Find localized versions of FME at the bottom of the tech specs page.
Here are some tips and fun facts about localization that my colleagues Lena, Gerhard, and I learned during a chat with Markus.
When localizing a technical product, do it yourself.
con terra decided to do localization themselves instead of outsourcing because it’s important to have experience working with the software. Having knowledge of FME, for example, helps when deciding which terms should be translated and which are software-specific terms or reserved keywords — e.g. reserved format names like File Geodatabase or established English terms in the geodata context like “nodata”.
Localization is critical when the software is used by governments.
The German version of FME is used mostly by governments, likely because:
- Some governments must use translated software by law or internal policies.
- Local governments, especially small communities, or companies with focus on the German market have less need to speak English to customers, and so are less fluent.
Localization is key when software has a learning curve.
A user is only willing to spend a certain amount of time learning a skill. They already have to put effort into learning how to use the software, so if they also have to translate what they’re reading then the time spent becomes longer. Localization shrinks the learning curve. Even for users who have a strong grasp of English, if they have to skip or look up even a single word, there’s a greater barrier to understanding.
11 odd localization challenges.
That sounds like the beginning of a clickbait title, but really. Here’s a list of things localizers like Markus need to consider.
- Names, symbols, or images can have different meanings across cultures. E.g. Mitsubishi Pajero is named after a cat but translates to Spanish rather inappropriately.
- Translations can result in text no longer fitting inside its designated space.
- Users are able to get more familiar with the software if the examples in documentation and training use familiar data. Examples should therefore be adapted to the region and include local data. (Open data makes this easier to do.)
- The. Yes, the. English only has this one article, while many other languages have masculine/feminine/neutral ones. The appropriate article must be used and correctly generated depending on the context.
- If software is developed with hard-coded rules about capitalization, pluralization, or punctuation, this can result in incorrect translations. E.g. automatically adding ‘s’ for pluralization or forcing nouns to lowercase can result in incorrect German translations.
- Some keywords or technical terms should not be translated. E.g. Esri Shapefile is a format name so you don’t want to translate ‘shape’ in this context. Other key terms need a decision process, like FME Server Notifications and Topics. Leaving them in English means standardizing communication between users, but makes the learning curve harder for those less familiar with English.
- Automation is key, because going through the entire software word by word to make sure it’s properly localized is near impossible. (For GUI, con terra uses SDL Passolo. For documentation they use MadCap Lingo.)
Fun fact: there are over 1.3 million words in the FME product and documentation. That’s more than the entire Harry Potter series.
- Context matters, because there can be different meanings of the same word. There’s no one correct translation.
- Sometimes the future comes back to bite you and you have to get creative. E.g. con terra translated Workspace to Projekte – but we later introduced FME Server Projects, so … Woopsie, sorry guys.
- Sometimes the solution is to invent a word. E.g. for transformers, con terra has to decide whether it makes sense to translate a word like Clipper or Bufferer, or invent a Denglish (German/English) term.
- No matter how much of an expert you are with the software you’re localizing, you still need to research some terms and sometimes try to get evaluation versions of other software to help the translation process.
Overall, Markus advises that there is no right or wrong way to localize. You make a decision, and just make sure to be consistent. It’s an iterative and continuous process — and a worthwhile one for users worldwide.