Hello Ann Jensen ,

One of the benefits of Tridion Docs our customers value, is that it stores and delivers the same content (having a single source of truth) in different languages through various channels.

This is to make sure that content consumers will receive the same message across all the languages it was translated into.

Around this baseline functionality is built. As Joe said “The baseline is language agnostic, and mainly serves to say which versions of which objects are to be in a given publication. The idea is that for a particular object version (say topic version), then all the languages of that are saying the same thing. They are different-language mirrors of the meaning of the source language, whatever that is.”  

This core model drives a lot of functionality in the product and adding a new layer on top would require a lot of effort not only from R&D but also from customers to adopt it.

 One example, the changes in baseline functionality that you are requesting might lead to a situation where the final delivered content will have differences between different languages that are hard to predict and control.

As you correctly pointed out for cases where language has more priority than the message you can use separate publications where you can set a working language to the one that you want to publish.

 So, currently, we are not considering this idea but we appreciate the input and will continue to think of improving use cases such as this.

Hi Joe/Dave

Just checking back in on this request of adding support for Autocompleting to the Latest Translated Versions of the working language (to be used when relevant).

While content teams do set the working language to the language they want to publish, they are still finding it challenging in large publications to ensure that every content object including conrefed topics are in status Translated which this feature would help with.

Can you let me know if there are any plans on the roadmap to support this?

Thanks in advance,

Ann

Hi Ann,

The working language (and also working resolution) is the language in which you 'define' the message. So selecting version 2 of a topic because you read its semantic message in the working language (en-US) means you know what you will bring across if somebody reads the message in a translation (after all fr-FR is just a different syntax) - the same message.

The system through baseline version selection disconnects the message from the translations. While your request reads that the language is more important than the message, so I read it that you would rather send out version 1 of the topic because it is available in fr-FR although it could contain the wrong/incomplete message (there must be a reason why version 2 was created after all).

So I think you answered it yourself, let me quote you: "I know that another way of doing this would be to create the publication and setting the working language to the language layer that we want to publish.... and might be something that we should consider." ... If language is more important than use that other language as working language, as in essence your publication will send out a different message (topic version 2 update missing) anyway.

Best wishes,
Dave

Hi Joe,

Thanks for quick reply. What I am asking might not be valid for how the Autocomplete feature operates but it is a common request we get so I wanted to explore.

I hear you when you say the baseline is language agnostic. My understanding is that it represents the selected content object versions in the working language, which is usually en-US for us.
Our normal process is to create publications using our base language i.e. en-US and then create outputs where we set the Requested Language to one of the the generated language layers we want to publish. I know that another way of doing this would be to create the publication and setting the working language to the language layer that we want to publish.... and might be something that we should consider.

A point of note is that our full complement of generated language layers are not always Translated for each content object version. So version 2 of an object might exist in status Released for en-US and fr-FR language layers, but version 1 of same  object might be in status Released for en-US, fr-FR and de-DE language layers. Therefore, if the Requested Language for an output is set to de-DE we want to use version 1 in the baseline while if the Requested Language for an output is set to fr-FR we want to use version 2 in the baseline.

In summary, the availability of the Requested Language layer in status Translated for a content object is what influences which version of that object we want to select for the baseline.

Our ask is, given a Requested Language layer value, to select the latest Translated versions of each content object for that language.

Please let me know if you want clarification on anything I have said here, and please correct me if my understanding is incorrect.

Regards,

Ann

Hi Ann, please could you expand on the use case a little? The baseline is language agnostic, and mainly serves to say which versions of which objects are to be in a given publication. The idea is that for a particular object version (say topic version), then all the languages of that are saying the same thing. They are different-language mirrors of the meaning of the source language, whatever that is.

And the flow is normally that you create the content you want in the source language, (e.g. if your Topic A version 1 needs changed, you create a version 2, and work on the content changes in the source language of that version 2 of Topic A). And then you use the baseline to generate translations for the other languages you want of that updated source content.

Apologies if this is all stuff you know already!

Could you describe a bit what you are trying to achieve – the starting point and where you want to get to? It may well be that I have just misunderstood (and there is at least a 50% chance that I will suddenly understand it as soon as I have posted this reply!)