** TEAM FPM ** – All about Translation and Texts of FPM applications

In the last weeks I was confronted quite often with the topic, how FPM texts are stored and more interesting – how they could be translated at all…

Of course there is a very helpful note available (#1646142, Storage of FPM texts), but nevertheless a kind of “bring it all together explanation” is still missing. This is why I started writing this blog…

So what are the most important points to address?
1) Everybody should know that texts of an FPM application can be stored in 4 different ways:
a) Data element
b) OTR (Online Text Repository), e.g. as OTR-alias in your component configuration ($OTR:<alias>)
c) Text elements of an ABAP OO class (e.g. your feeder class)
d) Configuration of a Web Dynpro Component (e.g. your List UIBB configuration)

2) How can I translate texts of my own created component configuration?
The translation process of texts stored within component configurations starts with transaction SE63. The object type for these texts is “TLGS” (Lockable Logical Objects, Short Texts).
To reach the Standard Translation Environment, navigate within the menu via Translation –> ABAP Objects –> Transport Object.

(Please also consider note #3050325 which contains a correction for translation of texts on OVP standard UI elements which are going to be added to a toolbar)

Remark for texts within customizing of component configurations:

You have 2 options to translate customizing texts:

a) via the Translation Tool for Customizing (only if customizing has already been created!)

b) via SE63 (as described for configuration Texts above but in a slightly different way, read below)

The Translation Tool you reach via WD application wd_admin_configuration, entering the name of the component configuration, then select the customizing link of this configuration and you will get a link displayed on the following screen (“Translation Tool for customizing”) which leads you to the Translation Tool.

Within SE63 you choose “ABAP Objects –> Short Texts”.

Depending on your release follow one of the following two descriptions:

• There you choose entry “A6” for table entries (TADC Tables, Customizing – maintenance by customers only). From there open the F4 help and find string “WDY_CONF_USERT2”.
• There you choose entry “00” for tables (TABL Tables (Meta)). Enter Object Name “WDY_CONF_USERT2”.

Enter the appropriate source and target languages and press edit. On the popup enter user scope = “A”. Additionaly you can search directly for the affected configuration ID. Now you get the well known SE63 list for translating texts.

Now you come to the well-known overview screen where you enter the transport entry of your object and source as well as the target language.

Pay attention to the Object Name! It is not only the name of your component configuration… You have to take the name of the object directory entry which you can find either within your transport request or within table TADIR or within se80:

You will recognize that within the object directory entry the configuration name is concatenated with “00” at the very end – copy this string and you can continue with transaction SE63.

After you have entered the transport entry of the object as well as source and target language, press “Edit”.

In the following screen all texts stored within configuration are displayed with their translated text or – if translation has not yet been done – with empty fields.

3) Application Hierarchy Browser
You came to the idea to copy a standard delivered FPM application via the FPM Application Hierarchy Browser and you are wondering, why texts are not translated afterwards.
This issue is known (until 7.31 SP04) and a solution is provided with note #1710822, which provides a report called WDR_CFG_TEXT_COPY. This report copies the text in the missing languages. Please have a deeper look within the given note to get further details how to run this report correctly.
For future releases all texts in all languages will be copied automatically by the FPM Application Hierarchy Browser.

4) Texts stored within GUIBB configurations (e.g. List, Form, Search, …)
Texts within GUIBBs, e.g. the text of an input field label, can be provided by several instances:
a) Component Configuration

b) Feeder Class (text has been defined within method GET_DEFINITION)
c) Data element (of the respective feeder class field)

A certain sequence exists how those texts are applied when it has been maintained in all of the above entities. At the very end the text stored within the component configuration wins, then feeder class and afterwards the data element. So if nothing else has been stored the text will come out of the data element.

5) What to do when the translation exists but it is not applied at runtime?
If this issue comes up mainly GUIBBs are affected where the source is a data element. Just activate the respective data element again and your application is showing the translated text. The root cause of this issue can be found within the language load. For further technical details you can also have a look into note #110910.

If you have checked the existence of all translations successfully and even then the texts are not applied, you have the possibility to invalidate the area CL_WDR_CFG_COMP_SHM_TRANS of the Shared Memory via transaction SHMM. You have to do that on every application server. Use the button “Invalidate” left-hand sided of the delete-button. See also note #1909945 for more information.

6) Last but not least: The FPM provides a Text Tool from NW 7.31 onwards…
To determine which static texts are used within your component configuration or application configuration, you can use report FPM_TEXT_TOOL to find out, which text types are used (e.g. “D” stands for data element, “C” for Configuration, …)

Additionally a direct navigation is possible via double-click to the named entities, like data elements, component configurations, …

Furthermore a very good documentation is included within the report so you can understand every detail presented by the FPM Text Tool.