Implementing the multilingual function in 2.6.0 is vital and I really want to see XOOPS do it in a right way.

Xlanguage vs EMLH:
1- I reported one functional bug in 3.03 that is not exist in 3.02. Anyway, as mamba stated maybe it is solved in 3.04 (I should test and report in its topic) sooner or later all bugs have been solved.

2- Performance of Xlanguage 3 is not good. I had a very bad experience with it. The CPU was overloaded. Also memory usage is worst. My server suspended me because of abuse. Then I changed to EMLH and everything was backed to normal. Of course you can not reproduce this error in low traffic websites. but in websites (like my website) with more than 1,000 unique visitors/day and more than 50,000 Hits/day you can find it.
I didn’t see any development in this area on Xlanguage so for now I strongly recommend "EMLH" by GIJ.
GIJ ones said in his website:
Quote:
source: http://xoops.peak.ne.jp/md/d3forum/index.php?topic_id=2768


3- Xlanguage did not offer any additional feature. Both Xlanguage and EMLH can change the content language. Xlanguage also can change the system language but EMLH could not do it in the original GIJ releases (because he want it to work as a hack in any xoops fork) but with a little great work by Trabis (that I think it takes just 15 minutes from him!) EMLH has been turned to a module (now can be renamed to XMLH) and now it can change the system language which works great in 2.5.5
http://www.xuups.com/easiestml.zip
Therefore what Ghia said is incorrect now.
Quote:
EMLH has no block because it is a hack. Therefore both admin and user can not select languages after install. You can create a custom block and put one bbcode [mlimg] into it and it show the languages. Also you can use [mlimg] anywhere in themes/template and it will show the languages. Anyway you should do one of the above to have the selectable languages.

4- Development on both modules has been stopped long long time ago. Of course Xlanguage has a nice admin area because Mamba implement the module admin class into it from version 3.03 and solve some bugs in 3.04 which I think it was because of that implementation in 3.03 because 3.02 works without bugs for me. EMLH Trabis does not develop anymore too. So both modules are dead modules.

5- IMO EMLH is more user- friendly (or better to say webmaster-friendly) than Xlanguage. You can not find many topics here in xoops.org and in GIJ website from people asking functional questions. There is a nice readme in GIJ website (which is not present in EMLH Trabis and should be added.) The configuration is very easy. You just open a file and add languages, add language images url and configure some options. IMO even a very simple webmaster will not have problem with it. Of course only one with the access to Cpanel can change the file (IMO it is good for security!). Anyway, EMLH can be changed very very easy to a xoops module with a nice module class admin, with block and nice configuration in preferences. IMO it is not important because it is just admin GUI feature that can be added at anytime. If any of our current developers like whishcraft, voltan, … take some time they can do it
On the other side Xlanguage save the languages in the database which im totally against it. A ML module don’t need a table because it don’t have any content itself. Having a table for languages is meaningless because your website available languages are already exist in language/YOUR_LANG folders. Also language Desc | Name | charset | code are all defined in XOOPS so having another configuration in database in Xlanguage is in conflict with XOOPS configuration in files (in global.php for each language). It is unnecessary and dangerous and also incorrect because maybe a simple webmaster will not input them to database as same as the XOOPS configuration (in global.php for each language) and damage his/her website. I call it unuserfriendly.
So you reach to my point. You already define language name (in language/YOUR_LANG) and charset, code (in XOOPS file=global.php) which can be only accessible by webmaster having access to Cpanel. The ML module works with these configs. When you can accept a nice admin GUI for changing the global.php configs you can do it for ML module too. Therefore I just can imagine a nice GUI admin, block and preferences for EMLH for selecting between options read from global.php. Ability for Changing these options in ML module (like Xlanguage) is funny.
At the end please understand that having ML functionality is not a simple feature. No webmaster add it into his/her website without think.

6- You can safely uninstall and remove Xlanguage and install EMLH and you will not lose anything. I can not tell/recommend you to uninstall a content module and install a better one because you will lose your data but when you will not lose anything by uninstalling Xlanguage and when you have the right to back to Xlanguage at anytime why I should not recommend EMLH for now? Anyway the right way is finding a developer work on EMLH and add the nice GUI admin, block and preferences and continue developing Xlanguage is wrong.

Just my idea based on 7 years experienced with ML functionality.

I cannot say much about the issues with "large Websites" because I didn't test xLanguage with such.

But I like the GUI of xLanguage, because it makes life easier for Admin and allows the user to select language in a block.

Quote:
If somebody wants to do it, I'm all for it

hi irmtfan,

Is there a way to create a custom block for [mling] in Control Panel Home?

I am curious what do xLanguage and EMLH actually do?

In simple explanation what do they accomplish?

Thanks!

I am asking because I may have an idea on something different but no need to reinvent the wheel or bore everyone with an idea if it doesn't make sense over what is available.

Quote:
They switch between languages:

a) that you have installed for XOOPS (i.e. Admin)
b) that you use in your content by using tags like these [en] English text [/en] [de]German text[/de]

Quote: You cannot create a custom block in admin side. To have a link in admin side you can add [mlimg] to admin themes. eg: In xoops256/modules/system/themes/default/xotpl/xo_head.html

[mlimg] - doesn't work on the admin side, not clickable.

Quote:
So they are different than the language constants that I would be used to seeing that are setup by the defines in the language files.

Is it more for user entered content than the module language constants?

It's BOTH!

The language constants are used by the XOOPS administration, and they are being covered by (a). The normal way is to go to System Preferences and switch the default language. Then XOOPS and all modules that have "language files" will use them for that given language. The xLanguage helps to do it via block.

The best way to learn more about it is to: download a French or German version of XOOPS, or only their language files, copy these language files over your English XOOPS installation, and then switch the language in your System Preferences.

Then install the xLanguage, add the languages, activate the xLanguage block, and then switch the languages using the block.

Then assuming that you have downloaded the French language, start entering in your News or other content module text like this:

[en] English text [/en]
[fr]French text[/fr]

And see how it changes in the View, once you start switching languages in the xLanguage block.

Just play with it...

So you need to have versions of both included in the block and it will choose to display whichever is the one for the current language?

That is kind of neat. But the person entering in the information needs to know how to speak in all languages they post entries in then right?

I haven't had time to try playing around with it yet to see what all it can do.

Can it replace the current language constant definition system used by most modules or is it more for entered content?

Otherwise I have an idea similar to one I had earlier where you build a central database of often used phrases and the module defines a script based on the phrases it uses and the install script will use this database to build its language defines based on the entries in the database. Would help make the current system much less dependent on translators. Might mean deciding on a base language such as English to build off from. Or might be totally language neutral not sure until I start coding. Once the database is built it would be easy to use it to build defines or anything else if we decide to change to INI or something else in the future. I am very busy at the moment but if it sounds like something worth while I could probably try looking into it more.