Have we reached something in multi-language contents?

I understand your concern, many share it (me included) and that’s only normal. One thing you can assume is that snippet, modules and plugins will work with the new branch. That might require adaptation (can’t vouch for backward compatibility) but full rewrite I doubt it.

Now, about the multi-lingual part of it, I think being able to take advantage of the new system will indeed require to rebuild the alternative languages content of our websites.

I’ll let Jason answer this in more detail (or contradict any stuff which is not correct in what I am saying).

Quote from: madmage at Jul 11, 2006, 04:13 PM

The only fear is that I will have to rewrite a lot of things or put in the trash a lot of work I’m doing on my websites just because I do not know where MODx is going... i.e. is the way I’m keeping multi-language content pages of my site easily portable to 1.0/Tattoo? or I have to rewrite everything from scratch? The snippets, the modules and so on need to be rewritten?

Certainly a valid concern madmage considering it is a rewrite from scratch, but I’m going to do everything I can to make it as painless as possible. That said, since the majority of the changes to the architecture for 1.0/Tattoo are in the data structures supporting the CMS core, the main issue of compatability will be in places where developers have modified a core data table or written a SQL query directly against a core data table. I don’t see anyway of avoiding such conflicts, but I also have a plan to assist users with existing data/add-on migration that includes:

[*] A set of backward compatibility add-ons that should allow most legacy MODx content and add-ons to execute as is, though this certainly will not be 100% effective. I expect 2/3 to 3/4 of existing content/code to work this way.
[*] A set of 1.0/Tattoo migration guides, most likely divided into individual developer and designer guides. This will introduce the new object-oriented API, the new, simplified template tag formats, and even explain best practices for converting legacy MODx content and/or code.
[*] A data migration tool that will allow you to map existing data structures (including data structures users may have hacked, say to add multi-lingual content) to the new object model, and import it with a minimum of effort.

These things may take second priority to actually completing a working preview of 1.0/Tattoo, but they have been part of my vision since the beginning and the new core is architected with this in mind.

So, yes, you will probably have to do some work to migrate successfully from your modified MODx 0.9.x to 1.0/Tattoo, but I think when you recognize the benefits of the new architecture, you’ll be able to justify the additional effort.

Hopefully, the new code will make existing developers excited to migrate anyway. Well, I can hope...

Can you provide some infos concerning the changes which are underway?
Might reduce stress and efforts, if we know in advance of things to be aware of when migrating!
A new thread in the core-forum might be the appropriate place for that.

thanks & best regards!

ppaul, there will be lots of info include percent of work that’s been completed in the very near future. There is some very exciting work being completed as we speak in fact.

Ryan and Jason,

Thanks for the updates. I am very excited to see the roadmap (and the build) you are working on.

Thanks again,
Chuck

Just to add my 0.02c here - I think the direction being taken for 118n/L10n is fantastic. The granular approach towards cultures is one that seems to be ignored by most multilingual solutions - exciting stuff.
Thumbs up too for the database abstraction layer. All good stuff.

Now, I would just like to add a word of warning that I know will not go down well with people who have been ModX converts for some time. Please do not make the mistake so many other OS CMS/frameworks have made with trying to make everything backward compatible. Some I can think of, have got so locked into backwards compatibility and the restrictions placed on them by legacy code that forward development has been seriously hampered. When a major refactoring takes place, it seems advisable to bite the bullet and move forward. Sure, this leaves other developers having to catch up and it can lead to more complicated migration BUT the disadvantage of this can often be far outweighed by the advantages.

ModX has a hugely exciting future and I would not like to see the reins pulled in over backwards compatibility.
Easy for me to say, I know - I am waiting patiently for 1.0 and am only playing until then I have, however, been involved in OS and with CMS for the best part of a decade and have seen just too many lose traction over backward compatibility concerns.

Good point. I believe the only concern should be to ensure that content is upgradable to whatever form 1.0 takes.

The way I read OpenGeek’s post is that backward compatabilty with 0.9.x will be an add-on - so most 1.0 users won’t need that burden.

Also, and I may be wrong, but my understanding is that MODx maintains compatibility with PHP 4 (but will work smoother on PHP 5) but one of the distinctions of Tattoo will be that it drops even that.

So yes, you won’t have to be held back by backwards compatability of any form.

I totally agree with the backward-compatability issues. Though, it doesn’t look like MODx will suffer this since it is being a total rewrite in preparation for 1.0. Just an example I’ve been thinking bout is Windows vs. Mac.

It seems every few years Apple changes its architecture and provides hooks for BC (Classic -> OSX -> Universal Binary). And I would say OSX handles sooo much better than my other machine.

Have I told you I am excited about MODx?

Chuck