Single store translations with Prismic

[FlushBG]

Summary

Include an alternative page translation engine, including dynamic data (product titles, description), using Prismic as a source

Motivation

Currently, the only good way to translate your store is to use the provided multistore mechanism. It uses static files for the page content, included in the project, and multiple ES indexes, being populated from Magento 2 to resolve the dynamic content (products, descriptions ... etc.) This, by itself, is a great and robust solution, but it would be a nice feature to be able to independently change the language / currency as a user. It would also enable you to outsource the content management / translations by providing the Prismic repository to your staff, so the content can be edited there.

Guide-level explanation

I am currently not able to provide a crystal clear vision of how this could happen, but I have a general idea how it could be achieved:

1. Create a module in vue-storefront, that either:

• has it's own store, containing the selected language, selected currency, some extra i18n stuff as country name, currency sign and sign position, and also probably a collection holding the data fetched from Prismic
• extends the Root Store state's storeView object with actions to change only the language and/or currency in the storeView's i18n propery
• has a component (a switcher, or dropdown, or even an entire Settings component), dedicated to manipulating the store we decide to go with

1. Create an api extension in vue-storefront-api, which is responsible for fetching from Prismic using a given language, and also processing items from ES using Prismic and the given language, as described here: https://docs.vuestorefront.io/guide/extensions/extensions-to-modify-results.html

A possibility would be to pull the whole Prismic repository in all languages and save it in the state, in a key-value pair collection: { "language": { translations } } The idea is to get rid of the current $t("text") function in the template, and navigate the Prismic tree instead, for example: home.mainTitle, or home.mainBanner.buttonText and search the records by the language key, set in the state.

... TBD

Reference-level explanation

Since this is still only an idea, I will leave the technical implementation as-is and add to it later, when answers to the below questions are available.

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• Its interaction with other features is clear.
• It is reasonably clear how the feature would be implemented.
• Corner cases are dissected by example.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

Unresolved questions

• How do we cache the responses, and make sure we are synced with both Prismic and the selected language at the same time?
• When processing items, if we are on the product page for example, how do we make sure that changing the language will re-process the item?
• Would it be better extending the storeView, or implementing a completely separate state holding the i18n information?
• What would be the best way to replace the $t() function?

Future possibilities

I believe this would make the store a lot more flexible and customizable by implementing Prismic or any other CMS for that matter, and at the same time utilize the translation engine provided by them. We could go further and also pull and enrich our products with images, videos and other stuff, pulled from the cms, and also specific for the selected language.

Please share your thoughts!