Multi language content

Hi everyone,
I really need to have a multi-language content support for my site, and it seems to me that this is in the roadmap but in the future.
So I decided to implement it by myself. I think there is the need of some change in the core, but first I need to decide how to implement multi-language content.

I read some post in the past, but the use of different documents (different ids) for each language does not seem to me the best choice (though the best until now).

1) What if you do not have a translation for one page?
The right answer is to have a "default" language and see all untranslated pages in the default language (e.g. English)

2) What if one want to switch to another language on a page that is not the home?
The right behavior is to go to THE SAME PAGE translated

So, Susan Ottwell has a great choice, but it can be improved.

I think there is the need to link each page with the corresponding page in all other languages. And also the need to can go directly to the translation of a page during editing phase, without having to look for it on another site-tree.

What do you think?

Hi madmage, I would suggest using TV. I’m working on implementation on this, because of my current clients request, and my target market. I will share my solution as soon as I got this thing done. That will include the modification in .htaccess, TV, snippets, and plugins required to be used.

If you have any other suggestion please feel free to post it in here.

Btw, I’m looking for a way to work with XML files for localization, but still struggling with the caching issue. If sonebody understand the basic model of caching in MODx, please share it with me.

Thanks

Today I wake up with this simple idea. It also has to do with Jason’s
http://modxcms.com/forums/index.php/topic,1657.msg11465.html#msg11465
(i.e. versioning and multi-language content with the same stuff)

We can start from Susan’s implementation and add two (three) fields in the content table: refId and language (and version if we want to do page versioning). In this way, we have a "main" page id, that is the page id that we refer to, that is the page in the "default language" and then another page, with another id (but somewhat hidden to the user) but referring to the main page id, in which the content has been translated (and the field "language" contains something like it_IT, fr_FR, etc.)

We then need to add some code to redirect the browser to the correct id given the language from Susan’s cookie or session or what-you-want.

What do you think about this?

There is some work to do in the manager, because the pages with the same refId has to be somewhat hidden (i.e. do not appear in the document tree, but they should be visible while editing the "main" document) (I will do, if nobody wants to do it )

Wendy, can you share just your idea, before it works, just to understand what you are doing?

And, finally, why do you think that XML is the right choice for the localization? (you are talking about snippets/modules translation, are you?) There has been one discussion in the past, for the choice of a translation db table, .po/gettext files and xml... and it never finished with a solution!

I’m sort of dealing with something similar at the moment.

I really think that for MODx to make it world wide that a stronger multi-language ability is going to be important. Several years back when phpnuke / GeekLog / postnuke were shooting it out several of my friends choose postnuke since it had a pretty decent multi-language ability.

I agree with the default to the "main" language idea (be it English or what not) and would like to throw in that maybe a link to BableFish or other translation service might be a good idea so that not to confuse the end reader.

hmmm, this is rather difficult to really ponder over since each site has it’s own set of rules and pulling things together into one is going to be a bit hard.

Currently I’m working on some code that is multi-lingual but almost all of it is in English (happy for me but S***_out_of_luck for others. Not good for the end user nor for the developers.

I’d love to see MODx be on a vangard leader in this field too.

Many of us hear are bi-lingual in some respects so ... why don’t we come up with some likes/equests/gripes/flat out complaints about systems that we have used in the past and are using in the present. Hopefully then we’d have enough data to actually start to come up with some kind of solutions.

Cheers!!!

:-)

Quote from: madmage at Dec 10, 2005, 02:20 AM

Wendy, can you share just your idea, before it works, just to understand what you are doing?

And, finally, why do you think that XML is the right choice for the localization? (you are talking about snippets/modules translation, are you?) There has been one discussion in the past, for the choice of a translation db table, .po/gettext files and xml... and it never finished with a solution!

To answet those question, I would like to address the use of XML. I use it for Localization, which is different with multi-lingual documents. A bit explanation about localixation, it’s for all the language being shown in the website, which is not part of the document intself, which can be a text and images. The reason why I said XML, actually it’s not the only solution. I would prefer to create some kind of parser, which can be run to fetch the data either from XML< database, or delimited text. No matter what they all will need to be transform into multi dimensional array and able to be catch later on.

SO here is what I’m going to do, I will concentrate my solution on Apache server only. I will append $lang following scotwell solution, and trying to use mod rewrite to rewrite $lang variables into something looks like directory. I will make a snippet to do the localization part, and I will use plugin to setup the right language, and I will use TV to store the document translation and plugin to do the logic. The idea of localization will be based on multi dimensional array, and the idea of plugin will be by the $lang variables on the address, and the idea of documents translation will be based on TV, and the value of TV will overwrite the default TV var, before it’s being parse to the document.

Hope that helps.
I’m currently busy right now, but if you can do it, please do share it in this forum, as I will try to share what I did so far, maybe on monday.

All the best with multilingual website.


Regards,
Wendy Novianto

I’m developing my own idea of multi-language content, taking as hints susan and wendy’s work. Now I need some advice from core-coders, since the documentation for developers is somewhat lacking (:-D), I’m wondering if I should read etomite documentation...

The first simple question is: what makes a document "visible"? For now I use "published AND NOT deleted", is there anything else to take into account?

My solution needs some small changes in the core code (in the manager and a couple of fields in the site_content table)... I am doing myself those changes, very small changes indeed, if you like my solution, may you include those changes in the next versions of MODx? Who I need to contact?

And if you want it to show in a menu, has to be "hidemenu == 0" ( or !$hidemenu) in the database. Only a few menu snippets are programmed to respect that field; DropMenu does.

Where are we on this ?

Madmage, if it does provide the right solution, than it will surely be included in the next release. I’ve seen several API that you need to change for the current document logic to be changed. I checked Newslisting snippet, and I believe Mark is using the formal provided API, without accessing Database directly, which is a good thing.

I did a little modification with implementing subsites, so all I did is change the current doc parser work to parse the path url with subdomain and etc. After I get all this things done, I make a little modification on makeUrl, which seems to be the API being used across all the snippets and the core doc parser to output the right url, and voila, everything works as if there is no modification at all to my MODx system, except for the fact I can run multiple website under the same MODx installation, so I can host multiple cmall websites without having to re-copy the MODx files and database. Believe me, if you do change this API as well, I believe 50% or more of all the snippets that we have right now will work. This is just a thought, maybe this can help you integrate the right solution.

If you do manage to make it seamlessly integrated into MODx system without sacrificing too much problem with the current repository of resources that we have, I will vote for it for sure, and keep bugging our core developers to make them add it to the future release,

Bad news,

I just look into newslisting snippet code, and I found out that it’s accessing the database directly. I checked the available API from MODx, and realize the limitation from the API, which will definetely force coders to access the database directly without using the API.