Translating your web app ⇄ウェブアプリの翻訳

Introduction

Written and spoken languages are the physical manifestations of thought; they’re mechanisms by which our expressions of emotions and logical processes are transcribed from our inner beings to paper. Why does sitting down to organize presentation notes, write a case study or embark on a creative literary journey have such a high catalytic cost to get the ball rolling?

Written languages across the world, I believe, are carefully balanced between logical order and poetic beauty. The right combination of the two, one may posit, is the genesis of literary mastery; a story that brings forth emotion — i.e., beauty — and in parallel clearly and coherently articulates ideas — i.e., structure — and plucks the literary chords of a symphony.

It is unsurprising that translation and interpretation are particularly creatively and mechanically difficult tasks. Ask a native speaker of two languages to translate an idiom or a particular word, and from time to time you might get an answer akin to, “Well, there is no good or direct translation,” or “That’s not something simply translated.” This begs the question, a developer may ask, why should we structure our website around translation, or how exactly should we structure our application, and what are some challenges we may expect along the way?

Abstraction and time

Developing an application with the projected goal of translation is both a technical advantage and a hedge against extraordinary code refactoring, which is both timely and costly. Beyond simple translation, the practice of abstracting text from the markup to a centralized location keeps the code more orderly. This means all language, text and words in the application are more or less maintained in a single file. One directory may contain multiple language files that can be programmatically interchanged when a consumer of the application changes language preferences.

Abstraction also allows developers to reuse common words or phrases across the application without duplicating the same language again and again. For example, if a client has a catchphrase used in 10 locations across 5 different pages, and the client submits a request to change the catchphrase, only one change is necessary across the entire application.

Setting up your application with abstraction built in leverages the advantages of mapping words or phrases to one place, and decreases the time spent searching for all instances of the catchphrase. Initially, setting up your preferred method of translation will require discussion on methodology, libraries, tools and so forth, but will undoubtedly save development time, refactoring time and pesky word inconsistencies throughout the entire application.

Setup

The first consideration to take into account is the desired structure of the translation tools.  There are several open source and paid tools to help translate a custom application. However, there are some principles that apply in aggregate to many of these tools. Here are three core pieces that are beneficial to setting up your application:

1. Translation data: This is a set of files — JSON files, for example — that contains all of your translations, mappings and key phrases.
2. Configuration file: This tells the application how to handle the important bits (e.g., default language, changing the lang tag for the html body, saving user preferences, and logic that handles switching language data).
3. The translation interface itself: This is the translation script or component that maps your translation key → value, with the key being what you are translating, and the value being the string.

Rendering technique is a final component that needs to be determined in order to bring everything together. This is largely up to developer preference, client requirements and tech limitations. Generally speaking, there are two types of translation rendering:

• Client-side rendering, where all translations are rendered on the browser
• Server-side rendering, where the back-end server handles the translations

It is conceptually intuitive to render translations on the client side for a single-page application, a dashboard or user page. On the other hand, server-side or back-end rendering might make more sense for something along the lines of email generation, where the server is sending out data. Either way, setting up an app with translation is mind will help improve scaling and mitigate the development maintenance. However, there are still a few challenges left when picking and choosing how to translate key-value pairs.

Challenges and whole phrases

Translation is tricky because linguistic typology confines how you can translate a phrase or sentence. Some languages, like English, are SVO — subject, verb, object — whereas a language such as Japanese is SOV. These linguistic differences define the granularity in which one should translate a sentence. Take the following sentence, for example:

“Please see our frequently asked questions before inquiring about product A.”

The underlined verb represents a link. One possible way to abstract the words from the markup to a translation file is to cut the sentence into the following:

• KeyA: “Please see”
• KeyB: “our frequently asked questions before inquiring about product A.”

This works well programmatically because we can render KeyA as a link and KeyB as a string. However, the typology changes with a language like Japanese. See below:

「プロダクトAに関する問い合わせの前によくある質問をご覧ください」

The underlined verb represents the same “please see” verb in English, but it’s at the end because Japanese has a SOV typology. This creates a predicament because our code expects KeyA to be the link and KeyB to be the string, and our code will render in order, something like the following:

<a>{KeyA}</a> <p>{KeyB}</p>

The first problem we see is the Japanese translation will be rendered backward. A possible solution is sorting the link; but that may not work for all languages with similar typological challenges. So what can we do?

We can translate the entire phrase and interpolate links and other dynamic data when necessary. This allows us to abstract the entire sentence KeyA and switch between English and Japanese, or any other language, with no fancy restructuring of the markup. That being said, we don’t want to translate sentence by sentence, per se. A better way to structure key values pairs is by idea. For example, from a single word (“More”) or two (“Contact us”), or even a sentence or full paragraph, a common idea or subject in the content should be used to determine different key value pairs. If the idea remains the same, keep that translation abstracted out into one key.

Building an application with the ability to translate content from the start will help scale the application, both in size and the number of languages a user could choose to display. It also makes sense to leverage the strengths of mapping key-value pairs to many locations across the application. It would be a time-saver for developers, allowing them to make edits and updates to a central location and at the same time mitigate replication errors across the entire application. Setting up an application that can translate content will require a bit of overhead to determine the structure, interface and logic, but will maintain the language data and user preferences as the application scales or changes over time. There may be challenges translating one language to another, abstracting ideas sufficiently enough to allow each language to be fully expressed logically and poetically. However, the addition of translation tools will undoubtedly save time and resources and allow your application to be more accessible to users around the world.

Illustration by Eno Olson-Malish

The views expressed by the author are not necessarily those of Ernst & Young LLP or other members of the global EY organization.