Introduction
When I first started working for my current employer, Kimball International, nearly a decade ago; I can't say that our operations
were all that international. We did have a showroom in Canada and a production facility right inside the Mexico/Texas border.
During these years however, I have seen our global footprint really grow. Today we have very active operations in Poland and
Thailand in addition to our North American ones. As much as we would like to think that our business language is English, there
is always a need for applications and information in the local language.
Background
If you remember back to one of my very first weblogs, the multi-language capabilities of BSP and the WebAS were one of the
deciding factors in our decision to go with this technology. Our R/3 system is currently setup as a MDMP system. This is a SAP
technology that allows our system to operate in multiple code pages without the use of Unicode. The application server sets your
code page when you logon and it is set for your entire session. This way the user interface can be translated (SAP provides various
levels of translation for different languages) to be displayed in the local language. This also allows for limited data input in the local
language. However any field in SAP that is not language keyed should only contain USASCII7 characters. If you are interested in MDMP
I suggest that you check out http://service.sap.com/globalization. You get English and German delivered in a SAP system standard.
We have also installed and configured Polish, Spanish and Thai. English, German, and Spanish all share the ISO-8859-1 Latin-1 code page.
Polish resides in the ISO-8859-2 Latin-2 code page. Thai has its own unique code page ISO-988/2533. We have setup all the matching
configuration in our WebAS so that we use MDMP and all listed languages.
Simple Translation
First of all you have all the translation capabilities that can be found in your R/3 system. You can create text elements, language dependent
texts, data dictionary descriptions, etc. You then can use the same tools that you do in R/3 to translate these items (SE63). I'm not going to
cover the tools that can be found in R/3 as well. There is plenty of documentation in the R/3 system on this. However when working with BSP
you have an additional translation tool - OTR. OTR or Online Text Repository is a tool that allows for translation inside your HTML code. You simply
surround your text with the OTR tag. This text will then be exposed for translation.
<!code><htmlb:textView design="HEADER2" >
<!code>
<!code>
You then can translate this in the OTR tool. The following is screen shot of this tool:
!https://weblogs.sdn.sap.com/weblogs/images/1918/OTR1.jpg|height=393|alt=image|width=579|src=https://...!
The following is example of this same text displayed in English and Spanish:
!https://weblogs.sdn.sap.com/weblogs/images/1918/OTR2.jpg|height=67|alt=image|width=254|src=https://w...!   
Field Labels
OTR tags are great for user interface elements like tab strips, buttons, and content areas but let's move on to field labels. Just like
in regular ABAP, there are lots of ways to reuse the data dictionary element descriptions for these field labels. The first way to do
this is to use MVC and allow the data binding to automatically fill in the field label for you. This works if the data dictionary element
for the field you are referencing exists in the WebAS. In this example we will have a user selection for Plant (WERKS). The following is
the code we place in our View:
<!code><htmlb:label for = "//model/WERKS"
<!code> required = "TRUE" />
<!code>
<!code><htmlb:dropdownListBox id = "mq_werks"
<!code> table = "//model/WERKS_VALUES"
<!code> selection = "//model/WERKS"
<!code>nameOfKeyColumn = "key"
<!code>nameOfValueColumn = "value" />
By using Model View binding, the Model class will do all the work for you. It will lookup the description for the field referenced, in the current logon language.
The Model View binding works great - as long as the data dictionary element exists in the WebAS. However often we find ourselves
reading data from R/3 where that isn't the case. We could recreate all the data dictionary elements and all their translations in the WebAS,
but that would be a lot of work. Instead we created an RFC that allows us to read the description from R/3. I usually just add another
element to my model class that will hold the description. Then in the initialization of the model I make the call to R/3 to pre-fetch all my
descriptions. The following is the code in the function module that reads the descriptions:
"----
"
*"Local interface:
*" IMPORTING
*" VALUE(ROLLNAME) TYPE ROLLNAME
*" VALUE(LANGUAGE) TYPE SY-LANGU DEFAULT SY-LANGU
*" EXPORTING
*" VALUE(DDTEXT) TYPE SCRTEXT_M
*"----
clear ddtext.
select single scrtext_m
from dd04t
into ddtext
where rollname = rollname
and ddlanguage = language
and as4local = 'A'.
if sy-subrc ne 0 or
ddtext is initial.
select single scrtext_m
from dd04t
into ddtext
where rollname = rollname
and ddlanguage = 'E'
and as4local = 'A'.
endif.
You can see that if the description is missing in the logon language we fall back to our business default language of English.
Data from Mixed Code Pages
We have talked about multi-language and translations issues for the user interface, but that only takes us half way.
Now let's talk about displaying data from multiple languages. In R/3 46C, with MDMP, you can only display one set of
code pages at a time. That means that there is no way to show Thai and Polish text together on the same screen.
Even though the WebAS may not be setup as Unicode, the ICM can return Unicode encoded data to your browser.
You can use this functionality to accomplish what 46C can't. The following screen shows data from R/3 on the same
web page encoded in Unicode but from multiple source code pages:
Unless you can read Polish and Thai, I guess you will have to take me on my word that this is displaying properly.
Lets talk in a little more detail about how you can accomplish this. First I mentioned earlier that the application server
sets your code page when you logon. However every time you execute an RFC you really logon on new. Using this
functionality you can setup separate RFC destinations for the same system with different logon languages.
By calling these different RFC destinations, you can in fact switch from code page to code page. So now we are logged
onto R/3 in the code page of the language we want to read data from. In order to get the data back to the WebAS
without corrupting it, we need to cast the character string into a binary string. The following is some example code
that will read a document info record description and do the binary cast:
"----
"
*"Local interface:
*" EXPORTING
*" VALUE(O_XSTRING) TYPE XSTRING
*"----
data: dktxt type dktxt.
select single dktxt from drat into dktxt
where dokar = 'ISS'
and doknr = '0000000010000000000002195'
and dokvr = '00'
and doktl = '000'
and langu = sy-langu.
field-symbols: The next weblog in this series will take a close look at User Authentication - specifically how we setup Single Sign On in our WebAS Environment.
18 Comments