Hi Richard,
Could this be http://jira.magnolia-cms.com/browse/MGNLEE-200 ? (I haven't
checked the details myself...)
-g
On 06 May 2011, at 19:41, Unger, Richard wrote:
> 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:
>
> <image001.jpg>
>
> 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]>
> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
