Searching with Multi-language Support

Introduction

When localizing an application, there is much more to consider beyond translating static text. We will highlight some interesting scenarios from a recent development effort:

• Consuming translated data as part of a localized application
• Adjusting layout and presentation based on language

First, we will briefly discuss the language selector and some results in the application.

Searching with Multiple Languages

Recently, we were expanding search features for a product catalog. Users can be found all over the world in 9 identified regions. But only 3 languages are needed: English, Japanese and Chinese. 

In the upper-right hand corner, a user selects a region. This will also select a language with English as the default.

All text within the application has an English translation. English is the default language. If a specific term does not have a translation in one of the other languages, the English value will be used.

Here is an example of advanced search with the Americas region selected. Users access the advanced search page to define specific search parameters, and narrow down the results. This is also called Parametric Search.

This grid presents column names, filters, then multiple rows of data. Selecting a filter will narrow the results that display in the grid.

The filter options are based on the data. Bit Size above has some options greyed out, due to the selected filter for Production Status.

Translating Data

Take note of the Select All option below in the PLP column with the Japan region selected.

The Select All term is an application resource. This is not represented in the underlying data as a content value. The Select All option is provided so that the user can quickly select all sub-filter options. There is currently no Japanese translation for the Select All term. With the requirement that all translations should fall back to English, this corner case is acceptable for now.

Looking around the grid a bit more, we see that the columns are translated as well as the data within each line item. Often, only the application resources are translated, leaving the underlying data in a single default language.

This search feature is driven by an API that accepts region and language. The API response contains both the metadata describing the columns in the result set as well as the data. The UI can build the complete grid based on the returned information.

The searchResults contain both the columns and the result line items. This illustrates a major consideration when localizing an application. Does the data need to be translated? Or, just the application prompts?

In this case, the data is managed in the backend in 3 separate languages. When a new product is updated, individual values are entered in all languages.

This highlights the need to translate content, not just the application itself. For this particular project, we just needed to align the exposed UI language options with the backend content management system (CMS). In other cases, we might need to expand the CMS features to support localized applications that consume the data.

Layout Changes

Another interesting case involves the column headers. The search page is responsive as the browser width is narrowed. Here is the same search page in a smaller window:

The column headings have been rotated 90 degrees to the left. This saves some horizontal space and is natural to read in English. For this client, rotating English 90 degrees to the left was the more natural way to present English labels with a narrow column.

The same view in the Japan region:

Since there is no Japanese translation for the Production Status columns, we can see something extra going on here. We were aiming to have Japanese labels displayed top-to-bottom. If the labels were stacked, requiring multiple lines, these lines would be right-to-left. This is a traditional way to read Japanese.

Here is another view including some stacked column headings in Japanese.

With this responsive change, any other text (including labels that fall back to English) will display right-to-left. For those cases, it made sense to rotate English 90 degrees to the right, so that labels like Production Status still displayed with the words in the expected order. If we rotated English to the left, the label would be Status Production.

Conclusion

We discussed specific examples of localization that go beyond simple language translations. The results are customized for this application and the needs of this client. Some of the decisions might be different in other applications. For example, the English text for a narrow column could be rotated 90 degrees to the right by default, rather than differ based on the selected language.

There could also be different strategies for translating content. In this application, the backend API provides translated content. In some cases, it could make sense to translate content on the fly, rather than storing translated content.

Remember, language is only part of localization. Working with end-users will help you identify interactions that vary from region to region and language to language.