Posted on: 01/06/07 06:44pm
By: mystral-kk
Hi all, I think I've found a bug with GL's multilingual support. Let me explain.
At a multilingual-aware site, objects have ids with '_' (underscore) and lnaguage shortcuts at their tail, for example, 'Introduction_en', 'Introduction_de'.
In displaying contents, Geeklog uses COM_getLangSQL() and identifies the current langugae a user prefers.
This is implemented in COM_getLangSQL() at line 5940,
Text Formatted Code
$sql = ' ' . $type . " ({$table}$field LIKE '%_$lang_id')";
'%' is a wildcard character in SQL, equivalent to '*' in regular expressions. So this code intends "Select ids which ends "_$lang_id".
Unfortunately, '_' is a wildcard character in SQL, equivalent to '.' in regular expressions.
http://dev.mysql.com/doc/refman/5.0/en/pattern-matching.html
Thus, line 5940 picks up any ids which end with any given language shortcuts **WITHOUT** a preceding '_'.
This is a bit inconvenient and inconsistent.
Re: Problem with multilingual support
Posted on: 01/06/07 07:54pm
By: jmucchiello
This is a better mysql referrence for LIKE: http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html
Re: Problem with multilingual support
Posted on: 01/07/07 05:24am
By: Dirk
Nice find, thanks.
It shouldn't be a problem in practice, though. When you're using the multi-language setup, all items with IDs not following the "_lng" pattern wouldn't normally be displayed, so it's unlikely that you will have any items that accidentally match anyway.
Still should be fixed, of course.
bye, Dirk
Re: Problem with multilingual support
Posted on: 01/07/07 07:29am
By: mystral-kk
Thanks for good info, jmucchiello. so all we have to do is change line 5940 from
Text Formatted Code
$sql = ' ' . $type . " ({$table}$field LIKE '%_$lang_id')";
to
Text Formatted Code
$sql = ' ' . $type . " ({$table}$field LIKE '%\_$lang_id')";
Dirk, I'm afraid you have some misunderstanding about '_' character. '_' in SQL matces any one character including '_' itself. Suppose you are going to setup a mutilingual-aware site where visitors can choose between English (shotcut 'en') and German ('de') and you have an article whose id is 'Freunde'.
The moment you enable $_CONF['languages'] and $_CONF['language_files'] arrays, all artciles will 'disappear' to all the visitors, but the 'Freunde' artcile will still be displayed to German-speaking people.
Re: Problem with multilingual support
Posted on: 01/07/07 07:37am
By: Dirk
No, I understand the problem perfectly (and I tested it with another German word ending in ...de).
What I'm saying is that if you're running a site with multi-language support enabled, you will usually not have any stories (or other items) whose IDs end in anything other then _en, _de, etc. anyway.
bye, Dirk
Re: Problem with multilingual support
Posted on: 01/07/07 07:50am
By: mystral-kk
Ah, I got it. Thanks for the reply, Dirk.
BTW, when I enabled multilingual support on my site, stories without language IDs were displayed in the 'Older Stories' block. When I hit the links, the articles were displayed. I wonder if there is a quick and easy way to fix this.
Re: Problem with multilingual support
Posted on: 01/07/07 08:11am
By: Dirk
The contents of the "Older Stories" block are cached. The next time you edit a story or that block, it will be updated.
bye, Dirk
Re: Problem with multilingual support
Posted on: 01/07/07 08:42am
By: mystral-kk
I updated some stories in the 'Older Stories' block and added a new one on my multilingual site. Surely the contents of the 'Older Stories' block were updated, but stories **without** languages IDs are still displayed in the block. I wonder if this is what's supposed to happen.