Hi Will I didn't want to say 'because it was always like it is now'. But Java has some well-defined patterns, also regarding the i18n stuff, which should /probably/ apply (ie. how you want to handle localized texts from properties, totally different again?).
Anyway, for me maybe it is most natural to resolve language specific values, as it follows a general pattern which is globally accepted. To switch the default-language, the localization just has to be removed from the base-name. The 'Convention over configuration'-pattern maybe also plays into this problem. I don't see many cases for changing the fallback language quite often, yet. And I don't believe it would be a big challenge to achieve as it is now. Just my opinion I couldn't keep to myself, thought. I was working in i18n-issues some big-times in the past years. Kind regards Marco -- 15 Years of Excellence - http://netcetera.com Marco Glur | [email protected] T +41 44 247 79 20 Netcetera AG | 8040 Zurich | Switzerland | http://netcetera.com >-----Original Message----- >From: [email protected] [mailto:user-list- >[email protected]] On Behalf Of Will Scheidegger >Sent: Montag, 3. Oktober 2011 13:41 >To: Magnolia User-List >Subject: Re: AW: [magnolia-user] Troubles with i18n node wrapper > > >Hi Marco > >Sorry, but I'm not convinced by your arguments > >- "It should be done that way because it always has" is not very helpful when >there is a problem. >- Renaming attributes twice... hmm... I don't know about that. Sounds like a >big hassle to me. And I'm quite sure that some attributes would be missed. >- And I've never encountered the situation where multi-language was >_removed_ from a site. > >The only argument that _does_ make sense is that this allows he developers >to add a second language later and things would still work. But that would also >be the case when you would check for the [attributename]_[languagename] >nodedata first and only fall back to the [attributename] nodedata when the >other one does not exist. > >-will > >On 03.10.2011, at 13:17, Marco Glur wrote: > >> >> In my opinion it should be transparent for i18n support to work >> according the well-known java message-resources pattern (no suffix in >> name=fallback) and most stable, of course, respecting existing code. >> >> Maybe valid migration path could be to >> a) rename all existing 'base' values that are i18n with the suffix >> according to the old fallback language >> b) then rename all suffixed from the new fallback language to have no >> suffix >> >> The default behavior is anyways not to have Multilanguage, so no need >> to reference a certain language in the node-data names with a suffix. >> The decision which is the fallback/default locale should instead be >> taken at the most early point of setting up a new CMS. >> >> Another obstacle having a default-suffixing always would be: >> How should it work still, when once you remove Multilanguage support >> for a site completely, need to migrate the node-datas manually, then? >> >> I wouldn't see any change of concept here in future. >> >> Kind regards >> >> Marco >> >> -- >> 15 Years of Excellence - http://netcetera.com >> >> Marco Glur | [email protected] >> T +41 44 247 79 20 >> Netcetera AG | 8040 Zurich | Switzerland | http://netcetera.com >> >> >> >> ---------------------------------------------------------------- >> For list details see >> http://www.magnolia-cms.com/community/mailing-lists.html >> To unsubscribe, E-mail to: <[email protected]> >> ---------------------------------------------------------------- >> > > > >---------------------------------------------------------------- >For list details see >http://www.magnolia-cms.com/community/mailing-lists.html >To unsubscribe, E-mail to: <[email protected]> >---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
