Thank you everyone for your suggestions so far. It seems that a couple of people like the square bracket approach. I don't currently run a multilingual site but I just imagined that on a large site if I wanted to support many languages (e.g. 10 or 20) then this approach does not seem very practical.

What I envision is a method where the user can select a language and items not available translated into that language are either shown in the as-written language or not displayed at all. As far as editing and storing the multiple translations... we have so far the square bracket approach. That means all translations are stored together and edited together. I think any problems with searching can be sorted out (probably with a little performance hit).

Another possibility is to store each translation in a separate database 'row'/record. This will improve performance (don't need to load all translations from database just to show one language version, and also don't need to parse for language identifiers). However, how does this get entered? I suppose a user would by default create the translation in their selected language. But how could they create additional translations in other languages? Perhaps a simple selector on the edit form would suffice to choose the language being entered. This could work for real content I think, but additional things like titles, block titles, menu items, etc... pose a bit of a problem. Perhaps a combination of the two approaches?

Just throwing some ideas out there... any thoughts?

After reading joelg's recent comment in this thread:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=10734&forum=14

I thought it would be useful to start a discussionn on how *best* to implement multilingual capability for CONTENT within Xoops.

The above mentioned thread is a nice 'hack' to the core that allows codes different languages for the same text to all be entered into the same field. Each language text is surrounded by square brackets, and only the text for the currently selected language is shown when the content is rendered. This hack deals with content, titles, administration, and even block titles, I believe.

But is this really the *best* way to do this? i.e. If the XOOPS core was going to support multilingual content how would we do so from the ground up? Perhaps we will decide that the methods discussed in the above hack are the best, but I would like to initiate a little discussion to see what others think.

As joelg and others have pointed out, this hack does have a few drawbacks:

- if you have a lot of languages on your site, then your text becomes huge (storage problem in limited size database fields) and becomes intimidating to edit

- your users may not be comfortable with using square bracket codes to surround text from a certain language

- if your users don't all understand all languages, then why make all translations available to them while they edit. This may be confusing and introduces the possibility that they can mess up the translations in other languages.

I love to hear thoughts on what is a good method, or simply what features/characterestics would a good method have? Also does anyone have any favourite software which does a good job of multilingual content that might serve as an example? etc... Comments welcome!

Quote:

Actually I've never tried this, but I don't believe there's any reason it wouldn't work (if it works in the non-xoops-integrated version). Perhaps there are some directories that need write permissions set? I will try to look into this in the next couple of days.

I believe you can do these kind of tricks with 'mod_rewrite' (if you are using apache web browser). Probably similar mechanisms exist for other web servers. However, such a feature is a *server-level* trick and cannot be done from within the XOOPS php code, I think.

The problem is that each module will probably need separate rules because there is no consistent use of arguments to specify which content page to look at. e.g. news uses 'article_id', forum uses 'forum', 'topic_id' and 'post_id', etc... But still, it could be done. Perhaps someone has already done this??

But for search engines, does it really matter? I've heard lots of discussion and from what I gather it doesn't matter if your URL is viewtopic.php&topic_id=1234 or view.topic.1234.html -- i.e. you would have equal rankings with google assuming all other content, links (to and from), and meta info is the same. Doing some random 'googling' I frequently see php scripts listed...

My preferred way is to put the files on my server in the directory e.g. xoops-2.0.3. Then I will make a symbolic link 'xoops' that points to xoops-2.0.3.

You don't want to put things too deeply, or your website address becomes ugly...

http://somewhere.net/xoops/xoops-2.0.3/

(unless you are able to use e.g. apache mod_rewrite to clean things up).

Just my thoughts...

I cannot duplicate your error... works fine here. If you continue to have problems, remove the comment lines from the end of the .sql file and it should work.

i.e. the lines:

#
# Dumping data for table 'mantis_user_table'
#

Which version of XOOPS are you running? This is not a problem since 2.0.3 (or perhaps even earlier) I believe.

I assume you're using the same root user/password combination in XOOPS setup. Do you have the server set to 'localhost' or whatever it should be? Double-check the spelling of everything. Whch version of XOOPS are you running? One early version of 2.0.4 (I think it has been repackaged now) had a small problem in the installer which gave this error.

I would also recommend creating a MySQL user for XOOPS instead of using 'root'. That way you can give access just to the XOOPS database and not all databases running on your server.

OK, I see now what you're doing with the 404. Perhaps all you need to add to the error404.php page is the statement

session_start();

??

Also you may have problems if you defined a 'custom' session name in the XOOPS preferences. If so, you will need to account for that in the 404 php page as well.

That's all I can think of right now...

Good luck

Can you provide a little more detail about what you are trying to do?

I doesn't look like you need $_SESSION or $HTTP_SESSION_VARS to do what you are describing since you are using your own database tables and your own id number.

Also, why not use mod_rewrite (if you're using apache) or www.mysite.com?memid=11078 instead of the 404 trick?