Localizing Web Dynpro components

[Former Member]

Having read and experimented with the tutorial 'Developing International Web Dynpro Applications' a few questions remain unanswered.

A) After copying a component's <file>.xlf file to <file>_<local>.xlf, using Web Dynpro to change some entries, reloading, and rebuilding results in a <file>_<locale>.properties file. Deploying and running my browser under the new locale shows the changed/localized entries. But if I go in and change the <file>_<locale>.properties file, rebuild and deploy, my browser does not see the changes I made to the properties file. Why?

B) How do third parties localize your Web Dynpro application? Third parties don't have the SAP tools and the xlf files are not human readable. But the properties files are (human readable). So, how is a Web Dynpro application localized if you have to send files off-site? And what files?

Lori <*>

[guru_subramanianb]

Hi,

Read the following steps for localization.

• Internationalization is used for adapting already existing Webdynpros application

Without changing the source code so that they can be used in several multi lingual languages.

• Here we keep text strings separately from the application source code in a particular format(keys & values) so they can be processed in the standard translation mechanism.

• Here frequently used texts such as labels or titles are stored as java dictionary simple types objects.

• To do internationalization, copy the automatically generated *.xlf files and save them under the new name in the same directory.

• For eg :- file convention like <old filename>_<language key>.xlf. Ex:- For German use the language key de.

• For a particular user the locale is specified by the User management engine.

• If not the locale is handled by the browser setting(HTTP Headers)

• If not the default locale specified by the application will be returned.

• If not default locale of the Virtual Machine(VM) is returned

• This locale is passed to java.lang.ResourceBundle in the J2EE engine.

• This will load the physically existing resource bundle either from any one of the following :-

Resource bundle of WD(if exists) or resource bundle of VM (if exists) or

Resource Bundle of without language suffix(always exists) given by the developer.

Answer to Q A) Are you using java.util.ResourceBundle class and having a key value pairs for the language you wanted to change.Are you importing this property file also in your Java file where you do Localization?

Answer to Q B)This is taken care of the Resource Bundle class and property file.If you want to send ur Webdynpro offsite also means you have to deploy it in WAS in which you have use Resource Bundle for acheiving Localization.

Only the deployed modules will be localized.

Hope it helps.

Regards,

Guru

Hope it helps.

Regards,

Guru

[Former Member]

Unfortunately this does not answer question A.

In short, why is it when the generated properties file (generated from an xlf file) is changed don't the changed entries show up in the browser? If the xlf file is changed, the properties file is generated with the changed entry and the browser displays the changed entry. So why can't the properties file be changed via a text editor and have the same thing happen (the changed entry show up in the browser)? Isn't Web Dynpro bundling, deploying and accessing the generated properties file for localized text? Or am I making an incorrect interpretation of how it does localization, bundling, and/or deploying? Is there some option I need to set in Web Dynpro to make this happen?

As to the fact that localizers have to use Web Dynpro to localize a Web Dynpro application (question B) is unacceptable from a business standpoint. This should not be a requirement. The whole reason to use Java is to make localization easy to do because properties files are human readable and text editable. The fact that the company now has to buy (at least one copy of) Web Dypro and give it to a third party so that they can do the localization makes using Web Dypro unappealing.

Or is using a separate resource bundle the only other option to question B? That presents its own problems (~100 UI components requiring context variables) but does allow for text-editable properties file(s).

[Former Member]

Hi Lori,

I know this post is really old, but have you find a solution of what you where looking? I´m looking to do something similar, that the internationalization could be done without the need to build and deploy a new .ear.

kind Regards,

Gerardo J

[Former Member]

Hi All,
  i would like to know if the labels are stored in property file there is no .xlf file generated for it. So how do i change it in Hindi or Marathi which i require in my Web Dynpro Application.