Your Rating: |
![]() ![]() ![]() ![]() ![]() |
Results: |
![]() ![]() ![]() ![]() ![]() |
113 | 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
- 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.
- Localized page resources, such as images, documents...
- simple implementation (only the following classes have minor changes: DialogControlImpl.initializeConfig, I18nContentSupportFilter, DefaultI18nContentSupport, I18nContentSupport)
- simple usage (one dialog for all languages)
- 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
- Content that should not be translated (ex. activation dates,...) - the problem here is that the workflow and activation are not i18n aware.
- All content MUST be first created in the fallback language (that is if you need it in all languages)
- 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:
- Change the definition of dataNode - add property isNodeContentNode() or isNodeTranslatable() that would be false by default
- 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?
- the solution for 2 will probably work here too..
5. Conclusion
TODO
Overview
Content Tools
Apps
Activity
3 Comments
Boris Kraft
Some needs:
Vasko Gjurovski
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
), 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
.
However, to be polite..
..and give you hints on your questions:
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
Christian Hauser
From the Backlog
'Feature: Enhanced Language Editing, for the Power User and Translator' http://jira.magnolia-cms.com/browse/BACKLOG-5