All features

Quality Checks

Term Base

Translation History

Translation Memory

Style Guide

Translation Team Management

Professional Translation

Machine Translation

Features

For managers

For translators

For developers

For designers

For enterprises

Solutions

Help Center

Blog

Case Studies

Integrations

Resources

Pricing

Demo

Book a demo

Navigation Bar

Our goal is to provide you with in-depth knowledge regarding localization.

Learn how CMS localization can boost your online presence, expand your reach, and optimize for international success with our informative article.

CMSs: industry state and how to localize them best

Newsletter Sign Up

Localization Blog

<blockquote>“ @ mperham : You have a problem, your data is in latin1 so you think : " I'll convert to UTF8 !" Now you have � problems .” cc @ kingshy_g</blockquote>

Everyone of us coders who dealt with encodings felt that pain, didn't you?

## Character Encoding

Since 2009, UTF-8 has been the dominant encoding (of any kind, not just of Unicode encodings) for the Internet, and as of March 2020, it accounts for 95.0% of all web pages. UTF-8 overtook all other encodings in 2008 and over 60% of the web in 2012.

Character encoding is an information point for anyone planning to create content outside languages that use the basic Latin alphabet characters. Character encoding refers to the proper readability of characters within the text - by human users, machines, and search engines.
Computers store characters as single or grouped bytes. Character encoding is the way these bytes (characters) are properly displayed.

It’s important to differentiate between fonts and character encoding - while you might have the proper character encoding on your hands, the selected font might not display the proper character and instead offer unreadable icons, such as empty squares, question marks, etc.

## ASCII basics

In the beginning, there was ASCII - American Standard Code for Information Interchange. ASCII is a character encoding standard for digital communication. ASCII includes basic characters, punctuation, numbers, and letters, which are present in the English alphabet.

However, as the Internet expanded further from the basics of the English language, billions of users had little use of Latin characters to access relevant content, and ASCII was succeeded by new character encoding.
It’s helpful to know that the first 256 code points (unique numbers for each character) of ASCII, ISO-8859, and UTF-8 are identical. Although ISO-8859 offers coverage of most languages that use the Arabic script, UTF-8 further expands and covers most living languages and writing scripts worldwide.

If you haven’t thought about your target audience (current and future), this is the time to do so.

## What is UTF-8?

UTF-8, or Unicode Transformation Format, is an extension of ASCII. UTF-8 encodes code points in one to four bytes.

Structure of UTF-8: 
- One byte: The first 128 characters ( corresponding to ASCII characters). 
- Two bytes: The following 1,920 characters require two bytes to encode (which includes a huge majority of Latin-script-based alphabets, but also Hebrew, Arabic, Cyrillic, and Greek)
- Three bytes: Includes other characters for languages such as Chinese, Japanese, Korean
- Four bytes: Includes historic scripts, mathematical symbols, and emoji. 


## Is UTF-8 compatible with ASCII?

The UTF-8 codes for the standard ASCII characters are corresponding. This makes UTF-8 ideal for backward compatibility with existing ASCII text. However, keep in mind that UTF-8 and UTF-16 are not as compatible.

In general, UTF-8 dominates the web and has been the recommended encoding since HTML5.

## Why is this relevant for you?

Since an HTML page can be only in one encoding, UTF-8 is the favorable choice. It supports many languages and allows a mix of different languages on a page.

Since all ASCII characters in UTF-8 have the same bytes, it makes backward compatibility easy as well.

Dealing with encodings can be frustrating for coders. It's still an ongoing issue in the tech industry, especially when working with various resource file formats. In this article we are sharing our experiences and solutions for this question.

Do you speak UTF-8?

Whenever we hear about Internationalization of web application, the first word that comes to our mind is "Translation". There are three ways to translate software:
<ul>
<li>Do it Yourself</li>
<li>Pay Someone for doing Translation</li>
<li>Ask your Users</li>
</ul>

No matter what, making the software 'Internationalization ready' is the developer's job. No static strings, dates in the code and so forth; every text must be put in resource files and the code decides which text to use. Luckily Ruby on Rails provides a simple ruby gem called "<a href="http://ruby-i18n.org/">I18n</a>" (internationalization) that does exactly that.

Definition of Internationalization & Localization :

First of all let's check the definition of Internationalization & Localization. According to Wikipedia,

i18n - "Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes." This means, the "Internationalization" functionality translates all string and other locale specific information ( like date and currency formats) from your application in desire language to end user.

l10n - "Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text." This means, the "Localization" functionality gives translations in local-specific language and other localized formats for local specific information.

How i18n mechanism works in Rails :

All the languages are different from each other in many ways (For example pluralization rules). It is very difficult for any tools/software to provide a general solution for language translation. To solve this problem I18n API provides two features in Ruby on Rails. <ol> <li>Give support for English and other similar languages out of the box</li> <li>Provide a user-friendly and adjustable functions for supporting other languages</li> </ol>

This means in Ruby on Rails every static string has been internationalized and you can "over-ride" these defaults with "localization" of the application.

There are two parts of Ruby I18n gem which are: <ol> <li>The public I18n API - provides a Ruby module with public methods to characterize the work of the library</li> <li>A default backend - which executes these public methods</li> </ol>

The Public I18n API comes with two most important methods which are: 

<ol> <li>translate # This public method do translations of the text</li> <li>localize # This public method localize Date and Time objects to local formats as per settings</li> </ol> 

These method have aliases #t and #l respectively, so you can use them like this:

\[gist id=772983\]

Setup/Configuration about the i18n mechanism

You can easily setup ruby I18n gem with few simple steps and use in your application for I18n support. Ruby on Rails application set up reasonable defaults in all .rb and .yml files in config folder. If you want to change the settings, you can easily change them according to your need.

To check the defaults for I18n module you have to check config/locales directory, which is default path for translation.

You will get one file named en.yml which default locale and contains these translation strings:

\[gist id=773002\]

English is default locale in I18n library. So, if your application is not set in different locale, :en will translate all the static text changes.

So, when you check this on console the output shows like following :

\[gist id=773005\]

Some other available locales which are supported by rails 3 are:

ar, bg, bn-IN, bs, ca, cy, cz, da, de, de-AT, de-CH, dsb, el, en-GB, en-US, eo, es, es-AR, es-CO, es-MX, es-PE, et, eu, fa, fi, fr, fr-CA, fr-CH, fur, gl-ES, gsw-CH, he, hi-IN, hr, hsb, hu, id, is, it, ja, ko, lo, lt, lv, mk, mn, nb, nl, nn, pl, pt-BR, pt-PT, rm, ro, ru, sk, sl, sr, sr-Latn, sv-SE, sw, th, tr, uk, vi, zh-CN, zh-TW

The easiest method to set your own locales to override the default locale is to change config/application.rb file in Rails 3. (You can apply same settings to config/environment.rb in Rails 2). Add this line to get German language as default locale:

\[gist id=773012\]

The first line of code tells the location of translation file to the I18n library. The second line of code will set the default locale to :de other than :en.

Using the I18n module

Put these lines in config/locale/de.yml.

\[gist id=773014\]

Let's check now whether this settings translate "hello" into "German" locale or not.

\[gist id=773017\]

Using the I18n with interpolation

Most of the time you want to use various variables with your translations. That's why I18n API also provide interpolation feature.

\[gist id=773020\]

Using the I18n with pluralization
In English there are only one singular and one plural form for a given string, e.g. “1 friend” and “2 friends”. The best thing is I18n API also provides a flexible pluralization feature in Rails applications.

We must note that an interpolation variable named :count plays key role in translation and pluralization.

\[gist id=773024\]

The algorithm for pluralization is:
\[gist id=773027\]

I.e. here 1 denotes singular and 0 denotes plural. So as specified using conditional operator, if count == 1, it will consider it as singular form otherwise its plural.

That's it for Part I. In Part II we will check other features of I18n like <ul> <li>Localization of Times/Dates</li> <li>Using views for translation</li> <li>Translating ActiveModel errors</li> <li>Organization of resource files</li> <li>Setting the locale (from domain, parameter or client) and of course storing it in the database when the user is logged in</li> </ul>

For more details you can check <a href="http://ruby-i18n.org/">http://ruby-i18n.org/ </a>.

Learn about the Internationalization (I18n) API in Rails 3, including its definition, mechanism, setup, configuration, and usage with interpolation and pluralization.

Internationalization (I18n) API in Ruby on Rails 3 (Part I)

In <a title="Internationalization (I18n) API in Ruby on Rails 3 (Part I)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-i">Internationalization (I18n) API in Ruby on Rails 3 (Part I)</a> and <a title="Internationalization (I18n) API in Ruby on Rails 3 (Part II)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-ii">Internationalization (I18n) API in Ruby on Rails 3 (Part II)</a> we already covered a lot of the Rails I18n functionality. In part III, we will now look at some more advanced features of I18n.

<h2>Using Different backend with I18n</h2>

The I18n ruby gem comes with backend support for resource files (more specifically .yml files). Additionally, it also provides simple approach to exchange the backend implementation using different gem/plugin depending on your requirements. Let’s examine an example where all translations are stored within database.

<h3>Using Database backend for Ruby I18n API</h3>

You can easily use your database for storing all the translations with the help of i18n_backend_database (<a href="https://github.com/dylanz/i18n_backend_database" target="_blank">https://github.com/dylanz/i18n_backend_database</a>) plugin. This plugin will store all your translations in the database instead of YAML files and provides a caching mechanism, so that the database doesn't get hit for every translation. When you tag items using i18n.t() within the code base, all of untranslated items will be noted as well as added into the database. You can translate untranslated textual content through an administrator panel provided by plugin.

Update 2011-02-01

Please note that this plugin is not yet ready for Rails 3 (see comments). Here are the steps to use this plugin for Rails 2.x:

\[gist id=801603\]

Add this lines in config/initializers/i18n.rb

\[gist id=801606\]

In config/routes.rb register admin panel routes

\[gist id=801610\]

Now, rails application can translate all the code from the database. All non-user generated text provided by the application needs to be wrapped in a call to I18n.t().

\[gist id=801637\]

Interpolation is handled by passing in key/value pairs as a value to an interpolation tag    ( {{ }} ).

\[gist id=801638\]

<h2>Translating Routes with translate_routes Gem</h2>

The Ruby gem translate_routes helps you to translate URLs to any number of different languages, even for an already working application. This gem works with Rails 3.x. and also with other Rails versions like 2.1.x, 2.2.x and 2.3.x. The Ruby gem translate_routes is working good with all type of routing definitions, which includes RESTful as well as named routes. You don't have to change your existing routing code, helpers, and so on; links work as expected - even in your tests.

Add translate_routes to your Gemfile:

\[gist id=801612\]

And let bundle do the rest: bundle install

1) Let's say you have this in your routes.rb file:

\[gist id=801614\]

You can see the available routes with the 'rake routes' task:

contact  /contact(.:format) {:controller=>"contact", :action=>"index"}

2) Now write your translations in a standard YAML file (e.g: in /config/i18n-routes.yml), including all the locales and their translations pairs:

\[gist id=801617\]

3) Append this line in your routes.rb file to activate the translations specifying the path of the translations file:

\[gist id=801618\]

4) Execute rake routes to see the new routes:

contact_es  /es/contacto(.:format) {:controller=>"contact", :action=>"index"}
contact_en  /contact(.:format)     {:controller=>"contact", :action=>"index"}

5) Include this filter in your ApplicationController:

\[gist id=801619\]

Now your application recognizes the different routes and sets the I18n.locale value in your controllers. But what about the routes generation? As you can see in the previous rake routes output, the contact_es_es_path and contact_en_us_path routing helpers have been generated and are available in your controllers and views. Additionally, a contact_path helper has been generated, which generates the routes according to the current request's locale.

This means that if you use named routes, you don't need to modify your application links because the routing helpers are automatically adapted to the current locale.

6) What about tests?

Of course, functional and integration testing involves some requests. The plugin includes some code to add a default locale parameter so they can remain untouched. Append it to your test_helper and it will be applied.

You can find additional information in the <a href="http://ruby-i18n.org/wiki">translate_routes' wiki</a>.

Globalize2 - Alternatives for Ruby I18n Gem

The Ruby gem Globalize2 was very popular in Rails community because it provides full-fledged internationalization solutions for Ruby on Rails application. You can use most of the features/tools independently and also you can combine them with other libraries or plugins.

The Feature/Tools for this gem are listed below. <ul> <li>Model translations – This functionality transparently translates ActiveRecord data</li> <li>Locale LoadPath – This gem load translation data from standard locations enforcing conventions that suite your needs</li> <li>Locale Fallbacks – This feature make sure your translation lookups fall back transparently through a path of alternative locales that make sense for any given locale in your application</li> <li>Translation value objects – You can access useful meta data information on the translations returned from your backend and/or translated models</li> </ul>

<h2>Conclusion</h2>

The I18n API comes with plenty of features and yet hides the complexity behind a simple to use API. With this gem, a Ruby on Rails application has a great built-in support for multiple languages. As the diversity of users is growing and more and more users speak different languages, a good localization and internationalizationsupport is necessary for every serious Web Framework. If your application has a more specific need, have a look at the various plugins and extensions available. Rails has also a great documentation, and of course there is an Internationalization section, <a href="http://rails-i18n.org/wiki">I18n Wiki</a>.

This article is the third part of the Ruby series, where we will delve into some of the more advanced features of I18n. Read it and the previous two parts in our blog

Internationalization (I18n) API in Ruby on Rails 3 (Part III)

In the <a title="Internationalization (I18n) API in Rails 3 (Part I)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-i">Internationalization (I18n) API in Rails 3 (Part I)</a> you read about <ol> <li>Definition of Internationalization & Localization</li> <li>How i18n mechanism works in Rails</li> <li>Setup/Configuration about the i18n mechanism</li> <li>Using the I18n with interpolation</li> <li>Using the I18n with pluralization</li> </ol>

You can read the full article on <a title="Internationalization (I18n) API in Rails 3 (Part I)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-i">Internationalization (I18n) API in Rails 3 (Part I)</a>, if you have not yet read it.

Now, let's start with some other features of I18n in Ruby on Rails.

Localization of Times/Dates
As I18n API provides date/time localization feature, we can easily add localized version of timestamp in Ruby on Rails application. To use this feature, first of all we need to add our localized translation for time format. Let's change our de.yml file to add a German version.
\[gist id=785930\]

Now, we can use I18n.l or Rails #l helper to localize the Time object in our desired time format.

\[gist id=785940\]

You can add many more formats for date/time to make it work using the format that you want. You can also get a ready made version of different types of local files from <a title="rails-i18n" href="https://github.com/svenfuchs/rails-i18n">rails-i18n</a> github repository. Once you place those file(s) in config/locales/ folder, they are ready to use for localization.

Using views for translation
In Rails 2.3 a new feature named "localized views (templates)" was introduced. For example, your application has an ItemsController class with an index view. Your default index template page for ItemsController is rendered by app/views/items/index.html.erb. If you want a localized version of index page, you will just have to write your text in index.de.html.erb file and then will have to save in the same folder. By setting the locale to :de, you can force Ruby on Rails application to render the German version of that template. When the locale is set to the default locale, the generic index.html.erb view will be used.

Generally, this feature is used for large amount of static content pages, where putting this large text content in YAML or in Ruby dictionaries feels cumbersome.

Translating ActiveRecord errors
You can translate Active Record validation error messages easily. Active Record uses different namespaces which can be used to translate easily models, attributes, and/or validations.

For example, an Item model with a validates_presence_of validation for the name attribute like this:

\[gist id=785954\]

In this case :blank is the key for the error message. So, Active Record will check this key in the namespaces:

\[gist id=785955\]

After following keys in the above mentioned order the result will be:

\[gist id=785957\]

If, your models are using inheritance then the messages are looked up in the inheritance chain.

For example, you might have an Book model inheriting from Item:
\[gist id=785958\]

Then Active Record will look for messages in this order:
\[gist id=785959\]

You can also add translations for Active Record error_messages_for helper like this.

\[gist id=785961\]

Organization of resource files
If you are using default i18n library settings, you may find that all files are stored in plain-text format on the disc. Placing all translations text of your Ruby on Rails application in one file per locale could be tedious to organize. You can easily store these files in a hierarchy structure which is easy to understand for you. For example, your config/locales directory could be organized like this:

\[gist id=785965\]

By following the above way to organize resource files, you can easily differentiate model and their attribute names from text inside views, and all of this from the "defaults". In Ruby on Rails, locale files in nested dictionaries structure are not being loaded automatically. So, to make it work we have to do this settings in config/application.rb

\[gist id=785967\]

Setting the Locale from the Domain Name
In the previous article you read about how to set the locale in Ruby on Rails using application.rb settings. There are also other ways to do so. You can set the locale from the domain name where your Ruby on Rails application runs. Like www.example.com will load the content in English locale, www.example.de will load the content in German locale. This way you can use top-level domain names to set the locale for Ruby on Rails application.

The benefits of using this method are: <ol> <li>The locale setting is an obvious part of the URL.</li> <li>Visitors obviously know in which language the content of the website will be displayed.</li> <li>It is very easy to implement in Ruby on Rails.</li> <li>Search engines love the content in different languages served at different domains.</li> </ol>

You can use it in your ApplicationController:

\[gist id=785972\]

We can also set the locale from the subdomain in a very similar way:

\[gist id=785973\]

You can also use switching menu option in your application like this:

\[gist id=785974\]

assuming you would set APP_CONFIG\[:deutsch_website_url\] to some value like http://www.example.de.

As previously mentioned this method has benefits, but what if you do not want to or able to provide different localizations ("language versions") on different domains. The solution to this will be to add locale code in the URL params (or request path).

Setting the Locale from the URL Params
We can also set the locale by including it in URL params like www.example.com/items?locale=de or www.example.com/de/items.

You can use it in your ApplicationController:

\[gist id=785977\]

You can get same benefits with this method as with setting the locale from the domain name, but the only little problem is it takes bit more code to implement. Here is the code to implement it by including it in our ApplicationController:

\[gist id=785979\]

This way we can easily set/override "defaults" for url_for and helper methods dependent on it. So, every url_for dependent helper method will now add the locale in the query string like, http://example.com/?locale=de.

Now, if you want URLs to look like this http://example.com/de/items (which loads the German locale), we need to set up routes with path_prefix option this way:

\[gist id=785982\]

So, when you call items_path for :de locales, an URL like http://example.com/de/items will be generated with the German locale. But, if you do not want to force the use of a locale in your routes you can set an optional path scope like:

\[gist id=785983\]

This way when you access http://example.com/items without a locale, you will not get a routing error, which is very useful for setting default locale when one is not mentioned.

Setting the Locale from the Client Supplied Information
Sometimes, you have to set the locale from the information that client had supplied (not from the URL.) i.e. user's preferred language or by choosing the locale in your application interface and saving it to their profile.

Using Accept-Language HTTP header
Client may set Accept-Language HTTP header in their browser or other client (like curl) and request the url. By supplying the information of the locale. We can implement this scenario with this code in ApplicationController.

\[gist id=785987\]

You can also use a plugin such as Iain <a href="https://github.com/iain/http_accept_language">Hecker’s http_accept_language</a> or even <a href="http://railscasts.com/episodes/151-rack-middleware">Rack middleware</a> such as Ryan Tomayko’s locale to implement this method in production mode.

Using User Profile
In your Ruby on Rails application it is also possible that users want to set the locale for their interface by setting it from database. In user's profile, user will have to choose the locale from a dropdown list and it will get saved in the database along with other profile data. In this case, you need to override the locale value something like this.

\[gist id=785990\]

That’s it for Part II. In Part III we will check
<ul>
<li>Using different backends for I18n API</li>
<li>Translating Routes</li>
</ul>

Internationalization (I18n) API in Ruby on Rails 3 (Part II)

Our familiarity with Japan is mainly due to its unique culture, popular symbols, and architecture, among other things. When people hear words such as "sushi," "sakura," or "samurai," they immediately associate them with Japan. 

However, this country boasts many other qualities that make it an ideal market for various businesses. As such, localizing to this region is a wise decision. Is your product still not talking Japanese? Let us convince you why fixing this brings success.


## The facts about the Japan market

So, why localize to Japanese? There is a list of reasons. Firstly, Japan is one of the strongest economies in the world. It <a href="https://www.statista.com/statistics/268173/countries-with-the-largest-gross-domestic-product-gdp/" rel="nofollow" target="_blank">ranks third</a> after the USA and China. 

At the same time, the people in Japan are deeply involved in the tech world - Japan is well-known as the motherland of different technology companies like Nintendo, Sega, and others. As a result, the mobile app industry in Japan is thriving with high annual installation and usage rates, making it one of the most important markets worldwide.

In 2022 it was <a href="https://www.businessofapps.com/data/app-statistics/" rel="nofollow" target="_blank">2.5 billion app downloads</a> in Japan, and users spent <a href="https://www.businessofapps.com/data/app-statistics/" rel="nofollow" target="_blank">45 billion</a> hours on them. So, if you have the application, localization to Japanese can boost the number of your users and revenue. 

Another reason for Japan's attractiveness for businesses is its robust economy. In recent years, Japan has kept <a href="https://www.statista.com/statistics/268173/countries-with-the-largest-gross-domestic-product-gdp/" rel="nofollow" target="_blank"> third </a> place as the strongest economy after China and the USA. Also, it has one of the world's largest e-commerce markets, with <a href="https://www.business.com/articles/10-of-the-largest-ecommerce-markets-in-the-world-b/" rel="nofollow" target="_blank">$144 billion </a> in annual online sales projected to reach <a href="https://www.statista.com/outlook/dmo/ecommerce/japan" rel="nofollow" target="_blank">$156.30 billion</a> in 2023. 
Based on these figures, Japan appears to be a promising market for entry. However, to succeed in this country, it is essential to understand the cultural context thoroughly and possess professional language knowledge. 


## Top challenges for Japanese localization

Localization involves translating and adapting an entire product, which can be challenging for your team when it comes to the Japanese language. The challenges range from bridging the gap between grammatical structures to using correct honorifics and idiomatic expressions, changing layouts for new fonts, and many more. Let's look at the main points of this question:

1. **Linguistic differences and loan words**. Japanese have significant differences in terms of grammar, sentence structure, and writing systems from the other languages. At the same time, the Japanese language is constantly enriched with new words borrowed, including from English, and sometimes these terms replace the Japanese words. One of the examples is the word "hotel." Besides the Japanese word 客舎 (*kyakusha*,) often you can hear/see ホテル (*hoteru*.) Using the wildly popular loan words in your content indicates that you are talking with the audience in the same language.
2. **Honorifics and politeness levels.** Japanese has a complex system of honorifics and different levels of politeness, which can be difficult to translate accurately. The polite language (丁寧語, *teineigo*); respectful language (尊敬語, *sonkeigo*), and humble language (謙譲語, *kenjōgo*.) Using the appropriate honorifics when addressing someone is crucial to avoid unintentional offense or disrespect. These honorifics vary based on the person you are speaking to.

3. **Cultural nuances.** The Japanese culture and view of the world differ from the Western world. For instance, taking coffee-to-go, usually to the USA or Europe, would be considered rude in Japan. When localizing your product, it's essential to ensure that the text content and visual elements, such as signs, icons, emojis, photos, and illustrations, are culturally appropriate for the Japanese context. Additionally, be mindful of local [figures](/blog/how-can-the-figures-be-a-challenge-for-your-localization), holidays, national celebrations, and other details.
4. **Writing system**. We have only 26 letters in English, the Japanese writing system kanji includes 4,400 characters. Of course, some are less used, but a person needs to know around 2,000 to become a good translator. But this is not all challenges. In the Japanese language, three different writing systems exist. In addition to **kanji**, there are **katakana** (for foreign words) and **hiragana** (for particles and other things). The *katakana/hiragana* function like the alphabet, with each character representing a syllable that combines with others to form words. However, *kanji* is more complex and challenging because each character represents a meaning or entire word.
5. **UI localization**. In the Japanese language, both horizontal and vertical scripts are used. Although the horizontal script is more commonly used nowadays, you can still incorporate vertical text for certain elements. It's essential to keep in mind that your design will be significantly impacted during localization, regardless of the script you select. This is primarily because of the variation in length between Japanese and other languages. For example, your text may be shortened by anywhere from <a href="https://wordminds.com/blog/different-languages-different-word-length" rel="nofollow" target="_blank">10% to 55%</a> when translating from English to Japanese.

At first glance, these things may seem complicated, but we have compiled the best practices to assist you.


## Best practices for localization of your product to the Japanese market


Build a strategy. Before any localization actions, the main thing is creating a clear plan and understanding the required efforts, your target, audience, budgets, etc. [Creating a localization strategy](/blog/how-to-build-an-effective-localization-strategy) will require deep market research from the marketing, sales, and business sides. 

- **Hire the native expert.** One notable aspect of European countries is their intertwined cultures because of open borders and proximity. This means that, for instance, French teams can somehow adapt their products for the Spanish market without hiring local employees. In the case of Japan, you couldn't do the same. From the first stages, you need a person to manage digital communication with your user. From style guide creation to design approval - local experts can save your business from failure. Also, the best thing will be hiring local linguists who can translate the content in the best way. 
Lingohub knows finding the perfect linguists for the project can be hard, so we offer to order translation or proofreading just inside our application. 
- **Provide as much context as you can.** So, you successfully prepared everything above and are ready to start the translation. When it comes to Japanese text localization, it is essential to provide additional information for linguists. A simple example is pluralization. In Japanese, there is no concept of plurals like in English. Instead, multiple objects are indicated by using a number and a counter or by understanding the context of the conversation.
To give our users more overview Lingohub team prepared a list of features that aim to provide the context for linguists:
 - **[Style guide](/features/style-guide)**. Provide information regarding the audience, including their industry, geographic location, age range, and the best tone of voice for contacting it.
 - **Context images**. Lingohub allows uploading context images for each segment using the Figma plugin or API to understand better how the text will look on the final product. 
 - **Term base**. Forget about incorrect proper names or other words' spelling. The Lingohub [term base](/features/term-base) suggests the correct option when recognizing entries during translation. If you have untranslatable terms, you can also specify them.

- **Take care of the QA stage**. Allocate sufficient resources and time for quality assurance [(QA) testing](/blog/what-is-localization-testing). Thoroughly test the localized product for linguistic accuracy, functional integrity, UI/UX compatibility, and cultural appropriateness. Engage native Japanese speakers for QA to ensure the highest level of quality.


## Conclusion

We hope this article gives you more overview of Japan, its market, and possible ways to localize your product for such a promising region. From our side, we at Lingohub are precisely targeted to provide the best user experience for customers to make the localization smooth and effective. 

To get more information about how Lingohub can help your team and business, schedule a quick [demo call ](/demo)with our team or sign-up for a free 14-day trial and use all the abilities of the application!

Did you know that Japanese is the one of the most commonly spoken language online? Almost one million Japanese-speaking internet users make up 5% of all internet users worldwide. Learn more about the importance of localizing content for Japanese audiences in our article.