In-context Software Localization

In today's episode, we chatted with Henk Boxma, the CEO and founder of Rigi.io, who elaborates on how providing an interactive visual context can simplify software localization. 

Episode Transcript

(00:16):
Hi, my name is Antoine Ray andI will be your host for this
Global Ambitions podcast episodetoday.
And today, my guest is HenkBoxma, founder and CEO of rigiio
, and today we'll be talkingabout ID-based visual visual
localization.
Hank, welcome to the program.
I'll dive straight into it, asusual.

(00:38):
On Global Ambitions, tell usabout what is Rigi, why Rigi and
what is it solving?

Henk Boxma (00:43):
Yes, well, our goal is to make software localization
easier, And the way we do thatis we provide a visual context.
And it's not just visualcontext in the form of a bitmap,
it's really interactive and itcan be used anywhere in the
process by translators, languagetesters, people who need to put
documentation in place, etc.

Antoine Rey (01:06):
So supposedly, with that visual context, less
errors are made and less testingmight be required, right?

Henk Boxma (01:12):
Yes, That's basically the idea, because if
you look at softwarelocalization then well, what I
often hear is well, we don'thave a problem because we don't
have many texts, right, We haveupdates and in those updates we
just have few texts.
But if the translators don'tknow what these texts means,
they are either going to guessor they're going to ask

(01:34):
questions.
And if translators, for example, want to know for a certain
string what it means, it may inaverage cost about 45 minutes
time because it ripples all overthe organization.
It's not a problem if you have10 strings or so, but if you
have many languages and you havemany updates, it kind of adds

(01:54):
and it slows down your releases,your time to market.

Antoine Rey (01:57):
I mean, we've used Rigi a good few times and it's
one of the rare tools I've seenthat really gives you that
interactive visual you knowwhere.
It's quite impressive to seewhen you're typing your text in
a TMS type kind of environmentand it's appearing on the screen
as it would be displayed in thesoftware platform, right.

Henk Boxma (02: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 theissue of software localization
And most tools.
They have, you know, somefunctionality that you can add a
bitmap or so to strings.
But usually it's a lot of workfor the developers to add that

(02:42):
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 needto maintain it.
And then if a translator wouldsee a static bitmap, with a lot
of information on it, how doeshe know, or she, where the text

(03:04):
is right?
So that's basically the problem.
So what we do with our solutionis we are able to capture HTML
previews of live applicationsand in those HTML previews we
have indexed all the texts, sowe know exactly which strings
are on there.
And that's also the reason thatwhen we change something we

(03:25):
immediately see it.

Antoine Rey (03:27):
Yeah, and that's very powerful for translators
and for testers in turn there.
So how does that compare?
This is an ID basedlocalization versus TM
localization, right?
Can you explain the differencethere?

Henk Boxma (03:39):
Yes, Yes, well, it's a little story because, well,
when I started as a developer, Iwas developing software and I
once visited this translationteam of the company I used to
work for.
And they tried to explain to mewhat 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 isthat in software, basically

(04:03):
every string that you show onthe user interface has a unique
identifier.
So they are in resource fileslike JSON or XML or whatever,
and typically the IDs of thosestrings will not change over the
lifetime of a product.
So when you get a new update ofyour product with your source
texts and the IDs at the sourcetext did not change, well, then

(04:25):
you also should not change thetranslations.
So in an ID-based system theparsers would automatically
recognize which strings are newand which strings were modified
and which strings were unchanged.
Also, in an ID-based system youcan keep track of the history
of a string, so you can exactlysee who changed what and when,

(04:48):
whereas in a translation memorytypically what happens is the
developers upload the new files,then it is run against the
translation memory, which does acomparison based on the source
text, sometimes also on the IDand then it comes up with
matches, and those matches canbe exact matches or fuzzy
matches or so.
But it is not as precise asID-based and it's also usually

(05:12):
slower, and what happens is thatit can introduce new issues.
You may lose information likestatus information.
So if a string was alreadyreviewed by language testers,
for example, and they weremarked as validated, then that
status information you can losewhen you update the system with

(05:33):
a new build.

Antoine Rey (05:35):
So you're, in this case, combining the best of both
worlds there, because you'renot losing the functionality of
the TMS and even translatorsfrom what you were saying.

Henk Boxma (05: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 parsethe system.
So we parse the files.
So we identify, okay, what arethe new strings.
And those new strings you cantranslate, against the

(06:05):
translation memory, of course,but the other strings you keep
as they are, including theirstatus.

Antoine Rey (06:10):
What are the challenges that you're seeing
when running Rigi with theclients systems and source
repositories?
Are there some securityconcerns?
How is it to implement?

Henk Boxma (06:24):
Yes, so it's really easy to implement because with
Rigi, we do not require any codechanges.
So it works with the system asis usually.
So what the customers can do isthey can capture HTML previews
during their automated UItesting processes, which are in
place, and then basically theHTML previews are sent to the

(06:46):
translators or TMS, or it's, ofcourse, done via a platform, but
they are offered to thetranslators via a platform
together with the texts, sothere's not a big impact on the
existing systems.

Antoine Rey (06:59):
But you have to inject a Rigi code that they
have to upload on the clientside right.

Henk Boxma (07:04):
Yes, so on the client side they need to install
Rigi codes, so it's a speciallanguage pack.
But this language pack is onlyused in a staging environment,
so it can be completely donebehind the firewall in local
host.
So we capture the previews andmake those available to the
external translators, forexample, or reviewers.

Antoine Rey (07:26):
Okay, so it's not usually any security issues on
the client side in this case,right?

Henk Boxma (07:31):
No, that's because we don't, and this was a very
important design decisionbecause we did not want anyhow
to have knowledge about theapplication of the customers.
We just want to look at thesurface and then get the
information from there.
The only thing we're doing iswe're previews.
kind of intelligent previews

Antoine Rey (07: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 thetranslation side or avoiding
mistakes, I guess, as well as onthe localization testing side,
I guess?

Henk Boxma (08:10):
Yes, well, that is actually a very nice question,
because when we started, I wasunder the impression I wanted to
optimize the process for thetranslators, to make the
translators' lives easier,because they asked us so many
questions.
So, but what we saw?
Because of that, we couldreduce the number of queries by
half.
So we get 50% fewer queries,and recently we published a case

(08:36):
study of one of our customerson our Rigi.
io website and they can now keeppace with their continuous
development processes.
So we can keep pace withdevelopment and I think that's
one of the most important things.
So Rigi, of course, makes thelives of the translators easier,
but the main goal is the timeto market.

Antoine Rey (08:56):
And it reduces the need for software testing as
well.

Henk Boxma (08:59):
Well, you always need to test your software.
I mean from a functional pointof view.
But for example, when you havethe context, when you see when
you type something and youimmediately see the impact in
the user interface, so thechances that, for example,
strings will not fit, or thatyou miss, for example, variables
, or so that you need totranslate, that you need to copy
that chances is lower.

(09:20):
But of course people alwaysmake mistakes, right.
So unfortunately we still don'thave a silver bullet.

Antoine Rey (09:30):
And so that started Rigi with web-based application
, and that still is the maincomponent.
But what else are youdeveloping and what's next for
Rigi?

Henk Boxma (09:41):
Yes, well, we also have customers who have embedded
software, And for theseembedded software we can use the
same technology.
So we integrate that with theirsimulators and we can kind of
basically scrape the userinterface in a intelligent way
and also create those previews.
We also have solutions forMicrosoft WPF, for example,
where we have developed acomponent that we can basically

(10:04):
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 foriOS and we are currently working
on Android, But hybrid mobilesystems like Codofa and so on
are working as well.

(10:24):
And what about for documentation?
For documentation, yeah, So indocumentation it's also very
nice We can generate screenshotsfor documentation,
multi-lingual screenshots.
So we have developed an editorwhere you can basically use one
of those HTML previews And inthe editor you can then select a
region.
You can, for example, highlightelements or blur elements.

(10:47):
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 allthe languages So they can then
immediately be imported indocumentation systems.
What you see a lot indocumentation is that companies.

(11:07):
well, they try to even preventscreenshots, so not to use them
at all.
But what you get then is thatin the text sometimes text gets
descriptive So that the textsays, OK, press the button on
the top right.
But then if you have a Hebrewlanguage or, for example, or the
layout changes, then the textdoes not match anymore.

(11:27):
So that's a problem.
Then you have the English texts.
Of course, t he Englishpreviews are used, I mean.
But what we can do is we cangenerate the multi-lingual
previews, which has a bigadvantage, And also what we do
is we can generate kind ofindexed files that the authors
of the documentation, instead ofhard coding the text that is

(11:47):
referenced in the UI, they canuse a reference.
So when you publish adocumentation it will always
have the correct translations asyou 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 yourproduct develop over the last
few years, and I'm sure ourlisteners will be interested to
contact you directly.
We'll leave your details on ourwebsite, as always, and if you
want to find out more, check outRigiio and contact Hank

(12:17):
directly.
Hank, thanks very much forcoming to the program.
Thank you for having me.