Lightning Talk: Going Global: Lessons From Internationalizing... Severin Neumann & Tiffany Hrabusa

This talk discusses the localization efforts within the OpenTelemetry project, emphasizing the challenges and strategies involved. The speakers explain that while AI, such as language models, can assist with translation, human expertise is crucial for accurately translating technical terms like traces, logs, and metrics. They highlight the importance of maintaining quality control over documentation through localization teams, which also serve as an entry point for newcomers to engage with the project. The session outlines a practical approach to setting up localization, recommending starting with a few languages and providing structure for contributors. Additionally, the speakers touch on the ongoing complexities of permission management and the need for more contributors to enhance open-source localization efforts.

Hi folks. Uh, I'm Tiffany. This is Severin. >> And I'm Severin. Hi. Um, I am here in place of our colleague Fabrizio, who was not able to be here today. So, I'm filling in. And we are both from the OpenTelemetry project, and we're going to talk about how we began the localization process. Awesome. So, first of all, apologies for my voice. I need to suffer for 4

minutes now. You may be, too. Um, there's a big elephant in the room. This is a big room. So, it's a very big elephant. Like, when we talk about localization, the first question you might ask yourself, like, "Hey, isn't it a solved problem?" Like, "I mean, we have AI now, right? So, just use an LLM. Problem solved, right?" And we think yes, but no. That's not true

for a set of reasons, right? Um, first of all, you know, need to know your topic, right? So, even if you use an LLM, it cannot always do the correct translation. So, you still need to review the stuff. You really need to look at the text. And most importantly, there's terminology where you're not maybe sure if it should be translated. And we figured out over time, this

is a decision that can be very different from language to language. So, in OpenTelemetry, for example, we have traces, we have logs, we have metrics. And we have some languages translating those terms, and some languages we're not translating them terms. And if they're translated, very often they don't know, like, "Okay, what is the right term even in our own language?" Another good reason is, like, with localization

teams, you get quality control for your English sources, right? If someone translates OpenTelemetry documentation to Portuguese, to French, and they read the text, and they're an OpenTelemetry expert, they stumble upon things and say, like, "Hey, even the English one is not correct. Let me fix that first, and then go back. And most importantly, it's about community, right? Our localization teams provide you an easy entry into our

project. The same is true for other projects that have a localization team. So, even if you don't feel comfortable with English with English today, you can get started in in your mother tongue and and step up from there. And we now have approvers and maintainers that started through localization and now are a crucial part of our project. So, how do you do it? How can you, if

you're a maintainer today, do it how we did? And of course, even we are standing off shall on the shoulders of giants, right? I mean, we just look like what would Kubernetes do, right? So, we looked up what they're doing. We learn from them. the practice is very simple, right? Start small, pick one or two languages, and try out things. Uh grow organically from there, and give

people structure. So, what do you mean by structure? Uh you need two people. You need someone uh who reads the text writes the text, someone who reviews the text. You need a mentor. So, you need someone who already maybe knows this thing, maybe someone who is already in the OpenTelemetry project or in your project that can guide the people. And then you just say like, "Hey, start

with the landing page." And then we maybe need to set up a few things uh because there's uh a lot of guidance we need to give you from there, like um how many PRs do you need to do before we can make you an approver, before we can make you make you a maintainer for that specific Um and there's a lot of tooling that you might need

to build over time. So, if you grow organically, you have much more time doing that, right? Like, drift detection, uh but also things like labeling or using project boards on GitHub. So, Severin has talked about what we learned, but there are still many things that we don't know how to do yet. Um the biggest one is that we want to empower the localization teams to take control

of their own doc set and their own workflows. Um we want to encourage them to solidify as a group to have synchronous meetings uh where they can discuss the problems that they're facing. For us as maintainers, one of the biggest challenges is permission management, and we have not figured this out yet. Um we haven't decided whether one repo is the better choice or multiple repos. Currently, everything

is in the same repo. Um and that has some advantages and some disadvantages. Um with one repo, um you have shared tooling. So, um our infrastructure experts only need to worry about maintaining a single repo. Um whereas with multiple, the work multiplies. And also, um there's for the um for the contributors, in a single repo, they have no ability to merge their own PRs, whereas with multiple

repos, we could give them um granular permissions so that they would be able to control those workflows. And of course, there is the evergreen unsolved problem of open source, which is how do you get more contributors? So, this is our call to action for you. If you are interested in contributing to open source and you speak more than one language, come contribute to our existing localizations or

follow these directions to propose your own localization. And last but not least, thank you if you already helping us localization, doing localizations. So, we are just the maintainers enabling those teams and yeah, thank you for doing that. And if you're thinking about starting, thank you for starting. And yeah, thank you for listening.