Companywide, we are very excited to have recently released support for French, German, Italian, and Spanish in the HotelTonight apps to better serve more people in more places! When it comes to supporting multiple locales, we are really just getting started in many respects. Despite this, we thought we would share some of our experiences from the past 3 months in order to help others better understand what’s involved once you decide that you’re ready to bring your mobile apps to an international audience.
This will be a eight part series of posts that discuss:
- Planning, tools, and process
- Measuring impact
With all of that out of the way, let’s dive in and talk planning, tools, and process.
So you want to expand to an international audience, where to start? We’re going to limit the scope of what we talk about to be very app-centric. In other words “What do you need to worry about that is directly tied to your mobile apps?”
When we started on this journey, there wasn’t much done.
- Neither the apps nor APIs were internationalized
- We used Unicode (UTF-8 and UTF-16) in all of our apps all the way through so there was no need to add support for nor convert data between character encodings
- The mobile app screen layouts were not necessarily designed with localized content (longer strings, etc.) in mind
- As a company, HT had zero translation experience
- We had implemented support for multiple currencies as we’d already expanded into Canada, the UK, and the Netherlands
- We had limited customer support staff with the language skills to support the new locales
- We had no full-time QA staff
So how’d we go about figuring out what to do?
Identify tools to help
Internationalization and localization is a solved problem at least to a degree. We absolutely did not want to re-invent the wheel and primarily focused on finding a hosted translation management system (TMS) that we could use to localize content. Some key features that we looked for:
- Hosted, affordable solution
- A tool that would allow either HT staff or vendors to carry out localization work
- APIs to get content in/out of the system (enables automation)
- Translation memory (including the ability to import/export in TMX format)
- Glossary (including the ability to import/export the data in a format such as CSV)
- Support for Ruby YAML, Android XML, and iOS Strings formats
- Read-only placeholders for inline markup and/or variables
We ended up choosing Smartling as the TMS that best fit for our needs. Besides satisfying our core needs they offered some nice features to help support better translation quality like the ability to associate screenshots with strings to give translators better context to translate with.
Roughly estimate technical scope
- We estimated and made changes to externalize strings in both the APIs and mobile apps
2) Mobile app screen layout
- Once the API and mobile app strings were externalized we generated pseudo translations via Smartling (albeit there are any number of ways to do this). The pseudo translations are fake translations with longer string lengths and preferably a mix of non-ASCII characters. We dropped these in the apps and APIs and filed tickets/stories to address obvious layout issues.
3) Web content and emails
- We estimated and made changes to externalize strings in web pages and email
4) Internal tools
- We decided to create an internal tool that allowed us to associate strings and screenshots and then publish those to Smartling. This is something that we’ve thought about open sourcing so if you’re interested please get in touch with us.
- For certain types of content such as hotel profiles, a large chunk of the the content isn’t reusable. For this situation we opted to extend our admin UI to allow direct translation of this content rather than send it through a TMS.
Roughly estimate localization scope
Once the strings were externalized, we were able to generate word counts via the TMS. A number that is often used for rough estimates is to assume that a professional translator can translate on the order of 2,000 words/day.
We used the word counts to project costs and a schedule. We staggered the schedule such that strings in the mobile apps and APIs were translated first so that we could begin testing as early as possible.
Start hiring help
We immediately began searching for localization help, multilingual customer support team members, and multilingual QA engineers. We were able to fill these roles in a 1-2 month period.
Since this was our first round of support for new locales, we intentionally kept things fairly manual out of the gate. Here’s the basic workflow we follow for each round of localization that we complete:
- From a designated branch in source control for each app, upload the externalized strings to the TMS
- Download the externalized strings from the TMS
- On a separate source control branch, create a pull request (we use github) for the Android, iOS, and Rails teams to review and merge in localized string updates
- Generate builds (automatically via continuous integration or manually in some cases) once the pull requests are merged in
- Test (at different points this ranges from the product team to the entire company)
- File bugs as needed
- Rinse, repeat
We plan more automation around this process to make it more continuous in the future, but wanted to make sure we had something basic that worked as a starting point.
When we need to adjust translations we search for and update them directly in the TMS. The updated translations are typically then pulled into the apps with the next round of localization.
Many of the roles here such as designer, engineer, QA engineer, or translator are fairly obvious. One that may not be obvious is the localization project manager. This person is responsible for:
- Creating and maintaining the style guide and glossary
- Managing the translators including answering any questions such as clarifying the context for a specific string
- Training translators on how to use various tools
For us there were additional responsibilities such as soliciting feedback from multilingual team members throughout the company. This is a full-time job! If you are working with a localization service provider you will likely pay for someone to take on at least a chunk of these duties, but if you are doing things in-house be aware that this isn’t a side job.
This concludes what we’ve got for you around planning, tools, and process. If you have questions or would like more details please don’t hesitate to get in touch with us. In upcoming posts in the series, we will delve into more specifics for Rails, Android, iOS, design/UX, QA, marketing, and analytics.