Finding Translations: Localization and Internationalization

by Valerie Woolard

The video titled "Finding Translations: Localization and Internationalization" presented by Valerie Woolard at RailsConf 2016 addresses the complexities and strategies involved in localizing and internationalizing software applications, particularly within Ruby on Rails. The talk breaks down key concepts in software localization, defining 'localization' as adapting software to a specific region or language, while 'internationalization' refers to preparing an application for these translations. Woolard emphasizes the importance of preparing for localization even if it is not an immediate priority, as doing so can broaden audience reach and enhance the overall development process.

Key points discussed include:

- Understanding Translation: There's a direct translation between languages but also context like regional differences (e.g., British vs. American English). Register and tone must align with the target audience.
- When to Consider Localization: Immediate attention should be given to localization processes, as potential user demographics can be much more diverse than assumed.
- Rails Localization Tools: Woolard covers tools and gems available within the Rails framework, including options for managing YAML files, utilizing translate/localize functions, and implementing backend solutions for easier access to translation resources.
- Managing Translations: The practical difficulties associated with handling translations, such as managing many strings and avoiding merge conflicts in files, are addressed. Suggestions include breaking down YAML files by functionality or employing a database for better organization.
- Cultural Considerations: The importance of recognizing cultural differences and legal contexts in different markets is highlighted, such as varying privacy standards and healthcare systems around the world.

Woolard concludes by underscoring the necessity of treating translation as a serious aspect of software development, urging developers to approach the task with careful planning and awareness of audience differences. She encourages viewers to recognize the potential benefits of incorporating localization practices early on, even if direct translation is not yet needed. By considering these factors, developers can create a more inclusive and accessible application for a wider audience.
Overall, the talk provides practical guidance for those looking to enhance their software through effective localization and translation practices.

00:00:11.300 Okay, so we're at 10:50, so I'll go ahead and get started. I'm going to be giving this talk on localization, translation, and internationalization in your Rails apps, cleverly entitled "Finding Translations." Although someone yesterday suggested the alternate title of "Many, Many ML Files," which we'll discuss as fitting for this talk as well. We'll start out by defining our terms. Localization is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating the text. Internationalization, on the other hand, refers to setting up your app in such a way that it can be translated. We'll mostly talk about how to set yourself up for success in terms of designing your app, even if you might not initially plan on having it translated. These processes and considerations will be beneficial in any case. Thanks, Wikipedia, for those definitions. In plain English, we're talking about translating and, more importantly, getting ready to translate your app.

00:01:30.659 So, what do we mean when we talk about translation? The most straightforward type is what most people consider when I say "translation." This includes tasks like translating between languages, such as English to French, French to Arabic, English to German, Swahili to Esperanto, Spanish to Cantonese, etc. However, it’s also crucial to consider what country you're addressing. Are you speaking to British or American consumers? What about Portuguese and Brazilian consumers? These populations may speak the same language but not necessarily have the same content delivered to them.

00:02:06.249 Another important aspect to be aware of is the register, whether formal or informal, professional or the tone used in your Twitter feed—for example, AP style or MLA style. Although we will primarily discuss the first type of translation, you should always have the second type in mind. When translating, consider the country from which the people using that language will come. Relevant topics include units of measurement, government legal terms, and date formatting.

00:02:40.580 The third type of translation we won't discuss in detail, but your translators should be aware of the register you want to convey in your app so they can write for the appropriate audience. I could also see these same tools being used to transpose between registers. For instance, if you have a version of your site for kids and parents, you can apply some of these internationalization conventions to achieve that, though I’ve never done it myself—it could be fun!

00:03:02.170 Now, let me introduce myself. If you get this joke—two, four, six, oh one—I'm Valerie Woolard, and on Twitter, I'm @ValerieCodes. You should tweet this talk because mentions are my lifeblood! I'm a Rails developer at Panoply, a podcasting platform that is part of Slate. If you want to geek out about podcasts, please find me after the talk. I'll share my recommendations, and my subscription list will continue to balloon uncontrollably! I have interests in linguistics, translation, and language studies. Before becoming a developer, I was a French major, and I studied cognitive science with an emphasis in linguistics. I've done some translating in an academic setting and hope to provide some insight for those less familiar with the translation process.

00:04:58.270 So, without further ado, if you want to localize your app, you might feel like this dog—especially if you're not well aware of the pitfalls that can arise during this process. When should you think about localization? The answer is: now. Even if you don’t foresee a future where you need localized versions of your app, consider that your possible audience probably isn’t limited to just U.S.-based English speakers. If you think about the number of languages spoken just in the United States, limiting yourself to only English speakers can significantly narrow your potential audience. Therefore, it should be on your radar as a possibility that may arise at some point.

00:06:06.130 Even if you never localize it, you won’t hurt your app by using some of these conventions, as they can provide other advantages in your development process. When should you internationalize? Again, this is something you want to consider before you need it. For example, don't hard-code strings into your views; this is an easy win. You can use locale keys in your views and reference YAML files, allowing you to keep all the copy for your app separate from your actual code. This way, if someone who's not a developer wants to make changes to the copy, they won't need to dig through the code. Instead, they can simply edit a YAML file, which is much easier for everyone involved.

00:07:05.860 There are many built-in tools for Rails localization. There's the i18n guide, which covers the basics of how to use those tools and create keys that are referenced in your app. The default setup for Rails localization is to have a YAML file where you will have a key and a string. When you reference that key in your application, the corresponding string will be pulled from the YAML file. You’ll also have separate YAML files for each locale, such as for French and English. Based on the locale setting in your app, the correct string will be pulled in. There are many built-in tools available to assist you with this process.

00:08:04.850 For instance, `translate` refers to pulling the correct strings, while `localize` deals more with contextual elements like units of measurement. You've got your YAML files filled with strings, but managing these files can become overwhelming, especially if you have hundreds or thousands of strings in your app, depending on complexity. You should consider whether this approach is practical for you and your organization. One way to ease this burden is to customize YAML files per feature so that you're not relying on a single large file housing every string used in your app, though for very complex applications, this might not be ideal.

00:09:25.380 Here are some helpful gems for your localization journey: Rails i18n provides numerous translations and different locales for errors that are baked into Active Record, including default date formatting, which saves you time. Locale app is a gem that offers a web interface for storing translations that translators can access. It's a paid service, and I’m not certain if there’s a free tier, but it’s worth checking out if you're looking to add translations.

00:10:06.170 Globalize is an invaluable tool when you’re adding translations to your Active Record models. This is essential if you want your blog posts, stored as Active Record models, to have alternate versions in different languages. The GeoCoder gem helps set a locale based on a user's IP address, which can be super helpful too. I18n tasks is another gem that scans your YAML files for keys that are missing or unused, allowing you to optionally remove them. It can also pre-fill missing keys from Google Translate if you want a quick solution.

00:11:28.780 One possible workaround for the YAML nightmare is proposed in a RailsCast episode, providing a framework for using a Redis-based backend for locale keys. Another option is implementing an Active Record or similar database-based backend. Just keep in mind that these keys will likely be loaded on every page, so having them stored in memory or some sort of cache is preferable to having to perform a database lookup each time a key is referenced.

00:12:09.630 If you decide to stick with YAML, one helpful tip is to edit it using a graphical YAML editor. When designing your translation backend, consider that those entering the keys may not be developers. If they’re from the marketing department or are professional translators, you probably don’t want to ask them to use Sublime Text to write keys; instead, provide a graphical interface to simplify their tasks.

00:13:34.350 These aspects are crucial when considering localization. First, you need clarity on what needs to be translated—what’s the scope? Are we talking about a 10,000-line project or a 100-line project? Do we need to hire a professional translator for polished translations, or will Google Translate suffice? We also need to decide what model attributes need translation. Consider the lengths of strings and the complexity of comprehension in a YAML interface.

00:14:40.930 Another thing to consider is special characters that your chosen database needs to support. What additional information would be helpful for translators? Providing contextual information and a user-friendly GUI for translation can vastly improve translation quality.

00:15:29.420 When concatenating locale keys to form sentences, reevaluate your choices. The reason for this is that fragments can’t always be translated accurately due to differences in sentence structure across languages. Instead, use the I18n system in Rails to support the passing of variables into full sentences—this allows you to provide context to translators.

00:16:12.090 Another pitfall to avoid is assuming that pluralization works the same way in all languages. In English, pluralization remains consistent for zero and more than one, but many languages do not follow the same rules or may distinguish between zero things, one thing, or more than one thing differently. The I18n module provides a way to manage these variations through a count variable to address pluralization accurately.

00:17:06.000 Furthermore, the specificity of translations may vary by language. You might need to give your translators more context than what an English string would provide. Issues like gender and register are essential; your translators should know how formal or informal they need to be in their translations. Additionally, be aware that other languages may require a message to be longer or shorter than in English, influencing design choices such as fixed-width or height containers.

00:18:21.170 Some languages read right to left, which can affect design and layout. For example, elements like logos and search bars may also need to be repositioned. Ensure your application supports other character sets, especially if you aim to implement non-Roman alphabet languages.

00:19:30.840 With all these considerations, be mindful of potential merge conflicts when managing your translations. If everything is contained in one large YAML file, conflicts can arise frequently. Therefore, it could be helpful to separate your keys by functionality and utilize submodules within your main repository, which can give translation teams restricted access to just the YAML files.

00:20:01.150 You could also utilize a database-based backend where translators make edits that are later pulled into your YAML files. This external source of truth helps avoid reliance on the potentially inaccurate YAML files in your repo, providing a reliable audit trail in case a file is lost or deleted.

00:21:38.450 Another crucial topic to touch on is the reasoning behind translating your app. It's not a bad idea to support non-English speakers and make technology accessible to diverse communities. However, it’s essential to explore cultural nuances, such as privacy norms, legal issues, and localization needs for different markets before making translation decisions.

00:23:16.240 For example, the U.S. has different norms regarding privacy compared to Europe, which may influence how tracking and personal data sharing are perceived in your app. Legal implications should also be considered since copyright laws and defamation may vary from country to country.

00:24:18.580 It's also important to note that certain needs may not translate well into other markets. If your app revolves around U.S. healthcare, it may not resonate in other countries. Thus, determining your target audience when deciding to localize or translate your app is essential. To summarize, please remember these takeaways: consider localization now rather than later. Even if you don’t plan to translate right away, implementing strong localization practices can yield dividends. Be thoughtful about the quality of translations needed, and ensure your translators are well-acquainted with the app’s details. Translation is a challenging endeavor, and if you care about providing a quality product for non-English speakers, investing time in this process is essential. Lastly, always know your audience when determining your translation choices. Thank you for attending; I'm here for any questions!