While much of the localization of a Web service has been discussed from conceptual viewpoint, little has been covered on how frequently dropped packets can result in significant interruption thresholds after multiple Web services are connected to or integrated into non-Web services or vice versa to complete a prioritized series of localization tasks. This is important as these thresholds could adversely impact uptime availability in the Service-Oriented Architecture (SOA) that has seen Web services competing with non-Web services for limited resources.
In this paper, I talk about the cultural and technical issues of localizing Web services when the translated text and graphics require more space and bandwidths than their English equivalents. I divide productivity localization into intra-localization and inter-localization as they pertain to office application productivity. In an upcoming paper, I will talk about the cultural, technical, and legal issues of digital games that require a different localization approach.
As the name implies, intra-localization is concerned with localizing a Web service to suit a local culture in the United States. It focuses on regional dialects, languages of professional and trade groups, and industry sectors and images they use. It also pertains to the more intensive use of text, graphic images, and sounds to accommodate some disability groups.
English language is not specifically a tonal language in which the same word has totally different meanings when spoken at different tones as in some Asian languages. Speaking in a digital tone; however, might be used to a certain extent to an audience of the disabled who cannot see the images very well to indicate the mood, rather than the meaning of a word or even a paragraph.
Inter-localization, on the other hand, pertains to localizing a Web service for a local culture outside of the United States. It focuses on determining how much space the translated text would need depending on the target language and culture. For instance, text in all Western European languages expands from its English equivalent, while Japanese/Chinese text contracts it.
Some colors and graphic icons that are culturally acceptable in the United States might be offending or have different meanings in another country. White is a color of purity in the United States, while it is a sign of mourning in Eastern cultures. In another instance, Americans instantly recognize the trash icon on a Macintosh as a waste paper basket. To British people, it represents a postal box. When they see the icon, they "throw away" e-mail that the intended recipients never get. The degree to which images and icons need to be changed also depends on the local culture and traditions.
Cultural differences also exist in the way you submit payments online. The United States does it mostly with credit cards. Other countries do bank transfers, COD, and so on. Correct formatting of times and numbers, currency differences, and metric measurement differences are other areas that need to be localized.
Translated text: table results
Let's take a look at the translated text of "securing Web services" in Western European languages -- first with table results and then with graphic images. As you will see in Table 1, Spanish text expands by 38% from its English equivalent of 21 characters while Italian or Portuguese text expands by 100%.
Table 1. Translating "securing Web services"
| Target language | Translated text | Expansion |
| Spanish | Asegurar servicios del Web | 32% |
| French | Fixation des services de Web | 33% |
| German | Sichern von von Netzdienstleistungen | 71% |
| Dutch | Het beveiligen van de diensten van het Web | 100% |
| Italian | Assicurazione dei servizi di fotoricettore | 100% |
| Portuguese | Fixando servicos da correia fotorreceptora | 100% |
Note that since these translations were taken from a Web site for illustrative purposes, you still need a professional translator to ensure the accuracy of each translation.
Translated text: visual representation
The following is a visual representation of the above table results. It illustrates how much more space you would need for each translated text.
Figure 1. Space needed for English and translated text

Here is another way of comparing space for English with that for other languages.
Figure 2. English versus Spanish and Portuguese

Each of the text is literally translated from "securing the services of the World Wide Web" in English. That's about 43 characters long. For English speakers, they prefer to say "securing Web services" - for short.
Because of its conciseness and brevity, English is more efficient than the Western European languages when it comes to reducing the number of packets to transmit a very large amount of text from a Web service as shown in Figure 3. The less packets the Web service needs, the less there is a chance of significant interruption thresholds impacting the uptime availability in a SLA guarantee.
Figure 3. Packets for large text

Limited bandwidth by a consumer's choice or limited availability in certain geographical areas of the world can hamper graphics or flash images that are more intensive in a set of localized Web services. If downloading of graphic and flash images slows down more than 10 seconds, an end user will most likely use the mouse to point to another Web site for faster downloading.
Limited bandwidths can also hamper translated text that results in an unusually large amount of visual text. If this text is transmitted as audio for the end user to hear, the computer voice might stutter due to limited bandwidths.
In both instances, this might cause an increase in the frequency of dropped packets resulting in significant interruption thresholds. This might impact the uptime availability specified in a SLA guarantee.
How much localization is needed?
One way of overcoming bandwidth limitations is to translate and localize some, but not all, aspects of text information in Web services into another language. Areas with highly technical material, in industries where English is usually used for the technical terminology, can remain in English.
Another recommendation is to convert icons and formats to a specific language and culture and eliminate culturally inappropriate colors, icons and images with the addition of new links to content (see Resources). Network packet-probing applications should be considered to determine how many packets have been dropped due to text expansion and more intensive graphics and flash images.
Developers must anticipate how much space the translated text will need for its English equivalent and what graphic images are culturally acceptable. They need to limit the size of a GUI interface in which the text can dynamically be expanded and more intensive and larger graphic images can be accommodated.
If developers set inadequate resizing limits, the translated text in a Web service will appear either truncated or as packed sardines, and the downloading of images will not perform well. Worst yet is that the link area in the larger translated text will be broken, as shown in Figure 4. This causes significant interruption thresholds.
Figure 4. Exceeeding resizing limit

Also important is the number of layers (Z-index) that can be placed on a Web page to accommodate the overflow of the expanded text and more intensive graphic images. Too many layers can slow down a Web page download.
While the platform-independent XML has the flexibility of localization, the IBM® Java Resource Buddle gives a far better performance as it is compiled and run as binary code. The longer an XML script and the larger the expansion of a translated test are, the more work the parser has to do thus slowing down the performance. If this gets to the point where slow performance becomes noticeable, a significant interruption threshold results.
One way of getting around this problem is to arrange XML scripts and Java programs in modular formats. If an XML script is not performing well, it can be replaced with a better-performing script or a binary-coded Java program.
While XML is currently a globalization standard language, more and more tools and techniques are being developed to support XML localization. One example is XLIFF (XML Localization Interchange File Format), an exchange format for translatable data developed by a group of localization customers, localization suppliers, and tools vendors, including: Oracle, Novell, IBM Lotus®, Sun Microsystems, Alchemy Software, Berlitz, Moravia-IT, and ENLASO Corporation (formerly the RWS Group). XLIFF is maintained by the OASIS XLIFF Technical Committee, where developers can participate. It has the potential of becoming a more mature technology offering better performance (see Resources).
Localizing office applications Web services in a heterogeneous SOA requires planning ahead of time and setting the limit on how much the translated text and visual areas of a Web service can be dynamically resized from their English equivalents based on word length and file sizes, respectively. The developers should communicate with localization specialists on the issues of dropped packets and significant interruption thresholds when specifying resizing and bandwidth limits in a SLA.
- Get information on how to use SLAs in a Web services context from the other papers in this series:
- "Guarantee your Web service with a SLA" (developerWorks, April 2002)
- "Guarantee second-generation Web services applications with a SLA" (developerWorks, August 2004)
- "Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
- "Secure multiple Web services with a SLA guarantee" (developerWorks, November 2004)
- "Firewall Web services with a SLA guarantee" (developerWorks, December 2004)
- "Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, January 2005)
- Learn more about what's beyond localization in "Globalizing Your Website."
- Learn more about the IBM Java Resource Bundle in "Globalizing your e-business."
- Need assistance with XLIFF? Go to Open Tag's Web site to take a look.
- Find out more about XLIFF as a multi-lingual data exchange standard for localization.
- Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
- Publish your Web service or application in IBM's UDDI version 2 registry, which features a graphical user interface and conformant APIs for public use. IBM's UDDI version 3 beta registry.
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.
Comments (Undergoing maintenance)





