From 6e061f51846b0d85c08505f27299405c9868e24d Mon Sep 17 00:00:00 2001 From: "Edward Z. Yang" Date: Wed, 24 Jan 2007 21:24:54 +0000 Subject: [PATCH] I18N -> International/internationalization git-svn-id: http://htmlpurifier.org/svnroot/htmlpurifier/trunk@696 48356398-32a2-884e-a903-53898d9a118a --- docs/enduser-utf8.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/enduser-utf8.html b/docs/enduser-utf8.html index 12a114c0..7144a202 100644 --- a/docs/enduser-utf8.html +++ b/docs/enduser-utf8.html @@ -572,7 +572,7 @@ Each method has deficiencies, especially the former.

the page, you still have the trouble of what to do with characters that are outside of the character encoding's range. The behavior, once again, varies: Firefox 2.0 entity-izes them while Internet Explorer -7.0 mangles them beyond intelligibility. For serious I18N purposes, +7.0 mangles them beyond intelligibility. For serious internationalization purposes, this is not an option.

The other possibility is to set Accept-Encoding to UTF-8, which @@ -640,7 +640,7 @@ set the encoding correctly using %Core.Encoding):

This behaviour is quite unsatisfactory. It is a deal-breaker for -I18N applications, and it can be mildly annoying for the provincial +international applications, and it can be mildly annoying for the provincial soul who occasionally needs a special character. Since 1.4.0, HTML Purifier has provided a slightly more palatable workaround using %Core.EscapeNonASCIICharacters. The process now looks like:

@@ -671,7 +671,7 @@ to be smart and only convert non-ASCII characters that weren't supported by the target encoding, but that would require reimplementing iconv with HTML awareness, something I will not do.

-

So there: either it's UTF-8 or crippled I18N support. Your pick! (and I'm +

So there: either it's UTF-8 or crippled international support. Your pick! (and I'm not being sarcastic here: some people could care less about other languages)

Migrate to UTF-8

@@ -746,7 +746,7 @@ Doing so can save you some huge headaches:

and attempting to convert your text when you don't want it to. -

MediaWiki, a very prominent I18N application, uses binary fields +

MediaWiki, a very prominent international application, uses binary fields for storing their data because of point three.

There are drawbacks, of course: