New

Exclude content only from specific languages in multi lingual outputs

When having multilingual outputs with many languages, sometimes content is only relevant to certain languages, e.g. Product Certification for Korea, CE for Europe, etc. or different product variations based on region.

Add a possibility to exclude specific topics during output generation from certain languages or to only include in some languages. This works perfectly with single language outputs  using conditions but fails when more than one language is in the output. I believe this is due to the way Antenna House runs through conditions and sets of languages prior looking into each of the translation files. 

DITA is capable of doing this by injecting a DITAVAL file, but Tridion does not have this possibility. Could also be doable with submaps and topichead with conditions, but the AntennaHouse logic also works against this. 

Need an easy to use way to filter out content from specific languages, when building outputs with more than 1 language. 

(Yes, variable can do this, by not having the variable library topics translated in the unwanted languages, but will still render the whitespace needed for the content)

RWS: Refer also to Support case CS0052118 for more details. 

Marc Samjeske
Parents

  • Hi Marc,

    Tridion Docs builds its relations based on logical-version-language. Something you know from Topics, where you have a topic about something (logical), there is a first version (version) holding a certain message and that message is expressed in a certain language syntax (language). As every language conveys the same message, it means translations are disconnected from your publication building. The same pattern was used for publications. So a publication about a certain device or so (logical). A DITA root map points to a collection of maps and topics, selection of topic versions (baseline) and an expression if conditions evaluate to true or false (context) is stored on the publication version. In turn the third level, publication output, expresses this message in a certain language and in a certain rendering (outputformat). The various PublicationOutputs are in this set up holding exactly the same semantics, just like the earlier topic translations did.

    No model is perfect, but in the real world, customers have some variations/optimizations they want to express like you only need CE in Europe. You are trying to introduce a second level of conditional text, that is how I read your DITAVAL on top of the product's @ishcondition/context combination but also DITAVAL has to be attached to a language. There is inherent complexity of layering two conditional engines.

    Perhaps this question might get more traction in the forum part, but I do think other customers have resolved it complying with their demands and information architecture. From what I remember...

    1. I think some customers deliberately broke the semantic message in a dedicated Library Topic which requires a bit more attention when doing localization. So the Library Topic can hold different message per language for 'ko' versus european market languages. 
    2. Introduce a market @ishcondition that filters out the big Library Topic, so CE for European Market. This will eventually lead to special handling if this (part of the) topic should be translated to Korean because CE is not relevant for them.
    3. ...

    I did not do extensive research, just want to make sure that we do understand what you are trying to do, but so far the product team did not find a one-size-fits all that solves these challenges across customers, respects all existing product concepts (baseline, context, logical-version-language, reports and more) combined with a low-learning-curve user experience. 

    Best wishes,
    Dave

Comment

  • Hi Marc,

    Tridion Docs builds its relations based on logical-version-language. Something you know from Topics, where you have a topic about something (logical), there is a first version (version) holding a certain message and that message is expressed in a certain language syntax (language). As every language conveys the same message, it means translations are disconnected from your publication building. The same pattern was used for publications. So a publication about a certain device or so (logical). A DITA root map points to a collection of maps and topics, selection of topic versions (baseline) and an expression if conditions evaluate to true or false (context) is stored on the publication version. In turn the third level, publication output, expresses this message in a certain language and in a certain rendering (outputformat). The various PublicationOutputs are in this set up holding exactly the same semantics, just like the earlier topic translations did.

    No model is perfect, but in the real world, customers have some variations/optimizations they want to express like you only need CE in Europe. You are trying to introduce a second level of conditional text, that is how I read your DITAVAL on top of the product's @ishcondition/context combination but also DITAVAL has to be attached to a language. There is inherent complexity of layering two conditional engines.

    Perhaps this question might get more traction in the forum part, but I do think other customers have resolved it complying with their demands and information architecture. From what I remember...

    1. I think some customers deliberately broke the semantic message in a dedicated Library Topic which requires a bit more attention when doing localization. So the Library Topic can hold different message per language for 'ko' versus european market languages. 
    2. Introduce a market @ishcondition that filters out the big Library Topic, so CE for European Market. This will eventually lead to special handling if this (part of the) topic should be translated to Korean because CE is not relevant for them.
    3. ...

    I did not do extensive research, just want to make sure that we do understand what you are trying to do, but so far the product team did not find a one-size-fits all that solves these challenges across customers, respects all existing product concepts (baseline, context, logical-version-language, reports and more) combined with a low-learning-curve user experience. 

    Best wishes,
    Dave

Children
No Data