You are reading the Drake CMS Official Forums archive, available for historical purposes only.
Drake CMS has been rebranded into Lanius CMS, visit the new Lanius CMS Official Forums if you need support about Lanius CMS or Drake CMS -> Lanius CMS migration.
It would be great
to verify another case of the situation you mentioned:polish
language selected but English day names
Here you go, Polish lang selected but day names still in
engliush. Try this one
Server enviroment is the issue.
stigi
Re: Wrong encoding ?
28 September 2007 16:56
Anonymous
Thank you very much trex1512 and
legolas558
What can be done with this problem?
stigi
Re: Wrong encoding ?
28 September 2007 17:02
Anonymous
I forgot to close the tag, of course should be
legolas558. Sorry. I can't edit my posts
legolas558
Re: Wrong encoding ?
28 September 2007 19:54
Anonymous
Quote:
Quote:
It would be
great to verify another case of the situation you
mentioned:polish language selected but English day names
Here you go, Polish lang selected but day
names still in engliush. Try this one
Server enviroment is the issue.
It is
probably on the server side, but seems to be hard to reproduce
it.
For example, the server for me and
stigi is the same (this one), but when I click
the Polish flag I get Polish text, while he does not.
On your example website instead it shows English text for me
too, so that is possibly a server with safe_mode active or anyway
putenv() usage disabled.
On this server we do not have
safe_mode and putenv() is callable.
My only
"scientific" explanation of the phenomenon is that our
server's PHP processes do overlap:
an user
(we call it user A) with a non-English browser
language (stigi for example) performs a request,
it does not matter if he is logged in or not
since
his browser language is not English, the server's locale should
be changed to something else, pl_PL for example, and putenv() is called for that
purpose
another user (with different locale,
English in our case), that we label as user B,
performs a request which starts after user
A's process has changed the server
locale
at this point, the process of user
A proceeds as the locale has been actually set
to the correct one for user A, and finishes the
response
user B's process
eventually finishes too, but his locale did actually overlap user
A's setting
This scenario could
only happen if the locale setting is server-wide, not
process-wide; and there are chances that here on SF.net (and on
thousands of other servers) that is the case.
But, if this is the case, sometimes
stigi should be able to see the correct text,
and seems like he does not! So I would like to know if this
amazing problem is reproducible on different configurations, if
he can give us a way to test it on our own (using the exact same
version of his browser).
stigi, where
can we download your browser from? That would help a lot in
recognizing the problem - since seems like it is only happening
to you
legolas558
Re: Wrong encoding ?
28 September 2007 20:18
Anonymous
Playing a bit with the flags I could experience
stigi's issue once or twice (not only with the
Polish language).
So now, to validate the scenario
previously described, the question is:
Quote:
Is the problem random
or deterministic? E.g. it depends from a random factor (other
user visiting at the same time) or from some other deterministic
factor?
stigi, can you please
play a bit with the flags and see if it sometimes/always/never
works?
Thanks
stigi
Re: Wrong encoding ?
28 September 2007 20:32
Anonymous
OK, but what is the time difference between user A select his
language (PL for example), then waits for page to load, and
during loading another user (B) change his language (and that way
server language locale)? Page load time counts not even in
seconds, but in ms. What is the probability that someone can
'switch' language during these miliseconds? I suppose it's very
low And I
have this situation EVERY time I switch language to PL
My
Internet browser is IE6, included with Windows XP with Service
Pack 2 (Dutch version).
I've
tried different language versions of Internet browsers, but
everytime it's the same. Thanks.
stigi
Re: Wrong encoding ?
28 September 2007 20:46
Anonymous
I've checked all languages and: For Italy, Croatia, USA and
Germany - works perfectly For Greece, Slovakia and Spain I
always have English day names: Example
And a lovely day it is here in Melbourne AFL Grand Final
Day...sorry back to Drake CMS..:lol:
I am getting an
identical results as stigi...
As a geust or logged
in..
TerryF
stigi
Re: Wrong encoding ?
29 September 2007 08:23
Anonymous
Hello,
I've took a closer look at the whole problem
and: 1) On my local web server I also have English names for
Polish language (instead of Polish) -> so it's really
depending on the server 2) I know a temporary solution 3) As I'm not very familiar with source code of Drake CMS, I
don't know the main answer 'why is this happens?'. Maybe it's
because server doesn't assign properly locale language to an
user, I guess some kind of a bug. Maybe
legolas558 can tell something more after taking
a look at next lines?
The solution: In file
includes/i18n/utf8.php there's a line: Code:
$d__locale =
setlocale(LC_ALL, $lids);
Now (I know it is
different, depending on the type of a used host system of a web
server - for me it was Windows), I've changed above line to: Code:
$d__locale =
setlocale(LC_ALL, 'polish');
I've found $lids in
4 files, one of them is header.php with this code:
Code:
//L: $d__utf8
will be set at runtime and will tell if utf8 re-encoding of some
PHP functions output is needed $d__utf8 = false; $lids
= explode("\n", _LOCALE); foreach($lids as $lid)
{ $d__locale = setlocale(LC_ALL, array($lid.'.UTF8',
$lid.'.UTF-8')); if ($d__locale!==false) { $d__utf8
= true; break; } } if (!$d__utf8) { //
provide a specific conversion function include
$d_root.'includes/i18n/utf8.php'; } else { function
lc_enc($s) { return $s; } }
Which
includes 'problematic' utf8.php.
Result: Pn Wt
Śr Cz Pt So N (which makes me )
legolas558
Re: Wrong encoding ?
29 September 2007 19:52
Anonymous
Quote:
OK, but what is
the time difference between user A select his language (PL for
example), then waits for page to load, and during loading another
user (B) change his language (and that way server language
locale)? Page load time counts not even in seconds, but in ms.
What is the probability that someone can 'switch' language during
these miliseconds? I suppose it's very low
The whole trouble would happen in the very first microseconds
(when the Drake CMS response is setup), the full response time
does not matter
Quote:
And I have this situation EVERY time I switch
language to PL
My Internet browser is IE6, included with Windows
XP with Service Pack 2 (Dutch version).
I've tried different language versions of Internet
browsers, but everytime it's the same. Thanks.
Well, so we have to reduce the problem to a
verifiable one (for everybody).
Are you saying that it
happens also with Firefox? Can you install the LiveHttp Headers
extension and attach to a bug tracker item the headers of a
request with English in the day names even when Polish is
selected?
I have to agree that it is hard to have such
an overlapping scenario, I am more convinced that it might be a
browser/cookie issue - and of course the application might have
its part in the trouble generation.
legolas558
Re: Wrong encoding ?
29 September 2007 19:53
Anonymous
Quote:
I've checked all
languages and: For Italy, Croatia, USA and Germany - works
perfectly For Greece, Slovakia and Spain I always have
English day names: Example
And a lovely day
it is here in Melbourne AFL Grand Final Day...sorry back to Drake
CMS..:lol:
I am getting an identical results as
stigi...
As a geust or logged in..
TerryF
Can somebody come up with the browsers'
headers sent?
legolas558
Re: Wrong encoding ?
29 September 2007 20:01
Anonymous
Quote:
Hello,
I've took a closer look at the whole problem and: 1) On my
local web server I also have English names for Polish language
(instead of Polish) -> so it's really depending on the
server[/code]
If you tested with the same browser, we
cannot assert that
Quote:
3) As I'm not very familiar with source code
of Drake CMS, I don't know the main answer 'why is this
happens?'.
Neither I which claim to know can
answer to that question..it's simply because there is a wrong
browser/server interaction, and we cannot yet individuate it. The
fact that locale-changing is a shady area does not help too Quote:
Maybe it's
because server doesn't assign properly locale language to an
user, I guess some kind of a bug.
Actually seems like
that locale-changing was unsuccessful on some requests. I might
add some logging lines to spot that - if we have luck and if the
relative code generate some form of error code. I still think
that there is a part of responsability on the client side because
it does not happen everytime in my case - but of course I'd have
to make deeper tests
Quote:
Maybe legolas558 can tell
something more after taking a look at next lines?
Let's see...even if I know that code because I wrote it (that's
why it does not work )
Quote:
The solution: In file
includes/i18n/utf8.php there's a line: Code:
$d__locale =
setlocale(LC_ALL, $lids);
Now (I know it is
different, depending on the type of a used host system of a web
server - for me it was Windows), I've changed above line to: Code:
$d__locale =
setlocale(LC_ALL, 'polish');
I've found $lids in
4 files, one of them is header.php with this code:
Code:
//L: $d__utf8
will be set at runtime and will tell if utf8 re-encoding of some
PHP functions output is needed $d__utf8 = false; $lids
= explode("\n", _LOCALE); foreach($lids as $lid)
{ $d__locale = setlocale(LC_ALL, array($lid.'.UTF8',
$lid.'.UTF-8')); if ($d__locale!==false) { $d__utf8
= true; break; } } if (!$d__utf8) { //
provide a specific conversion function include
$d_root.'includes/i18n/utf8.php'; } else { function
lc_enc($s) { return $s; } }
Which
includes 'problematic' utf8.php.
Result: Pn Wt
Śr Cz Pt So N (which makes me )
'problematic' ? utf8.php is used when the
server's PHP does not have embedded utf8 conversion functions -
without it some servers would not be able to serve responses
encoded in UTF8
The lines you mentioned have no
relation with the problem because no client input is considered.
The _LOCALE is in the pl language resources. The
only input from the browser is the Accept-Language (parsed
elsewhere), but I suppose that your browser gives always the
same.
Reading the headers will clear out some doubts -
and perhaps raise others; next, I will create a specific PHP page
to execute a testcase and gather specific results on this issue
stigi
Re: Wrong encoding ?
29 September 2007 23:22
Anonymous
I've tested website on my friend's notebook (with Polish
operating system installed) and he's got the same. Maybe everyone
have this problem, except of legolas558 (lucky
one )
Anyway, after my small modification of code in
utf8.php and post from legolas558,
especially part: Quote:
The _LOCALE is in the pl language
resources
I've figured something out..
Normally, _LOCALE variable for Polish language is pl_PL.
But.. I've made MANY tests today, and it doesn't always work. It
depends on a server. When locale is wrong, it shows English
names. When it's good - Polish. But I've never had Polish
language with wrong encoding (like for 'Friday'). I've noticed
following variables used as _LOCALE (in common.php) for Polish
language: 'pl_PL' 'polish_pol' 'polish' (that one
worked for me only on 1st web server) 'pl_PL.iso88592' 'pl_PL.utf8' (this one worked only on 2nd web server)
Tested on my 2x local, independent web servers - works great
(the same as manually changing $lids variable, but now it changes
automatically while changing a language). I have no idea which
one could work on sourceforge.net server, and how I can add later
all these locales in common.php. Maybe I can make an array from
it?
It would be very nice if a webmaster of this site
can change _LOCALE value to one of them mentioned above (in
Polish resources, file common.php). Thank you in advance. After
verifying that was the problem, I'll update common.php via SVN to
a proposed value.
legolas558
Re: Wrong encoding ?
30 September 2007 12:08
Anonymous
Quote:
I've tested
website on my friend's notebook (with Polish operating system
installed) and he's got the same. Maybe everyone have this
problem, except of legolas558 (lucky one )
A
precisation: I always get Polish day names, except once or twice
which now I cannot reproduce.
I have tried again with
Greek, Spanish and Slovak and I confirm that they show English
day names...
I would include Polish within the set of
languages without correct locale, but it correctly shows to me
Quote:
Anyway,
after my small modification of code in utf8.php and post
from legolas558, especially part: Quote:
The _LOCALE is
in the pl language resources
I've figured
something out.. Normally, _LOCALE variable for Polish language is
pl_PL. But.. I've made MANY tests today, and it doesn't
always work. It depends on a server. When locale is wrong, it
shows English names. When it's good - Polish. But I've never had
Polish language with wrong encoding (like for 'Friday'). I've
noticed following variables used as _LOCALE (in common.php) for
Polish language: 'pl_PL' 'polish_pol' 'polish'
(that one worked for me only on 1st web server) 'pl_PL.iso88592' 'pl_PL.utf8' (this one worked only on 2nd
web server)
Tested on my 2x local, independent web
servers - works great (the same as manually changing $lids
variable, but now it changes automatically while changing a
language). I have no idea which one could work on sourceforge.net
server, and how I can add later all these locales in common.php.
Maybe I can make an array from it?
It would be very
nice if a webmaster of this site can change _LOCALE value to one
of them mentioned above (in Polish resources, file common.php).
Thank you in advance. After verifying that was the problem, I'll
update common.php via SVN to a proposed value.
Before all, please read Special language resources if
you haven't yet; please update common.php, I will update the file
on this server accordingly.
If you modify common.php
through the Language manager, you will see that _LOCALE is marked
as a special language resources. Each line will be an element of
th $lids array.
stigi
Re: Wrong encoding ?
30 September 2007 13:02
Anonymous
Quote:
A precisation: I
always get Polish day names, except once or twice which now I
cannot reproduce.
I have tried again with Greek,
Spanish and Slovak and I confirm that they show English day
names...
I would include Polish within the set of
languages without correct locale, but it correctly shows to me
For me it's a little bit strange, as I've
mentioned - when language locale wasn't assigned properly - it
shows English (it looks you've this situation with Greek, Spanish
and Slovak language). When it's OK - it shows assigned language
(Italian, Croatian, English and German, for example). But.. on
drakecms.sourceforge.net it shows Polish, but with wrong encoding
of Polish letters. So it looks like Polish (and Turkish) locale
is assigned, but a different version than it should be. Magic
Quote:
If you
modify common.php through the Language manager, you will see that
_LOCALE is marked as a special language resources. Each line will
be an element of th $lids array.
Now
everything gets clear I've already updated common.php via SVN. Thank you
for help!
legolas558
Re: Wrong encoding ?
30 September 2007 21:52
Anonymous
Quote:
Quote:
A precisation:
I always get Polish day names, except once or twice which now I
cannot reproduce.
I have tried again with Greek,
Spanish and Slovak and I confirm that they show English day
names...
I would include Polish within the set of
languages without correct locale, but it correctly shows to me
For me it's a little bit strange, as I've
mentioned - when language locale wasn't assigned properly - it
shows English (it looks you've this situation with Greek, Spanish
and Slovak language). When it's OK - it shows assigned language
(Italian, Croatian, English and German, for example). But.. on
drakecms.sourceforge.net it shows Polish, but with wrong encoding
of Polish letters. So it looks like Polish (and Turkish) locale
is assigned, but a different version than it should be. Magic
The problem is that if it is a server-only problem,
it should not vary second the user Quote:
Quote:
If you modify
common.php through the Language manager, you will see that
_LOCALE is marked as a special language resources. Each line will
be an element of th $lids array.
Now
everything gets clear I've already updated common.php via SVN. Thank you
for help!
I noticed you removed the
"pl" from the list. I would suggest to put it back, if
it does not consitute a trouble for correct locale choice
stigi
Re: Wrong encoding ?
01 October 2007 00:33
Anonymous
Quote:
I noticed you
removed the "pl" from the list. I would suggest to put
it back, if it does not consitute a trouble for correct locale
choice
Done. Hope now it'll be OK.
legolas558
Re: Wrong encoding ?
01 October 2007 06:51
Anonymous
Order matters: the 2-3 letters identifier should
be first
legolas558
Re: Wrong encoding ?
01 October 2007 06:55
Anonymous
I have set the _LOCALE for Polish here on the SF.net server to
"pl\npl_PL\npolish_pol"
Wrong encoding ? 
)
)