Automation of product translation with Akeneo PIM

At some stage of sales development, expansion abroad seems to be necessary. By deciding on this step, in addition to a whole range of potential new customers, you also gain many responsibilities. One of them is the need to make translations for current products, and also, in the future, for the next ones.

If you are wondering how to automate this process — you’ve come to the right place!

From this article you will find out:

  • How to build a product structure for multiple language versions using Akeneo PIM;
  • How the product version system works in different countries;
  • How to optimize your translator’s work when creating product versions for multiple languages;
  • How to automate the acquisition of product information for any language.

Before I move to the explanation of making the automation translation, you must first understand how Akeneo manages the different versions. To begin with, it’s important to know how the channel and localization work and how the product attributes associated with them behave.

Basics of managing product versions for different countries

Ziggy - Akeneo PIM


These channels are what makes Akeneo such a powerful tool for sales expansion.

They allow you to define any destination for your products. In general, the channels must be different to some extent in terms of the set or versions of the information about the products that go to them.

Example: The “e-Commerce” channel in company X is supported by an online store and the “Mobile” channel by a mobile application. Both channels differ in terms of descriptions and images used.

In order to understand even better what channels can do, it is important to know that in Akeneo a product consists of a set of attributes — description, photo, specification attributes and many others. Each of them can have separate versions of their values in products for different channels.

Example: for the product “Baseball caps”, the long description in the web shop will be extensive and in the application short and concise, to make it easier for mobile users to use it.

In summary, the attributes in Akeneo PIM may have different values depending on the channel they are intended to reach, but they are still the same attributes.


To make things a little more complicated, I’ll add locale to all this.

Locale is a combination of two information: region and language. Examples of locations are:

  • poland_polish (pl_PL),
  • german_german (de_DE),
  • swiss_french (gsw_CH).

Locales are directly linked to the channels. Each channel can have many locales. They allow you to customize products for different target regions. The scheme is very similar to the channels. Product attributes for different locales can have different versions. By setting an attribute, you can decide whether to have separate values for a locale.

Example: The store has two locales — France and Poland, both have the attribute “Description”, but it is different for each location (one is in French, the other in Polish).

What is important, you can also keep the same versions of the attribute for selected locales.

Example: In the product “Headphones X” there are many versions of the long description for different locales, while the power expressed in watts is left in one version because this value remains the same regardless of the language.

By activating a new locale in a channel, Akeneo automatically provides the ability to add translations to all used labels within the channel. This means that you can add the language version: attribute names, attribute option names, category names, family names and any other static data.

Below are snapshots of several views, showing how it looks in practice:

Akeneo PIM locale 1

Akeneo PIM locale 2

Akeneo PIM locale 3

Akeneo PIM locale 4

Of course, the elements I mentioned are components of the data structure. There is also a set of functionalities for people responsible for creating translations, e.g. copying versions between countries, mass operations on translations, filtering products after translations or finding products with incomplete translations.

Automation of product translations with Akeneo PI

Translation automation with Akeneo

Okay, so all the activities are to make it easier for the translator and the structure to be organized. But what if you would prefer to minimize or even eliminate the translator’s work?

Or, going further, so that descriptions in any language are created automatically and available immediately? How to approach this topic?

To implement translation automation, use the engine of your choice. Akeneo does not have it in itself, so you need to build integration with the chosen external engine. In order to minimize the work required, you can use translators, for which Akeneo has integration modules. This means that you only need to purchase and configure the module yourself to start the automation.

Integration modules are already available with:

  • Wazen;
  • Globallink;
  • Textmaster.

Before you choose one of them, pay attention to the following aspects:

  • whether it supports your version of Akeneo PIM;
  • what set of features Akeneo provides (apart from the integration itself);
  • how accurate and correct the translations used in the engine module are;
  • what are the costs of using a given translation engine;
  • whether there are any quantitative limitations.

The users of the module (e.g. Wazen integrator) are given a set of functionalities, e.g. the possibility to select languages, mark products (translated or not), queuing of translations, the possibility to select attributes to be translated and so on.

Using such a module, it is also possible to select products that are going to gain a new language version and plan to create translations for them. The whole process can also be automated using Cronjobs embedded in Akeneo, where after creating a translation profile and specifying the product selection key for the translation and the target language, the whole operation will be performed automatically.

Optimizing the work of translators

It is known that translators, no matter how praised and reputable, are never fully accurate and infallible. If they are used to creating versions of important products for an important market, it is worth having the translator check and correct the generated text later.

However, if you are planning an experimental expansion into an unknown market and do not want to invest too much until you make sure that you can count on a return, the mechanism described above will allow you to significantly reduce the costs associated with preparing a product base for a new market. Similarly, for an assortment that does not generate major profits, or its descriptions are very simple — you can trust the translator and automation you have built — it’s always better than no description or Polish descriptions in a UK store ?.

Of course, you can also integrate Akeneo with many other translation engines than those mentioned above. It is important that a given translator has the possibility of remote access, e.g. via API. If you choose a translator to which the Akeneo integration module is not available, you have to take into account the higher costs. This is due to the need to write both the integration itself and the functionalities needed to handle it.


Akeneo PIM allows integration with translation engines. With modules or custom functionality you can use them to create and automatically insert product translations into Akeneo in any language version (available in translators). This mechanism optimizes the work of the translator, reducing it to checking the correctness of generated translations for the most important products and languages in your offer.