I’ve got a multi language page without any configured fallbacks. On this page I want to have contact-address records and I want them to be stored as nodes.
These addresses should be the same for all language presets. That means, I only want to create / update / delete them only once, but display them for all languages.
Further, these addresses are grouped in department categories. These categories need to be translated. I also like to have the categories stored in the CR. The address nodes need to reference those categories.
Hopefully, I am not the first one to solve such a scenario and I am looking forward to head your best practices / ideas to solve that.
Can think of two potential solutions, however have never tried them out myself.
First one would be a simple approach by storing the nodes in one of the four languages and then in Fusion retrieve the nodes from that hard coded language. In the backend it should be possible to make the nodes editable from all languages, but it would only be possible to create new ones in the correct language. Referencing the categories might be a little tricky as you might have to retrieve the reference in the specific language and then retrieve it’s translation from that.
Second one is to create an arbitrary fallback language only to be used for these shared records. E.g. create a language dimension called mul_ZZ and set that as fallback for all the languages. This should allow you to create these nodes to be shared easily without having to do any custom fetching in Fusion. Categories also shouldn’t be an issue as you’d create them in mul_ZZ as well and then translate them.
Second one is definitely more elegant, but unsure if it causes any undesired side-effects.
Thanks for your reply. I also thought of that two solution possibilities. But I hoped (and didn’t gave up yet) that I am not the first one having that problem and that there is a more standard way to do so.
The first solution you mentioned has the disadvantage, that I need to also adjust the elasticsearch indexing and eventually the querying as the nodes need to be full-text searchable - and that sounds like some things that might break.
The second fits more in the standard for reading the nodes but could be error-prone on the editors side. As this additional dimension should only be used for some special tasks. I like this one better so far.
I’ve though about 2 other ideas, which requires some coding:
Third: The field “dimensionvalues” of a node is an array. That could mean, that I can add more than one dimension where a node exists. I guess this is meant to check dimension presets for different languages - but maybe it also can find nodes that are in 2 presets of the same dimensions, e.g. in two languages. Than a node type configuration setting could mark that node to be in all available dimensions and add this value on creation. But I didn’t got it to work till now.
Fourth: When adding a node of a defined node type on the default language, some code could automatically adopt that node to all other languages. A change on data of that node needs to get propagated to all other nodes with the same identifier, same goes for deletion.
These “solutions” would hide the problem from the editor and the integrator as adding nodes and querying them would be the same.
I used the fallback dimension in such cases so far. Option 3 can work on current API level if you created a context with multiple target dimension values, which the services we have do not allow AFAIK, but in PHP that should be entirely possible. Please don’t mess around with the array directly though, as it muts be in line with the respective dimensionhash and the nodedimension table entries.
Option 4 could work by just hooking into existing events.
for those having the same problem, here is my solution.
I decided for option 4 and created a small package that automatically replicates nodes to dimensions the parent element already exists in. The replication is configurable per node to copy the node on create and delete all variants when a node is removed. And additionally replicate content changes from a node to its variants.
The benefit of this solution is, that no further adjustments for integrators (FlowQuery, ElasticSearch Indexing and querying), nor editors are necessary.