This is an interview transcription; if you want to listen to the full version that includes a Q&A session from the audience, watch this video.
Background
We often hear complaints from people in the localization department that they have trouble reaching the developers, getting them to pay attention, or simply cooperating. And sometimes, it seems as though expectations and how things are done between localization development are not well understood by either party. That’s why we decided to take someone from developers, not the localization side, to talk about bridging this gap.
AJ is an engineering manager in Measurable enterprise software for managing large-scale real estate. The company is focused on helping building owners and investors to be more sustainable by tracking and decreasing their carbon footprints. Over the past year, Measurable has been rapidly expanding outside of the US, which is where the project for supporting multilingual applications that AJ is working on came from.
Adam: AJ, can you describe how you are performing software localization today?
AJ: Today, we have about eighty engineers on our team working across multiple repositories and working on dozens of branches in each repository every day. So what we have right now is the following system – a branch gets created, then automatically goes through our Lingobot (a Lingoport bot service that connects to Slack or Teams for launching or managing localization) to our translation service. The translation gets created, and it automatically comes back into that branch to get merged and deployed.
A repository is kind of where software developers work; it’s their saved work they can each access, kind of like a shared drive for documents.
The branch is a sort of copy of that of the code.
Lingobot is a feature of our localizer software that lets developers actually interact like you would with a chatbot to get translation projects started.
Adam: And what would it look like if you didn’t have automation in place?
AJ: It would have been an incredibly manual process. The process I just described is kind of the Holy Grail of how we can get our text translated, without that developers would have to work on their code, take a break, switch over to the translation portal, figure out what the status of their project is to download the files add them back into the code and then merge it to get deployed. I always try to keep the cognitive load to a minimum because the more times you have to think about something, there are more opportunities to mess things up. So without the automation that we have with Lingoport, there would be a lot of mistranslations or just things that were wrong or maybe tripping on ourselves throughout the process.
Adam: How often do you release, and do you translate for every release?
AJ: We are constantly releasing, so we have a continuous deployment system setup. Any branch could get deployed to any of our environments at any time, and we have really high confidence in our code, which means that the translation is also happening constantly. One of the big hurdles that we had, and our goals, was to make sure that our translation would be coming in just as fast as developers are writing code.
Adam: When you translate, do your developers need to pay attention to that, or do they just take things for granted?
AJ: They don’t have to pay too much attention; like I said, we want to decrease that mental load. So what’s really awesome about what we have in place today is that developers create a branch just like they normally would for themselves in the software development lifecycle. And once the translated text is ready, it just automatically comes right back into their codebase. So there’s very little thinking that needs to happen.
Adam: What were your initial concerns when taking on localization?
AJ: It was a lot of thinking about how developers can keep up their momentum without having to switch gears too much. And at the same time, how do we make sure that the context of our text is going to sound normal in a different language and that the two of those goals are not conflicting with each other?
Adam: An important part of anything that is agile is to be able to see your results. When you’re taking on localization, are your developers actually seeing the results before you release?
AJ: Yes, and that is all part of our quality assurance process. As soon as we can create the new translation project, we get an instant of the Esperanto version (pseudo-localization using the Esperanto locale placeholder) of just a bunch of text and symbols, including expansion, to make sure that the text is actually getting translated, and then at that point once it actually goes into a human’s hands to turn into another language, our developers can actually see that come in, and they can run it on their local systems. We can deploy it to a staging environment, and everyone on the team can actually verify that the text looks right and it’s been translated directly.
Adam: Do you work with an internal localization team, or do you push it out there and deal with the vendors directly?
AJ: We work with the vendors. We work with LingoTek, as I said before, and we do have some. internal team members who are native speakers outside English. For example, German, which we focus on right now, so we have some driven speakers who can help us verify. But what we mostly rely on is our partnership with LingoTek and making sure that they understand our branding and the context.
Adam: Do you have a localization manager on your team? [00:10:38]
AJ: We don’t; we just have confidence in our code base and in the system that works on this, so really, every team is managing its own translation of its own domain that the application.
Adam: That’s unusual. Did you feel like your concerns about development and continuous integration were understood?
AJ: Yes, definitely! Lingoport provided so much tooling that it would have taken us a year or two years to develop things like lingobot and the Slack integration. We were able to switch from Bitbucket to GitHub without any engineer really noticing any change in our translation process. We have all this tooling, and we can plug it into our system super easily and not have to be distracted from other initiatives.
Adam: Okay. What were the features that were particularly attractive to you for a continuous localization solution?
AJ: Yeah, I think Lingobot and Slack were super useful because developers don’t have to switch gears. They don’t have to go out of their normal IDEs and communication tools to check the progress of the translation or make sure that the project actually got created. So because we can stick to all of our normal systems and tools that we are familiar with, there’s kind of no friction in making sure everything gets translated.
Adam: Nice. So for those not in the know, Slack and Teams are both quite a bit more than instant-messaging tools. They can literally tap into your source code development processes, and you can execute things, GitHub, for instance, directly from Slack. Lingobot is Lingoport’s implementation using which you can do things much easier. Just type translate or clone this project, or add a locale, or send this file to translation. There’s all these things you can do just interacting with Slack or Teams rather than having to go look for files. So it’s a different level of control than many people know about, and it’s pretty cool.
Adam: After a year of using Localyzer, what are the features that remain important to you?
AJ: We weren’t quite sure what we didn’t know, and now that It has become more normalized in this process. I couldn’t imagine not having translation as part of the process. It really becomes so easy to include this and rely on the tooling to make sure that our app is not just doing what it needs to do today, but it’s going to keep scaling and going forward as Measurable keeps growing across the globe.
Adam: Would you say that the developers are actually proud and psyched about offering software in multiple languages?
AJ: Definitely! It’s amazing, and it’s really rewarding being able to look at our user numbers and see people coming in from different countries and changing their default language and really being able to say – “We did that, and because we provide this, now our application is growing so much and so quickly”.
[Quote: It’s amazing, and it’s really rewarding being able to look at our user numbers and see people coming in from different countries and changing their default language]
Adam: What are the hiccups that you still encounter?
AJ: It’s an interesting one, I think. Most developers don’t have this experience of having to translate their application and deal with that new step. It’s not just that your code works and it gets approved by other developers; now you actually need another human to look at it and add that translation. But what we’ve become more used to is thinking of this life as a normal software development life cycle where we have to add tests, and we have to go through a quality phase. And this is added on to that, and I think our experience is on the right path so that once we start supporting 10 languages, we’re going to be ready for that.
Adam: Is machine translation a future direction for you?
AJ: Right now, it is not, and I think that is because of the context. The example that I would like to give is building: is it a verb of creating a structure, or is it a noun? What we found is that a lot of the machine translation tools can’t get that context, and it’s really important for us that context is explained, which is why we have such a happy reliance on a human translation.
