My multi-content solution is ready to be tested... who wants to test?

Quote from: rthrash at Mar 07, 2006, 07:56 AM

Also, should we seriously consider using this or a similar implementation for MODx multiple language sites by default in the manager? I would like to have this addressed much sooner than later. (Jason, see any problems in porting madmages’s solution to the contexts/versions in Tattoo?)

Yeah, I don’t think this approach will be very similar at all to how Tattoo will be serving multi-cultural content. I’m still not real excited about having this directly on the site_content table in MODx either. If anything all content needs to be removed from that table, not more fields or rows added to it to store additional content there. The idea in Tattoo is to give you the facilities you need to build sites with localization and internationalization features with the structure and approach you want to take. For instance, I could create a separate context for each local culture I want to support, and duplicate a tree from another context, providing a whole other section. Or, I could have it all in one context, with sub-folders representing each language, with pages that are very specific to each locale. Or, simply create a page and provide as many different versions of the content (and each one of it’s elements, e.g. snippets, templates, chunks, TV’s) you want in the page, and then have system/context/user preferences determine the best matching cultural revision for each request to the page. All three of those approaches, and probably more like them, will be possible in Tattoo, because everyone has a different idea of how best to support localization and/or internationalization for their specific needs.

Thats said, it will always be possible to port information; we’ll just have to write/customize utilities to create Tattoo deployment packages from sites built using this solution. Then you could import your data into Tattoo, despite the structural differences in the persistence layer.

I do understand the first and second concept, but the third concept, I might need a little bit more explanation.

Or, simply create a page and provide as many different versions of the content (and each one of it’s elements, e.g. snippets, templates, chunks, TV’s) you want in the page, and then have system/context/user preferences determine the best matching cultural revision for each request to the page.

Another thing, the only reason that we need it to be embedded, it will make the website seamlessly translated. So for example if the specific page doesn’t have any translation yet, then it will receive the main language page, while if the Page has been translated, it will show up like normal. Basically this thing will required visioning for the original document content, as well as the translation content. I don’t think a redirection approach, to redirect user to the default translation will be good. Another thing, translation does includes longtitle, summary and etc, which each snippets developer will need to be able to detect that.

So if we implement it in the core, and have an API to fetch documents. Basically when a snippet developer use this API, the API will automatically return the right content, longtitle, title, and etc, without the needs of patching and hacking. This will help to generalize the snippet being created as well. Consider if newslisitng being created without multilanguage in mind, while dropmenu build with multi language support. Then when a designer wanting to create a multi lingual site, they can just use dropmenu snippet, while they need to hack or patch newslisting to act like dropmenu to support multi lingual content. This problem won’t happen if we have the core code architecture build with multi lingual support.

Hope I get my message across.

Quote from: madmage at Dec 26, 2005, 07:23 AM

A small demo you can find in http://www.mindreamz.net/modx091/ but I would like the MODx-gurus to look at my code to know if I used the right functions in the right places (going into the core code to find out which function to use is not a great thing, maybe sometimes I used a deprecated function or something like this)

The goal was to provide a multi-language-content site, in which the user can choose a preferred language and browse the site reading pages in that language if they are available, and been redirected to a "default language page" if not.

My solution is the following:
1) there is a $_SESSION variable that stores the preferred language choice of the user;
2) I modified the *_site_content table adding two fields:
- contentLang, that stores something like "en", "it", "fr", ...
- refId, the id of the page in the default language which this one is a translation
3) I added a snippet to show the language flags for the user choice
4) I added a plug-in that redirects to the right-language page
5) I modified the DropMenu to show only the chosen language entries
6) I modified the manager in these ways:
- in the document tree, each page has next to it its current translations (you can click on them and go to the translation, without the need to have a different tree for each language and to have not every page translated)
- while vieweing a document, you can also see in which language is the content and you have a button that duplicates the page to begin to translate it
- in the settings page you have to write which languages your site is in and the default language

The only thing that is to be implemented is a plug-in that rebuilds the tree accordingly after the insertion of a new translation (it is needed and you can easily figure out why)

Now, then, how can I show my solution? I can give to someone the access to my manager, in order to see my modifies. Or... what else?

hi
Regarding the Multilingual Support it really looks that you solved the problem...

i am new at modx and I really need this feature..

i got the points 1 to 2 of your post regarding this issue but the rest is a blur since I dont know what snippet you developed and the rest......

_________________________YOUR POST____________________________________________
3) I added a snippet to show the language flags for the user choice
4) I added a plug-in that redirects to the right-language page
5) I modified the DropMenu to show only the chosen language entries
6) I modified the manager in these ways:
- in the document tree, each page has next to it its current translations (you can click on them and go to the translation, without the need to have a different tree for each language and to have not every page translated)
- while vieweing a document, you can also see in which language is the content and you have a button that duplicates the page to begin to translate it
- in the settings page you have to write which languages your site is in and the default language

The only thing that is to be implemented is a plug-in that rebuilds the tree accordingly after the insertion of a new translation (it is needed and you can easily figure out why)
_____________________________________________________________________________

Please if you would be kind to help me i would be greatefull to you.


Best Regards.

Jason and Wendy,

Would this option work for a multilingual site:
- create textbox/WYSIWYG TV’s for each language (english, spanish, french, etc.)
- have snippet that reads from either session,cookie, or advanced_user_table** which TV to load
- if nothing is set go to default

Would this work for multilingual sites?

*problem: Another thing, translation does includes longtitle, summary and etc, which each snippets developer will need to be able to detect that.
- would you be able to declare these with the TV’s?

I’m a newbie but an idea guy too. What do you guys think, or are you already working on these things for 1.0?

Chuck

PS - advanced_user_table** = My plan is to create an addon where a user can describe many attributes for their user account. This would be a new table with the id’s linked to the normal user table. If this happens, the user could also describe their preferred language (or template, etc.)

PPS - Jason, I agree more items need to be removed from site_content table instead of more items being added to it.

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

Would this option work for a multilingual site:
- create textbox/WYSIWYG TV’s for each language (english, spanish, french, etc.)
- have snippet that reads from either session,cookie, or advanced_user_table** which TV to load
- if nothing is set go to default

Would this work for multilingual sites?

Sounds like a reasonable plan.

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

*problem: Another thing, translation does includes longtitle, summary and etc, which each snippets developer will need to be able to detect that.
- would you be able to declare these with the TV’s?

Using TVs would be your best bet for now. As for future directions, all the metadata of a document will also be able to have multiple translations and change revisions, just as the content will, with the exception of alias, which is used to create a unique resource identifier/locator (URI/URL) for the page.

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

I’m a newbie but an idea guy too. What do you guys think, or are you already working on these things for 1.0?

Yes being worked on already for 1.0.

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

PS - advanced_user_table** = My plan is to create an addon where a user can describe many attributes for their user account. This would be a new table with the id’s linked to the normal user table. If this happens, the user could also describe their preferred language (or template, etc.)

Why not use web_user_settings table to store this information? Just need to use unique names for your properties and you should be fine to use this existing table for this purpose. It’s kind of what it is meant for.

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

PPS - Jason, I agree more items need to be removed from site_content table instead of more items being added to it.

Indeed; table-size is just as important a consideration as overnormalization can be, where you have unnecessary joins to frequently used data. It’s a balancing act, but I really feel the benefits of isolating content from the definition of a page are important.

Quote from: OpenGeek at Jun 27, 2006, 09:20 AM

Quote from: ProWebscape at Jun 27, 2006, 04:23 AM

PS - advanced_user_table** = My plan is to create an addon where a user can describe many attributes for their user account. This would be a new table with the id’s linked to the normal user table. If this happens, the user could also describe their preferred language (or template, etc.)

Why not use web_user_settings table to store this information? Just need to use unique names for your properties and you should be fine to use this existing table for this purpose. It’s kind of what it is meant for.

So that table is there for that. Thank again Jason. I am coming from the Mambo/Joomla camp where it’s not good to add anything to the main db tables- especially the user ones.

2 questions:

1. How do you plan to account for this table (with its added columns) during MODx upgrades? [or is it expected for the MOD user to manually go through the SQL updates?]

2. Is there any db schema/API/rules to prevent other addons from clashing with additions to this table? Aka, best practices?

Thanks again Jason,
Chuck

PS - You guys have done one HELLUVA a job on this. I was working with J! today and just couldn’t bear it.

Quote from: ProWebscape at Jun 27, 2006, 06:07 PM

1. How do you plan to account for this table (with its added columns) during MODx upgrades? [or is it expected for the MOD user to manually go through the SQL updates?]

You shouldn’t need to add columns to this table, only rows of key/value pairs per user, which it already handles.

Quote from: ProWebscape at Jun 27, 2006, 06:07 PM

2. Is there any db schema/API/rules to prevent other addons from clashing with additions to this table? Aka, best practices?

Just name them uniquely and all should be well with the world. For instance, prowebscape.default_template could be a setting_name, with a setting_value of 2 for webuser 1. I don’t think we’d ever maliciously try to overwrite that value on upgrades, and if we did, whew, would we deserve a proper ass kicking or what

Quote from: ProWebscape at Jun 27, 2006, 06:07 PM

PS - You guys have done one HELLUVA a job on this. I was working with J! today and just couldn’t bear it.

Flattery will get you everywhere here.

But seriously, thanks for the kind words, and your participation in our community.

Cheers

This is my short term solution that I use for my current website. It uses TV and session

PLUGIN


SNIPPET


Hope it gives you a basic example on how to adapt the implementation into your site.

Sincerely,
Wendy Novianto

Thanks a lot Wendy for this one !

Nice

This is my short term solution that I use for my current website. It uses TV and session

Sorry for the dumb question:
But: How do Plugin and Snippet interact? And why is the Plugin needed at all? It seems to me that the snippet is performing very similar actions to those of the plugin (also using the $_SESSION variable for instance?