(ˢᵒᶜⁱᵉᵗʸlog)
(ˢᵒᶜⁱᵉᵗʸserver)
(ˢᵒᶜⁱᵉᵗʸtask)
Chandler
REST
angular.js
coding-for-fun
cordova
css
hackerspace
installation
javascript
mockups
multi-language
nReduce
pike
publishing
retreat
sTeam
stylesheets
user-interface
virtual hosting
xiamen

multi language documents
multi-language | publishing | sTeam

sTeams way of handling multiple languages for a document currently works like this:

First, multi-language support needs to be configured by a sTeam administrator by specifying which languages are to be supported in the multilanguage_languages attribute on the admin group object. Once that is active, containers and rooms show an option to configure them as multi-language containers. If this is activated you are able to select a document in the container for each language that was configured above on the admin group.

This is rather suboptimal. Different pages may want to support a different set of languages. There is nothing in offering a certain set of languages that would require admin intervention. The above language list could be a hardcoded list covering all languages on the planet for example, but then we'd get a long list of languages to select in each container.

The next problem is that, in order to select a document for a language, the document needs to exist. So, first you need to create a document for a language, then go to the language setting for the container and select that document. And then better don't try to move the document into another container...

A better approach might be the following:

Throw away the admin setting. Just allow any container to be configured for multi-language use regardless. Then for each document or object even, specify its language, just like you currently specify the content-type. That language can then be reflected in the documents icon.

Optionally, if the container is a multi-language container then register the document with the container as the index document for that language.

With multiple languages, one document should be marked as the original. This document could then be used as a fallback if no suitable language is found. It would also allow marking other languages as up-to-date or not, as those should be newer.

Next, we need to decide if there should only be one document per language allowed, or multiple ones. The later might simplify some things, but complicate others, such as a translation interface which would need to differentiate which documents in each language are related. This question relates to the more general question of handling multi-part documents. A multi-part document would be a container with multiple documents inside which make up various parts, such as header, footer, sections, pictures, etc...

A multi-part document could be edited with all parts open in a separate text area at once, or all parts displayed and each to be made editable with a click. A multi-language document would show the original on top and all other languages below either with tabs or with an accordeon style interface opening one language at a time.

But how would we handle a multi-part and multi-language document? If the multiple parts are arranged from top to bottom, languages can be placed side-by-side perhaps? Put the original language on the left and select the target language on the right. In the inventory documents would be ordered by their appearance for each language.

How to implement all this?

  • Ignore the multilanguage_languages attribute and always allow a container to be configured as multi-language container.
  • Register a language attribute for the Document or even the Object class. (update: there already exists a OBJ_LANGUAGE attribute that appears suitable, it defaults to the language of the user)
  • Add a field to set the language in the object details.
  • Create an interface to edit a multi-language document. Given the above consideration this should probably be side-by-side even if it is only one document. This would also help in case the document is very long as you would be able to scroll and keep the translation always in view with the original.
  • In the admin view a multi-language container should have a direct edit-link to not require entering the container for editing.
  • When displaying a container with multiple articles, check if any containers inside are multi-language containers, and pick the appropriate content. Actually this can likely be done already in the xml generation stage, so that the xsl template does not need to deal with the multiple languages at all.
    • This can probably be done with a get_content() like function that calls get_content() on the appropriate language. For a multi-part document, this would have to concatenate the parts.
    • Ideally, a multi-language container would be able to look like a document in the xml structure. Can we do that? (update: if there is only one object per language we can probably handle this in get_public_inventory() by just returning the appropriate document instead of a container.
  • For a log, order the articles by container-creation time
Author : mbaehr   |   size : 5143Bytes   |   Publish Date : May/13/12/14:44   |   to Top