Have we reached something in multi-language contents?

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?

Quote from: madmage at Jul 08, 2006, 11:03 AM

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.

Waow Jason I just love the concept !

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

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!

Quote from: OpenGeek at Jul 08, 2006, 08:11 PM

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

Quote from: OpenGeek at Jul 08, 2006, 08:11 PM

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

Quote from: ppaul at Jul 08, 2006, 10:50 PM

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

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

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

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

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?