Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 111 rates

Implemented in 4.3

For more information see blog posts: Authoring support and implementation/video

Official Documentation Available

This topic is now covered in i18n and l10n.

1. Concept

In MAGNOLIA-1431@jira it is stated that we should make copies of dialog controls (or even locale tabs) with locale extensions if we want to have i18n aware dialog. This solution leads as to many copies (tabs) if we want to cover many languages.

So the idea of the concept is the following:

  • modify the initialization of dialogs in order to have one dialog for all languages
  • when a page is displayed i18ncontentsupportfilter sets the current locale
  • when a dialog is opened all the control's names are suffixed with the locale (if the locale is different than the fallback locale) ex. a dialog with edit control named "text" will become "text_".
  • the rest of the job remains to the Save handler which creates the localized content (nodeDatas).

2. Advantages

  1. If you edit the dialog then the content of the current language is filled in the controls. This way we have only one dialog and unlimited number of languages, without the need of creating additional tabs (or controls). Note: This way there is no possibility to edit more than one language at once.
  2. Localized page resources, such as images, documents...
  3. simple implementation (only the following classes have minor changes: DialogControlImpl.initializeConfig, I18nContentSupportFilter, DefaultI18nContentSupport, I18nContentSupport)
  4. simple usage (one dialog for all languages)
  5. if the secondary language (or any other language except fallback) paragraph is not translated, the content in it is replaced from the fallback language (useful for finding untranslated pages). This also could be a problem (see 3 bellow)!

3. Problems

  1. Content that should not be translated (ex. activation dates,...) - the problem here is that the workflow and activation are not i18n aware.
  2. All content MUST be first created in the fallback language (that is if you need it in all languages)
  3. Different number of paragraphs in different languages. If do not want to translate some content it should not appear in the other language. This works from secondary to fallback (ex. you have german text that do not want to have english, just create the paragraph in the german language), but not in the opposite direction (if you have english as fallback and only want content only on english not in german, you cant!)

4. Solutions to problems

These are only ideas:

  1. Change the definition of dataNode - add property isNodeContentNode() or isNodeTranslatable() that would be false by default
  2. well, not sure if this is a problem, but it is correlated with 3. So generally lacking the concept of translate or not translate something. So a check box would do the work?
  3. the solution for 2 will probably work here too..

5. Conclusion

TODO

  • No labels

3 Comments

  1. Some needs:

    • textual content will sometimes be have to be extracted and sent to external translators and then reinserted into the system
    • potentially, publishing has to be deferred until the translations are back in the system
    • changes need to be translatable as well. Assume you have a site with 30 languages (we have such a need now), and you change a sentence in a text block, it has to be fully automatic what happens next (the difference has to be detected and sent to the translators, potentially with a link to the context of the changed sentence).
    • I strongly suggest to research existing solutions to learn from them
    1. Boris,

      I believe what you are referring here is a translation system, not a simple I18n support. I think you should separate these two concepts. The text above is a concept of a simple I18n support, ex. translate the texts on the page, separate localized images, localized page labels etc... I do not underestimate the need for a translation system (which would cover a lot of customers (wink) ), but, to be honest, Magnolia is lacking a simple I18n support, and there where the focus should be at the moment. This is web content, it should be informative content, not reading the bible (smile) .

      However, to be polite.. (smile) ..and give you hints on your questions:

      •  for this you should have some kind of a extraction tool that would export the content, send it to the translator, he should load it into some kind of a translation system that will recognize the format of the exported file, translate the text (what about documents and images?), and reverse the process back to the magnolia instance. The problem here is the format of the document. Translators work on diferent tools (trust me I know, I had a translation project a while ago) which format whould the export go?
      • The best concept for translations I have seen is the Pootle project, regarding translation of Linux applications. The concepts there should be checked out, if you plan a whole translation system.

      And at the end, to finalize, in order to translate the content, you should be able to enter it! Magnolia does not have a way to enter simple localized content.

       Regards, Vasko

  2. From the Backlog

    'Feature: Enhanced Language Editing, for the Power User and Translator' http://jira.magnolia-cms.com/browse/BACKLOG-5