Publishing multilingual web sites

Some highly flexible structures

Although simple to use, multilingualism in SPIP enables highly flexible and diverse structures. But er can still make a few recommendations for the following configurations that make life easier for both editors and administrators:

-  For a site intended to publish a number of articles in several languages, the simplest solution is to create a main section for each language (e.g. one main section for French, one main section for Spanish, and one main section for Polish); the language of each article will then be directly defined by its section; we can activate the translation links between the articles, but we forbid the assignment of the language to each individual article (its language is therefore uniquely deduced from the section to which it belongs); as an example, this is how this SPIP documentation site is constructed; this makes life simpler for editors, and the site structure (the definition of the section hierarchies) is not complicated; in addition, this makes it very simple to define administrators who are responsible for a single language ("restricted administrators limited to a given section").

-  For a site that only occasionally offers translations of articles, it is preferable to define the language of each individual article, and to group the various translations of an article into the same section (since they relate to the same theme). This means we don’t need to define languages for the sections.

-  The solution that consists of mixing the two methods (define the language both for the sections and for the articles) is reserved for certain extreme scenarii: although this offers enormous flexibility, it can rapidly complicate site management, the creation of templates and incur logical inconsistencies in the structure of your site.

One very simple "trick" can make life much simpler, lighten up the private area interface and avoid incorrect operations by the editors: you can activate the multilingual functions when you define the sections (or for the occasional translated articles), and then deactivate them when you have finished such operations. The multilingualism will not consequently be eliminated by deactivating it in the private area - it just simply continues to operate but quite transparently to the site’s participants.

For example: take the case of a site structured into main sections per language, and for which the articles are not translations of each other: we can activate the multilingual features only for the brief moments when we actually define the major sections themselves (and hence assign them their language) and then turn off the feature immediately afterwards. The sections are then "frozen" in their language (the dropdown menu enabling the language to be changed will disappear), but the articles created or moved into those sections will automatically adopt their corresponding parent language. What’s more, the multilingual feature can be switched on again any time later if you so desire.

Monitoring the translations

The private zone page that displays "The entire site" can be used to monitor the status of article translations. This is particularly necessary for sites that have the majority of its articles translated.

In the example above, we can see a list of articles for each section. On the left we can see the language of the original version of the article ("fr" here is short for "French"), and on the right we can see the status of the translations of the site’s four other languages (Arabic, German, English, Spanish):

• a missing language indicates that the article has not yet been translated at all; for example, the article titled "Principe général" has not been translated into English nor German;
• the dark patches indicate that the article has been translated and that the translation is up-to-date; it is therefore not currently necessary for translators to work on that translation; for example, the article titled "FAQ webmestre" has been translated into Arabic, German,English and Spanish and these translations are up-to-date;
• the light patches indicate that the translated articles exist, but that the original article has been modified after the translation(s) was made; the translator must therefore update the translation(s) to reflect the modifications made to the original article; in our example, the article titled "Où placer les fichiers de squelettes ?" has been translated into Arabic, English and Spanish but not German and has been then afterwards: the Arabic and Spanish translators have not yet revised their respective versions.

Multilingual template files

The public area of a SPIP site is generated using a system of "templates". SPIP offers a variety of possibilities so that these templates can be multilingual themselves (for example, the French section of this documentation site displays the text "Télécharger la dernière version", but in the equivalent English section, this notice reads "Download the latest version").

These rather technical components are fully described in an article from this online documentation.

SPIP is not massively multilingual

In contrast to some other content management systems (CMS) such as Glastnost, SPIP is not a massively multilingual system.

In a massively multilingual system, absolutely all components can be translated and apply a particular interface to make this happen. Within SPIP, the choice has been made to limit the translation systems to the translation of articles only (methods exist to overcome this limitation, but they are deliberately reserved to experienced users).

This choice can be explained in several ways.

-  Primarily because of SPIP’s own history: SPIP was not originally multilingual at all, but became so at a rather late development to the framework. Turning it into a massively multilingual system would entail some extremely unwieldy modifications to the core code: possibly incurring interminable development delays and enormous risks of introducing complex bugs.

-  The basis for SPIP is the search for an easy-to-use system that can be instantly understood by a novice user. Some principles of easy-to-use ergonomics that are now firmly "set". It was therefore decided to opt for an evolution of the code that followed SPIP’s logic (articles clearly identified and separated into sections, and not different versions of the same article in different versions of the same section), and the considered options for evolving the system were not to impinge upon the established ergonomic principles of the system.

-  A massively multilingual system must apply an interface that is entirely oriented around the translation functions. And yet a vast number of sites created using SPIP are published in only a single language or that contain multilingual articles that are not actually translations of other articles. The choice was therefore made to introduce multilingualism to SPIP without making translation the core focus of the interface as would be necessary.

-  If SPIP’s policy appears somewhat less flexible than a massively multilingual system, it nonetheless does offer webmasters enormous freedom with a variety of features and mechanisms. These make it possible to have both articles that are translations of each other and other articles that do not have such links between them at the same time; or separate sections for different languages and other sections that combine several languages, etc.

The visitor’s language

By default a multilingual site in SPIP does not automatically reflect the visitor’s language (for example, directly displaying French articles to French visitors, and English articles to English visitors). It is still possible, to a certain degree, to construct such sites using SPIP, but applying these features is not a routine matter.

It all comes down to a matter of choice.
— Above all, it is extremely rare for users to actually configure their browsers properly to specify their preferred languages, even if such facilities routinely exist in all major browsers. The user is therefore usually identified only by the language in which the browser was first installed; as such, since the browser was not later configured to specify multiple languages, the user is typically considered to speak (or understand) just a single language; or even worse, the visitor could be using an English download of the browser software when that visitor actually speaks French natively... In any case, sites that rely on automatic language detection will only offer such visitors information in a single language, and maybe only in a language that the visitor doesn’t actually understand well enough at all.
— It is frequent that a visitor can understand several languages, but with varying competencies and preferences (fluent in one language, but capable of reading slowly in another...). And such visitors, rather than being assigned an automatic choice, would often prefer to adapt their visit to a given site depending on those varying competencies: such a visitor might therefore prefer to read in French, but when a French translation is not available, that visitor might opt for the English version (and failing English, then Spanish, then ...etc.). Automated mechanisms common on the web today are few and far between indeed.
— For the webmaster building the site interface, it is extremely complex to create a navigation mechanism that relies on language automations, except for just staying in the language choice imposed by the software; on the other hand, building a decidedly multilingual interface in which the visitor modifies his/her own navigation behaviour depending on the options momentarily made available to him/her, is certainly a practically achievable goal. The degree of difficulty for the webmaster of a given site is directly proportional to the degree of flexibility that the site design and structure stipulates.