Multilingual Websites for a Global Presence
Studies have shown that today about 50% of Internet users do not speak English. Analysts predict that by the year 2004, 50% of online purchases will be made outside the USA. When these users visit websites, they will look for their own languages, or leave the site. On average, users stay twice as long in websites that are in their own language, and the likelihood of an online purchase is actually quadrupled. Source: Forrester Research
Think globally - act locally
In order to be able to use the internet as a global sales and marketing instrument as well as an infrastructure for global business processes, the cultural, technical and commercial content must match the specific requirements of these markets. If this is not the case, you are taking a risk of losing customers everywhere in the world.
In a few years, it will be just as hard to find a company that has a website with only the local language as it will be to find one that has no website at all.
Localizing Content Objects
Enomaly manages structured information that exists in the form of individual content objects, for example a message, a contact, or a document. This provides excellent conditions for successful translation. Consequently, the information only has to be translated once, independent of its publication on one or more pages or websites. However, translating is only the first step in localization.
Structural Considerations
In the beginning, a decision must be made regarding a functional structure for the future website, which is appropriate for the goals that are to be achieved. Depending on the requirements, the following procedure models are possible:
Multi-portal solution - Internet presences that are logically completely separate from each other, but still have the same system and are maintained in one database (local specific model)
Content sharing or cross portal publishing solution - Shared use of content objects in the various structure levels: page (subject), module (page sub-area), or object (e.g. individual message or document) (hybrid model)
Single portal multi-language solution - Management of Internet presences with identical structures but with localised content in one portal (lockstep model)
Here, providing completely separate Internet presences with a choice of language on a homepage (multi-portal solution), is seldom the best choice. The costly consequence of this method is the high effort of maintenance as well as the decreasing homogeneity of the presence. The high degree of overlap of the content and structure of the individual Internet presences of the subsidiaries is often an argument against it.
The content sharing or alternatively cross portal publishing solution provides the greatest flexibility, but also the greatest complexity. It makes it possible to have shared use of mandatory content, recommended shared content (proposal), or alternatively optional parts (informal) that are binding in all languages. Moreover, the individual country portals can contribute their own content very flexibly, which will only be shown in that particular portal.
The single portal multi-language solution is the easiest to implement and to maintain. The website structure is identical for all languages and is usually specified by the head office. Therefore, it can be implemented within a portal very easily. The content only has to be localised by the subsidiaries. Additional content in the respective local language is possible at any time. Slight deviations from this content can be defined in the page template for specific local regions (e.g. regional trade fairs).
Default Language as a Fallback
There can be different methods for content that is not localised, or not yet localised. Either it won't be displayed (e.g. the respective documents are put into a download area) or instead, the content will be shown in a defined default language (usually English), which is the fallback rule. Using a default language makes is possible for the subsidiaries to localise gradually while operations continue. The respective content that has not (yet) been localised will be automatically identified by the system with a reference that is defined in the template (... not localised ...).
Automatic Choice of Language
The language that is displayed can be selected by the CMS based on the settings in the visitor's browser. However, you must be careful here. Many users work with English versions of operating systems or software without it being their own language. The user should have the possibility of making a subsequent choice of language using appropriate symbols. Including the language in the URL (sub-domain or subdirectory) makes it possible for the visitor to save the selected settings so that they are available for the next visit.
Changing Languages in Context
Enomaly makes it possible to change languages in the context of the specific object. For example, if a message is opened in English and it exists in another language, then you can change to the other language directly for this content object, i.e. for this message. This has many benefits. If the user coincidently finds the English version when accessing the site through a search engine, then he will be thankful if he can make use of the offer in his own language. The internal linking of the system, e.g. for a reference to a related article or a responsible contact person, is language independent or multi-language. A connection that is established manually or even automatically by means of categories and content relationship management is only established once at the content level and then it applies to all languages.
Character Sets
Representation in various local languages requires the correct usage of the respective character sets, for example the use of UTF-8. Then, there is no problem when the languages are mixed:
Сделайте Google стартовой страницей! (Russian)
Κάντε το Google να είναι η Αρχική σας Σελίδα (Greek)
Currencies and Date Formats
Decimal points are handled differently for prices, and also the use of currencies and their symbols is very different. In Germany and other European countries, $1,000.00 is written as 1.000,00 $. Most European countries use a 24-hour clock. Consequently, "9 a.m. to 5 p.m." should appear as "9:00 bis 17:00" in German. Here, the technology is really helpful. Microsoft.NET Culture Tags make it possible to take unique country-specific features into consideration for the presentation, with regard to the language and the specific culture (e.g. de-ch). They must be programmed into the template later.
Cultural Aspects
Above and beyond formal aspects, the cultural features of individual countries should be taken into consideration. Not every representation is suitable for every cultural group. Therefore, it is quite important to have the possibility to localise resources such as illustrations as well as multimedia components like videos or sounds.
Legal Aspects
There are considerable differences in the laws and regulations that must be observed in the online sector. Some examples are the necessity for imprints and general terms and conditions, the right of withdrawal for online purchases, or a reference to the responsibility for content on your own or external linked pages.
Templates
It must be possible to have a language independent design for templates that are used in the various levels (page, sub-page, and object).
In order to prevent increasing the work load when creating templates, you should work with language-independent symbols as much as possible. For example a printer is understood to be a printing symbol independent of culture. Arrows can replace the customary "more..." as a reference to more information since "more" must be localised. However, if tooltips or alternatively ALT tags are used because of barrier freedom ("Section 508"), which is required in some countries, then there are limitations.
Text-only Version
We recommend providing a text-only version by making use of alternative templates. This not only makes it easier for the handicapped to access the information, but it can also help in case of poor bandwidths or older computers.
Since the content objects exist in a media neutral way and are published in modules (corresponding to sub-page areas), these modules can be recompiled or presented in a simplified form in alternative page templates that take into consideration the specific requirements of different users or even scanners.
Orientation / Reading Direction
Different cultures have different reading directions. The Internet Explorer provides the possibility to manually or automatically change this setting (Use: View -> Encoding -> Left to right document or Right to left document). The structure of individual content areas in the page template should take this requirement into consideration right from the start, if localisation is planned for these cultures.
Maintenance by Local Editors
If too much control is exercised on content that can be contributed by a local subsidiary, for example, then you will not exploit the benefits of true web localisation. Employees who are responsible for a country or region can often better judge whether content has any legal or cultural significance or if it is commercially useable in their market. Consequently, the probability of having successful e-Business is much higher in these markets. However, the Internet not only creates the need for a decentralised approach, but it also provides a way of doing it.
Software Installation vs. Browser
The prerequisite for easy, decentralised maintenance is still a completely browser-based application that works entirely without a software installation. You must be careful when using Java or ActiveX. Firewalls or administrative guidelines often don't permit an installation on the editor's PC. Therefore, the applied solution should work without any installation at all. Access must be ensured through firewalls and proxies (Port 80). By the way, this also applies if localisation is not performed directly in the subsidiary, but directly in the system by external service providers (e.g. translation agency).
Licensing
With the decentralised approach to maintaining the Internet presence, there can be a rapid increase to the number of editors. Therefore, the consequential costs for license models, which are based on the number of named or simultaneously active users, are difficult to predict. Here, server or alternatively CPU-based license models provide more planning certainty, because the costs are independent of the number of websites that are operated, the languages, and editors.
Multilingualism in the CMS User Interface for Editors or Administrators
The user interface for editors or administrators should at least be available in English, but it would be better if it were in the most important languages. Managing text and picture elements in the user interface in a resource file (e.g. XML), which is separate from the programme code, makes it possible to localise quickly and economically, depending on the project requirements. Moreover, it is possible to change the language context at runtime. The last language that the user selected is maintained for the next login.
Access Rights and Guidelines
The large number of editors that often participate in localisation puts considerable demands on the system's access rights. Here, access rights at the page level are no longer adequate. Even rights at the object level, for example a message or a document, which are typically used in Intranet/extranet scenarios, are often not adequate. Here, it must be possible to accurately differentiate the rights to the individual language versions of a content object. Every editor who is responsible for a localisation wants to be certain that no one changes his version. The administration of such a system can quickly become complicated. Therefore, the need to group these rights into security guidelines is unavoidable. Any editor can understand and use a "Confidential - Management" guideline, independent of how complex it is in detail. These guidelines are created once and then assigned to the content objects, automatically if possible. Changes to the guidelines have an immediate effect on all content objects to which they are assigned.
Workflow
The workflow, from the initial creation of a content object in one language up to its translation, localisation, and release in all supported languages, is tedious and certainly complex. Here, the system should provide practical support at critical places. It should be possible to assign and trace tasks for localisation. Templates or alternatively text modules should be available for frequently occurring tasks. Questions like: "Which language is not available for a document?", or "Which content is about to exceed the publication time period?" must be answered. Flexible reporting must be available for this purpose. The quality of the workflow that is provided has a decisive effect on the cost of localisation.
Bandwidth
There is a considerable difference in the bandwidth (transmission capacity) that is usually available in the individual countries. This must not only be taken into consideration when developing the Internet presence, but also when maintaining it. It should at least be possible to maintain content using low bandwidths. Here, it is interesting to use server-side components for compressing the HTTP data stream. In any case, this saves transmission costs, even if the bandwidth is basically available.
This important component is already included in the Enomaly basic system.
Resolution and Colour Depth
There are many regional differences in the resolutions and colour depths that are available in receiver terminals. A compromise must be found here. In all cases, the website must also be useable with a resolution of 800x600 pixels. Additional information for example, can be placed in the area outside this.
Meta Information and Content Relationship Management
Meta information for individual content objects, such as pages but also announcements or documents, must be made language-independent, and the specific target language must be recorded in the corresponding metatag. This applies not only to keywords, but also to categories, for example. Individual content objects are assigned to each other in a multi-language way according to content perspectives. However, in each case, the language context applies to the presentation of these connections, for example as navigation content or as related content. That means tree structures for categories must be localised as the need arises.
