Dashboard > Magnolia Development > ... > Concepts > Concept i18n next steps
Concept i18n next steps Log In View a printable version of the current page.

Added by Philipp Bracher , last edited by Boris Kraft on Nov 13, 2008  (view change) show comment
Labels: 
(None)

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

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
Powered by a free Atlassian Confluence Open Source Project License granted to Magnolia International. Evaluate Confluence today.
Powered by Atlassian Confluence 2.7, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators