With Henk Boxma, Founder and CEO of Rigi.io

Below is an automated transcript of this episode

Antoine Rey: 0:16

Hi, my name is Antoine Rey and I will be your host for this Global Ambitions podcast episode today. And today, my guest is Henk Boxma, founder and CEO of rigiio, and today we’ll be talking about ID-based visual visual localization. Hank, welcome to the program. I’ll dive straight into it, as usual. On Global Ambitions, tell us about what is Rigi, why Rigi and what is it solving?

Henk Boxma: 0:43

Yes, well, our goal is to make software localization easier, And the way we do that is we provide a visual context. And it’s not just visual context in the form of a bitmap, it’s really interactive and it can be used anywhere in the process by translators, language testers, people who need to put documentation in place, etc.

Antoine Rey: 1:06

So supposedly, with that visual context, less errors are made and less testing might be required, right?

Henk Boxma: 1:12

Yes, That’s basically the idea, because if you look at software localization then well, what I often hear is well, we don’t have a problem because we don’t have many texts, right, We have updates and in those updates we just have few texts. But if the translators don’t know what these texts means, they are either going to guess or they’re going to ask questions. And if translators, for example, want to know for a certain string what it means, it may in average cost about 45 minutes time because it ripples all over the organization. It’s not a problem if you have 10 strings or so, but if you have many languages and you have many updates, it kind of adds and it slows down your releases, your time to market.

Antoine Rey: 1:57

I mean, we’ve used Rigi a good few times and it’s one of the rare tools I’ve seen that really gives you that interactive visual you know where. It’s quite impressive to see when you’re typing your text in a TMS type kind of environment and it’s appearing on the screen as it would be displayed in the software platform, right.

Henk Boxma: 2:20

Yes, correct, and we integrate with many systems. So we did not want to build, you know, another TMS. We wanted to really solve the issue of software localization And most tools. They have, you know, some functionality that you can add a bitmap or so to strings. But usually it’s a lot of work for the developers to add that information, so it may end up, you know, at the documentation departments of organizations, but it’s quite some work to add that information. Then the next step is you need to maintain it. And then if a translator would see a static bitmap, with a lot of information on it, how does he know, or she, where the text is right? So that’s basically the problem. So what we do with our solution is we are able to capture HTML previews of live applications and in those HTML previews we have indexed all the texts, so we know exactly which strings are on there. And that’s also the reason that when we change something we immediately see it.

Antoine Rey: 3:27

Yeah, and that’s very powerful for translators and for testers in turn there. So how does that compare? This is an ID based localization versus TM localization, right? Can you explain the difference there?

Henk Boxma: 3:39

Yes, Yes, well, it’s a little story because, well, when I started as a developer, I was developing software and I once visited this translation team of the company I used to work for. And they tried to explain to me what a TM was. And basically, as a developer, I didn’t have a clue. I didn’t understand it. The concept. So the point with software is that in software, basically every string that you show on the user interface has a unique identifier. So they are in resource files like JSON or XML or whatever, and typically the IDs of those strings will not change over the lifetime of a product. So when you get a new update of your product with your source texts and the IDs at the source text did not change, well, then you also should not change the translations. So in an ID-based system the parsers would automatically recognize which strings are new and which strings were modified and which strings were unchanged. Also, in an ID-based system you can keep track of the history of a string, so you can exactly see who changed what and when, whereas in a translation memory typically what happens is the developers upload the new files, then it is run against the translation memory, which does a comparison based on the source text, sometimes also on the ID and then it comes up with matches, and those matches can be exact matches or fuzzy matches or so. But it is not as precise as ID-based and it’s also usually slower, and what happens is that it can introduce new issues. You may lose information like status information. So if a string was already reviewed by language testers, for example, and they were marked as validated, then that status information you can lose when you update the system with a new build.

Antoine Rey: 5:35

So you’re, in this case, combining the best of both worlds there, because you’re not losing the functionality of the TMS and even translators from what you were saying.

Henk Boxma: 5:43

They’re integrated into a system like MemoQ or XTM and a few other tools right, yes. So basically what we do is we, when a new update comes from the developers, we basically parse the system. So we parse the files. So we identify, okay, what are the new strings. And those new strings you can translate, against the translation memory, of course, but the other strings you keep as they are, including their status.

Antoine Rey: 6:10

What are the challenges that you’re seeing when running Rigi with the clients systems and source repositories? Are there some security concerns? How is it to implement?

Henk Boxma: 6:24

Yes, so it’s really easy to implement because with Rigi, we do not require any code changes. So it works with the system as is usually. So what the customers can do is they can capture HTML previews during their automated UI testing processes, which are in place, and then basically the HTML previews are sent to the translators or TMS, or it’s, of course, done via a platform, but they are offered to the translators via a platform together with the texts, so there’s not a big impact on the existing systems.

Antoine Rey: 6:59

But you have to inject a Rigi code that they have to upload on the client side right.

Henk Boxma: 7:04

Yes, so on the client side they need to install Rigi codes, so it’s a special language pack. But this language pack is only used in a staging environment, so it can be completely done behind the firewall in local host. So we capture the previews and make those available to the external translators, for example, or reviewers.

Antoine Rey: 7:26

Okay, so it’s not usually any security issues on the client side in this case, right?

Henk Boxma: 7:31

No, that’s because we don’t, and this was a very important design decision because we did not want anyhow to have knowledge about the application of the customers. We just want to look at the surface and then get the information from there. The only thing we’re doing is we’re previews. kind of intelligent previews

Antoine Rey: 7:52

And can you tell us if you have any hard facts or data about the benefits of RIGI, then in terms of the amount of time that it saves on the translation side or avoiding mistakes, I guess, as well as on the localization testing side, I guess?

Henk Boxma: 8:10

Yes, well, that is actually a very nice question, because when we started, I was under the impression I wanted to optimize the process for the translators, to make the translators’ lives easier, because they asked us so many questions. So, but what we saw? Because of that, we could reduce the number of queries by half. So we get 50% fewer queries, and recently we published a case study of one of our customers on our Rigi.io website and they can now keep pace with their continuous development processes. So we can keep pace with development and I think that’s one of the most important things. So Rigi, of course, makes the lives of the translators easier, but the main goal is the time to market.

Antoine Rey: 8:56

And it reduces the need for software testing as well.

Henk Boxma: 8:59

Well, you always need to test your software. I mean from a functional point of view. But for example, when you have the context, when you see when you type something and you immediately see the impact in the user interface, so the chances that, for example, strings will not fit, or that you miss, for example, variables, or so that you need to translate, that you need to copy that chances is lower. But of course people always make mistakes, right. So unfortunately we still don’t have a silver bullet.

Antoine Rey: 9:30

And so that started Rigi with web-based application, and that still is the main component. But what else are you developing and what’s next for Rigi?

Henk Boxma: 9:41

Yes, well, we also have customers who have embedded software, And for these embedded software we can use the same technology. So we integrate that with their simulators and we can kind of basically scrape the user interface in a intelligent way and also create those previews. We also have solutions for Microsoft WPF, for example, where we have developed a component that we can basically inject in the application. It’s a kind of neat thing. And we can inject it. And then, using that component, we can generate those HTML previews. But we also have solutions for iOS and we are currently working on Android, But hybrid mobile systems like Codofa and so on are working as well. And what about for documentation? For documentation, yeah, So in documentation it’s also very nice We can generate screenshots for documentation, multi-lingual screenshots. So we have developed an editor where you can basically use one of those HTML previews And in the editor you can then select a region. You can, for example, highlight elements or blur elements. You can even replace names, like John Doe, You can replace it with local specific names, And then with the press on the button we can generate it in all the languages So they can then immediately be imported in documentation systems. What you see a lot in documentation is that companies. well, they try to even prevent screenshots, so not to use them at all. But what you get then is that in the text sometimes text gets descriptive So that the text says, OK, press the button on the top right. But then if you have a Hebrew language or, for example, or the layout changes, then the text does not match anymore. So that’s a problem. Then you have the English texts. Of course, t he English previews are used, I mean. But what we can do is we can generate the multi-lingual previews, which has a big advantage, And also what we do is we can generate kind of indexed files that the authors of the documentation, instead of hard coding the text that is referenced in the UI, they can use a reference. So when you publish a documentation it will always have the correct translations as you find in your software.

Antoine Rey: 11:57

Great. Well, lots more to come, then, from Rigi, and we’ve certainly seen your organization and your product develop over the last few years, and I’m sure our listeners will be interested to contact you directly. We’ll leave your details on our website, as always, and if you want to find out more, check out Rigiio and contact Hank directly. Hank, thanks very much for coming to the program.

Henk Boxma

Thank you for having me.

Henk Boxma

Founder and CEO of Rigi.io

LinkedIn