Hello magnolians! To answer my own question from before: This seems to be a BUG, at least in Magnolia EE v4.4.2.
To understand the following, see my code excerpts at the end of this email.
What is happening is the following:
1. info.magnolia.cms.gui.i18n.DefaultI18nAuthoringSupport is responsible
for the i18n in Dialogs, see method i18nIze() of this class.
2. In line 04, the method retrieves the fallbackLocale from the
i18nContentSupport object, a final field of the class
DefaultI18nAuthoringSupport which is initialized in the constructor.
3. In lines 13-16, the suffix is only appended to the property name, if
the dialog's locale is different from the fallback locale.
4. In Magnolia EE, each site can have a different i18n configuration
(each site has its own i18nContentSupport object associated with it).
5. However, the i18nContentSupport object is only initialized in the
constructor, and is final after that. Also, DefaultI18nAuthoringSupport itself
is only initialized once, close to server startup (on first page request?).
Therefore, when the dialog is rendered, the i18nContentSupport object used is
NOT THE CORRECT ONE FOR THE WEBSITE in which the edit is performed.
I verified this by subclassing DefaultI18nAuthoringSupport, overriding
i18nIze() and outputting the values of fallbackLocale and locale.
It is the case that despite my site having fallbackLocale "de", the
fallbackLocale output by i18nIze is "en". I assume at initialization time,
DefaultI18nAuthoringSupport is grabbing a default configuration, rather than
the one for my site definition.
Since the "demo-project" uses fallbackLocale "en", which is also the default,
everything works fine for "demo-project" i18n.
In sites which use a different fallbackLocale, you will see an error.
Personally, I think it is a very bad idea to store some content in nodes with
suffixes, and some without. It certainly means you can't change your i18n
configuration once you have content! Personally, I think it would be much
better to remove the check for defaultLocale (line 13, below), as far as I can
see this would make everything work correctly.
However, if it is really desired to store the fallbackLocale without suffix,
then i18nIze needs to check the site's i18n configuration, and not use a
default initialized at startup. That works for CE, but not in EE with
multi-site.
Retrieving the correct i18n configuration probably can't be done in the normal
way, (see ETKI18nContentSupport.getI18nSupport() ), since this depends on the
aggregation state, which (I assume) will not be set up right when the request
is to the edit-dialog rather than rendering content. Probably a new method is
required which gets the i18n configuration of the site to which the node being
edited belongs.
But I do really think it would be much better NOT to remove the suffix for the
fallbackLocale.
Please let me know if this issue is already addressed in 4.4.3. If not, I will
open a bug in JIRA.
Regards from Vienna,
Richard
This is the method i18nIze:
01 public void i18nIze(Dialog dialog) {
02 // TODO: should this be set in the aggregation state?
03 Locale locale = LocaleUtils.toLocale(dialog.getConfigValue("locale",
null));
04 boolean isFallbackLanguage =
i18nContentSupport.getFallbackLocale().equals(locale);
05
06 if (isEnabled() && i18nContentSupport.isEnabled() && locale != null )
{
07 List<DialogControlImpl> tabs = dialog.getSubs();
08 for (DialogControlImpl tab : tabs) {
09 List<DialogControlImpl> controls = tab.getSubs();
10 for (DialogControlImpl control : controls) {
11 boolean i18n =
BooleanUtil.toBoolean(control.getConfigValue("i18n"), false);
12 if (i18n) {
13 if(!isFallbackLanguage){
14 String newName = control.getName() + "_" +
locale.toString();
15 control.setName(newName);
16 }
17 String translatedLabel =
control.getMessage(control.getLabel());
18 control.setLabel(translatedLabel + " (" +
locale.toString() + ")");
19 }
20 }
21 }
22 }
23 }
Von: [email protected] [mailto:[email protected]]
Im Auftrag von Unger, Richard
Gesendet: Freitag, 06. Mai 2011 17:58
An: Magnolia User-List ([email protected])
Betreff: [magnolia-user] i18n Problems
Hi Magnolians!
I'm having some bizarre problems with i18n, I can't figure it out :-( . We're
using Magnolia 4.4.2.
We have a site configured for multi-language as follows:
[cid:[email protected]]
AFAIK, this is a "correct" i18n configuration.
Needless to say, all relevant controls have their i18n=true set in the dialog
configuration.
Now if I want to edit the content using the dialogs, I can edit the german
version just fine. The german content is stored in nodes "articleTitle_de" and
"articleText_de" (for example). The german content is then displayed correctly.
Now if I switch to English, and edit the English content, I get a "blank"
dialog - all form fields are empty, or with their default values. If I enter
content into the dialog, it is then saved under nodes "articleTitle" and
"articleText" (note: no "_en" suffix)!!
When the page renders, the German (fallback) content is displayed, presumably
because there are no nodes "articleTitle_en" and "articleText_en".
When I edit the English content again, I see the values I entered before (the
ones saved under "articleTitle" (no "_en").
If I add a third language to the configuration, french for example, it works as
expected (as for german).
If I create the English content in the JCR Browser, I can switch between the
English and the German versions of the site, content is rendered in the correct
language.
If I output ${model.site.i18n.locale.language} and
${model.site.i18n.fallbackLocale.language} in the template, everything looks
correct.
If I examine the edit-dialog in firebug, the hidden fields (mgnlSaveInfo) are
indeed pointing to the wrong property names when editing English (no suffix).
In demo-project, i18n is working correctly.
For the life of me, I cannot see the difference between my setup and that of
"demo-project", other than the fact that my default and fallback language is
"de", while demo-project is "en". But even if I change my default and fallback
to "en", the behavior is unchanged.
Is this a known issue?
Have I missed some critical configuration?
Thanks a lot for any advice,
Regards from Vienna,
Richard
________________________________
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to:
<[email protected]<mailto:[email protected]>>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
<<inline: image001.jpg>>
