/
Proposal for Multi-Lingual Content

Proposal for Multi-Lingual Content

Owned by Geoff Bowers
Last updated: Oct 09, 2011Version comment

Overview

At the moment FarCry provides an option for multi-lingual websites to develop separate branches of content within the same site, each branch containing content based on a different language.

FarCry could be customised to manage multilingual content at the individual content item level. This could be achieved with the following approach:

  • entail using a single tree of content in a primary language to determine the information hierarchy of the site
  • manage multiple translations of each navigation folder for menuing systems
  • manage multiple translations of the same content item; a primary content item translation will be used to position the content in the site tree
  • dynamically determine the visitors required language and render the relevant translation (defaulting to the primary language if a translation is not available)

Technical Approach

This technical approach eliminates the need to make major modifications to the core FarCry libraries, instead leveraging the ability to extend core content types functionality. However, it does require the use of features only available in FarCry v3.0 namely extended array properties.

develop an approach to flagging visitor locale

Web visitors will need to have their locale determined before an appropriate translation can be rendered. This might be set and stored in a cookie after an initial determination (preferred), passed on the URL as a parameter or set in the session scope.

Extending dmNavigation

Add aTranslations array property with the following extended property fields:

  • locale
  • label

FarCry 3.0 introduces a new feature for COAPI array properties that allows data in addition to the standard object references to be stored. An array property could be used to store an array of navigation label translations.

The Navigation overview handler will need to be updated to allow contributors to edit and add relevant translations for the label.

Extending dmHTML, dmNews, dmEvents etc

Add the following content proerties to primary content types:

translationID
A UUID reference to the objectid of the primary translation object instance of the same content type.

locale
A string identifying the locale (and translation) of a specific content item.

The FarCry presentation layer will determine the primary language content item by its location in the tree or directly by objectid. If an alternative translation is required, a query to look up a content instance matching the relevant locale and translationID will return the relevant translation and use that object instance for display invocation instead.

Its envisioned that this will work in a similar fashion to the way versioning currently works for dmHTML objects, with a versionID in the draft object providing a reference to the objectid of the live object.

Each content type overview display will need to be updated to allow contributors to edit multiple translation instances and/or create new translations as required.

Additional Issues

Additional development work will be required in the presentation layer as several "webskin" tags will need to be modified or rebuilt to accommodate to dynamically "lookup" the relevant translation based on the visitors locale.

We'll need to make sure that versioning of multi-lingual content continues to work. This will require several modifications to the versioning codeā€”but minor enough to accommodate in a farcry_core enhancement.

Reporting will not accurately reflect website activity across multiple languages without modification. Statistical information is recorded by objectid so it would be hard to calculate hits to the same content position aggregating hits to all the relevant translations. Reports based on tree location will only work for the primary language object without modification.

Security assumes that if a contributor is allowed to edit an object that they can edit any translation for that object. However, I'm sure additional permissions could be added to restrict certain roles to certain translations.

Verity search collections would need to be modified to create an independent collection for each locale.

Random Notes

Paul H added a comment - 25/Aug/05 10:20 AM

  • determine locale, you can use the geoLocator for that but you MUST have a manual way for the user to swap locales. i think session storage is safer than cookies.
  • "The Navigation overview handler will need to be updated to allow
    contributors to edit and add relevant translations for the label." "Each content type overview display will need to be updated to allow contributors to edit multiple translation instances and/or create new translations as required." it seems you're proposing that farcry handle rb (or whatever) management. that's a lot of work for something that's already built into existing products.
  • for verity, why not just use it's new unicode bits. pre-cf7, you're not going to get a lot of locales anyway.

Geoff Bowers added a comment - 08/Jun/06 9:42 PM

  • "The Navigation overview handler will need to be updated to allow
    contributors to edit and add relevant translations for the label." "Each content type overview display will need to be updated to allow contributors to edit multiple translation instances and/or create new translations as required." it seems you're proposing that farcry handle rb (or whatever) management. that's a lot of work for something that's already built into existing products.

FarCry navigation elements are typically built from the navigation folders in the tree. This allows contributors to change the navigation and information hierarchy at will.

  • for verity, why not just use it's new unicode bits. pre-cf7, you're not going to get a lot of locales anyway.

My only thought was to allow for a locale specific search. But heh I don't know enough about Verity i18n to be sure if you can index and search different locales on a single collection.