Fork me on GitHub

Search

Donat-O-Meter

Make donations with PayPal!
Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00

Learn XOOPS Core

Local Support

Advertisement

XOOPS Code hosted on SourceForge

Cumulus Tag Cloud

- 2 2.5 2.6 3.0 4 6 2013 adslight Android AntiHarvesting AntiMalUser AntiSpam API Apple Battlefield billige Bootstrap By Captcha cell cent chronolabs Clicks content CĂN demo docek download Dresses evden eve facebook Fat Food for free Gateway Google Guide herre Home Honeypot Human HỘ IP iPhone jQuery Law Legal List log Loss mobile module modules Monster new newbb news NHÀ online PARK Payment phone PHP Prevention profile project Protector publisher RESIDENCE responsive review Rights rmcommon security Sentry Signatures Signed site Smartphone Smoking Solution Spam Studio tags tdmcreate template The Theme themes web weight Wishcraft xoops Xortify XPayment

New Users

Registering user

# 137911

mydarkglobe

Welcome to XOOPS!




Bottom   Previous Topic   Next Topic  |  Register To Post

(1) 2 3 »


#1 Posted on: 2012/7/23 3:35 The best approach for a multi-language XOOPS
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:

EMLH dare to maintain system language although it is quite easy to swith system language.
You should know xlang is just a derivered version from EMLH.
And I think this is just a corrupted.

The reason why I name it "corrupted" is caching problem.

You can find the problem with xlang just by turning "module cache" or "block cache" on.

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= ... roup_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:
$GLOBALS['xoopsConfig']['language'] = $easiestml_dirs[EASIESTML_DEFAULT_LANG];
        return 
true;

    }

}
?>


source here:
http://xoops.org/modules/newbb/viewto ... 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:
Resized Image

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]




Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#2 Posted on: 2012/7/23 5:04 Re: The best approach for a multi-language XOOPS
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:

[en]This is a very very very long English title[/en][fr]This is a very very very long French title[/fr]


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:

http://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....

Top


Please support XOOPS & DONATE
Use 2.5.7 | Debugging | Requests | Bugs
Mamba
Joined:
2004/4/23 13:58
From Ohio, USA
Group:
Webmaster
Registered Users
Designer Group
Posts: 8132
(Show More) (Show Less)


#3 Posted on: 2012/7/23 5:40 Re: The best approach for a multi-language XOOPS
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= ... roup_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.





Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#4 Posted on: 2012/7/23 6:09 Re: The best approach for a multi-language XOOPS
Quote:

irmtfan wrote:

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.


This might have a negative impact on performance.

From Stackoverflow:
Quote:
In MySQL, temporary tables and MEMORY tables store a VARCHAR column as a fixed-length column, padded out to its maximum length. If you design VARCHAR columns much larger than the greatest size you need, you will consume more memory than you have to. This affects cache efficiency, sorting speed, etc.


Top


Please support XOOPS & DONATE
Use 2.5.7 | Debugging | Requests | Bugs
Mamba
Joined:
2004/4/23 13:58
From Ohio, USA
Group:
Webmaster
Registered Users
Designer Group
Posts: 8132
(Show More) (Show Less)


#5 Posted on: 2012/7/23 21:25 Re: The best approach for a multi-language XOOPS
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) Multilingual Interface, done with xLanguage or EMLH and local langugaes
b) Multilingual content, like the one done by Wishcraft.

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.




Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#6 Posted on: 2012/7/24 1:36 Re: The best approach for a multi-language XOOPS
Mama i just finished reading that valuable topic you linked me to.
There are some important notes that i should state my opinions.

Quote:

Mamba wrote:
- module developers can easily add the Multilingual feature to their modules (like it is done with xLanguage)

- modules owners/admins can easily extract all local text and give it to translator for translations (right done with "language files")

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= ... roup_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




Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#7 Posted on: 2012/7/24 3:45 Re: The best approach for a multi-language XOOPS
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/83 ... max-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:

Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions


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


Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#8 Posted on: 2012/7/24 15:26 Re: The best approach for a multi-language XOOPS
Interesting article on TEXT vs. VARCHAR performance related issues.

Top


Please support XOOPS & DONATE
Use 2.5.7 | Debugging | Requests | Bugs
Mamba
Joined:
2004/4/23 13:58
From Ohio, USA
Group:
Webmaster
Registered Users
Designer Group
Posts: 8132
(Show More) (Show Less)


#9 Posted on: 2012/7/25 0:38 Re: The best approach for a multi-language XOOPS
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:

Memory usage may not exceed 10% per domain/file/application
CPU usage may not exceed 20% per domain/file/application
Apache connections may not exceed 30 connections
15 MySQL maximum user connections allowed
350 emails per hour, per domain
Inodes should be below 200,000 and should be below 100,000 to enter into daily backup.


Top

irmtfan
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3371
(Show More) (Show Less)


#10 Posted on: 2012/8/12 6:28 xLanguage and EML
@ Irmtfan:
Quote:
As for the crappy buggy Xlanguage. I dont know. I just recommend as always:
uninstall it and install EMLH.

You can implement GIJ easiestML hack very easy.

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:
xLanguage has the avantage that it sets also the XOOPS website to the selected language. With EMLH, only the content of articles etc, shifts languages, but the menu and other fix texts stay in the original language.

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.

Top


Please support XOOPS & DONATE
Use 2.5.7 | Debugging | Requests | Bugs
Mamba
Joined:
2004/4/23 13:58
From Ohio, USA
Group:
Webmaster
Registered Users
Designer Group
Posts: 8132
(Show More) (Show Less)




(1) 2 3 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You can vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create pdf.
You cannot get print page.

[Advanced Search]