Hey Aske,
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.
What do you think?
Cheers,
Daniel