Translations

Actors

• UI Translator
• Backend Users
• Content Creator
• Content Translator
• Translation Manager
• Administrator
• Site Visitor

Use Cases

UI Translator
Is able to login to the backend and translate the entire backend interface into different languages - including help text, popups, images, buttons, navigation, editors.
Hooks are provided to enable 3rd party extensions and plugins to be translated.
When an upgrade occurs or a new plugin is added, a diff screen is generated to display the new strings that need to be translated.
Can use a backend search function to quickly identify untranslated strings.
Can work offline and merge changes back in easily.

Backend Users
Backend users are automatically presented with the interface and content in their own language, based on browser settings.
They can select their language/locale of choice from their user management panel.
They can choose to view all backend functionality and content in the source language as well as their own language, using a split window.

Content Creator
New content can be created in any language that the Administrator has set up a virtual directory for, ie. translation is two-way with no "default" language as far as the content creator is concerned.
New content has a parameter where the content creator selects the language/locale of the new content item.

Content Translator
Has permissions to access content for one language or locale, or for many.
Logins into the backend and sees a split screen, with the source language content appearing on one side of the screen and an editing panel for the new translation appearing on the other side of the screen.
Is able to add localised images, or select general images from a central image repository. Localised images are held in their own folder within the image repository.
Content translator has access to an assets list so can easily identify PDF's, videos, and other media that need to be translated. Translated assets are in a subfolder of the assets repository.
Content Translator creates the URL alias and meta description.
Content Translator creates translated menu item alias.
When the content translator has completed their task, the content is marked for review and an notice sent to the Translation Manager.

Translation Manager
The Translation Manager receives notification of content for review and either approves it as complete or adds comments and sends it back to the Content Translator.
Can change the URL alias for the translated content item (page).
Can roll back to previous versions of the translated content.
Can view diffs between versions of the translated content.

Administrator
Administrator creates language/locale space by assigning a virtual directory to a particular locale, eg. example.com/en/, example.com/fr/
Administrator sets default preferred languages based on locale - for example, if content is not yet available in French Canadian the default fallback may be French. If its not available in New Zealand English, the default fallback would be UK English.
Templates have a separate, included file for the header block. The Administrator is able to assign a locale-specific header to each language.
The Administrator is able to switch the CSS that is used in the header (LTR or RTL).
Administrator can see which language/locale translations have been approved as completed by the Translation Manager and which ones are yet to be completed.
(Note: This is very important for some government agencies which are not allowed to publish content until it is available in several different languages).
Administrator sets default content for content that is not yet translated.
Administrator sets flag on content that is not intended to be translated so that this content does not appear in the localised menus.
Administrator can bulk publish each block of translated content.

Site Visitors
Site visitors land on the content for their locale, based on browser settings and/or IP address.
Site visitors can select which language to use and a persistent cookie will remember this.
On pages that have comment forms, the comments made on that page "stick" to the page and are not reproduced across translations.

User Story

In creating a multilingual site with Mambo we ended up creating multiple sites,using subdomains after finding mamblefish was too restrictive.

The difficulties we had were these:
Visitors expected to be able to select between English and Spanish by clicking a button and seeing the same content. This cannot be done currently. Users have to go back to the frontpage and select their language, then navigate from the menu.

We wanted some menu items that were in English to be hidden from the Spanish translation.
We also wanted additional menu items in the Spanish translation that were not to be shown to English language users.

It is not always appropriate to translate every page but the current system expects every page to be translated. We wanted to have some pages in Spanish that were not needed in the English content. Because the site had English as the default language, new content had to be written in English before it could be translated into Spanish. However, content is always about context and we found that a 1 to 1 relationship between the languages was not suitable.

The site structure has to be able to present the right content to the right users and this content is not always the same.

Mamblefish and Nok Kaew do not provide a clear separation between the locales. This means that both users and search engines do not have a clear path to follow when retrieving content. We ended up with English results in the Spanish search engines and Spanish results in the English search engines, which was not good.

We needed the ability to localise the URL's for each language. Currently, this is not possible. With having itemID-based URL's the site was at risk of being penalised for duplicate content. The only way we could produce appropriate URL's for each language was to have two separate sites.