For property files that are expected to have international characters, the problem with using ISO-8859-1 is that a great many of those characters require \xNNNN escape sequences, and that makes the text unreadable to the human eye, so then you need some special editor support (e.g. a plugin).
As it says at http://tapestry.apache.org/localization.html, Tapestry expressly uses UTF-8 when reading the properties files in a message catalog. This means that message catalog property files should be encoded as UTF-8 (but *without* a BOM). No need to use the Java native2ascii tool or a special editor. On Tue, Feb 12, 2013 at 4:14 AM, Johan Stuyts <j.stu...@javathinker.com> wrote: >> Tapestry expects UTF-8. > > > Which is fine for file types defined by Tapestry. > > >> Eclipse handles UTF-8 just fine. Eclipse can be set to default to UTF-8 >> for templates and properties: >> >> Preferences > General > Content Types > Text > HTML > *.tml >> Preferences > General > Content Types > Text > Java Properties >> File > *.properties > > > I never ever override the specifications of a file type for any project. > What if I have another project open that does stick to the specification? > > >> If you go down this path then all languages work without further thought, >> so I'd sincerely recommend it. > > > All languages will work without further thought if you stick to the > specification of Java properties files. Problems can be caused by one or > more of the following: > - Your IDE: it does not properly support Java properties files. It uses a > text editor that uses the default encoding of the user to store properties > files. Your IDE is essentially generating corrupt files. A better IDE or an > additional plug-in will fix that. > - Your API/framework: it does not properly read properties files. > > >> You can see it working fine in all of JumpStart including the localization >> examples. > > > It's not about whether it works in one particular situation or not. Not > adhering to a specification may break other applications/tools. > > There is absolutely no need to muck around with the encoding of Java > properties files. It is very well defined. By using the correct tools and > APIs everything will work perfectly. > > Note that Java 1.6 introduced additional methods that accept "Reader"s and > "Writer"s. A bad decision IMHO because the encoding of properties files can > now be anything instead of one fixed encoding. > > > -- > Regards, Johan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
