Languages and translations

Anyone holding product data in more than one language comes across two terms in TRADElube that sound alike and mean different things: language and localization. The difference is not hair-splitting, because the one decision on this page that cannot comfortably be changed later hangs off it.

Language and localization

Both are managed under Settings, through the buttons Languages and Localizations.

A language is the entry for the language itself, with a name, a code and an ISO code. It is the technical anchor by which a target system recognizes what it is dealing with.

A localization is a named version of your data pointing at exactly one language. It is what you actually have in front of you while maintaining data: a tab on the record, an assignment in the transfer plan.

Localizations in the settings with name and the language they belong to

Why two terms are needed only becomes visible with the second shop. Several localizations may point at the same language. A retailer running a consumer shop and a trade shop can serve both in German and still hold two different versions of the texts, one with marketing copy and one with a technical description. The language says in which language it is written, the localization says for whom.

If you do not have that case, you notice little of the difference: there is then one localization per language, and both carry the same name.

The default localization is set once

One of the localizations is the default localization, and it is more than the first in the list.

Its texts sit on the record itself. That is why the product list, every pick list, every reference and every message show exactly that version, regardless of which language you have set the interface to. The other localizations sit beside it and only become visible where they are explicitly asked for: on the language tabs of the detail page and in the transfer plan.

That yields a rule worth hearing once before it catches up with you: the default localization is set during setup and not changed afterwards. Changing it would silently declare the base texts already written to be in the new language, without changing a single word. German product names would become English ones that merely happen to sound German, and nobody would get a message about it.

What is translatable and what is not

Three of the six main objects are translatable: products, categories and manufacturers. So exactly those whose texts a buyer reads in the shop.

Description section of a product with the tabs of both localizations

The translatable fields are the descriptive ones: Name, Short Description, Description and the meta entries for search engines. On the detail page they sit under one tab per localization, and the button Insert adds a further version.

Everything else exists exactly once, and that is no omission: an article number, a price, a stock figure and a weight have no language.

One exception regularly comes as a surprise and therefore deserves attention: properties are not translatable, neither their name nor the entries of their option lists nor the values on the product. A property "gloss level" with the value "silk matt" exists once, in the language you created it in. Where a target system needs it in its own language, the route runs through the Mappings of the respective channel, which record, per channel, which external value corresponds to which internal one.

Multilingual target systems

An online shop running in two languages needs no second channel for that. In the transfer plan of the task there is an assignment of its own per language field of the target system, and there you choose which localization ends up in it.

That is the same mechanism as for any other field, only with the localization as an additional entry, and it has two pleasant consequences: you can add the languages of a shop one at a time, and you can send the same localization into several systems without maintaining it twice.

Which languages a particular system accepts at all is listed under Channels and tasks. A marketplace often carries exactly one.

A shop in two languages

Suppose your shop runs in German and Dutch. In TRADElube that is two localizations, and German is the default localization, because that is how you maintain your data. The work then spreads across three places:

Where	What happens there
On the product	On a second tab you enter Name, Short Description and Description in Dutch. Number, price, stock and weight stay where they are
In the upload's transfer plan	One assignment per language field of the shop, each with its localization
In the channel's Mappings	The values of the option properties, that is "silk matt" against "zijdemat"

The third row is the one nobody expects. What gets translated are the descriptive texts, and a property is not one of them. Without that mapping a Dutch customer reads "silk matt" in the filter while the rest of the page is in Dutch.

Where a translation is missing it stays quiet: the transfer goes through, the field in the shop stays empty, and no message points it out. After switching a new language on, a look into the shop at a handful of articles is therefore worth more than a look into the traces.

How it fits together

The language of the interface and the language of the data are independent of each other. You can operate TRADElube in English while maintaining German product texts. The interface is switched in the user menu.
In the data model every translation hangs on the record, not on a separate copy of the product. So there are not two products but one product with two versions of its texts.