English has plurals but other languages have genders that modify the form of a noun and/or adjective. In French, a web site (un site Web) is masculine, but a web page (une page Web) is feminine. Adjectives must agree with the number and the gender of what they modify.

Note that the word "good" assumes four different forms in French, depending on gender and number. Translating the word "good" by itself is "bad". And, note that the articles with the nouns also change.

From the English column, it looks like some money could be saved by translating "the good web", "page" and "site" and simply append an "s" when you needed to. In reality, it would drive translators crazy, the translation would be awful, and rewording would require code changes.

Word order is not necessarily the same in different languages. For example, English adjectives usually precede the nouns they modify (e.g., the large green icon), but usually follow in French, with the exceptions being the most common, (e.g., la grande icône verte).

In French, some adjectives can go before or after the noun they modify, with occasionally amusing / unfortunate results:

In French, there is conventionally a space before a colon: If the colon is appended by application code, then the application needs to know that a space is required. Many punctuation characters are handled differently. It might be easier to simply include the punctuation so that the translator can take care of any details.

In French, it is common to use italics to show an untranslated name (e.g., WorldCat), so some care must be taken when displaying marked-up translations because the markup might not get interpreted, e.g., in the window's title bar or in hover-text (hover your cursor over WorldCat and you may see uninterpreted HTML).

Parts of phrases can not simply be concatenated. For example, the English text that might accompany paginated results: is translated into Chinese as: When values can not be appended, they can be inserted by allowing translators to move variables. To translate variables can be defined elsewhere and inserted when the text is displayed.
Here is an example with perl variables: and here is one for an SGML-entity format: It is critical that the translators recognize the syntax of variables and know how to move them correctly. Otherwise, translators may translate a variable name or cause a syntax error. While the order may be the same for English and French, other languages (e.g., Chinese) might display the information more like:

Inserting variables into a sentence can be tricky. To indicate "Your search found 10 records", it will not work to translate "Your search found" and "records" and insert the number found. Even in English, the method will produce grammatically incorrect text like "Your search found 1 records", or require the awkward term "record(s)". An alternative is to use a label and a value: This translated well into all languages (at least left-to-right languages), but note that the colon is preceded by a space in French, unlike other languages, so even that part must be translated.

When inserting values (numbers, dates, currency), keep in mind that different locales will expect them in different formats.

In OCLC FirstSearch language files, the name of a variable conveys its meaning, and the section of the language file conveys how it will be used. For example, the labels for fields (e.g., Title, Author, Year, Publisher) for bibliographic records are all in the same section (the [field] section) of the language file. The same variable names in an [index] section could show the names of search indexes (which might not match the field labels). Yet another section might give search examples for the named indexes. Avoid names that provide no information beyond the English version, especially if the word conveys little information, such as prepositions. Instead, use names that are descriptive, possibly much longer than the values in a particular language, so that the meaning is clearer to the translator.

Sometimes it is necessary to embed some markup in the text so that the translator can move the marked-up text in a phrase. or Even simple markup might get mangled a small percentage of the time, but including a lot of markup can make unintended changes more likely, which can result in a feature not working. For example: Translators may not know much if anything about coding and might inadvertently break the code by modifying some markup or by inadvertently translating some markup. In the example above, it may not be clear that the only text that should be translated is the title attribute "terms", and that translating other "terms" strings will break the code. And frankly, reordering complex HTML to match the target language grammar might be error prone even for programmers. Variables like the following might make the translator's job easier: and then the code can be hidden from the translator:

System-wide variables: A special case of code to hide from programmers are system-wide variables, such as locations of files. These are best defined in one place and inserted as variables so that if they need to be changed, the change is made in one place, not in many language files, where they might be mangled by translators. And if the values of the variables vary by language, then a variable can be used to adapt them (assuming a regular naming convention; otherwise, there can be a separate store of variables for each language).

If there is any code in translated text, it is a good idea to validate what comes back from the translator (valid HTML tags, correct syntax for entities). And from experience, it is a good idea to validate what is sent to the translators before it is sent, because any errors will probably be dutifully maintained in all translated languages, and then need to be fixed in many places.

Unless there is a compelling reason to do otherwise, use ISO 8601 date format (e.g., 2008-05-12). Besides being an international standard, it has the virtues of being unambiguous (unless you think someone would display years, then days, then months), relatively compact, and easy to implement. Note that hyphens in HTML can be broken across lines, so instead of using the effective but invalid <nobr> tag, you can use CSS:

If you want to display more "natural" dates, please note that the punctuation, order of values, and value display all vary by locale (combination of language and location), so translating dates requires more than just translating months and maybe weekdays. For more natural date and time displays, see the Java formatting for Dates and Times. In addition to date formatting, there are Java classes for numbers and currencies (not everyone uses a decimal point or a comma to delimit thousands).

While on the subject of international standards, it should be noted that the United States is practically the only country in the world that is not on the metric system. With geographic information systems becoming more popular, distances should be reported in kilometers (or kilometres) as well as miles. The units can be based on the browser locale setting, with miles reported for en-US, and metric for others. Note that the United Kingdom (en-GB), while officially metric, conventionally uses miles for travel distances, as well as some other Imperial measures such as pints of beer.

Making a button with some text can be an attractive choice for full control over graphic design. The font, color, spacing, ..., are fully controlled. To translate text on images requires

• translating the text
• creating the image, ideally in the same size, but probably in a different size because languages differ
• having a native speaker review the image, possibly with changes (e.g., because of illegible fonts)
• integrating the image, possibly with size differences

The whole translation process often takes about a week, if all goes well, but if there are several languages to translate, then there might be problems. A common bad result is that an image with English text is shown to all users. Even if the initial costs are acceptable, when it becomes desirable to change the text, the costs make text-on-image maintenance so unattractive that it is usually avoided.
If an interface must contain text on images, use the language code (e.g., ISO 639 codes such as en, fr, es, zh-CN) in the file name or path so a single expression can be used for all languages. or
In addition to translation problems with text on images, there can be cultural issues with graphics on images, particularly body parts such as hands and eyes.

English text is shorter than some languages, longer than others. Don't expect that careful editing to fit onto one line in English will translate to the same effect in other languages.

The acceptability of abbreviations varies across languages, locales, and translators, so you might not be able to count on translators using them. In WorldCat.org lists, pagination looks like this in different languages:

Notes:

• In French, the forms are all feminine because they modify the implicit feminine term "page".
• In each Chinese label is the same and means "page", so the Chinese pagination controls are both more verbose and shorter at the same time.
• In Arabic or Hebrew (not shown), both right-to-left languages, the arrow directions have opposite meanings: "first" and "previous" would be on the right and point to the right, and "next" and "last" could be on the left and point to the left, shown with English labels below:
  Last   Next   8 7 6 5 4   Prev   First

Flags are not languages, wrote Steven Pemberton, when he explained that flags represent countries, not languages. UK flags and American flags and even combined UK/US flags have been used for English, although there are several languages with origins in the UK, and there is an official flag of England. Spanish is from Spain but it is spoken in many countries, and even within Spain, the Spanish language is not universal. Arabic is spoken in many countries, but it may be difficult and even politically naive to try to select a flag to represent a language.
When displaying a language option to a user, the user needs to be able to understand the option, so these would not be a good set of links to select a language:
A native Chinese speaker might not even recognize that the options are for languages, but most people can recognize their own language in their own language. In the following list, the languages are ordered by their two-character ISO 639 language codes. Notes:

• There are diacritics in the French and Spanish language names, and these can be represented with HTML numeric or symbolic entities (e.g., &ntilde;, &ccedil;).
• The Chinese language name appears correct because the two Unicode characters are represented by HTML entities (decimal: &#20013;&#25991; or hex: &#x4E2D;&#x6587;) representing the two Unicode characters. If represented by an image, at least the image will not need to be translated. Some interfaces might show two Chinese options, one for traditional Chinese used in Taiwan (zh-TW) and Hong Kong (zh-HK), and simplified Chinese used in Mainland China (zh-CN) and Singapore (zh-SG), but the browser locale can be used to distinguish the two.
• If users can not read the language names, they might still wonder what the names represent, so a title attribute can be added in the "current" language, shown in bold in the second list of links if the cursor hovers over the name. Whether the current language should be "hot" is debatable.
• A pulldown menu might be missed if the user can't understand the visible part:
  Select a Language: Deutsch English Español Français Nederlands 中文
• Maps are not languages either, but a map might be a useful way to indicate a market (e.g., U.S., E.U., or a country), and language options might be presented for each.