Everybody know the advantages of a multilingual website but unfortunately i can not see any progress in the xoops core.
IMO It is a little late for xoops core to do something for it but in an sophistical viewpoint its never late to mend.

IMO the server-side programming (PHP and MYSQL) for this matter is completed by two modules "Xlanguage" and 'EMLH" and they both are workable.

therefore im against of doing something more in server-side like the whitepaper that Wishcraft introduced here.
It just learn a complicated messy method (multilingual database) for creating multilingual modules one by one when we already have a very simple approach (Xlanguage, EMLH) in hand that can implement the multilingual feature in your whole website.
IMO we dont need multilingual fields in database to make our website multilingual. It just make everything more complicated. I read another same idea from Voltan somewhere but i think they both are wrong. If im wrong please tell me the great benefits.

why we need to hack all of the current modules and make all old modules incompatible when we already can have multi-language websites by just installing Xlanguage or EMLH?

So I repeat IMO the server-side programming is finalized and completed.
If any developer have some new enhancement for better performances please contribute.

So just one thing is still remained in server side:
choosing between Xlanguage and EMLH and implement it in the next core.

I just can show you the GIJ opinion about xlanguage module:
Quote:
source: http://xoops.peak.ne.jp/md/d3forum/index.php?topic_id=2768

I have this bad experience with Xlanguage module in the past. The CPU was overloaded in a high traffic website so i had to stop using that.
furthermore, EMLH can do the job with just one file.

Anyway i sent a feature request to the tracker:
https://sourceforge.net/tracker/?func=detail&aid=3545262&group_id=41586&atid=430843

Also Trabis did a good job and make EMLH to a module compatible with the latest xoops 2.5.5 and dont need to hack mainfile.php.
you can download here and easily install (no admin or user GUI is available you can not see anything):
http://www.xuups.com/easiestml.zip
Just Trabis mentioned a little (IMO non important) bug in his emlh module.
Bug on preloads/core.php
Change last lines to:


source here:
https://xoops.org/modules/newbb/viewtopic.php?post_id=322273#forumpost322273

But about the GUI there are a lot of works remained that should be done.

Now without any GUI our simple and non experienced end users should use bbcodes like this:
eg for a news title: for english and french
[en]english title[/en][fr]french title[/fr]

but we should use some JQuery methods to divide fields like below:

english:
english title
french:
french title

eg: see this picture for visualizing:


you can see there are multiple fields in the user interface (GUI) But as i said above It can be saved in the database in just one field like this:
[en]english title[/en][fr]french title[/fr]

Irmtfan, this is a very good discussion, and hopefully, this time we'll get somewhere.

You approach is good if you deal with two languages.

But what happens, if you want to have a truly "multi-lingual" solution, that works fine with 10 or 20 languages?

The issue is that you'll run out of space for "title" field, if you want to include each language like this:



Now multiply it by 5 (so you have a 10-language solution), and calculate the size of the field to accommodate it.

Clearly, the size of the "Title" in News or any other content modules, will be too small. But if you try to do it the biggest possible, you'll be wasting space for those people who want to have only one or two languages.

So this is not the way to do it.

We need to set a difference between:

a) Multilingual Interface, done with xLanguage or EMLH and local langugaes
b) Multilingual content, like the one done by Wishcraft.

We had once a discussion about it with Frankblack:

https://xoops.org/modules/newbb/viewtopic.php?post_id=301229

and if I am not mistaken, Wishcraft used some of these ideas in his module.

So, if we want to make XOOPS a truly multi-lingual solution, that would work with 10 or 20 languages (if needed), and which would make it very easy for translators to translate the content, without creating monster database, it seems to me that the combination of xLanguage/EMLH and Wishcraft's approach could address these needs reasonably well.

Of course, if we find something better, I'm all for it....

If the problem is only the size of new title field i would be really glad with my statement because we now should change it to a "TINYTEXT" or "TEXT" for a multi-byte language like persian.

Mamba, to be honest i already changed many of these limitations for my Persian websites.
eg:
current news module title field is VARCHAR(255) --> only 127 persian characters which is nothing to handle even one language.

So yes the approach can handle 10 or 20 languages.

Xoops should increase the fields limitations and it is not related to the multi language feature. Even i sent some of them as a bug here:
https://sourceforge.net/tracker/?func=detail&aid=3534503&group_id=41586&atid=430840

I dont know about how xoops can handle big size fields and the possible problems occurring in performances. but i just think we should not have any problem with big size fields because we need them.
maybe a developer can response.

Quote:

This might have a negative impact on performance.

From Stackoverflow:
Quote:

That quoted statement just said you should define an exact value for VARCHAR unless MYSQL will get the maximum value. We need to know what is the impact when we change the VARCHAR to TEXT. (Now newbb module uses TEXT field for each post text and it can handle it very good. IMO the number of queries are important not the field size)
Also another question is what is better in performance to handle 10 or 20 languages:
1- having one huge field size.
2- having a multilingual database
also i should correct this:
Quote:
a) xLanguage or EMLH are Multilingual content
b) Wishcraft want to introduce a Multilingual database (which i dont agree)

Anyway, Im agree with you that it is not fare and it is a waste of space to force a huge field size to all XOOPS websites because of very very few websites that need a larger size.
It comes to my mind that we need a "Database field size advisor/warning/error plugin" in xoops. We already have a simple table maintenance in system module. That plugin should show all tables structures and should advise about the field sizes. for example when you have a 2-byte language (like persian) in your website, in the news module table structure (_story table), it should warn the webmaster for the possible limited size in title field in red/yellow color.
eg:
title VARCHAR(255) - It is 255 characters in english but 127 characters in persian

(please pay attention that i dont request a "Database field size editor plugin" because IMO a simple webmaster can damage his/her website easily with that tool)

example of the issue when there is no warning for limited field size:
when a simple end user submit a news in my website and its title is very long, the title is just run out of space in database and he/she will end up with a cut-off news title and just complaining in my forums about it and stated he/she didnt receive any error.

also please note that in 99% of multilingual cases we just need 2 or 3 languages and the request for more than that is very very rare.

Mama i just finished reading that valuable topic you linked me to.
There are some important notes that i should state my opinions.

Quote:
These two concepts are completely different and need completely different approaches.

1) Multilingual Content: xLanguage or EMLH
2) Multilingual Translations: lang files in your host
3) Multilingual Database: Wishcraft whitepaper introduced it
4) Multilingual Interface: an online translator like google translator can do it for every language

Please do not conflict the four above-mentioned concepts.

The first one is multilingual content which we discussed here and is solved in server-side by EMLH or Xlanguage.

The second one is "Multilingual Translation files"
Please pay attention that they are files stored in your host and they are completely different from contents that store in the database.
Also im totally against of storing language files in database. it just make everything messy.
To solve the second issue core team should introduce a language file editor like any other CMSs.
Also language files should be changed to INI and they should be reduced to one unique language eg: EN-GB, ... (There are many discussions about this in forum especially from DCrussader)
Also this feature in the tracker:
https://sourceforge.net/tracker/?func=detail&aid=3520611&group_id=41586&atid=430843
I think once core team make INI language translation files happen we can easily introduce a lang-tool for translation and store them in the host

Also as i stated several times i have not good experienced with Xlanguage version 3 in my high traffic website. I strongly recommend EMLH.
My website with above 80,000 daily Hits is a good test example.

just my 2 cents

I had a discussion with Voltan in persian support site and he pointed me to some valuable information.
1- Xoops core should change its database engine from MyISAM to InnoDB which i think it is under way.

2- we can not change the VARCHAR to TEXT because we can index VARCHAR fields but TEXT fields can not be indexed?

Also i found that TEXT fields are outdated.
developers encouraged to change TEXT fields to VARCHAR(MAX)
see:
http://stackoverflow.com/questions/834788/using-varcharmax-vs-text-on-sql-server
Also Now we can have VARCHAR maximum field size more than default 255.
see:
http://dev.mysql.com/doc/refman/5.0/en/char.html
Quote:

So i still dont know if it really cause bad impacts on the server RAM/CPU if we have a VARCHAR(600) for example?

Interesting article on TEXT vs. VARCHAR performance related issues.

Yes. that link is very interesting.i should said my prev idea about changing the TEXT to VARCHAR(MAX) is incorrect.
As i said before it needs an expert developer response.

I fear our discussion here goes to off topic but i would be glad to test the results in my website.
My website is a good example to test XOOPS performances.
It is bilingual english and persian (persian is 2-byte so you can take it as a 2 languages in db)
Im in a shred hosting and my limitations are very tight:
Quote:

@ Irmtfan:
Quote:
I am not sure I understand the issue here.

I did install EML (the version from Trabis), and it is very user unfriendly. Only the Admin can changed the languages, and it has to be done manually, as there is no block to switch between languages by the user.

We've just fixed few bugs in xLanguage 3.04, so if there are more, let's fix them all, so we have a good module that is user friendly and allows users to change languages on the front end.

As Ghia once said:
Quote:
If the algorithm from EML is better, let's see if we can incorporate it into xLanguage.

So let's have a good discussion about the pros and cons, and what can we do about it.