8 Dec
2012
8 Dec
'12
1:31 a.m.
+1 for utf-8 only.
Ok to wait till 5.0 unless there are good migrations.
To be able to answer I need to understand more. For
example what currently doesn't work with any encoding the user wants to use?
Shouldn't we just be transparent and use whatever encoding is specified and not
hardcode anything?
Unfortunately, this has been a dream that never comes true that has never been
sufficiently tested.
I know for sure that both Solr and XWiki will remain imperfect at some edge cases which
few people test if their application-level-configured encoding differs from the
platform-encoding.
XWiki may well have thought well about this since its developers pay attention to
deprecations often, there's a zillion remaining other places where this is not done as
cleanly.
Sergiu, I understand your proposal to include a validation of the environment at startup,
is that correct? Including a validation of the DB abilities?
paul
We've
moved more and more toward an UTF-8-only application, and XWiki
has only been tested with this configuration for several years.
I propose that we require UTF-8 for a valid, supported installation.
This means:
- JVM encoding (-Dfile.encoding=UTF8)
- Container default URL encoding (Tomcat has ISO-8859-1 by default)
- Database encoding (MySql is still configured with latin1 on some distros)
There's one big site to update on our side: xwiki.org.
Here's my +1. This is a move toward a future web, since more and more
standards require (or at least assume as a default) UTF-8.
After thinking a bit more, it would make sense to require a valid
Unicode encoding, including UTF-16, which is preferable in countries
that don't use a latin alphabet. However, XWiki doesn't currently work
under 16-bit encodings at all.
For XWiki 4.x I'm -1 since it's a big change and we don't want to break our
users that currently use 4.x with ISO8859-1 for example
For XWiki 5.x I'm not sure.