What Does Real-Time Localization Really Look Like?

What Does Real-time Localization Really Look Like?

Like any digital, data-driven business process, localization has its fair share of jargon. We hear about ‘agile’ this and ‘hyper-localized’ that.

But one of the most common examples you’ll hear in our industry is ‘real-time localization’ or ‘localization in real time’. You’ve probably used the phrase yourself, but would you be confident explaining exactly what it means, beyond ‘really fast’ localization?

Buzzwords like this usually take some deconstruction before we can figure out what they really mean. So in this post we want to look at the concept of real-time localization, and what it means for global brands.

Defining ‘real-time’

If you watch live sports on TV, you’re experiencing events as they happen (forgetting about the few seconds of broadcast delay). That version of ‘real time’ is simple enough.

In technology, real-time sometimes means ‘simultaneously’ or ‘in an instant.’ Other times, it’s used to mean ‘as rapidly as required.’

In other words, ‘real’ time seems to slow down and speed up depending on the context.

All of this means that global brands—and those responsible for globalizing their content—are understandably confused when they hear about real-time localization. They might even distrust anyone who promises it.

So what does real-time localization really look like?

The short answer is that there’s no such thing as real-time localization—or no single thing.

In localization, the definition of ‘real time’ is highly contextual. For example, we may be talking about technology that transcribes speech, translates it using machine translation (MT), and then displays the text in subtitles. Here, there is a short delay, but it’s a lot faster than traditional translation.

There are also some apps that translate voice to voice; there’s a pair of earbuds coming out this September from Waverly Labs that act as a kind of Babelfish to translate and stream voice right in your ear.

Live interpreting is a great example of a human real-time translation process. While there is of course a small delay while the interpreter sorts through what a speaker said, comprehends the words and ideas, and then relays them in the new language, the response time is effectively instantaneous.

Instant publishing (like on a website) makes multilingual content available in seconds, provided the translation work has been done in advance. But some of the (non-translation) localization work can be automated for real-time execution—for example, converting metric to imperial units, or swapping one currency for another.

Monitoring and data analysis are other real-time processes, but they're reactive too. There must be something useful to monitor, and there must generally be something one can do in response to the thing(s) being monitored. A dashboard could display real-time data: for example, how far along a job is at any time. That gives project managers the ability to react when something is out of an expected range (or better yet: a smart system could do that on its own).

And then there is a whole class of reporting tools that can collect the latest information whenever you need it.

Once again, context is everything. It’s not always critical that the data is in real time, just that it’s as up-to-date as possible so stakeholders can react in time. Microseconds usually don’t matter in tasks that involve human responses. You just need the information in time to make the right decision. But microseconds do matter when processing real-time automatic translations such as in multilingual chatbots, where your aim might be to resolve customer service queries in live conversations.

Minimize delays by managing ‘buffer’ time

The point is, localization is inherently a reactive process because the source content has to be provided first. So speed means reacting to a localization need quickly—but not necessarily simultaneously or instantly.

For a process to be ‘real-time,’ it must be highly responsive and free from delays. That is, whenever a demand event triggers the start of a process, the steps must continue as quickly as possible until the task is finished.

Project management is key here. Its role is to remove obstacles from the critical path of a project, automate where it makes sense to do so, and use ‘buffer’ time to protect the finish date of your project should any issues crop up. And since the translator is probably the most valuable (and expensive) resource in the process, much of this effort is geared towards making their working hours as efficient and productive as possible.

The demand event itself is a key factor, too. Does all content require real-time localization? Some tasks should be triggered as soon as possible, like an emergency memo, but for most localization jobs, it’s worth waiting until the source is final. And almost all tasks can be ‘batched’ so a translator can work on all of it during their time zone's working hours for greatest efficiency.

Real time: too fast for its own good?

How many of us have sent an email in a rush and immediately regretted it because it contained something sensitive, or we addressed it to the wrong recipient?

The ability to process something instantly can actually be problematic; there can be errors and omissions caused by just moving too fast. And the higher the stakes, the riskier that ability becomes.

Some questions to ask when considering real-time localization

If you’ve heard about real-time localization and you think you need it to meet the turnaround goals of your program, first ask yourself a few questions.

  • How quickly does the content need to be localized? Is real-time critical, or can it wait?
  • How will it be consumed by my audience? Live in-person, or on-demand later?
  • What resources (human and technological) do we have at our disposal to make the process work?
  • How can we eliminate delays in the process?

 

Need help figuring out how real-time localization could work in your program? We love to talk about this stuff. Get in touch!