2 laibcoms Apr 09, 2009 18:04

OMG 8| too many words for me. Try to edit the existing en-US to utf-8 in regional settings, this is all you have to do.
Why create another locale if you can change the charset in one place...
um... wouldn't it make more sense to find out why an installation that is supposed to be English (PH) is showing as English (US) instead of just cobbling a patch?
sam2kb wrote:
OMG 8| too many words for me. Try to edit the existing en-US to utf-8 in regional settings, this is all you have to do.
Why create another locale if you can change the charset in one place...
For various reasons ^_^ Mainly for testing purposes. It just happened that I started with "en-PH", I could and can use "jp" or "fil" or "fil-Tglg" or "cn".
Secondly, well, en-US is en-US, not any other language ;) The encoding is just the second part of a locale, the main part is the language.
EdB wrote:
um... wouldn't it make more sense to find out why an installation that is supposed to be English (PH) is showing as English (US) instead of just cobbling a patch?
That's my report above :p The "anonymous" ie non-logged-in or site-guest/visitor is going back to Regional locale "English (US)". It's somewhere there, and I think that's beyond me.
^_^
Laibcoms wrote:
... The "anonymous" ie non-logged-in or site-guest/visitor is going back to Regional locale "English (US)". It's somewhere there, and I think that's beyond me.
^_^
At least you understand enough to dig in for analysis! I look at it and think "good thing this app shows up in a language I know..." ;) I poked into the files for 3.1.0.bc and couldn't even find where all the locales are listed anymore so there ain't no way I'd be able to figure out why it decides an installation that was "ab_CD" suddenly becomes "ef_GH" when the boss ain't looking.
yea.. too many words for me too...couldn't read the whole thing. but this "problem" persists in 3.3.3...
everything was fine until after i enabled new locales "en-us" & "ru-Ru" for sam2kb to use.
Then i viewed my blog as a visitor and non-latins were converted to ????'s.
Anyway, i overcame the situation by forcing the charset as above.. just wanted to add when it happened to identify the problem and whether this is a bug or not
Disable en-US and enable en-US-utf8
Ok, just an update, after a few tests and experiments, I found what I think the culprit is.
the "anonymous" locale setting
Here's what I have:
1) Global Settings -> Regional
2) I cloned/copied en-US / English (US)
3) Created a new locale en-PH / English (PH); the changes are:
Locale: en-PH
Name: English (PH)
Charset: utf-8
Priority: 1
Since the Page Source shows a charset of UTF-8; we can assume that the English (PH) setting was parsed correctly
But for some reason, the rest of the page is then rendered in English (US)
After I explicitly changed English (US) via the Regional settings tab to utf-8, the problem for "anonymous" was fixed