joachim_nissler
Returning Observer

Getting all languages from a data source entry

Jump to solution

HI community,

I'm trying to get all translations for a datasource entry within a section template.

The list of all relevant languages is defined as "st_languages" as ("de", "en", ...).

"allItems" is the result of the CMS_HEADER Query.

Does the code below meet the best practises or is there any better solution for doing this?

 

$CMS_FOR(item, allItems)$
	    <item FSID="$CMS_VALUE(item.fs_id)$">			
		$CMS_FOR(lang,st_languages)$
			<label language="$CMS_VALUE(lang)$"><![CDATA[$CMS_VALUE(item.getValue("tt_name_" + lang.toUpperCase()))$]]></label>
		$CMS_END_FOR$
	    </item>
	  $CMS_END_FOR$ 

 

Cheers,
Jo

0 Kudos
1 Solution

Accepted Solutions
hoebbel
Crownpeak employee

Hello Jo,
this solution will work with FirstSpirit schemas configured by default. Of course, if language-dependent columns have been defined by hand, there may be problems (since they can have any name). Furthermore, there may be problems with complex input components (which themselves contain the language information).

As long as the solution works properly, in my opinion this is the most performant (and therefore recommended) solution.

Solutions that handle special cases can use the dataset (this "knows" in which column the language-dependent content is stored) and possibly even have to output this in a different context (i.e. within a format template and before calling this the output language [#global.language] has to be changed).

Note: FirstSpirit is designed to automatically output the appropriate content for the current language. As long as you only want to output this current language, you do not have to worry about this. However, outputting content from other languages bypasses this concept, which then leads to more or less effort.

Best regards
Holger

View solution in original post

1 Reply
hoebbel
Crownpeak employee

Hello Jo,
this solution will work with FirstSpirit schemas configured by default. Of course, if language-dependent columns have been defined by hand, there may be problems (since they can have any name). Furthermore, there may be problems with complex input components (which themselves contain the language information).

As long as the solution works properly, in my opinion this is the most performant (and therefore recommended) solution.

Solutions that handle special cases can use the dataset (this "knows" in which column the language-dependent content is stored) and possibly even have to output this in a different context (i.e. within a format template and before calling this the output language [#global.language] has to be changed).

Note: FirstSpirit is designed to automatically output the appropriate content for the current language. As long as you only want to output this current language, you do not have to worry about this. However, outputting content from other languages bypasses this concept, which then leads to more or less effort.

Best regards
Holger