Have we reached something in multi-language contents?

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[madmage]

Hi everyone!
I've been very busy so far, but now here I am again :-)

What has it happened since my last visit? How are we about multi-language contents? Is it there any project, or any decided direction for this?

[OpenGeek]

Hi everyone!
I've been very busy so far, but now here I am again :-)

What has it happened since my last visit? How are we about multi-language contents? Is it there any project, or any decided direction for this?

Howdy, I believe there is a plugin/snippet combination authored by sottwell here that many are using in the meantime while I am diligently working to complete the new MODx core, which will provide at least 3 new facilities for localization/internationalization).

First, it will provide the ability to define culture-specific content for any content element (i.e. template, chunk, snippet, plugin, TV, page content, pagetitle, longtitle, and even custom-defined page metadata), and manage detailed culture settings by user preference/user session/site context/site.  One of the keys here is the concept of culture itself, which provides the ability to be more granular with your multi-lingual content, by defining multiple cultures that might use the same language, but with different default date format settings or different currency format settings, etc.  All of this is part of the new approach to localization that we are developing.  This cultural content revisioning is part of a more general content revisioning facility in the new core, which will allow for easy revisioning and rollback of any content in the system.

In addition, there are efforts for internationalization as well; this will most likely take the form of something I refer to as a Lexicon, that will start out as a simple multi-lingual dictionary, and could easily evolve into a more advanced linguistics service that could organize vocabulary by certain principles or even provide generation facilities for contructing new words or word variations following a set of syntactical rules.

Finally, by utilizing the custom metadata and improved access control facilities of the new core, along with the Lexicon, it will be possible to easily create custom publishing workflow with translation tasks, so anytime new content is introduced, it can be easily and instantly accessible to the responsible content editors, so they can provide proper cultural-specific translations.

In summary, lots of new features and flexibility are coming in this regard that will give you a wide-array of choices in organizing a simple or complex multi-lingual site.  The new MODx 1.0 roadmap, which includes this information is being finalized and will be published in it's entirety in the next couple of weeks.  Let me know if you have any questions or concerns in this regard.

[davidm]

Waow Jason I just love the concept !

This was a nice read
I am quite eager to read the roadmap !!!

[ppaulousek]

First, it will provide the ability to define culture-specific content for any content element (i.e. template, chunk, snippet, plugin, TV, page content, pagetitle, longtitle, and even custom-defined page metadata), and manage detailed culture settings by user preference/user session/site context/site.

@jason: Sounds great (from a marketing point of view), but from a user's/developer's point of view I fear it might get MODx to be one of those tools you have to visit a virtual "tool university" to get able to use them effectively.
Maybe I underestimate the genius of the development-team, but, please, don't let MODx become as unusable as Drupal or make it more difficult than to develop  homebrew, project-focused solutions!
Meanwhile I think the main competition MODx might get in is not J! or other foolish stuff, but plain individual PHP5/MySQL or RoR development. If it gets more time-consuming or challenging to understand how a specific framework handles an issue than to develop an individual solution from scratch - all will be lost!
And, beside of this general remark, I relate that argument to MODx: I found it extremely difficult to tackle all that MODx-manager stuff. Incredibly complicated! This awkward mixture of http/$_POST, Javascript, SQL, $modx->"dunnowhat", and other conventions concerning "opcodes" and the like...
When thinking of the reasons I found MODx interesting in the first place, I really have to ask myself: Is it worth the effort to explore a foreign world just to master my own? This is a metaphor, of course, but I think you'll get the point.

Simplicity is one of the main advantages of MODx! Do not loose it!

[madmage]

Howdy, I believe there is a plugin/snippet combination authored by sottwell here that many are using in the meantime while I am diligently working to complete the new MODx core, which will provide at least 3 new facilities for localization/internationalization).

HHmm, yes I knew that! I myself developed an integrated solution in the manager to deal with multilingual content... it has been forgot, it seems...

...snip...

It sound great for me... but I agree with the guy that says that we need semplicity and easy-to-use stuff... maybe instead of talking about cultures and new visions of the i18n or l10n, we should work on documentation and clean all that modx->stuff, $_POST, etc.

That's not a criticism... it's just my view...

In my opinion, susan's solution is ok, maybe we only need something to treat it less as a hack...

[OpenGeek]

@jason: Sounds great (from a marketing point of view), but from a user's/developer's point of view I fear it might get MODx to be one of those tools you have to visit a virtual "tool university" to get able to use them effectively.
Maybe I underestimate the genius of the development-team, but, please, don't let MODx become as unusable as Drupal or make it more difficult than to develop  homebrew, project-focused solutions!
Meanwhile I think the main competition MODx might get in is not J! or other foolish stuff, but plain individual PHP5/MySQL or RoR development. If it gets more time-consuming or challenging to understand how a specific framework handles an issue than to develop an individual solution from scratch - all will be lost!
And, beside of this general remark, I relate that argument to MODx: I found it extremely difficult to tackle all that MODx-manager stuff. Incredibly complicated! This awkward mixture of http/$_POST, Javascript, SQL, $modx->"dunnowhat", and other conventions concerning "opcodes" and the like...
When thinking of the reasons I found MODx interesting in the first place, I really have to ask myself: Is it worth the effort to explore a foreign world just to master my own? This is a metaphor, of course, but I think you'll get the point.

Simplicity is one of the main advantages of MODx! Do not loose it!

@ppaul: My goal for the entire 1.0 rewrite is to further simplify the MODx approach to being a CMS framework.  Though the concepts may sound complex from my point of view as a core developer, they are being engineered for the following primary purposes, all of which involve a reduction in complexity both from an end-user perspective, as well as a developer perspective:

1. to reduce the complexity of authoring a page by reducing the different types of content-producing elements to a single, extensible class, as well as reducing the different types of template tags used to represent these elements within MODx content.

2. to reduce redundancy of code seen throughout the manager and front-end, creating a simple, consistent, and robust API that does not need to be duplicated for each variation of functionality a MODx developer/designer might need

3. to make it possible to utilize the MODx API in hand-authored PHP pages; this will also make it very easy to create and/or extend manager functionality without all the complexity inherent in the current MODx manager

4. to isolate SQL code from the MODx API and optimize it to a specific target database platform; the MODx API will essentially be an object-oriented API with a core implementation for MySQL, or PostgreSQL, or MS SQL Server, or any database that can be utilized via the emerging PDO database layer which is the standard extension for DB connectivity in PHP 5.1+; and users will not need to author SQL statements in order to develop add-on's as the API will abstract the use of direct SQL, but without preventing more advanced users from doing so if they want to

5. to introduce additional RAD/prototyping facilities to MODx (via XPDO, the new db layer and ultra-light OR/M framework I've developed to power the new MODx core); similar to RoR's ActiveRecord facilities, but optimized and engineered for maximum performance on PHP 4 and 5

6. to maintain compatibility with PHP 4 while still allowing MODx sites to take full-advantage of PDO and other PHP 5 enhancements/features when available

This is not the roadmap, but a list of motivations for the work I've been doing on this rewrite since December.

@madmage: no one has forgotten your work, it simply is not the final vision I have for implementing localization in the new core.  Again, simplicity and ease-of-use are definitely part of the goal here, along with addressing the organization of the core to allow simple solutions to be easily constructed of pre-fab parts without forcing advanced developers to hack up the core in order to extend those parts.  And in addition to complete API documentation, the consistency of the object-oriented API will make it much easier for users to interact with MODx when developing add-ons.

Now, back to the roadmap... 

[ppaulousek]

Thanks Jason, for this instructive review of your work and goals!
Guess I was too pessimistic: someone who could create a solution as convincing as MODx 0.9 is of course able to improve it without spoiling the main advantages already achieved.
Just had the impression that the roadmap might has become too heavy or overloaded to be realized in a reasonable time or to lead to a result which would be too different from MODx as we all know and love it.

best regards,

ppaul

[madmage]

thanks jason... i think that the main preoccupation of all modx users is that our urge to build our websites using modx fights with the big work you developers have (we see this by looking at the roadmap and at your ideas)...

that's probably a problem without a solution... we need just to wait...

maybe some more teaser trailer and some discussion of the core changes may help... it seems to me that apart from some vague idea, we are not aware of what is happening in the core...

[davidm]

You're right madmage, this is one of the key issues that won't be adressed by the 0.9.x branch (remember that the 1.0 branch is a complete rewrite, thus efforts are not seen short term but should be much more profitable in the long run). We have to manage this with unsatisfying solution (TVs and cookies are nice but not absolutely satisfying I agree).

I think Jason has posted a lot about the next rev, even in public forums. True, it's scattered here and there, we might have to communicate in a more structured way about what's to come. But that's a fine balance, since lots of things are not "locked" right now : while you can communicate about choices that are made, you can't easily communicate publicly about options being examined... This of course is just my take on things, I'll let Jason and the team elaborate about the process.

I think the more we approach the release of a beta for the 1.0/Tattoo branch, the more you'll get information about the future... in the meantime, you'll have to put faith in the choices made by our (great) dev team

[madmage]

Hi David,
I am sure that your dev team is great, I have no doubt (if I had doubt, I should have moved to another CMS!)

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?

[davidm]

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).

[OpenGeek]

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

[ppaulousek]

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!

[rthrash]

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.

[ChuckTrukk]

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