4.1.2.1 Fixed Textual Objects
Description
Fixed textual objects are objects that should not be translated. Ideally, international developers should ensure that these objects are not internationalized in the first place. If this can be done, it substantially reduces the risk of problems later. However, developers often do not have control over the accessibility of fixed text objects by translators. Most translators are not programmers, and have difficulty distinguishing between programming logic, comments, and text information. This is often the case in files that contain both fixed textual objects and textual objects, for example, X resource files. Although this is not within the scope of internationalization, the provision of a special editing tool to hide fixed text objects from translators would prevent fixed text from being translated. Examples of fixed text objects include:
- User or group names, passwords, hostnames, and shell and environmental variable names
On Solaris and for the Internet, these objects are restricted to 7-bit ASCII for the moment.
- UNIX commands and command line options
ls -l for example is still ls -l in all locales.
- Device names
The translation of strings without concern for the actual use of these text items almost inevitably leads to problems. On a Microsoft Windows machine, for example, imagine the problems that would result from translating the word device in the device specification string device=c:****.sys in the config.sys file. The device driver in question would obviously not load due to the software not understanding the translated string. Likewise, on a UNIX machine, a string like var/spool/mail would not be translated; otherwise the mailer would fail to find the device used for spooling mail.
- Some resources
The following are examples of X resource fixed textual objects that should not be translated:
X color resource value: *background: burlywood
X font resource value: *fontList: serif.r.14
- Other configuration file settings
For example, in the http configuration file httpd.conf, the following text should not be translated:
AddLanguage .french fr
Command Line Interface
Options in command line interfaces are usually fixed textual objects, as in the previous ls -l example. This is true even though the particular option in question can be derived from an English word, for example, the l parameter in ls -l is an abbreviation of long.)
Character Interface
Fixed textual objects can be used in character interfaces. The vi editor is a good example of a character based interface. It provides a rich set of commands for text manipulation, most of which are derived from English words. For example, the s command can be used to substitute one string for another. This command would not work if the s were internationalized and subsequently translated to the first character of the local word for substitute.
Graphical Interface
Fixed textual objects may be used in graphical user interfaces (GUI). The problems associated with internationalizing and inadvertently translating fixed textual objects, as described previously, permeates through to the GUI, where control of the application often resides. A GUI implementation is a consumer of the operating system's services, that is, the provider; therefore, the GUI implementation is directly affected by any underlying internationalization problems inherent in the provider. On UNIX systems, for example, default device names are often used for printing and mail applications to indicate printer or mail spooler locations. Users often use these default settings as cues to the real locations. If these device names are translated, it is more difficult for users to guess the real locations.
Application Protocols
Fixed textual objects can be used in application protocols, such as HTTP for web browsing, SMTP for email, NNTP for broadcast communication, and LDAP for directory access. HTTP, for example, is the protocol used to transfer web pages between a server and a client. HTTP uses fixed text objects as part of its internationalization support, some of which are described in the following table.
Table 4-3. Use of Fixed Textual Objects in Application Protocols
| Fixed Text Object |
Description |
Sample Client/Server Output |
| charset parameter |
Specifies the character encoding of the document |
Content-Type: text/html; charset=iso-8859-1 |
| Content-Language response header |
Indicates the languages in a page sent from the server to the client |
Content-Language: da |
| Accept-Language |
Restricts the set of natural languages that are preferred as a response to a request from the client |
Accept-Language: da |
It is important that the client/server output is not internationalized and subsequently translated, since the output consists of standard parameter names that are recognized by browsers worldwide, for example, Content-Type. The output can also consist of standard parameter values that might have been registered with specific standards bodies. HTTP is an example of where server and client are both providers and consumers of internationalization related information.
Storage and Interchange
Storage
Fixed textual objects can be used in certain file formats. These tend to be the richer file format types, such as HTML, XML, and SGML. In this case, the fixed textual objects are tags that play a key role in enabling applications to interpret the document. They should never be internationalized. However, authoring or editing tools that create or modify files with rich file formats do require internationalization. It is important, for example, that editing tools protect document tags from translation. We can use the feature of language tagging in HTML and XML to illustrate the importance of not internationalizing and localizing fixed text objects in storage.
Language codes can and should be used to indicate the language of text in HTML and XML documents. For HTML 4.0, language codes are specified with the lang attribute. For XML, language codes are specified in the xml:lang attribute. In both cases, language information is inherited along the document hierarchy; that is, inner attributes override outer attributes. The language has to be stated only once if the whole document is in one language. HTML and XML rely on RFC 1766
to define language codes. RFC 1766 is in turn based on ISO-639
two-letter language codes, and on ISO-3166 two-letter country codes. Examples include:
en, en-US
Changing these tags without changing the text they describe can result in undefined behavior.
Interchange
Interchange protocols can contain fixed text objects. An example of this, is the property in inter-client communication in X. Properties are set directly by one application and read by another. They enable you to associate arbitrary information with windows, usually to make that data available to the window manager or other applications. A pre-defined property is uniquely identified by an integer ID called an atom; however, for non-predefined properties an ASCII string is also used. This string is used most when applications need to find out the atom for a property for the first time using XinternAtom(). This returns the atom for the property, which is used to access the property from then on. If this property string were internationalized and localized, it might cause unpredictable behavior.
Application Programming Interfaces (APIs)
Function names and their arguments are usually fixed text objects. They should never be internationalized. Compilers should flag this for you.
Requirements for Compliance
- Determine whether the text should be translated--use a common sense approach to do this.
- If the text should not be translated, do not internationalize the text.
- If the text appears in resource or configuration files, you can do either of the following:
- Provide a tool that prevents any fixed text from being changed.
- Provide detailed comments in the resource or configuration files indicating whether text should be translated.
Command line interface
See "Requirements for Compliance."
Character interface
See "Requirements for Compliance."
Graphical interface
See "Requirements for Compliance."
Application protocols
See "Requirements for Compliance."
Storage and interchange
See "Requirements for Compliance."
Application programming interfaces
See "Requirements for Compliance."
|
|
Print-friendly Version
