[RFC] Proposal for translatable PHPCR documents (pages, blocks etc.)

[koemeet]

So we have a lot of translatable models right now, but some very important ones are missing, such as pages and menu nodes. I am currently trying to find a good strategy to handle this. Since we have the TranslatableInterface in the resource component, I was thinking about setting up translations in PHPCR this way. You also have multi-lang build in into the PHPCR ODM of Doctrine, but it has some serious drawbacks, such as not being able to load multiple translations of the same document in the same runtime (I think you can work around it by cloning etc, but still, it feels very different from how Sylius handles translations now).

What do you guys think about not using the translations mechanism Doctrine provides for us and simply have a separate document to store translatable fields, just as we do with products etc. We could for example store the translation documents in /pages/about-us/en, /pages/about-us/nl.

Being able to do the following would be awesome:

$page = new Page();
$page->setName('about-us');

$translation = new PageTranslation();
$translation->setLocale('en');
$translation->setTitle('About us');
$translation->setBody('Content in English');
$page->addTranslation($translation);

$translation = new PageTranslation();
$translation->setLocale('nl');
$translation->setTitle('Over ons');
$translation->setBody('Content in het Nederlands');
$page->addTranslation($translation);

$dm->persist($page);
$dm->flush();

$page->getTranslations(); // would return "PageTranslation" documents

Would love to hear any ideas or feedback on this!

I will probably have this finished for myself on Monday, if this approach is preferred, I will be glad to open source it and provide a PR with the implementation for this.

[koemeet]

This works btw nicely with the CreatePHP library and the routing endpoints CMF provides for us. So you can also inline edit the content for the locale your currently looking at in the online store 👍

[gabiudrescu]

@steffenbrem we are also interested in this. currently, we handle PHPCR content translations by manually creating two entities for the locales we support.

having them translatable, just like products, would be great.

please let us know what's the progress of this and if there is something we can help with.

[koemeet]

@gabiudrescu I've made some good progress on this and currently had to rush an implementation for a client of mine that had to be done quite quickly. I am planning on making a PoC PR in the coming days. I also had some discussion in doctrine/phpcr-odm#704 about Sylius PHPCR translations.

[ibasaw]

news ?

[koemeet]

@ibasaw The discussion about this moved to doctrine/phpcr-odm#704, right now I have a working solution running in production. When things are cleared up I could work on a PR to integrate it into the main Sylius repo. There are some important things that need to be considered, such as migrating existing data etc. it has to be a minimum effort without weird stuff going on to do those migrations if we would include this in Sylius.

[koemeet]

Right now I stopped using PHPCR all together, so I don't think I will be able to make my old changes ready for Sylius. Jackrabbit was too slow for me in the end and using a MySQL database worked way better, even though hierarchies are not managed very well in it. Using the doctrine-dbal driver is not really worth the extra overhead (since you won't have much of the phpcr features) and Jackrabbit on 5-10ms per query (because of the Davex layer) was simply not acceptable.

I don't know which way Sylius wants to go with it's CMS features, if it really wants to stick with phpcr-odm I could integrate my work when I have some free time.