Localization is the invisible dimension of DevRel
Serving intenrational developer communities is not just about translating content. It’s about making the entire developer experience usable, and relatable.
Developer Experience is more accessible to developers when it properly recognises three localization layers: linguistic, technical, and cultural. In this article I’ll unpack these aspects based on my proffessional experience.
So why does localization matter? Although many non-native developers use English as their primary business language, it is not always the case. In my professional experience, I have worked with developers who did not speak English, and we communicated with the help of a translator. You might say, it’s not a big percentage of the developer community, however by supporting Japanese developers at Box, I have learned that, it is highly localized content is highly appreciated even if developers are fluent in English. It supports deeper understanding of complex and abstract technical concepts.
This relates to the most basic localization layer - linguistics. It includes developer documentation, microcopy in developer consoles, and all sorts of supporting content such as tutorials, blog posts, and videos. At first glance, this might seem like the easiest part to solve. Translate the content, and you’re done. In practice, it’s not that simple.
I worked directly with translators and localization team, and during a content migration to a new documentation platform, I realized how much effort this actually requires.
During this process we discovered that many strings were hardcoded or translated inaccurately with AI within the documentation framework itself, which made consistent localization difficult. From this experience, I can deffinietelly say that AI translation is not quite there to support technical content transation efforts and I experience it first-had by reading generated translations to Polish.
Overall, human translators ensure that the technical nuance is not lost, terminology and naming is consistent, and the final result feels natural to native speakers. This applies not only to the developer documetation, but also to developer blog, changelog, and communication related to critical changes, for example via e-mail.
To extensively support global communities and expand into new markets, it’s worth investing in accurate and well-maintained translations, as a part of delivering a localized developer experience.
But this this just the surface of this deep rabbit hole…
Let’s switch gears and focus on the technical aspects of localization. This layer ansures that the developer tool is actually usable.
Earlier in my career, I worked as a frontend developer on projects that required Right-to-Left (RTL) layouts. At the time, I saw it as a very fascinating and nuanced technical area. Recently, I realized that this layer also impacts adoption of developer tools. Just take a look at this n8n community request related to support for Persian or Arabic.
Amazingly, this need was actually so strong, that it was tackled not by the product team itself, but by the community contributor. The repository includes the persianArabicTextProcessor.js file and tackles some of the challanges related to following areas:
“Character Shaping: Converts standard Unicode Persian/Arabic characters into their appropriate presentation forms (isolated, initial, medial, final) based on surrounding characters.
Ligature Handling: Supports common ligatures like the various Lam-Alef combinations. [ligature - a character consisting of two or more joined letters, e.g. ﻻ/لا, æ, fl.]
Right-to-Left (RTL) Reversal: Reverses the order of characters and tokens to ensure correct RTL display within each line.
Smart Reversal: Preserves the order of numbers and correctly swaps parentheses direction during the RTL reversal process.
Basic Line Breaking: Adds simple line breaks based on a maximum length, finding a suitable space to split the text and ensuring lines appear in the correct top-to-bottom order for RTL reading.”
I believe, it’s important to consider those aspects at the early stage of the product development, as the basic RTL support should be straitforward to implement. I have gathered all my experience related to this topic in this article, so you don’t have to traverse all interet for a search of examples and solid resouces.
Earlier in the post, I have criticised AI for not handling translations well, but I’d be curious how well would a coding assistant handle localization from technical point of view.
Continuing the thread of the technical adaptations, I’d like to mention another prominent example we faced during the aboved mentioned documentation portal migration. Team members from Japan have flagged a critical bug - users were not able to submit advanced characters in the AI assistant chat input. It was a moment, when I learned about the Japanese Input Method Editors (IMEs) - software tools that allow you to type Japanese characters (Hiragana, Katakana, and Kanji) using a standard Latin-script (QWERTY) keyboard. Toghether with the translation team, we strongly advocated for all users using this feature. This effort led to a better developer experience for all users who leverage the input method in this product.
I’m certain, that there are more of such cases, as localization is a very complex area. It touches date formats, numeric systems, and much more. That’s why I believe, it’s crucial to consult solution with specialists in this niche.
Last but not least, we need to admint that culture and regional nuances shapes how developers trust, adopt, and use tools. And it also should impacts the DevRel programs.
Think about product use cased within your content that apply only in certain regions, but are totally foreign to others. In my case, I focus on proceses related to document management. For example, at my work I learned that in the US there is widely recognised W-2 form (a wage statement form). However, this is not globally recognised form, so people in EMEA or APAC might have no idea what is actually is.
That’s why keeping the persective of your audience, either in your written content, or during your presentations in various countries matter. First and foremost, you need to ensure the use cases are relatable. This applies not only to specific country, but also industries across the world.
Other cultural differences might include tone and politeness. This is externmaly important while crafting messages about upcoming breaking changes. In my work, I rely on experts and native speakers to ensure the style of the annoucement is appropriate.
Additionally, I have to admit that that users from certain regions expect extreme precision within specifications. And they have been my grates allies! They help to pin point the gaps and missing details in product and in developer docs. I think, it’s a perfect synergy, and it’s really worth appreciating it.
Finally, this demonstrates, why it’s important to have a diverse DevRel team. Cultural diversity enriches perspectives thanks to various backgrounds, thinking patterns, languages, and also personal experiences.
By publishing this article and showcasing the examples, I don’t mean that DevRel teams should solve all localization issues or make sure to cover all corner cases. I think, the most importnat part is the openness to learning about various struggles developer face. As Developer Relations practicioners we should support them as much as possible. It’s also worth addmiting that solutions developers are building are oftentimes targeted at various markets, and they also may want to localize their projects.
Buidling developer experience and ecosystems is certainly a cross team effort. I don’t think I’m able to indicate a developer tool or a platform that I would name a golden standard in localization space. As a matter of fact, it’s actually hard to asses and address all those issues, with contraints that we work with, and the complexity of the reality ifself.
However, I’d like to encourage you to keep and eye on this, so it’s not your organization blind spot. Make the effort to truly provide a localized experience for devs around the world or make a concious decision about which markets you support.
Start by looking through a lense of localization layers and you’ll start noticing more nuanced reality of developers.