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]> ----------------------------------------------------------------
