Management of language variants using the example of our iiRDS
Connection between language variants via iirds:InformationObject and iirds:is-version-of
An iiRDS topic always describes a set of metadata for a concrete expression in a language and a concrete version. Each iiRDS topic is therefore assigned its own ID in the attribute @rdf:about and is thus uniquely identifiable across versions and languages.
In our use case 'Blog' it is essential to know in which languages and versions this content is still available in the system.
Because we want our readers to be able to switch to the other languages that this post has been translated into in each blog post. And for that, the blog posts must have a relationship to each other.
We have established a relationship with a general, virtual resource for this purpose. In iiRDS this resource is called iirds:InformationObject, to which a relationship is established via the property iirds:is-version-of.
<iirds:Topic rdf:about="https://www.c-rex.net/ns/iirds/td/cms/c-rex-dts_001_de-DE">
<iirds:title xml:lang="de-DE">Nie wieder Probleme mit Daten im falschen Format</iirds:title>
<iirds:language>de-DE</iirds:Language>
<iirds:revision>001</iirds:Language>
<iirds:is-version-of>
<iirds:InformationObject rdf:about="https://www.c-rex.net/ns/iirds/td/cms#c-rex-dts"/>
</iirds:is-version-of>
</iirds:Topic>Thus, one can access a concrete topic and can issue a query to the system, e.g. querying all topics with the same base ID of the iirds:InformationObject.
This will give you all the versions and languages that are related to the current topic.
If you narrow down the query further by asking for a specific version and a specific language, it is possible to switch to the current topic in another language in the portal.
Advantages of using iiRDS for multilingual management
Those who implement their information design in this way have the great advantage that every new language that is added is already automatically assigned. It does not have to be maintained manually via entries in config files or URL mapping tables as in some other systems.
As avid readers of our blog know, we use Machine Translation for translation.
How quickly and easily we add a new language, we have shown in the following animated gif. In the example, it is the translation and subsequent publication of the blog into Polish via the call to two transaction scenarios that we have set up for this purpose. The two scenarios in the oXygen XML environment are chosen for illustrative purposes. Publication can be easily integrated into a Daily Build process and thus fully automated as soon as a contribution is released.

If you want to understand this in detail, you can read about it in more detail in our article Why we rely on iiRDS and c-rex.net IDS for our blog.
Surface language and content language
When implementing our blog, we also had to think about the difference between user interface language and content language. A significant difference.
When the language is switched in the menu, what do users expect? Furthermore, a German user interface and the content in the respective languages? Or should the user interface also change to the selected language?
For a blog, the question is probably easy to answer. When users find the content in Polish on the web, they also want to see the page completely in Polish. And that's why we've chosen to do the same on our blog.
Nevertheless, there may be other cases. It is common practice to offer some content in many different languages, but some only in English.
For us, as a software company that uses data routines, automated processes not only for ourselves, but offers them as a service to our customers, we need to distinguish these two cases in the basic implementation of an automated translation workflow and also make it possible to provide fallback content (Polish not available, so then English) in a concretely selected language.

