Sun Software Product Internationalization Taxonomy

Print-friendly Version

Chapter 3 Interfaces

This chapter divides possible software interfaces into groupings for the purpose of discussion. A project team should use these groupings when describing the internationalization issues and techniques employed for the interfaces of a software project. The objective is to allow generalizations for describing the internationalization issues of a whole class of interfaces at once. Most software projects have an interface in more than one of the following sections, but software projects are unlikely to have an interface in every section.

Whether a certain interface belongs in one grouping or another might not be completely clear. If this is the case, the interface can be included in whatever section eases the discussion of that interface and its internationalization issues.

The command line interface refers to the shell command used to start a program, including both the command name and its arguments and options.

NOTE: The Solaris guideline for command lines, which is based on based on getopt rules, specifies that option names must be one character long. Using single character names for options can aid international use, as non-English speakers should find it easier to type -n than -newer. For more information, type the following command:

man -s 1 intro

On the man page, see the "Command Syntax Standard: Rules" section.

We also group a command line interpreter in this section. The command line interpreter refers to any program that acts on subcommands typed by a user, for example, the shell and dbx.

A character interface is a user interface which is character or text based; that is, non-graphical, for example:

• Full-screen interface, such as the vi or Emacs text editors



• Output to a daisy wheel or other character-only printer



• Pop-up description box

Certain types of terminal messaging also fall into this category.

A graphical interface renders information onto a bit mapped (pixelated) or vector drawn space. Some examples are:

• Graphical user applications, such as a word processor or web browser.



• Output to a PostScript or PCL printer, or to a phototypesetter.



• Drawing on a pen plotter.

NOTE: Many graphical applications behave as if they were character interfaces. They use the default fonts supplied by the window system, assume fixed width characters, and use no icons or other graphic elements.

An application server provides a set of well-defined services to client applications using some form of interprocess communication. The protocols used are interfaces and are often layered on lower-level protocols. Protocols are sometimes exposed to customers, so software on other systems can communicate with local software as a server, client, or peer.

For example, a Simple Mail Transfer Protocol (SMTP) server accepts email for delivery on a known communication port. Most email messages are intended for humans, even if produced programmatically, for example, by cron, the UNIX® clock daemon. However, some messages might be communicating with a server of some kind that understands the format of messages directed to it. In this situation, SMTP is being used as a store-and-forward transmission medium. Both the lower-level (SMTP on TCP/IP) and higher-level protocols (the programmatic message content) are protocol interfaces. They have separate syntax and semantics descriptions, and hence potentially different internationalization choices.

Private protocols are sometimes called messages or interprocess communication. For the purpose of internationalization, these are all grouped in this section; however, a private protocol might not require internationalization.

Server software and hardware is often shared by speakers of different languages. Protocol elements or data structures should be as universal as possible and interpreted for human consumption by internationalized and localized clients.

File formats include the input formats accepted, output formats produced, and storage formats, whether documented for customers or kept private for internal use. Many file formats are a mixture of customer data and required syntax or "boilerplate."

File formats can be transported across a network to a different host. If appropriate, file formats should be reusable in various timezones, languages, and cultures. Since entire networks of systems cannot be upgraded simultaneously, different systems are likely to be running different versions of any software; therefore, exchanging files leads to additional versioning considerations.

A database is the same concept, whether implemented in multiple files or not, and whether useful for interchange or solely for storage. Databases are therefore grouped in this section.

Logging, log files, and controlled file names and file suffixes are also assigned to this section.

APIs are programmer calling sequences to access a software library. When compiled, the library implementation and the client programs conform to an application binary interface (ABI). If they use the same translation rules, the ABIs are compatible and the client and library can communicate successfully.

Within an API, there might be aspects that require potentially different internationalization decisions. Function names, like command names, are not altered; they are the same worldwide for program and programmer portability. However, messages printed by a function should be internationalized. In general, API functions should not print error messages, but should provide status values to the caller.

Certain libraries also offer a systems programming interface that implementations can plug into. These implementations are often device-specific. They are also considered part of this section.