Dimensions

In Neos, content can be varied in multiple dimensions, including but not restricted to language.

Neos 9

This page is for Neos 9.0 with the new Event Sourced Content Repository.

Neos provides the concept of content variation in form of Content Dimensions. While translation into different languages is the most prominent example of variation, it is not the only one supported in Neos. It is even possible to define an arbitrary amount of dimensions at the same time.

Each dimension again can have multiple values as well as a fallback mechanism within the set of values. A dimension value that falls back to another is called its specialization, the other the generalization respectively. Note that specialization is a unidirectional relation, i.e. two values cannot be each other's generalization and thus cannot fall back to each other. Values not connected via fallback are called peers.

Given the values "fr" (French), "de" (German) and "gsw" (Swiss German), we can define the dimension "language" as follows:

^{The Variation Graph for dimension "language"}

In this example "gsw" is a specialization of "de" and "de" a generalization of "gsw".
"de" and "fr" are each other's peers and so are "gsw" and "fr". "de" and "fr" also are called root generalizations as they have nowhere to fall back to.

Also note that since there is no single root generalization, there also is no defined default value for language.

#The Dimension Space

Supporting multiple dimensions simultaneously means that dimension values can be combined. Those combinations may be restricted in that combinations can be explicitly disallowed. If e.g. we add another dimension "market" with values "global", "DE" and "CH" with "DE" and "CH" falling back to "global" and disallow the combination EU;gsw we now have 8 possible combinations: global;fr, EU;fr, CH;fr, global;de, global;gsw, EU;de, CH;de and CH;gsw.

These combinations are the coordinates of Dimension Space Points and the eight available ones form the Allowed Dimension Subspace. To define the fallback mechanism between dimension space points, we need to decide which dimension to prioritize. With market being the primary and language the secondary dimension, the fallbacks can be described as follows:

This is called the Interdimensional Variation Graph.

Note that in this two-dimensional case, Dimension Space Point {"market": "CH", "language": "gsw"} has three specializations: {"market": "CH", "language": "de"} (weight 1, the first to be effective), {"market": "global", "language": "gsw"} (weight 2) and {"market": "global", "language": "de"} (weight 3, the last to be effective).

In regard of reading nodes, when we first need to remember that all variants share the same aggregateId. The fallbacks then manifest as follows:

If you create a node in Dimension Space Point {"market": "global", "language": "de"}, this will be its origin. Due to the fallback mechanism, it will additionally be available in {"market": "global", "language": "gsw"}, {"market": "CH", "language": "de"} and {"market": "CH", "language": "gsw"}. The set of these four Dimension Space Points where the node is available in is called its coverage.

The order of fallback effectiveness comes into play if we create a specialization variant of our node in {"market": "global", "language": "gsw"}. When we now fetch the node by aggregateId in {"market": "CH", "language": "gsw"}, we will find the variant originating in {"market": "global", "language": "gsw"} which has precendence over the one originating in {"market": "global", "language": "de"}. Or in other words: It's closer to what we asked for since it falls back in dimension market but matches the requested language