[MAGNOLIA-2124] I18nContentSupport for dialogs Created: 24/Apr/08  Updated: 10/Sep/10  Resolved: 10/Sep/10

Status: Closed
Project: Magnolia
Component/s: gui
Affects Version/s: 3.6
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Stojan Peshov Assignee: Philipp Bärfuss
Resolution: Outdated Votes: 2
Labels: i18n, toreview
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Irrelevant


Attachments: Text File i18n.patch     Text File i18supportForDialogs.patch    
Issue Links:
relation
is related to MAGNOLIA-1431 i18n: basic content support Closed
supersession
is superseded by MAGNOLIA-3062 i18n: support multiple languages in e... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

In MAGNOLIA-1431 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.
Therefore, we've modified the initialization of dialogs in order to have one dialog for all languages.
The solution works like this:
When a page is displayed i18nContentSupportFilter sets the current locale and 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_[locale]".
The rest of the job remains to the Save handler which creates the localized content (nodeDatas).
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.

For this functionality we modified the following:

  • DialogControlImpl.initializeConfig
  • I18nContentSupportFilter
  • DefaultI18nContentSupport
  • I18nContentSupport
    All of the classes have minor changes, that don't affect other functionalities.

We attached the patch and hope that you'll like it.

p.s. we also have created a language chooser (changer) tag that successfully implements the suggested solution



 Comments   
Comment by Philipp Bracher [ 25/Apr/08 ]

I changed the fix version to 3.6 in the hope that we can apply the patch.

Many thanks!

Comment by Magnolia International [ 27/Jun/08 ]

Please check MAGNOLIA-2097 as I see changes in this patch which might be related, thanks !

Comment by Philippe Marschall [ 04/Jul/08 ]

Sorry but this does not sound very useful. There are always properties which you don't want to translate. Examples include:

  • activation date
  • deactivation date
  • images
  • links
    Second it would be easier if you could change the language in the dialog instead of the page.

I hope there will be a way to disable this and switch to the old behavior.

Comment by Stojan Peshov [ 04/Jul/08 ]

That is very subjective idea.

  • Why wouldn't I want to have localized activation dates? Wouldn't that mean that my language2 version activates separately from the language1 version?
  • Don't tell me that you haven't struggled with localized images yet. Greatest example would be (language) country flag.
  • Not to mention localized flash or animated gifs, banners (very common in advertising). And you can always use DMS if you want to reuse the same image.
  • I even have use-case for the links: I want to link to a site which has two languages just as I do.

Maybe it's easier to change the language in the dialog, but what happens when you have 10+ languages?
You will copy your dialog tabs 10+ times multiplied by the number of the dialogs, instead of having just one dialog.
We can also achieve to change the language in the dialog by adding a combo with the languages above the tabs in order not to change the language and then edit the content.

And I think the best feature of all is that if you leave some nodeData field empty in the secondary language, the page will always use the primary (fallback) language field. This is also an answer to your images, links, dates problem.

We already have implemented this concept on a live web site (jug.mk) and works just fine.
I'm willing to contribute more on this issue, but I still wait for a positive answer from the Magnolians.

Regards

Comment by Philippe Marschall [ 04/Jul/08 ]

I didn't say there are cases where you want everything to be "translated". What I'm saying is there are cases when i don't want everything to be translated. With the state of affairs in Magnolia 3.5 I can do that. With our proposal I can't do that.

Comment by Vasko Gjurovski [ 04/Jul/08 ]

Hi Philippe,

If you do not want translate something, you do not have to translate
it at all. As Stojan said before, if you leave a field empty in the
secondary language it will receive the value from the primary
(fllaback). So if you do not want to translate it you simply don't do
it!

However, there is a small problem with the different number of
paragraphs in the different language pages. For example, if you have 2
laguages (en and de, en as fallback) and you have 2 paragraphs in the
en page, and only one in the de page. The "extra" paragraph from the
en page will appear in the de page in english (just to be clear, it is
the same page, although I speak of en and de page). However, it is not
the opposite case. If the de page has 2 paragraphs and the en page has
1 paragraphs, the "extra" paragraph will not appear in the en page. I
guess this can be fixed some how programmaticly, so I wouldn't be
worried much about it.

As every idea, perhaps it needs a little more development and testing,
but I think that this is a good idea and should be a part of Magnolia.
If you do not agree it's ok, but I still haven't seen a better one
from anybody. It's easy, does not have extra config nodes, and it does
not affect any of the other magnolia functionalities.

Regards..
Vasko

Comment by Philippe Marschall [ 04/Jul/08 ]

I haven't looked at in detail but as far as I understand time based activation is not i18n aware. A whole node is activated and not simply some of its properties. Excuse we if I'm wrong here.

So what will happen is the user can set different activation dates for different languages simply because he can. Then he'll find out that it doesn't work.

Comment by Stojan Peshov [ 07/Jul/08 ]

Hmm, you are absolutely right. As long as activation isn't i18n aware, my point is worthless.

I haven't seen the activation workflow in details, but i assume that it can be easily adjusted to activate only the current language.
That is, of 'course only the solution for those using the workflow module. For all the rest, simple exchange can be modified.

I've been thinking lately about other workaround. A simple (i18nIgnore) property added in the dialog in config could give us the ability to exclude some of the fields from i18n saving mechanism. There should be minor modifications in Save class for this functionality.

Comment by Philippe Marschall [ 07/Jul/08 ]

Yes an additional property to disable it for a given node would invalidate all my objections.

Comment by Philipp Bracher [ 08/Jul/08 ]

Some days ago I quickly locked at the patch and then finally resisted to apply it. A share the concerns of Philipp Marschall. I also thought on introducing a flag (controls, or tab level). The dialog would then add the additional controls for i18n controls/tabs (same result as you have now but less copy pasting, easy adding of new language).

For the most users it is important to have the original message in the same dialog in which they translate. May I invite you to start a concept page here: http://wiki.magnolia.info/display/DEV/Concept+i18n+next+steps

Note about activation: I consider it best to separate the i18n content from the real content. So that per language activation should be trivial. The i18n support was original designed in that perspective. The nodedata is not necesserely stored under the same node. Actually not even in the same workspace.

Comment by Magnolia International [ 10/Jul/08 ]

pushing to next version - needs more discussion

Comment by Vasko Gjurovski [ 22/Jul/08 ]

Ok, it looks like there is a need to separate the nodes that can be localized and those that don't. So why don't do it? Just separate the nodes in to two types (config nodes and content nodes, or any other terminology that suites better)? I haven't looked at the code but I believe that it is not more than just a method isNodeContentNode() that can be configurable in the admin central (like the node type and name are configured). It would be by default false. This way we can make difference between the conifg nodes (those that do not need to be localized) and content nodes (those that can be localized).

Comment by Vasko Gjurovski [ 02/Oct/08 ]

Updated version of the patch for Magnolia 3.6.1, due to core changes in the i18n classes

Comment by Vasko Gjurovski [ 05/Oct/08 ]

I just managed to read through all of Genuine Overvie (it is loong ), and as managed to see there an important feature in i18n concept is to be able to provide a view of two languages at the same time, in order to make it more accessible for translators. Well, as Stojan and Philipp said somwere above, a nice tab level view of the language would be enough. For example a combo for the languages at the top of the dialog? It is not quite the feature you were asking in http://wiki.magnolia.info/display/DEV/Genuine+Overview, but a simple keyboard switching (since it is planed to be supported in the next editions for Admin Central) such as Ctrl+L would be switching between the fallback language and the curent language (the language that needs to be translated).

Generated at Mon Feb 12 03:33:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.