This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

MIND


This article assumes you're familiar with Dynamic HTML
Download the code (2KB)

DHTML Localization on the Windows Update Site
Nick Dallett

With 31 languages served, the Microsoft Windows Update site has to be flexible enough to allow fast updating. The architect of the site's localization provides some guidance for when you're speaking to the world.
One of the least understood and most overlooked aspects of Dynamic HTML site design is internationalization. The vast majority of Web developers have worked in a single language, creating a Web site for a company that will do business in one or perhaps two countries.
      Unfortunately for Web developers, the increasingly global economy often demands that sites be developed for multiple languages. Sites must be developed with flexibility in mind so that translating the site is simply a matter of translating the words, and does not require a full site redesign.
      While this requirement is important for sites that must be viewable in two or three languages, it becomes absolutely critical as the number of translations increases. Microsoft® Windows® Update, the Web site extension of Windows 98 and the upcoming Windows 2000, is currently published in 31 different languages, and new content is published in each of those languages every two weeks. Maintaining a site of this magnitude in so many languages, with so much updated content, would be a technical nightmare without solid guidelines and procedures for site and content development. This article will describe the guidelines that I developed while localizing the Windows Update site (http://windowsupdate.microsoft.com) into two of the most challenging languages for English language developers—Arabic and Hebrew, the bidirectional, or "BiDi," languages.
      The challenge posed for English-speaking developers by these two languages lies in their reading order. Unlike English text, which flows on the page from left to right, Arabic and Hebrew flow right to left. A properly designed BiDi site will be a mirror image of the equivalent English site. The ramifications are enormous, and not just for text. Images that point "forwards" must now point in the other direction. Buttons on dialogs such as the familiar OK and Cancel must be reversed. Mixed-language phrases must be carefully cast to preserve the reading order of each language.

The DIR Attribute
      Microsoft Internet Explorer natively supports right-to-left (RTL) rendering of HTML content. Toggling left-to-right (LTR) and RTL display in the browser is as simple as adding one attribute—DIR—to the HTML element. <HTML DIR=RTL> will cause the entire page to display from right to left. This means that the page is rendered so that the top-right corner is the origin, with the X axis increasing from right to left. A properly constructed page will flow correctly with the DIR attribute set to either RTL or LTR (leaving this attribute off of the element will default to LTR). The lion's share of page reversal is provided to you for free.
      The MSDN™ documentation for the DIR attribute doesn't indicate that it applies to the HTML element, nor does it list DIR as an attribute of the <HTML> tag. DIR does in fact apply to the HTML element, and there are important differences between placing it there or placing it in the <BODY> tag. A DIR attribute in the <BODY> tag will affect all visible elements in the document, but will not affect ambient properties on ActiveX® components. Putting DIR in the <HTML> tag will set the ambient property of the document for ActiveX controls to AMBIENT_RIGHTTOLEFT. Also, if RTL reading order is set in the HTML element, the reading order of the document can be changed at runtime by setting the dir property of the document object through script.
      To get your feet wet with RTL rendering, try running the code in Figure 1 in Internet Explorer. Clicking the Switch button toggles the display from RTL to LTR and back again. Notice how the text does not change direction, but does change alignment and flow. Notice also how the punctuation moves from the right side of the text to the left side, and how the scrollbar on the page does the same. Similarly, the cells in the table reverse themselves when you toggle directions (see Figures 2 and 3).

Figure 2: Left-to-Right Alignment
      Figure 2: Left-to-Right Alignment

 
Figure 3: Right-to-Left Alignment
      Figure 3: Right-to-Left Alignment

      Unfortunately, this simple example doesn't take into consideration the complex positioning that is applied to HTML elements on real-world sites. Let's jump right into a real-world example, see the types of problems I encountered localizing Windows Update, and look at how establishing formatting guidelines helped to resolve most of those problems with a minimum of bother.
      Figure 4 shows the product catalog as it appears on the English Windows Update site.
Figure 4: The Product Catalog in English
      Figure 4: The Product Catalog in English

Figure 5 shows the same site as it appears after translation into Arabic and the addition of DIR=RTL to reverse the reading order. Note the following problems:
  • Directional images still point to the right rather than to the left.
  • Catalog items, the blue headline, and the blue legend at the top of the page are all aligned to the left rather than to the right.
  • The dark blue header runs off the right edge of the page, resulting in truncated text.
  • Borders on the Download button must be reversed to look right when combined with the arrow point.
Let's look at the causes of each of these problems and discuss how to format the page to avoid them in the future.

Figure 5: The Translation to Arabic with Glitches
      Figure 5: The Translation to Arabic with Glitches

Directional Images
      Images can cause real headaches for localization. Many Web sites use images that contain English words (including the Windows Update, Microsoft, and Microsoft Network logos on the Windows Update site). Often these images have to be recreated at great expense in the local language. In this case, I have a slightly less onerous problem: images whose left-to-right orientation on the page convey meaning.
      For localization in general, and the BiDi languages in particular, it is best that developers avoid directional images or images with text altogether. For example, in this scenario, the hand holding the window icon could well be replaced by two hands, seen (symmetrically) head on. The Download arrow could be replaced by a rectangular Download button. In this case, though, I'm dealing with the reversal of an existing site, so I must use other means to work with existing images.
      To provide a single code base that renders correctly in either direction, it's not enough to simply provide alternate images for the BiDi versions of the site. You have to include script in the page that dynamically changes the images based on the rendering mode being used. Since the Windows Update site supports only Internet Explorer 4.0 and 5.0, I was able to use a Cascading Style Sheets (CSS) filter on the images on the site to effect this change. The filter, flipH, which is installed with both Internet Explorer 4.0 and 5.0, flips any element horizontally so that it displays as a mirror image. The following is the inline script that will determine the direction of the images: 

 <SCRIPT Language=VBScript>
 Option Explicit
 Dim strFilter
 If document.dir = "RTL" Then
    strFilter = "filter:flipH;"
 Else
    strFilter = ""
 End If

 document.write "<IMG SRC='images/big-hand.gif' Style='" & _
    strFilter & "'>"

 </SCRIPT>
Because the actual Windows Update site uses an automated preprocessing step to determine the value of conditional variables, you won't be able to see this code if you view the page's source. This is the client-side script equivalent of the actual code used.

Unwanted Left-alignment of Text
      When you look at the source for this page, you'll see that the catalog is built of HTML tables in which most of the cells are marked ALIGN=LEFT. This results in correct behavior for the English site, but preserves the left alignment when the page is reversed, resulting in incorrect rendering for BiDi versions. The ALIGN parameter in this case is superfluous—since the default alignment for LTR display is left, and the default alignment for RTL display is right, removing the align attribute completely will cause the page to display as expected: aligned left for the LTR case and aligned right for the RTL case.
      As a general rule, less is more: if you put into your code only those elements and attributes necessary to produce the effect you need, you will avoid unnecessary headaches later.

Elements Running Off the Right Side
      The problem here is in the CSS stylesheet. Here is the class definition for this element in the stylesheet for the page: 


 .SectionDiv {
 font-size: 9pt;
 color: white;
 font-weight: bold;
 background: #00319C;
 padding-top: 1px;
 padding-bottom: 2px;
 margin-right: -15px;
 padding-left: 1px;
 font-family: Verdana, Arial, Helvetica;
 }
Note the margin-right attribute. This style was applied to the section headings to ensure that the DIV ran flush to the right edge of the page. For the RTL case, this results in a DIV whose origin is to the right of the actual display by 15 pixels.
      Generally, pages should be designed so that CSS styles are horizontally symmetrical. Any element with a margin-right style should have an equivalent margin-left. While this requires more up-front design time and somewhat limits a developer's freedom in the initial coding of a site, it results in fewer headaches during localization.
      My fix for this particular problem was to use preprocessing to change margin-right to margin-left. I could also have accomplished this by having translators reverse hardcoded left and right parameters in the stylesheet.

Bad Borders on the Download Button
      The Download button is made up of a <SPAN> tag with borders specified with the CSS attributes border-top, border-bottom, border-left, and border-right. As noted earlier, hardcoded left and right attributes are not reversed by Internet Explorer when rendering right-to-left, so this button must be manually reversed by swapping the border-left and border-right attributes. Here is the (greatly simplified) original code for the button: 


 <SPAN ID='SpanNext' CLASS='ButtonG' 
 STYLE='WIDTH:93px;HEIGHT:30px;
 BORDER-LEFT:none;PADDING-TOP: 7px;'>Download
 </SPAN>
      You could use either of the previous two approaches to change this attribute: dynamically writing the tag using script, or allowing translators to make the change manually. In the latter case, the inline style would have to be moved to a global stylesheet to be readily localizable. This means creating a new class that consolidates the ButtonG class with the individual style for the Download button: 

 .DLButton {
 background-color:  #909090;
 border-bottom:     #5f5f5f Solid 2px;
 border-left:       none;
 border-right:      #5f5f5f Solid 2px;
 border-top:        #c0c0c0 Solid 2px;
 color:             #ffffff;
 font-family:       Verdana, Arial, Helvetica;
 font-size:         8pt;
 font-weight:       bold;
 text-align:        center;
 height:            30px;
 width:             93px;
 padding-top:       7px;
 }
The values of the border-left and border-right attributes could then be swapped by translators to produce correct reversal: 

 border-left:         #5f5f5f Solid 2px;
 border-right:        none;
      Figure 6 shows the Arabic product catalog after applying these changes to the page.
Figure 6: Arabic Product Catalog with Fixes
      Figure 6: Arabic Product Catalog with Fixes

CSS Positioning Issues in BiDi Design


      CSS positioning presents special problems for bidirectional Web sites. Figure 7 shows the EULA dialog after translation to Arabic and application of the RTL attribute.
Figure 7: Problems with Absolute Positioning
      Figure 7: Problems with Absolute Positioning

The buttons on the EULA dialog had been positioned using absolute CSS positioning. Not only do the buttons overlap the text, but the order of the buttons is fixed—the Yes button is fixed on the left side, the No to its right. Here is the code: 

 <BUTTON ACCESSKEY="Y" style="font-family: 
	Arabic Transparent, arial; font-size: 10pt; 
	position:absolute; width: 58pt; height: 19pt; 
	left: 146pt; top: 230pt" 
	onclick="doOK()" ><u>Y</u>es
 </BUTTON>
In this case, absolute positioning was superfluous; if the position attributes had been left off the buttons, the buttons would self-align naturally. Removing the position, top, and left attributes (shown in blue) from the style on the button causes the button to align more naturally below the text. In addition, allowing Internet Explorer to control the flow allows the button positions to be correctly reversed (see Figure 8).
Figure 8: Position Attributes Removed
      Figure 8: Position Attributes Removed

      Specifying relative positioning can be problematic as well. The BiDi version of Internet Explorer 5.0 has a bug that causes text to disappear from the page when position:relative is specified in the stylesheet for that text. This is easily remedied by replacing position:relative with margins on elements that specify their offset from other elements. This way, you are specifying the attributes of the element with respect to its own size, rather than with respect to the position of other elements. For example, rather than specifying 

 position:relative; top:15px; left:10px;
try this: 

 margin-top:15px; margin-left:10px;
Bidirectional Tables
      If you take another look at the sample page in Figure 2, you'll see that I used a table to position several columns of text. Note how well the table reformats itself when DIR=RTL is applied to the <HTML> tag, as shown in Figure 3. In fact, tables turn out to be the best and most reliable way to ensure that your content is correctly reversed when moving from LTR to RTL, provided you do not specify alignment on the table cells.
      A nested table can be used to format a complex HTML form, for example. The form will reverse correctly when the page is set to use the RTL reading order. Tables can be used to align text to the right of the page without using align=right by using empty, oversized table cells to push content to the right. In the following code, note the oversized cell whose width is set to 700 pixels and the 30 pixel spacer cells used to position the text. Since the text is enclosed in cells that precisely define its right and left edges, applying DIR=RTL to the <HTML> tag results in a perfectly reversed table. Figures 9 and 10 show the resulting table in both standard and RTL formats. 

 <TABLE width=100% border=0>
 <TR>
     <TD bgcolor="#C0F000"><NOBR>Item 1 </NOBR></TD>
     <TD width=30 bgcolor="#C0F000"></TD>
     <TD bgcolor="#C0F000"><NOBR>Item 2 </NOBR></TD>
     <TD width=30 bgcolor="#C0F000"></TD>
     <TD bgcolor="#C0F000"><NOBR>Item 3 </NOBR></TD>
     <TD width=700 bgcolor="#C0F000"></TD>
     <TD bgcolor="#C0F000"><NOBR>Item 4 </NOBR></TD>
 </TR>
 </TABLE>
      Another advantage of positioning using tables is that they resize gracefully—something that cannot be said of a page with absolutely positioned text. When this page is resized, the oversized cell used to push Item 4 to the right will shrink and expand to fill whatever space is necessary to have Item 4 just reach the edge of the page.
Figure 9: Using Spacer Cells
      Figure 9: Using Spacer Cells

Figure 10: …and then applying DIR=RTL
      Figure 10: …and then applying DIR=RTL

Known Issues
      Internet Explorer 4.0 and 5.0 have done quite a bit to support bidirectional languages, but there are a few known issues with the RTL rendering code.
      Left-side offsets for elements are always calculated as larger than the page width when in RTL mode in Internet Explorer 5.0. Elements render correctly, but this makes it a challenge to determine the correct offset in script (such as when showing or hiding a pop-up menu). This is a known problem that should be fixed in a future version of Internet Explorer.
      As noted, specifying the CSS position:relative style for any element causes text in that element not to be displayed. The workaround is simply to remove position:relative (which is the default) for pages with right-to-left orientation.
      Dialog boxes displayed by the Document Object Model (DOM) do not honor the DIR attribute. This includes window methods such as alert, prompt, and confirm. This is also true of the native VBScript function MsgBox. Windows Update uses the showModalDialog method to display HTML dialogs instead of the DOM methods on the Microsoft BiDi sites. This issue should be addressed in future releases of Internet Explorer.

Six Rules to Make Your Life Easier
      To summarize, here is a list of general rules that can help ease the translation and text reversal process.

  1. Avoid specifying align=left unnecessarily.
  2. Apply CSS attributes symmetrically.
  3. Avoid inline styles.
  4. Avoid CSS positioning.
  5. Use tables for robust reversibility.
  6. Avoid MsgBox, alert, prompt, and confirm.
      While these won't remove all of the challenges a developer faces when creating a globally diverse Web site, they should provide a baseline on which to construct sites which gracefully translate into Arabic and Hebrew without putting undue burden on translators.
      

MSDN
http://www.w3.org/TR/REC-html40/struct/dirlang.html
and
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/dir.asp

From the October 1999 issue of Microsoft Internet Developer.