Subject: Problem with multilingual support

Posted on: 06/01/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,
PHP 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: 06/01/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: 07/01/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: 07/01/07 07:29am
By: mystral-kk

Thanks for good info, jmucchiello. so all we have to do is change line 5940 from
PHP Formatted Code

$sql = ' ' . $type . " ({$table}$field LIKE '%_$lang_id')";
 
to
PHP 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: 07/01/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: 07/01/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: 07/01/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: 07/01/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.

Geeklog - Forum
https://www.geeklog.net/forum/viewtopic.php?showtopic=73364