SAP Fiori Application Translation

The blog covers different places an SAP Fiori Application can pickup translations from and how to maintain translations for these objects.

I have this List and Object page Fiori Elements app with Tile ‘Product’ under Tile group ‘Sample’

Report as I mentioned is based on the List and Object page Fiori Elements template. Development objects (Domain, Data element, Table, CDS, Metadata extension, Launchpad artefacts) are created in English and the app looks perfect when I log on to Fiori Launchpad in the English language.

App pickup translatable text/labels from different places these are 1) i18n file 2) Metadata extension 3) Data Element 4) CDS 5) Text Table/Text CDS

However, when I log on to the system with Logon language as French result is not quite perfect. Some translatable text keeps on displaying in English, some fall back to the technical name and few aren’t displayed at all. For example, Tile Group and Tile are displayed in English. A couple of columns are being displayed as technical names e.g. ColourCode and IsRed. In the Object page, section headers and field labels are missing.

Admittedly, the columns Material and Plant are translated into French. Material descriptions have picked up French values.

Let’s explore how we translate these different elements along with some of the techniques used in CDS.

Translating Fiori Launchpad Contents

We create Tile Catalog, Target Mapping, Tile and Tile Group in Fiori Launchpad designer. These objects are translated using transaction SE63. The trick is to find the right object to translate.

FLPD contents are attached to transport as ‘Web Dynpro Component Configuration’. The easiest way is to check your transport, look for Web Dynpro Component Configuration and take note of these object names.

Now go to SE63 , follow menu path Translation->ABAP Objects->Transport Object

Specify the object directory entry, source and target language and perform translation.

Run /UI2/INVALIDATE_GLOBAL_CACHES and you should see translated Tile Group and Tile in Fiori Launchpad

Modelling Code and Language Dependent Text

SAP stores language-dependent text in text table. These are table with object key, language key and descriptions in the given language e.g. table MAKT which hold the language-dependent description for Material.

Two CDS views are used to model key/code (Material) and language-dependent description (Material Description). A text association defines the relationship between two.

Take the example of Material that is modelled using two CDS I_Product and I_ProductText.

I_Product defines association to I_ProductText in line 3. This association is later qualified as text.association in line 5. In line 7 association is exposed.

define view I_Product
  as select from mara
association [0..*] to I_ProductText  as _Text on  $projection.Product = _Text.Product
{
   @ObjectModel.text.association: '_Text'
   key cast (mara.matnr as productnumber preserving type )                  as Product,
   _Text
.
.
}

I_ProductText is defined with dataCategoty #TEXT. This tell system that this CDS is a text provider. Semantic.language tells the system which field is Language and @Semantic.text tells the system which field contains language-dependent text.

Note that you can annotate more than one view field as a text field. However, only the first annotated field will be considered in the text consumer view for OData exposure.

@ObjectModel.dataCategory: #TEXT

define view I_ProductText
  as select from makt
  association [1..1] to I_Product as _Product on $projection.Product = _Product.Product
{
  key makt.matnr                                              as Product,
      @Semantics.language: true
  key makt.spras                                              as Language,
      @Semantics.text: true
      cast(makt.maktx as productdescription preserving type ) as ProductName,
      _Product
}

Example 2: Colour key and values are stored as domain fixed values in generic tables DD07L and DD07T. Using some clever select statement but the same concept as described above, Colour keys and language-dependent values are modelled.

define view ZI_Colour
  as select from dd07l
  association [0..*] to ZI_ColourText as _Text on $projection.ColourCode = _Text.ColourCode
{
      @ObjectModel.text.association: '_Text'
  key cast(LEFT( dd07l.domvalue_l, 1 ) as zcolour ) as ColourCode,

      _Text
}
where
      dd07l.domname  = 'ZCOLOUR'
  and dd07l.as4local = 'A'

@ObjectModel.dataCategory: #TEXT

define view ZI_ColourText
  as select from dd07t
  association [0..1] to I_Language as _Language   on $projection.Language = _Language.Language
  association [1..1] to ZI_Colour  as _ColourCode on $projection.ColourCode = _ColourCode.ColourCode
{

      @Semantics.language: true
      @ObjectModel.foreignKey.association: '_Language'
  key dd07t.ddlanguage                               as Language,
      @ObjectModel.foreignKey.association: '_ColourCode'
  key cast(LEFT( dd07t.domvalue_l, 1 ) as  zcolour ) as ColourCode,
      @Semantics.text:true
      dd07t.ddtext                                   as ColourCodeText,

      _Language,
      _ColourCode

}
where
      dd07t.domname  = 'ZCOLOUR'
  and dd07t.as4local = 'A'

Once I maintain translation for domain values I should be able to see values in French for Colour keys. Translating in SE11.

And I have the values

Field Labels

Field labels and column headers are automatically picked up based on language from the data element. You can see Material and Plant fields are translated in French for simple reason that they refer to the data element MATNR and WERKS_D for which SAP has already maintained the translation.

If you are create Z table, reuse SAP data elements as much as possible. This way you won’t even have to worry about translation. If you do have to create a data element, translate it from SE11 into the target language(s) and system will pick relevant text.

After I have maintained the translation in French, I can see the French label for the column.

The last column ‘IsRed’ is the calculated column in CDS and the label is added directly in CDS. We will see in next section how to translate CDS, however, my recommendation here is instead of using @EndUserText in CDS you create a data element and use cast statement to link the calculated field to the data element.

Anyhow, let’s look at how to translate texts defined in CDS.

Translating CDS

The translation is done in SE63 transaction.

Use object R3TR-DDLS

After maintaining translation I can now see the column header in the List page and the field label in the Object Page.

Translating Metadata Extension

Some captions, for example, facet heading are specified in the Metadata extension object. These too are translated in SE63.

Use object R3TR-DDLX

After maintaining the translation I can see texts in the French language.

i18n Translation

To translate i18n file copy default i18n.properties field rename it by adding 2 letter language suffix. Maintain french text in this new file.

Relevant i18n file will be picked up for test by the framework.

Custom Field and Logic

If you have created objects like new fields, email templates, CDS in key user extensibility apps then maintain translation in the app itself (instead of using SE63).