About transformations for multilingual websites

The cms.news.detail is the transformation code name. The format of the transformation code name is composed like this: <pageTypeCodeName>.<TransformationName>.

So, if you have the News page type, its code name is CMS.News. Now, for this page type you create a transformation called Detail. So, the code name for the transformation will be: cms.news.detail This is because you can have a different Detail transformation for Article page type. So, the transformation code name would be articlePageTypeCodeName.Detail

This is built in based on a suffix on the end of the transformation's code name. check out the documentation here. Look at the last blue box on the page labeled with: Transformations for multilingual websites

You may need to display different text in transformations based on the currently selected language. If you are using the built-in multilingual support, you can achieve this by creating a separate transformation for each language, using the appropriate culture code as a suffix in the transformation name.

Example:

• English (default language) transformation code name: cms.news.detail
• French transformation code name: cms.news.detail_fr-fr

When a user switches the content culture to French, web parts and controls automatically load the French version of the transformation.

I may not have provided enough information, so I will add some additional information.

Currently, the "Spec" field for product A in the two cultures contains the following data. The "Spec" is retrieved and displayed by Transformation.

en-JM：xxxxxxx fr-FR：yyyyy

en-JM culture displays the set data "xxxxxx". I want fr-FR culture to ignore "yyyyyy" and get and display Spec "xxxxxx" of en-JM.

The following method is certainly helpful, as it allows us to change the process for each culture. English (default language) transformation code name: cms.news.detail French transformation code name: cms.news.detail_fr-fr

What I would like to know is how to code the fr-FR transformation to get the data for the en-JM culture.

If you can help me, please let me know.

By the way, the version of Xperience I am currently using is 12.0.95 PortalEngine.

Wouldn't it be just easier to abandon the ASCX transformations and use the text/XML in which you can use macros and in the macro you can easily tell from what culture you want to get the value? The aSCX transformations have their limitations - there is just limited set of built-in methods and if oyu want to stick with ASCX, you will need to create a custom transformation method which will get the value from the culture version you want.
The macro engine gives you much more options without actual coding.

Up to now, only the ASCX format has been used. The reason is that I am used to using it.

If the question we are asking this time can be easily realised, we think there is no problem in using the TEXT/XML format.

What we need is not which method is preferred, but how it can be achieved.

Could you give us a sample and tell us exactly how to implement it?

What we want to implement is to get data from a different culture than the current culture, as mentioned in one previous comment.

How to create a custom transformation method is described in the documentation. And then, depending on your exact needs, you will use the API to get the appropriate culture version of the page and its properties.
While, when using macros, it would be for the page system fields like:

{%Documents[NodeAliasPath].Documents["< cultureCode >"].DocumentName%}

and for all fields, including the coupled data fields from the page type the macro could look like this:

{%Documents[NodeAliasPath].CultureVersions["< culture code>"].FieldName%}

I would like to suggest to use the macro console and either with some real or virtual data check what the options are available for pages (and in the same matter for all other objects). The console can help you building the macro. Sample screen shot.

You can select the one you want. You have two options - either create custom transformation method and develop the code logic using C# and API or, use macros in a text transformation. The decision is up to you.

I think you're misunderstanding how the transformations work. For a given page type you can have multiple transformations. Let's say you have a page type called Article (code name cms.article). In this page type you have a transformation with the code name of detail By default in your repeater web part when you select the detail transformation for the cms.article page type, it will display that in the site's default culture which we'll say is en-JM. That transformation has whatever code you want in it. It could have a totally different layout, it could be displaying totally different fields, and it could be formatting the data totally different from any other transformation. The key is that is used for the default culture of the site AND any other cultures that are not yet defined like below.

In the transformation listing for the cms.article page type, clone the default transformation and set the code name to default_fr-fr. Modify your transformation to have whatever code, layout, fields, etc. you want for the French culture. In the repeater, you do nothing, just leave the initial transformation (cms.article.detail) selected and the system will do the rest. When someone navigates to your site and selects the French culture, it will automatically pick that up and use the French transformation.

Now on to your specific issue, I'm unsure of what the Spec field's datatype is or what it's expecting for data format but let's assume it's a string that is always 12 characters long and has a value of something like xxxxxxyyyyyy. In your detail transformation, which would be for the en-JM culture, on the cms.article page type, do something like the following

<%# Eval("Spec") %> // displays the full value of the field
<%# Eval<string>("Spec").Substring(0,6) %> // displays the first 6 characters

Now in your detail_fr-fr transformation on the cms.article page type, do something like the following:

<%# Eval<string>("Spec").Substring(6,6) %> // displays the last 6 characters

You can use regular C#, in most cases, directly in your ASCX transformation.

I'd highly recommend going through the Kentico 12 Developer Training as these are some of the fundamentals Kentico was built. And you won't get very far if you don't understand the fundamentals.

Thank you all for your answers.

We were able to realise the originally existing Transformation with a small amount of code in TEXT/XML format based on the following advice.

{%Documents[NodeAliasPath].Documents["< cultureCode >"].DocumentName%} {%Documents[NodeAliasPath].CultureVersions["< culture code>"].FieldName%}

For those Transformations that already exist in ASCX format and have a large amount of code, there is a high possibility that converting them to TEXT/XML format will cause problems at our technical level, and we would like to consider using a custom transformation method as Juraj has suggested.

I would like to leave this question open for a bit longer.

Again, thank you for all your advice.

I don't think it's a matter of coding it in ASCX vs Text/Html, it's a matter of not knowing the difference between the two options and how to work with either of them. Learn how to work with ASCX and you'll be ready to go. What I provided for naming conventions for your transformations will work 100% without needing to create a custom transformation method. Just read the documentation, the system was built to work that way out of the box without any custom code. Don't over engineer it.

@Brended - if I am getting their request correctly, they do not want to switch the culture for entire transformation - using the suffix. But when the page is in FR-FR culture, the transformation, for one particular field (or maybe just few fields), should still return the value from default culture and not the FR-FR culture.

@juraj Thank you for the follow-up. You are right.