+1 for option 2 Catalin On 3/10/07, Sebastien Gaide <[email protected]> wrote:
Wow ! so many good arguments against everything in UTF8 from you and VIncent. OK I understand better now why UTF8 everywhere may be problem.
nevertheless, we have used utf8 for everything for more than a year now (Eclipse, vi, notepad++) with no special configuration for javac, maven etc ... and as of today with no problem. But of course our team is less spread than the XWiki team ...
S.
2007/3/10, Sergiu Dumitriu <[email protected]>:
On 3/10/07, Sébastien Gaïde <[email protected]> wrote:
Vincent Massol a écrit :
+1 option 2 too (I think option 1 is never going to work because it's too constraining for developers).
why ?
XWiki is the only project that is not encoded in utf8 in my workspace. All the other projects are 100% utf8, with no problem.
Depending on a particular encoding is bad because: - The IDE has to be configured to use the encoding - Building from command line needs extra parameters - Opening a file using a standalone viewer, and not an IDE, will display the file using the system encoding, and we can't tell the user to change this - There are some people still using a shell, and something like midnight commander to open files, and the support for non-ascii chars is not so good in text shells.
So the best solution would be not to have any special chars in the source files, so that any encoding works fine. However, there are some modules, like tests and translation files, where special characters are needed. And the only way to correctly display these chars in any environment is to use \u sequences. Still, we should make a full switch to utf8, including the source, so we should switch all the files to utf8.
Sergiu
S.
-Vincent
On Mar 8, 2007, at 4:01 PM, Gilles Serasset wrote:
Hi all,
While working on encodings problems, I saw that some of the source file do use non ascii chars (which is normal, especially in unit
tests).
But, there is currently no decision on the encoding of the source file, hence, compilers cannot correctly read the files that do use non ascii chars. This leads to tests working on single instances but not on others, only due to compilation settings.
There are 2 solutions:
1. force everybody to use UTF-8 encoding for their source files (it's quite easy to st up most IDE once and for all for this...) and specify the encoding in javac parameters in ant and maven. 2. force everybody to use unicode escapes (\uXXXX) to specify a non ascii char in the sources (easily detectable on build, but harder for developpers who have to use native2ascii)
Current files with non ascii chars:
/Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/main/java/com/xpn/xwiki/plugin/autotag/FrenchStemmer.java
/Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/main/java/com/xpn/xwiki/plugin/autotag/AutoTagPlugin.java
(Both are in ISO-8859-1)
/Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/test/java/com/xpn/xwiki/content/LinkTest.java
(this one seems to be encoded in VISCII (vietnamese encoding)
As in LinkTest.java, the test uses vietnamese characters, it's likely that ISO-8859-1 encoding is not a viable option for the xwiki source encoding. In the mean time, LinkTest.java should use \uXXXX uniocde escapes in order to run correctly in all installs.
Can you please tell me which solution you prefer ?
Regards,
-- Gilles Sérasset GETALP-LIG BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
--
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws