0

A website I am currently developing with Neos / Flow includes a self-developed shop system implemented as a Flow Plugin. The products, variants and vouchers are kept as domain models. Since the customer wants to provide their website in different languages I need to find a way to manage translations for the domain objects. I cannot find a way which is baked into Neos/Flow so my first thought was to simply insert translation identifiers inside the translatable fields (description & stuff like that) which are then used inside the view with the translation viewhelper. This would work totally fine if the customer would not want to edit those fields by themselves.

My next idea was to just implement an extra field for each language-dimension and each translatable field (like description_en; description_es, …). But this would be the worst approach in terms of maintainability and changeability. I usually worked on TYPO3 projects where translation of domain objects is really easy and working out of the box. So this experience inside Neos is very frustrating.

Does anybody came across a similar problem or even has found a solution to this?

hoebbelsB
  • 21
  • 6

2 Answers2

1

whenever we've got the requirement to have multi-language content so far, we've solved that, by storing the data within the Neos Content Repository. This way language handling aka dimensions work out of the box. Also, building a UI for that records is very easy by using inline editing or the inspector of the content module.

Note, that storing data in the CR does not necessarily means, that you have to store it under the /site root node. You could also add a new root node /products to store your products.

You could have a look at https://github.com/neos/metadata-contentrepositoryadapter where meta data is stored under its own root.

Hope that helps, Cheers, Daniel

dlienert
  • 228
  • 1
  • 4
  • I guess this currently is the only way of doing it. But imho this is an unnecessary mix of different concepts. Domain objects suit better for the purpose of storing domain information...but well, at this point I have no other choice than using a mix of persistent domain models and contentrepository nodes. thanks for the quick reply :) – hoebbelsB May 24 '18 at 13:47
0

For the record, something like that could also be achieved with the Doctrine Translateable extension in pure Flow:

https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md

See http://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#on-the-doctrine-event-system on how to activate the extension in Flow.

However, the cleaner aproach indeed is to actually separate domain model and content (unless you build a CMS and the content is your domain ;)

albe
  • 51
  • 4