Patrick R. Michaud [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
If you could save me the trouble of identifying the specific PITS
pages for each of these... I may be able to see about solving some of
these (e.g., case-insensitive utf-8 searches) while I'm in the process
of
On Monday 12 March 2007 08:22, Athan wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
If you could save me the trouble of identifying the specific PITS
pages for each of these... I may be able to see about solving some of
these (e.g., case-insensitive
Petko Yotov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
The proposed patch at http://pmwiki.org/wiki/PITS/00682 looks really good.
There is also this library http://phputf8.sourceforge.net/ which adds utf-8
wrapper functions that really work!
Although Patrick seems to prefer
Patrick R. Michaud [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
A second approach might be for PmWiki to treat xlpage-i18n as though
it is a simple charset declration whenever an associated xlpage-*
script doesn't exist. Thus, if someone sets 'xlpage-i18n' to
'euc-jp', and
On Mon, Mar 12, 2007 at 03:59:57PM +0200, Athan wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
A second approach might be for PmWiki to treat xlpage-i18n as though
it is a simple charset declration whenever an associated xlpage-*
script doesn't
On Sat, Mar 10, 2007 at 06:04:38PM +0200, Athan wrote:
Hi again,
It seems that an xlpage-iso-8859-xx.php file is necessary for each encoding
to work.
I wonder why core not appends the xlpage-i18n encoding in PmWiki
$HTTPHeaders by default.
The core doesn't do it by default because it's
On Sat, Mar 10, 2007 at 07:17:04PM +0200, Athan wrote:
Oliver Betz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
which problems specifically?
No case -insensitive searching, random broken chars with specific markup,
incompatibilities with many reciepts (most of them are using
I was trying to convert Greek translation from UTF-8 back to ISO-8859-7
(because of many problems I had with utf-8 implementation in pmwiki).
Unfortunately pmwiki seems to ignore encoding stored in xlpage-i18n. It
isn't included neither in http header, nor in html Content-Type meta.
Btw even
Hi again,
It seems that an xlpage-iso-8859-xx.php file is necessary for each encoding
to work.
I wonder why core not appends the xlpage-i18n encoding in PmWiki
$HTTPHeaders by default.
Athan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
Athan wrote:
I was trying to convert Greek translation from UTF-8 back to ISO-8859-7
(because of many problems I had with utf-8 implementation in pmwiki).
which problems specifically?
Unfortunately pmwiki seems to ignore encoding stored in xlpage-i18n. It
Since my preferred encoding is
Oliver Betz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
which problems specifically?
No case -insensitive searching, random broken chars with specific markup,
incompatibilities with many reciepts (most of them are using the limited
single-byte PHP string functions) and many
Athan wrote:
thanks for the information on UTF-8. I will stay with ISO-8859-1
[...]
(you wrote even pmwiki.org seems not to send any encoding header)
One minute ago, I got a HTTP-Header Content-Type: text/html;
charset=ISO-8859-1; from pmwiki.org
Don't know about 8859-1, but the rest
12 matches
Mail list logo
