Lost in Translation

Imagine you downloaded a new productivity app from the app store. It’s got a ton of five star reviews and people online are raving about it. They’re saying it’s life changing; delightful. You open the app for the first time and see this: 

Hmm… Strange. The words don’t fit properly in the button. You can’t understand what information you’re supposed to enter. And even worse; the content is German in some places, and then randomly, English in others. You close the app and hope that a reboot will fix things, but it doesn’t. You begin to wonder why people enjoy this app when you can’t even navigate to the main screen. Oh well, you say, and go back to Evernote. 

Well, it turns out this app wasn’t designed with you in mind. It was designed in another language for different users. Most of the reviews were from users who speak that language, and they have no idea what it looks like to you. Believe it or not, this is a common scenario that a lot of non-English users experience time and again. A lot of tools that are available on the market are designed and built in English, including HubSpot. 

Today, we market HubSpot as a fully localized product in 6 markets outside of the U.S., but we haven’t fully delivered on that promise to our global customer base. Not only do translation errors breed mistrust in our non-English users—they hold us back from our goal of creating a truly global product that works for our customers. In our current development process, all translations are handled after features have been designed, tested, iterated on, and implemented. This process breaks down on a couple different levels: our translators have little to no context when working on translations, and we currently don’t have a quality assurance process around checking translations. 

Now that we’re in code red, it’s the perfect time to look at our approach to localization in order to help ensure that the integrity of the designs we agonize over are maintained in all our supported languages. I believe there are several plays we can make as a design team (and with minimal effort) to improve our experience and help our customers grow better. 

Identify Problems

The first step to improving our translation process is to discover current translation pain points for our customers, and then work to prevent them. By remembering to include internationalization in your design process, we can improve the quality of our experience for our global audience. This will not only help create a stable product, but could help prepare us to design for other emerging markets in the future. Below are some tips on how you can identify translation problems in the current product, and how to prevent them in the future: 

• Run empathy sessions and audits:  Ask our international coworkers if they could carry out empathy sessions on your part of the product. We’re lucky to have in-region localization experts who can put color to these experiences. For example, Constance Starcky recently completed a secret shopper walkthrough (you can watch it here) in French that was eye-opening and identified multiple translation pain points for our French customers.

Another way to build empathy is to run a UX audit of your product in a different language. If you don’t speak any additional languages—no worries—simply partner with a friend and do a side-by-side comparison of the HubSpot portal. 

• Pseudo-translating: Translate.me is a handy Sketch plugin that uses the power of Google translate to mock- or pseudo-translate text layers into almost any language you want. You can follow the guide to download the plugin, and I can provide the Google API key to get it working. This hasn’t been widely adopted, so please give it a try and share your experiences. Pseudo-translation will never replace localization, and should only be used as a guide during the design process.

• Testing with non-US customers: Including non-US customers in your research or usability tests is a great way to experience how different cultures perceive design. The UX Research team has already made it an effort to include non-US (but English speaking) customers in their research sessions. However, it’s also important to start thinking about testing with non-English speaking customers. There are quite a few HubSpotters that speak multiple languages, and, in my experience, are willing to help out with translating something or helping facilitate a user test. Therefore, you shouldn’t be afraid to try; there’s plenty of help. You can also leverage usertesting.com to run unmoderated tests with customers from all over the world.

Set guardrails

When you’re working on a design, it’s important to work with your Content Strategist to make sure your content is easily internationalized when it goes for translation, They're best-placed to write - or to help you write - in Plain English. Plain English is the best base from which translators can work from. However, if you’re writing your own content, you should stick to a few basic principles to make sure it’s as easy as possible to internationalize.

• Keep it short. Short sentences are easier to understand, read, and translate. It also helps in the translation process because, when translated from English, some languages can extend character counts up to 40 percent (here’s looking at you, German). By keeping your sentences short you’ll allow room for this expansion. Remember to make sure you’ve left enough real estate for this too.

• Steer away from jargon, idioms, and phrases: Technical jargon should always be avoided in user-facing content, but it’s also difficult to translate exactly. And while there are some idioms and phrases that may be well known in English, it doesn’t mean that they work in other languages. Knocking out of the park doesn't make sense in German!

• Use our content systems: If you haven’t heard of Bethbot yet, you’ve been missing out. It's HubSpot’s automated editor tool. You just paste in your content and Bethbot will check it against the HubSpot style guide, and voice and tone guidelines. It will also assess its readability, accessibility score, inclusive language score, and more. This is vital to making sure your copy is in Plain English. You can get it as a Chrome extension, Slack bot, web app, and Sketch plugin. If you can’t get your content to pass the BethBot test, or you want a little extra help, try Hemingway.

If you have any doubts or queries your content strategist is there for you, so be sure to reach out!

Give translators context 

Being a translator at HubSpot is a tough job, and at times frustrating. I’ve heard translators describe their experience translating new strings as a “blind” process. Unless they receive some information about what the strings should be and how they should look when a feature is released, they can only guess and hope their translations will resonate with customers. This often results in language errors being reported by our customers and in-region colleagues. Here’s a typical view of our Translator’s software: 

As you can see, there’s no way to tell what the final product will look like. Thus, If a translator can’t figure out what a string is supposed to be they have to open a ticket with the responsible product team. The common result is extra time spent processing translations shared between the product team and translator. To help alleviate back and forth between translators and product teams there are a couple of things that you can do to help provide relevant context to our translators. 

• Uploading screenshots:
The i18n team has built a great resource center for i18n here(you know you want to bookmark this!). In the i18n resource center, you can search for the translation source code of your feature (if you can’t find it, ask your Front-end Engineer for the file name). Once you find your source file you can add screenshots to each string. We currently have a ticket in to hopefully have the ability to add in comments with these screenshots, but in the meantime you can work with your Front End Engineer to get comments put in with the translation strings or upload a pdf with more information on the feature. 

• Details you can clarify for Translators:
   When providing context to translators, err on the side of including too many details. I’m sure our translators won’t complain about getting too much context. Here are some examples you can share with the localization team:

• How will a string appear? Is it for a button? A drop-down menu? A header? Right now translators are operating without a lot of screenshots or visuals so any context here is helpful. 

• What triggers the message and what the desired user action is. 

• Whether placeholders (areas with dynamic text like dates) need to be translated, and also all the types of content that could appear in that space. For example, all the options in a dropdown. 

• Who the users are and whether the text needs to achieve a desired tone. For example, error messages may be frustrating, and the tone should be soothing rather than abrupt. 

• How ambiguous words should be translated. Translators need to know if a word is a noun or a verb, or if the word is defined by the gender of the user. Some languages have gender-specific forms for nouns and adjectives.  

I hope you found some of these tips helpful. If you have other design tips for Localization or Internationalization, feel free to chime in below, and we can all learn from each other. By spreading the word about Localization and Internationalization, I’m hoping we can all do our part to build a better HubSpot for all of our customers around the world.