Advantages of Localizing UI’s While Confirming Screens

Guest contribution of Kozo Moriguchi, President and CEO of our liaison Kawamura International in Tokyo, Japan

Software localization typically involves translating a variety of materials such as online help pages, training materials, marketing content, usage statements, labels, and user interface (UI) text. While UI text accounts for only about 5% of the total text to be translated, it can still result in hidden costs and pose challenges for translators. Unfortunately, the importance of UI text is often underestimated, leading to careless use of machine translation, which can result in user complaints. Therefore, it’s crucial to consider all aspects of software localization and prioritize the quality of UI translations.

For example, exporting UI text to Excel for translation by a translator may cause the translator to frequently encounter the following issues.

  • Difficulty ensuring contextual consistency with on-screen UI text
  • Inability to translate in accordance with layout and input restrictions
  • Inability to know for sure what is used where (is something a button or a message, etc?)
  • Increase in questions (questions) related to insufficient information

When translators are unable to translate content correctly due to a lack of context, it can lead to stressful situations for them. Additionally, when translations were performed without proper context, the following issues can occur when the translations are displayed in the actual UI screens.

  • There is not enough space for the translated string and messages are truncated
  • UI text is inconsistent, with multiple translations for one word
  • Translation is correct, but not suitable for the screen (e.g. message text is not translated in dialogue style)

As the requester of a translation, it’s easy to become stressed when you feel that the translation was not performed properly. This can be exacerbated by the time it takes to make corrections, which can lead to increased frustration

Typically, problems caused by translation errors only become apparent during screen tests or language tests, which can result in back-and-forth communication and corrections. This can be particularly time-consuming if the UI has been exported to Excel and handed over to a translation agency for translation, as the company may not know which text belongs to which screen. This can require additional time for comparisons and can result in confusion and delays.

Using Rigi in cases like this solves all these problems as the translation can be done while viewing the screens, in addition to all the functionality needed to translate UI text.

  • The quality of the translation will improve significantly as the translation can be done while visually confirming images from the screens.
  • Translations can be done with an ID base, making it easy to track down differences and correction reflections.
  • The time it takes to respond to queries can be reduced as queries can be handled within the system
  • Screenshots can be taken for all languages with a single action, drastically reducing the time needed for correction instructions.

Can Machine Translation Be Used in Software Localization?

Next, we’ll cover integration with the LDX hub, which is the subject of this blog. LDX Hub provides a rich set of services and API linking functionality for applications that are helpful in solving the problems associated with language services, along with process automation that combines these services. Visit https://ldxlab.io/ldxhub for more information.
Services and applications can be freely combined and linked and automation with more than 2,000 combinations is currently possible. Starting with input on a single document, a variety of changes, processes, and machine translations can be linked to create a wide variety of outputs to suit your needs. RIGI is also linked to the LDX hub via API and the machine translation available via the LDX hub can be used to translate UI text.

So let’s assume that machine translation can be used in UI text localization. UI text has many short strings, such as buttons and drop-down lists, and replacing strings with the correct word is much more common than translation that takes context into account. At first glance, replacing strings might seem like something machine translation excels at, a word can have multiple translations, and machines can struggle with context and background information, meaning you may not get a suitable translation.

Additionally, while UI text for buttons simply requires the text to be swapped, conversational dialogs need to be translated. Machine translation may not be able to properly distinguish which translation is which, leading to work that must be done by hand.

However, the usefulness of machine translation is not just limited to the translation process; it applies to the entire localization process. Particularly in the software testing process, it can be used to streamline verification work by inserting dummy text.

There are several tests in software development. Among the tests for any development process, feature tests and performance tests to verify load and thresholds, it is mostly feature tests and usability tests that are performed while checking the user interface. While it is possible to enter meaningless strings like “XXXXXX” for testing, using the local language will be more effective in usability testing, even for machine translation. For example, if you do a visual check of font size, string length, and content details, machine translation will get the job done.

Furthermore, machine translation is suitable for software development that involves repetitive prototyping, as the tests are repeated countless times, thanks to its ability to make small errors at low cost in a short time.

By using Rigi, you can instantly display screens of machine-translated text, making it possible to run function and usability tests before starting the translation process. These tests may involve extensions to the layout of UI screens, and this may go back to upstream processes. With these risks in mind, keeping this separate from the translation process can reduce the time required for refactoring.

Reducing UI Translation Processing Time by 20% with Rigi and LDX hub

Imagine a project where a user interface with about 1,000 lines needs to be translated into 3 different languages. For multilingual translation projects, management costs and the time required for corrections increase proportionally with each language compared to single-language translation projects. Rigi enables the unified management of even multilingual projects within the system, reducing management costs and the time required for corrections.

Explained below are some tricks to reduce release time using Rigi with machine translation.

Time to translate a project with 1,000 lines in 3 languages without Rigi (i.e. low visual context)

Trick #1 – Run tests that require changes to the user interface screen layout before the translation process

Normally, testing comes after translation, as the translated text is displayed in the screens. However, because using Rigi makes it possible to use the machine-translated text as dummy text to be displayed on test screens for checking, visual UI tests, usability tests and function tests can be performed in advance. This eliminates loss through the need to request re-translations in the event that the layout of the UI screens needs to be changed (Process reductions to item 7 in diagram 1).

While testing is required once the translation is complete, any issues are related to the translation or the text itself, not operation or usability, meaning these issues are addressed during the language testing process (item 7 in diagram 2).

Time to translate a project with 1,000 lines in 3 languages with Rigi (i.e. high visual context)

Trick #2 – Reduce translation time by manual post-processing of machine-translated text.

Simply running machine-translated text is not enough to complete a UI text translation. As we’ve already mentioned, machines can struggle with context and background information, which means you may not get a suitable translation. Judgment calls are a human’s expertise. Post-processing (correcting the machine-translated output) while you watch the screens can save costs and time compared to human translation.

Trick #3 – The time required for questions and quality assurance can be reduced.

In addition, as we mentioned above, displaying the test screens allows the quality to be increased and the number of corrections to be drastically reduced. Inquiries can be handled within the system and even targets where things are unclear or whose source needs correction can be found quickly through search, as management is unified in the system, significantly reducing the time required.

Trick #4 – Reduce correction work through batch acquisition of screenshots.

One of Rigi’s strengths is the ability to get screenshots through a batch process. When an area is found that needs correction, taking a screenshot in one language can cause that screenshot to be taken in all other applicable languages through a batch process.

Finding and correcting the area is easy with Rigi if you know the screen, solving problems with screenshots alone.

Trick #5 – ID base localization compatible with Agile development process.

Since Rigi is specially made to handle UI text translation, UI text is managed with an ID base. ID-based management makes it possible to instantly search for segments that have been added or corrected, allowing changes to be managed effectively even during parallel development. What we showed in diagrams 1 and 2 may seem like waterfall development, but where Rigi really shows its strengths is agile development.

In this way, we estimate that using machine translation with Rigi can reduce the total time required for your localization by 20% or more. There are benefits for all parties involved, through the reduction of errors in the translation process and the streamlining of correspondence regarding corrections and comments. If you want to reduce the time it takes for UI text localization, give it a try.

Using machine translation with Rigi can reduce the total time required for your localization by 20% or more.

Application of Machine Translation to Rigi, Which Is Using LDX hub

If you use the LDX hub and apply machine translation, you can choose from the following machine translation providers. Using the LDX hub is convenient as there is no need to develop an API connector for each machine translation engine.

  • Minna-no-jidohonnyaku @KI
  • Google Cloud Translation Advanced
  • Microsoft Translator
  • Translate Amazon
  • DeepL
  • IBM Watson language translator
  • SAP Translation Hub
  • SYSTRAN Translate
  • ModernMT

As a Rigi user you can follow the next procedure:

1. Perform machine translation service settings at a system level (this setting can only be done by accounts with SUBSCRIBER privileges or greater). Click “Server settings” from the profile icon in the upper right hand corner of the screen.

2. Set the following on the “Server settings” screen.

  • MT Provider: MT service to be used
  • MT Profile: MT setting profile based on set MT provider

3. Click “Add provider” from the “MT provider” menu, enter your authentication information and set your MT provider.

4. Click “Add profile” on the “MT profile” screen, and set the language and services you will use in the MT profile.

5. Add languages to be used in machine translation.

6. Select a machine translation provider and service to be used for each added language. This completes the settings.

7. Next, perform machine translation settings on a project level.

8. In “Overview” on the “Text” menu, check off the languages you want machine translation to be applied to and click the machine translation icon at the top of the screen.

The machine translation profile that is going to be applied and the setting details will be displayed, so ensure that there are no errors and click the “Translate” button.

Machine translation will only be applied to strings with the “Untranslated” status, after which, the status will automatically be changed to “Translated”. If there are any strings that you do not want machine translation applied to, changing their status to “Translated” beforehand will ensure that they are not machine translated.

Related articles

Embracing an agile localization approach

Software localization teams face increasing pressure with agile development processes. In a continuous release cycle, new software features can be released daily, sometimes even multiple times per day. However, traditional localization workflows struggle to keep up with this accelerated pace if the goal is to only ship localized versions that…

Read more >

Internationalization testing with your Figma design

Use your Figma designs to test if your user interface is ready for a global rollout.

Read more >

Hidden costs of software localization

The world is globalizing at a fast pace in many aspects. People, technology, cultures, goods and services are crossing borders more and more with less constraints. This is made possible by the decreasing costs for international transport the last decades, combined with the democratization and digitization of the media. Since…

Read more >