Best Practices for Languages and Currencies in Relewise

When implementing Relewise, it is useful to consider exactly how and why you want to employ languages and currencies in the implementation. This article aims to address some of the most well-known pitfalls and useful pieces of advice.

We strongly encourage you to read our article on languages and currencies before you proceed, to ensure that you understand all the different contexts of Relewise's use of the two concepts.

Use Multilingual and MultiCurrency Data

Even if your site only has a single language and/or currency, we still urge you to use Multilingual data for fields that contain language-specific text, and MultiCurrency data types for your price-related fields. Language-invariant data such as an image path usually does not need to be Multilingual, except if your site uses different images for different languages. Similarly, numbers that do not need to be "translated" between markets do not need to be MultiCurrency, but can be stored as regular Double data instead.

Using Multilingual and MultiCurrency data types ensures that these fields are properly formatted, and for languages ensures that they are processed by the natural language processing built into Relewise. Whenever you receive results back from Relewise in later search and recommendation responses, we will ensure correct mapping of the language- and currency-specific value for the selected fields, based on the values passed to us as part of the request.

Ensure Congruency

Languages in Relewise function as a link between API requests, the Search Index, and your Entity Data. This means that you have to be careful to use the exact same language data between these points of contact, or the system will begin to throw errors. If, for instance, your entity data contains Multilingual data for en-us, you must make sure that you also send en-us as the language property in your API requests in order to retrieve this data.

Likewise, it means that if you perform a search request using en-us, the Search Index must be set up with en-us in its language field in order to perform the search on any of the indexed data. Note that a failure to specify a valid, indexed language will mean that the search request is unable to search in any product data except product IDs.

The short answer here is that languages must be consistent in naming across API calls, search index, and entity data.

The same principle applies for Currencies, where any API request that contains the currency property must employ a currency that matches data integrated to the dataset.

If you are unsure what data has been integrated into the dataset, you can identify it by looking up a relevant entity in My Relewise, under the Entities view.

Use Only What You Need

In Relewise, you are billed for every language your dataset registers beyond the first. This means that it is prudent to consider whether you actually need multiple languages or not - to consider the technical as well as the business consequences of having multiple languages at once.

For instance, front-loading entity data in a dataset with languages that you have in the pipeline to release over the next year might seem like a good idea to get ahead of future work, but since Relewise will register these languages as now being "in use", you will wind up paying for them despite not necessarily "using" them.

Since adding additional languages to entity data after the fact is not an issue with Relewise, we strongly urge you to only implement the languages and currencies that you actively need.