Skip to Content

This blog is an extension to Perumal Kanthan’s blog of

Application Internationalization in SAP-WebAS Using Java Resource Bundle.(Part II) (WebDynPro Perspective)

Instead of the user selecting the language from the WebDynpro UI form, the language selection is automatically done from the language settings of the Internet Explorer and the UI elements are displayed accordingly.

The steps are as follows:

1. Create a WebDynpro project with a component, application and upload the properties file under the package structure

(as per the reference blog).

image

image

2. Create the context (Value attributes) for the view controller with

a. FirstName_Label

b. LastName_Label

c. Submit_Label

d. FirstName

e. LastName

f. TextView

image

3. Properties of the UI Elements are :

UI Element Name

Property

Context Variable

FirstName Label

TEXT

FirstName_Label

LastName Label

TEXT

LastName_Label

Submit Button

TEXT

Submit_Label

FirstName Input Field

VALUE

FirstName

LastName InputField

VALUE

LastName

TextView

TEXT

TextView

image

4. The code for ViewController (LanguageCompView) is as follows :

Others Section


wdDoInit() Method


OnActionButton() Method


5. Now create the archive (from NWDS) and deploy it.

(Do not run the application)

Initially keep the Internet Explorer Language settings as English (en)

You can the change the language settings by opening an IE, navigate the menu bar to Tools -> Internet Options -> Languages

image

image

6. Run it from the NWDS. The result would be

image

7. Now change the Language setting to German (de) by repeating step 5.

(Put German language on the top of the list.)

image

8. Run the Application. (It is not required to re-deploy the application)
The result would be

image

Things to remember are:

1. The language setting of the Internet Explorer (at times) doesn’t come into effect unless and until all the IE applications running on the desktop are closed.

i.e. You may have to close all the IE applications once the language settings are changed and then RUN the application.

2. The properties file used in this application is “competence” which is under the folder structure “com.wipro”, uploaded as per the mentioned blog.

3. If the language settings of IE doesnt consist of any languages then it would take english or Operating System language as the default language.

The sniplets of the Properties files are as follows:

+

competence_en.properties


textView.FirstName = First Name:

textView.LastName = Last Name:

button.Submit.text = Submit

textview.Welcome = Welcome

competence_de.properties


textView.FirstName = Vorname:

textView.LastName = Nachname:

button.Submit.text = Senden

textview.Welcome = Willkommen

+

Comparsion with SDN Tutorial

The SDN Tutorial  also gives the Internationalization of WebDynpro application  but with a different approach i.e. via the copy-paste-rename of the *.xlf files that belong to the application.

It’s a tedious process of copy-paste-rename of the *.xlf files and editing the files with the S2X editor with the appropriate changes in the language.

For example if we would like to support 5 languages for the WebDynpro application developed, then using the .xlf approach, we should copy-paste-rename-edit nearly 5 languages multiplied by 6 (.xlf files for the WebDynpro application), which would result in 30 changes, but the same with the help of above blog would result in just uploading  the appropriate language properties files under the package structure and  re-deploying i.e.

without any changes to the files nor to the code.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Valery Silaev
    Prashant,

    The only word I can say about your post is “nonsense”.

    The approach described in SDN Tutorial based on WD API and architecture, it is solid and convenient enough. Your one is based on your own knowledge of Java property files but not WD.

    The “tedious process of copy-paste-rename” XLF files is exactly the same as “simple process of copy-paste-rename” of properties files. The number of files is same: one language – one file.

    For example if we would like to support 5 languages for the WebDynpro application developed, then using the *.xlf approach, we should copy-paste-rename-edit nearly 5 languages multiplied by 6 (*.xlf files for the WebDynpro application), which would result in 30 changes

    Nice arithmetic. Let us calculate number of properties among all files that you have to translate. Huh? This will be the very same number both in case of PROPERTIES file and XLF files. Does it really matter that you have 5 property files with 300 entries or 30 XLF files with 10 entries? One day, please ask the person who needs to translate files does it really matter.

    And then ask him/her is it “simple” to use Java native2ascii utility to convert every property value in command line, then copy value and paste it back in property file. And s/he tells you that it’s more convenient to use S2X editor, trust me. If you are wondering what native2ascii is for, then try to create property file in Chinese, Russian or Greek. Or you have full Unicode codes table right into your memory?

    Btw, how you plan to split work among several translator over one super-duper property file with all application texts? Really, I’m curious. With XLF files I can easily assign several translators — translate texts of component A, translate texts of component B and C…

    … but the same with the help of above blog would result in just uploading the appropriate language properties files under the package structure and re-deploying i.e. without any changes to the files nor to the code.

    And changes in XLF file requires code modifications? C’mon…

    Now take a look at source code. With standard WD approach and XLF files developer may simply code views, all texts of labels and texts are automatically extracted to XLF file in project locale. Any new translations are supported automatically. On other hand, _your_ approach forces developer to do extra work (and a lot of it). XLF files efficiently removes all code lines you posted.

    Let me overwrite your conclusion:
    In light of XLF format + tools like S2X and NetWeaver IDE, using property files for I18N of WD applications is plain stupidity.

    VS

    (0) 
    1. Prashant Patalay Post author
      Hi VS,

      Thanks for your comments ! !

      My point of telling “No code changes” didnt mean that the *.xlf approach requires code changes but rather meant that the WD Developer doesn’t require to open the S2X editor for any changes in supporting of a new language.
      When the translator has completed his job of translating the texts and delivering it as a key-value pair property file (i.e by whichever approach he uses either the native2ascii or the S2X editor), then its the job of the WD Developer to copy-paste-rename the *.xlf files and paste the translated text into the XLF files for every new language that has to be supported.

      Whereas from the above approach its only about importing the language properties file delivered by the translator under the package structure.

      XLF approach efficiently removes the all the code lines posted by me, but this one time coding saves the WD Developer from any more changes i.e let it either be copy-paste of *.xlf files or editing the same in the S2X editor.

      Anywaz, concluding my part, this blog is one of the ways of implementing I18N.

      Best Regards,
      -Prashant.

      (0) 

Leave a Reply