By my reading of Java history, the notion that a Java properties file must be encoded in ISO 8859-1 is a remnant from the days before the Java SE 1.6 specification. Given that 1.6 has been with us for 6 years now - in fact it is so old that it is being end-of-lifed this month - I'd suggest it is appropriate and safe to let go of that notion, perhaps on a project-by-project basis.
Besides, let's face it, ISO 8859-1 was a pretty narrow-minded choice in the first place. On 12/02/2013, at 10:40 PM, Bob Harner wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
