All of the content that you create within Cloud CMS supports localized translation. This is often referred to as internationalization (I18N) in the enterprise world. Cloud CMS has full support for localization so that any content you put into Cloud CMS supports multiple translation bundles. When content is retrieved from Cloud CMS, either through the APIs, the editorial interface or from your own applications, Cloud CMS respects the locale being requested and serves back a best-match fit for that locale.
To localize your content, you begin by taking a regular content node and you add the " f:multilingual" feature to it. You don't need to provide any configuration for this feature. Rather, by simply stamping your content node with this feature, Cloud CMS will detect that this content node may have zero or more translations associated with it.
A content node that is tagged with the "f:multilingual" feature is known as a master node. It is effectively the default or the fallback content in an assumed default locale. If Cloud CMS can't resolve a translation to use, it will fall back to using your master node.
One thing you'll notice is that the Cloud CMS user interface will look a little different once you've added the "f:multilingual" feature to a piece of content. A "Translations" page will appear on the left-hand side that lets you manage the translations for the content into different locales. This makes it easy for your editorial team to work on translations of content.
Each translation that you create is basically another node of the same type. The translation is stamped with the "f:translation" feature and is associated to the master node via an "a:has_translation" association. From a graph perspective, this means that your master node has a relationship to another node. The relationship remembers the locale key of the translation.
As an example - you might have a master node Article that you write in English. This might be your master node and it's content type might be "my:article". Let's say that you create a translation in Spanish (es_ES). The translation will also be a node of type "my:article". However, the translation will have the "f:translation" feature on it where as the master node has the "f:multilingual" translation. The master node points to the translation via an "a:has_translation" relationship which stores the locale key of "es_ES".
Now suppose you read this node via the API using a GET. If the "accepts-language" header indicates "es_ES", the Spanish translation will be served since it is an exact locale match. Partial matches are also supported. If you request with an "accepts-language" header of "es", Cloud CMS will look at the available translations and find a best fit. In this case, "es_ES" will do and you'll still get Spanish back. However, if you were to request Chinese ("zh_CN"), Cloud CMS would not be able to find a match and instead would serve back the master node (in English, not in Chinese).
This localized content retrieval works across all of the Cloud CMS APIs. It works for simple object retrieval as well as lists, query, search and more. Everything in Cloud CMS is indexed with respect to localization and so all of your translated content participates in the same core set of functionality.
When using the Cloud CMS user interface to work with translations, the graph considerations are all entirely managed for you. You just click and type to start populating new translated content. Similarly, translations can be worked with from a CRUD perspective within the API. In this case, the API will take charge of maintaining these graph elements. You just create, update and delete translations as you see fit.