How Technical Writers Are Becoming Localization’s Secret Weapon

Speaker A: Welcome to the Agile Localization podcast by Crowden, where we unpack the strategies and solutions that make localization fast, scalable and efficient. I'm, um, your host, Stefan Yui. Good morning from Dallas. It's early in the morning. Here I am with Ian Crowley, a, uh, technical writer at Salto with a background that seems it's right at the intersection of language, technology and user experience. Ian holds a degree in modern languages and speaks three fluently. We're going to quiz him about that in a minute. And he has a genuine passion for localization and internationalization and, uh, workflows that actually work in the real world and beyond his work at Salto, Ian also contributed to open knowledge initiatives, including localization efforts through Google Season of Docs, helping improve the translation experience for global education platforms. He's someone who's clearly appreciating both the linguistic side of our craft and the technical systems, and that makes him the perfect guest for our Agile, uh, localization podcast by Crowden this morning. Ian, is there anything important that I blatantly forgot?

Speaker B: No, that sounds great. Effectively I am a technical writer, but as is often the case with technical writers, we do a lot of different things that aren't actually technical writing. And so one of that is, of course, yeah, looking after our internationalization, localization processes. Uh, Salto.

Speaker A: Awesome. What are the languages that you speak?

Speaker B: Well, so I'm based in Spain in the Basque country in northern Spain. So I speak Spanish. I've been here for quite a few years. I speak pretty fluent Spanish. I studied so my baccalaureate years in France. So I also speak French, which is useful because I'm very close to France here as well. So those are kind of like. And obviously English is, as you can hear, is my, my native language. I'm originally from Scotland.

Speaker A: Uh,

Speaker B: Uh,

Speaker A: All right, all right, good. Let's get into the topics a little bit. When you look at a product, where do you think localization truly begins?

Speaker B: Yeah, great question. I think localization, I'm m going to say it begins at the beginning. And what I mean by that, you know, it starts at the start of the product life cycle. I think you have to be thinking about localization in the inception stage, in the design stage. And even if English is your source language, particularly in products that, you know, are targeted to specific markets, you have to take into account that there are going to be translations. You know, obviously there are some products that are out there that don't contemplate translating or using another language that say, not English or whatever, but say, for example, you have a product. In our case we're using, a lot of our applications are angular apps. And so this framework already has uh, an internationalization model built into it and it's useful to be able to understand how that works before you're even thinking about strings, before you're even thinking about actually translating. And then you might be targeting a country, for example, where a right to left language needs to be supporting your Arabic and that kind of thing, you know, needs to be built into the product and kind of considered from the beginning. Yeah, yeah.

Speaker A: Uh, what's talking about strings right away? What's something most teams misunderstand about strings in software? You think There's a lot of talk about strings nowadays in the localization industry?

Speaker B: I think I see often outside our world, um, strings can kind of often get mixed up with words.

Speaker A: Right.

Speaker B: Um, some people kind of think that a string is a word, but that's not the case obviously. And I find that happens, you know, quite a lot outside the development world. Um, yeah, I think that, you know, the effort required in ensuring that strains are coherent work well. And it's generally not understood, you know, this kind of, I guess, a UX writing content design task. But understanding which string is being used, where to use it, requires a great deal of context. And when it comes to translation, context is highly important. And of course context switching is particularly hard, you know, particularly when you have a huge range of applications, which is kind of our case.

Speaker A: Yeah. Traditionally there's been, uh, quite a lot of disconnects, I think, between developers and writers and developers and translators to collaborate on a string level. How can developers and writers collaborate better at the string level, in your opinion?

Speaker B: That's a great question. I mean, in our case, constant communication, you know, I don't think there's another way. I think as a kind of technical writer, uh, we're used to sort of being, or at least trying to be everywhere at the same time in every place. I don't know if that's the way that's the correct name of the film. And it's not just obviously development teams, it's the sort of UX and UI design teams as well. And of course tooling helps. Right. Obviously crowded. There are other tools out there specifically for string management.

Speaker A: Right.

Speaker B: There's things like ditto, uh, which sure you're aware of, but communication, communication is clear. You know, like I say, as technical writers, we're used to kind of picking up scraps from wherever we can find them. You know, we're the scavengers of the development world and getting that kind of understanding of we should be helping the development teams when it comes to string management is key.

Speaker A: Yeah. And about string management and string context in particular, you'd think that's still the biggest on so problem or there's other connected problems that you think are just as important.

Speaker B: So yeah, obviously, I mean we will probably talk about AI at some point and I think string context is. We're getting there. I think it's a lot better than it used to be. There's, there's tooling that helps you understand where a string might be. You know, you can integrate uh, figma or Sketch into your tms. And I think part of like transmitting to translators the meaning of what a string means. I think it's a huge part of the whole UX and technical writing process, which is kind of undervalued. And as I say, we'll talk about AI, but obviously as well as human translators, AI needs that context as well. So it's kind of even more important in this day and age.

Speaker A: Yeah, and if we put you in charge, then how would you redesign how strings are handled from scratch? What would you change?

Speaker B: Yeah, so I think for a start, please, you know, no more Lorem Ibsens in designs. I think that's one of my bugbears. I mean designs and this is something that we try and do is, you know, design should be made with real strings in mind from the start. I think that's really important. And um, you know, I think a key point with string management is there always should be one unique source of truth. Right. Whether that's the code, whether it's a design tool, translation tool even, or some external tool we talked about. Ditto already. I think this is vital. Obviously working with versioning is a nightmare. You want to be always thinking about where is the truth for my strings. Having multiple versions of strings is unmanageable. And I see things as well. I mean it's not something that's new, but pseudo localization, for example, is interesting. I see a lot of companies that stress test at with pseudo localization. It's something that we've kind of touched on a little bit as well in Salto. So yeah, I mean, I think there's a lot of things that we could do. There's things, you know, are improving. But yeah, it's a big collaboration process between design teams, development teams and of course whoever is looking after your localization processes, whether that's technical writers, UX writers, translators themselves.

Speaker A: I'm sure the translators are Happy that you speak a couple of languages yourself and you can talk shop with them. Where does technical writing sit in the localization life cycle today?

Speaker B: I mean, I think tech writers play a pretty fundamental role in localization. Again, I think it's undervaluated the role that we play, you know, and I guess obviously we're talking about both tech writing and UX writing here, not just technical writing. And often the two are. Although they're very much the same field, they're different disciplines if you like, but there are a lot of crossover.

Speaker A: Right.

Speaker B: And I think the most important part of the tech writer's role, as we know, is to help users understand the application or the software, the hardware. And it's inevitable that tech writers are key in helping to facilitate the work of translators to understand string context. And there's many ways of doing this manually retroactively answering emails, messages, or you can be proactive and you can bake all of this into the context engineering workflows. So for example, we talked about this already, syncing design tools with your tms, things like persisting context of strings in the code, which was something that I worked on with the Season of Docs project that you mentioned, the Calibri project. They had a really nice setup where, you know, essentially the context went wherever the string went. And that was really useful, I think, when giving context to translators. But yeah, I mean, a super fundamental part of my day to day is designing messages for ui, right? Say an error message, but at the same time I'm also writing a document that maybe explains those error messages. Right. But you know, UX writing I find hard, but as I'm going to say probably more than once today, you know, it's a theme that context is everything. Context is king as used to be bandied around a lot.

Speaker A: Yeah. Do you see technical writers as becoming quality gatekeepers for multilingual products? Are they well suited to become gatekeepers in that sense, you think? Especially when they speak multiple languages like you do?

Speaker B: I think definitely. I think obviously this depends as well on your organization. I guess in bigger companies they are lucky enough to have people who are dedicated to looking after localization and internationalization workflows. But as far as gatekeeping content, and again, I'm going to just talk about string context here, tech writers are sort of always a translator's, in our case, first point of call, um, any kind of query about meaning or trying to understand what a string means. You know, the translators will come to the tech writing teams first because we, uh, supposedly know a lot about the product. Again, we may have to escalate that to developers, product managers, et cetera. But we're sort of the first point of contact.

Speaker A: Yeah, I was going to ask you, how do you personally stress test your strings before they go live?

Speaker B: Yeah, I mean, I think like we mentioned a little bit before, we've been working a little bit with pseudo localization, and that's been, of course, you know, you have a language like German and strings are much longer. Translations have a tendency to sort of break your application. You want to try and cache that, uh, obviously before it gets into the application itself. And you can do that. You know, other things that we've done. For example, we've recently been looking a lot into markets where Arabic is spoken. I think I talked about that, you know, and adapting your application, ensuring that it can work. But it's not just about making sure it works. It can be read right to left. The whole design of the application itself needs to be adjusted. And again, I think it's the point that some people maybe, you know, have this idea that, well, now, again, AI, you know, you can just take an AI tool and translate your application and there you go. And as I'm sure you are aware, and listeners to this podcast are aware that not the case at all.

Speaker A: And what's the cost of not having that second layer of review that you described?

Speaker B: Yeah, cost of having a, you know, a second layer. I mean, I think, yeah, you end up getting an application that people don't understand. Right. And I think translations that, uh, can go wrong, you know, even kind of humorous things where, you know, translations are I guess not even like, looked at by a human eye, and you end up getting kind of really odd and misunderstood strings within your applications. So, yeah, there's a big cost. And I think as far as on a commercial level, you know, you can promise that your application is translated into whatever language, Vietnamese. But I think also one of the things that we have certainly tried to work on is our translators tend to be people who either work in the company itself or have a, uh, very strong connection so they understand the products. Right. And I think that's kind of key. I mean, yes, you can outsource your translation and that's fine, but I think you always need that sort of extra step where somebody can come in and somebody who has knowledge of the product. And again, it works really nicely with us that we rely often upon translators within the different markets to come to us and say, well, hey, this doesn't quite work for our market. And. Or I don't really understand the string in the context of like how we are selling this product. You know, that can happen. So yeah, it's interesting.

Speaker A: I'm um, interested a little bit in finding out how your processes work a ah, bit better. How do you collaborate with localization teams and in tools like crowd and practice. And can you tell us your process a little bit when it comes to that?

Speaker B: So essentially. Well, we've been working with crowded for quite a few years now and of course some of the initial projects are way before AI pipelines were even in place. But now certainly what we're trying to do is move towards more uh, of an AI first process. And what does that mean? Well essentially you take a workflow that will translate everything in at least a first version in AI and obviously that's kind of improving velocity, it's making things faster. But there's always like a second step there and the second step is that a human translator has to come in and review and how we collaborate. Well, a tool like crowding is great because you can essentially work with a translator within the tool itself. And anytime they comment or have queries about anything, you know, that's all stays with the string or the texts that they're translating at a time.

Speaker A: Version control I uh, would think is important in this regard as well. How do you handle version control and how do you make sure that the integrations have the right version? And does that come into play in your workflow?

Speaker B: Absolutely. So most of our integrations are with say GitHub. We do have other version control systems, but mainly we use GitHub. And uh, that's been around for a while now, but it's really a game changer as far as automating the process. And I think the fact that essentially developer adds strings to an application, right, with whatever input from design teams and from the technical writing teams, UX writers, et cetera, those strings get added, they will then go straight through into crowding, where a uh, translator gets a notification, picks them up, translates whatever, they come back automatically via uh, a pull, uh, request into GitHub. And that point, and you talked there previously about that kind of extra check, you still then have an extra check there where you can do a quick run through even in the pull request itself, right? Particularly if you have people in the team who speak other languages and can make that kind of final check. And then once you're sort of happy with that merge in the new translations and I think at that point you can still spin up a local version and again this will depend on how, I guess your technical writers are or whoever is managing those processes. But if you could spin up a local version of the application and even see, you know, before anything goes into production, how your strings are being translated and what the application looks like with those new translations, then that's a, uh, win win totally.

Speaker A: There's a lot of automation going on these days. However, has your day to day work as a technical writer changed in the last couple of years?

Speaker B: Yeah. So I guess moving away a little bit from translation, I mean, obviously AI tooling has had a huge impact in our sector and I think more and more we are bringing AI tooling into our workflows, using it to be able to automate processes and whether that's automating reviews, for example, or at least helping give first reviews, even helping to generate first drafts of documents, and even as far as strings goes as well, being able to bounce ideas off an LLM with the context of the code. Right. And the context of the code and essentially the context of perhaps conversations that have been had around that code and around the implementation and maybe with the design teams as well and all of that. Again, I talked right at the beginning about context switching, which is a really hard thing for a technical writer. And LLMs are, I find certainly personally helped me a lot with that. Uh, and um, how do I get out of sort of one context into another one? But yeah, no, as far as obviously even things like tooling, even being able to. So being a technical writer and being able to, for example, help with tooling around a website that hosts your documentation, whereas you may have a little bit of an idea of web development and I don't want to say like vibe coding, but you know, you can have a pretty good effort now at even like helping out with coding and I think it's transforming the industry and I think this idea that technical writers are becoming more of a kind of context engineer, product manager for documentation. There's a lot of talk about that in the sector and I think, yeah, very valid.

Speaker A: Uh, is there maybe a workflow that you can think of that used to be painful and that now is almost invisible even?

Speaker B: Yeah, I mean I would say that as far as automating translations, you know, we just talked about it, you have a integration with your version control system. You've taken a huge amount of the pain out of translating.

Speaker A: Right.

Speaker B: You, you know, previously, and I can remember back in the days when, you know, things were maybe done manually in like uh, a CSV.

Speaker A: Right.

Speaker B: Um, to be honest, it's not that long ago.

Speaker A: Right.

Speaker B: When we were still kind of working in that way. But obviously that the rise of translation management systems has obviously contributed greatly to improving those workflows and long may it continue.

Speaker A: Yeah, yeah. And if something breaks nowadays, where does it typically break between content and translation?

Speaker B: That's a great question. I think talking again about version control, we can see because we have checks in our CI, for example, so when translations come back to the repository in an application, or as I was saying before, in maybe a documentation website, something like that, if something breaks, it's going to break there and um, we're going to see it and you know, it'll tell us exactly what's broken. It might be that a translator has maybe misinterpreted something like what we call maybe a short code or a piece of code that was within a website. And those kind of things are pretty easy to fix. I think more and more translation tools pick that up at the tooling level and I think there's been a lot of improvements in that case. We don't see things breaking as much as we used to, but you'll still get the odd thing breaking, but usually it's pretty easy to detect with the tooling that we have and fix it, you know, on the spot.

Speaker A: Maybe what's special in your case, we've talked a little bit about it already, is that you're multilingual as a tech writer and that gives you certain superpowers in your field, not just from a localization perspective. How, uh, does speaking multiple languages change the way you write in your primary linguistic question for you?

Speaker B: Yeah, no, that's a really interesting point. I mean, because I've lived and worked in Spain for many years, you know, I end up, I think in both English and Spanish. And that does affect how you write in both languages. Right. And when you're starting out trying to think about what texts are uh, going into your designs, so maybe into your Figma designs or whatever, you're almost already thinking about this sort of second language as well and how it might work. And um, there, of course you're thinking about terminology all the time. You're thinking about when a, ah, new feature is being added to maybe one of your applications and there's like a brainstorming session, you know, what are we going to call this and what do we call like all these different buttons and features and what text are we going to use? And at the same time it's really useful to work in. So I work mainly in. We have development teams kind of all over the world. But our main R and D team is based in Spain and so sort of bouncing off ideas right from the beginning about, you know, how we're going to call things in. I'm going to say multiple languages is something that is right there from the start. And again, I'm going to say that we also work, um, you know, I'm based in the Basque country, so there's another language there as well. It's not just Spanish. It's a lot of multilingual speakers in the company who speak both Basque and, um, Spanish. And so I think that affects the mindset about when it comes to texts in general.

Speaker A: We're both fans of multilingual skills, it sounds like. Do you think multilingual writers approach clarity differently?

Speaker B: Yeah, I mean, you know, I think, as I said before, you're sort of always got your second language maybe in the back of your mind. There are times, for example. So, mainly like in our development teams, I work with another writer who is Spanish and whose native language is Spanish, and she tends to look after the documentation in Spanish, of course, but also in English. And when she was out, she was on maternity leave for a while, and I was kind of looking after both English and Spanish versions. And there I started to think, wow, hang on, this is getting hard because I've not got anyone to bounce off the ideas with. So, yeah, I think multilingualism is useful, but there's limitations to it as well.

Speaker A: Yeah. Do you find yourself rewriting things because, you know, they won't travel well, does that happen?

Speaker B: I mean, I find myself rewriting things all the time. That's the burden of being a writer, is you're never happy. I'm never happy with what I've written, you know, and I'll look at something, you know, that I wrote six months ago and, um. Who the hell wrote that? You know? Oh, it was me. Right. So, yeah, no, I mean, I don't know whether that's a multilingual thing, but we're constantly refining and that goes for streams as well. And, um, what I find interesting is it's great in sort of when we have better testing for our applications and we get feedback and people actually give feedback on the strings themselves and they say, hey, I didn't really quite understand what that was. Or even I didn't understand because you can switch the version and people will understand. Other languages say, well, I kind of understood what it was saying to me in English, but maybe when I switched to Spanish, it didn't feel like I was understanding. It as well. And so you could say, oh well, maybe there's an issue there with the translation. So yeah, absolutely. It's love tuing and froing.

Speaker A: Never happy just like that. We filled our time quite nicely. Ian, a fascinating discussion. Maybe one last parting question that I can lob you. What's your favorite feature in Crowden nowadays as a tech writer?

Speaker B: Yeah, I mean I'm going to have to say, like the AI workflows, it's a game changer. It's helping us for, uh, at least start to get first versions. Whereas before a process that would take a very long time to translate an application that has 25,000 strings or something, we can do that a lot quicker. But I'll also say, and um, this is something that I've seen recently and I need to investigate more on the Crowd in blog that agentic workflows in the sense that using agentic workflows for translation, where there are a lot of automated things that we can do and I think that's kind of where we want to go. But again, the human has to kind of be there to make sure everything's working okay. And I think we still have a job as an automation engineer or whatever, a context engineer. But yeah, really excited with all the new features around AI and um, looking forward to seeing what comes next.

Speaker A: Much more to come where that is being created for sure. Thank you, Ian, for spending some time with us today and we wish you, uh, the best of luck doing and continuing your technical writing. Pleasure to have you.

Speaker B: Thanks. Great to be on the show and speak again, Sid.

Speaker A: Well folks, that's a wrap on today's episode of the Agile Localization podcast by Crowden. We hope you found it as insightful as we did. If you enjoyed today's conversation and want to learn more about how leading companies are managing their multilingual content efficiently, be sure to subscribe so you don't miss any upcoming episodes. Thank you for tuning in. For more resources on how to streamline your localization process, visit crowdon. Com. See you next time.