| hmm... some locale problems... [message #3009] |
Fri, 07 June 2002 12:46  |
tufan
Messages: 70
Registered: June 2002
Karma: 0
|
Member |
|
|
Hi,
When I override the locale and give my locale (tr_TR), the forum gives the following error message in all forum areas (index, administration, reg user etc):
Query Failed: UPDATE fud2_users SET last_visit=__REQUEST_TIMESTAMP__ WHERE id=1
Reason: Unknown column '__REQUEST_TIMESTAMP__' in 'field list'
From: /var/www/html/forums/fud/tree.php
Server Version: 3.23.48
I didn't understand exactly what was wrong..?
I searched this forum about locale problems, and there seems to be no problem with my sistem:
$ export LC_ALL=tr_TR
$ locale
LANG=en_US
LC_CTYPE="tr_TR"
LC_NUMERIC="tr_TR"
LC_TIME="tr_TR"
LC_COLLATE="tr_TR"
LC_MONETARY="tr_TR"
LC_MESSAGES="tr_TR"
LC_PAPER="tr_TR"
LC_NAME="tr_TR"
LC_ADDRESS="tr_TR"
LC_TELEPHONE="tr_TR"
LC_MEASUREMENT="tr_TR"
LC_IDENTIFICATION="tr_TR"
LC_ALL=tr_TR
$ date
Cum Haz 7 15:38:12 EEST 2002
What can be the problem?
Thanks,
|
|
|
|
| Re: hmm... some locale problems... [message #3011 is a reply to message #3009] |
Fri, 07 June 2002 12:50  |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
__REQUEST_TIMESTAMP__ is actually a define, we define ourselves, it stores the request timestamp. It would appear changing the locale made the code no parse the define properly.
Which PHP version are you running on your system?
FUDforum Core Developer
|
|
|
|
| Re: hmm... some locale problems... [message #3015 is a reply to message #3009] |
Fri, 07 June 2002 13:39 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Hmm I've just replicated the very same problem on my test machine, I'll try a few other locales to see if this is something unique to tr_TR locale or if it is something more sinester.
As scary as it sounds, it could actually be a PHP bug.
FUDforum Core Developer
|
|
|
|
| Re: hmm... some locale problems... [message #3017 is a reply to message #3011] |
Fri, 07 June 2002 14:03 |
tufan
Messages: 70
Registered: June 2002
Karma: 0
|
Member |
|
|
My versions: php 4.2.1/apache 1.3.24
the same thing happens with php 4.0.6 and apache 1.3.22.
it's strange, because when I
define ('__REQUEST_TIMESTAMP__', time());
just before its use for the database, e.g. (for index.php) just before the line:
Q("UPDATE fud2_ses SET time_sec=".__REQUEST_TIMESTAMP__.", action=".STRNULL(addslashes($this->action))." WHERE id=".
$this->id);
index page displays correctly, and dates are displayed in turkish locale. Everything is ok!
There is no such problem with pl_PL or de_DE locales... I changed the core.inc directly to these locales modifying the setlocale line, and there was no problem:
All pages are in turkish, and all dates are in polish or german locale  I wonder if any other locale causes such a problem...
I tried a few locales defined in my system: polish, thai, japanese, german, es_US and a few others, there seems no such problem.... 
(Admin page cannot be used either, so you cannot change the setting back to english using the administration page, you have to edit GLOBALS.php and change LOCALE to something safe, such as english)
I still haven't understood what's going on...
|
|
|
|
| Re: hmm... some locale problems... [message #3018 is a reply to message #3017] |
Fri, 07 June 2002 14:13 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
The code is fine, I too have tried a few other locales, such as german, polish, swedish, russian and all have worked fine. But when I try tr_TR locale it seems to break, I suspect this is actually a bug in PHP rather then the forum, mostly because the problem appears for a particular locale.
I did find an solution to this problem however:
Edit the core.inc.t file, go to the line which says:
define('__REQUEST_TIMESTAMP__', time());
and move this line below the
@setlocale(LC_ALL, $GLOBALS['LOCALE']);
which is right below it.
The end result should look like this:
@setlocale(LC_ALL, $GLOBALS['LOCALE']);
define('__REQUEST_TIMESTAMP__', time());
On my system that seems to have solved the problem. I am guessing something about the tr_TR locale makes PHP unset the __REQUEST_TIMESTAMP__ define, which is technically impossible, since defines cannot be undefined in PHP.
FUDforum Core Developer
|
|
|
|
| Re: hmm... some locale problems... [message #3020 is a reply to message #3018] |
Fri, 07 June 2002 14:43 |
tufan
Messages: 70
Registered: June 2002
Karma: 0
|
Member |
|
|
I was about to say I've solved the problem (well, at least a workaround ), but you said it before i did
Yes, indeed, I created a file, and
define('SOMEDEF', "somedef");
setlocale(LC_ALL, "tr_TR"); // or setlocale(LC_CTYPE, "tr_TR");
print "somedef: ".SOMEDEF;
it didn't display the value of SOMEDEF. Strange...
The problem is caused by setting/changing LC_CTYPE, the defines become undefined. No problem with the code:
define('SOMEDEF', "somedef");
setlocale(LC_TIME, "tr_TR");
print "somedef: ".SOMEDEF;
What is more interesting, I HAD tried what you said on my server before I posted a message to this forum, but seemed it didn't work... Perhaps because of my browser's cache, who knows?
Anyway, the problem seems to be solved, and there is a little more for turkish translation (just the user interface for the time being, but since we intend to use it for our university, translations of the help documents and administration interfaces will be available as well, I hope)
Thanks very much for your help...
|
|
|
|
|
|
| Re: hmm... some locale problems... [message #3023 is a reply to message #3009] |
Fri, 07 June 2002 15:29 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
I've confirmed that this is indeed a bug in PHP and thanks to a PHP developer even know why it seems to happen.
Apparently defines, for some reason get affected by the locale setting, and since tr_TR locale does not have the letter I, all defines containing that letter get broken once the tr_TR locale is set.
After more testing, it appears that moving the define below the setlocale line seems to solve the problem on the PHP's I've tried this on.
FUDforum Core Developer
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]