db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: Re: translation checker...
Date Thu, 02 Nov 2006 05:12:31 GMT
On 11/1/06, Myrna van Lunteren <m.v.lunteren@gmail.com> wrote:
> > > There's little actual failures I found, but still...
> > > Does this look like a useful tool to be added to derby?
> > > If so, where should it live?

If it finds any problems, then it's useful.

If we're not going to actually employ it at build time to do anything,
and it doesn't look like we will, then we should put it into
tools/i18n/ or tools/testing/i18n/ or somewhere like that, along with
a readme and a simple build.xml that builds it into the same directory
as the source.

> > I think this will be really useful going forward, as  locale files are
> > updated  by the Derby community. I will surely give this
> > a try. Also noticed you are using "UTF8" as encoding for reading the
> > locale  files - is the reason that all the respective locale files
> > (Chinese, Japanese etc.)  are unicode escaped ?
> It's more that I took "UTF8" to be needed to handle this unicode
> escaped files. Maybe I was wrong and another encoding is better?

The javadoc for java.util.Properties says ISO8859-1 is used to encode
characters in properties files. The JLS, 2nd Edition says all
non-ASCII characters needing to be Unicode Escapes in section 3.3. I'm
going with the JLS, since native2ascii converts valid ISO8859-1
characters in the 128-255 range into Unicode Escapes. So, maybe
LocCompare should detect anything outside of the US-ASCII character
set and report that as a problem.

> Well, of course, I have no idea how this is matching out with Rick's
> new messages.xml.
> I need to look at that and see if anything in my little program is
> still of value.

Well, if messages.xml was the file being translated, then you could
rewrite it to compare nodes in the XML files. As it is, we're still
working with the translations being properties files, so when you run
LocCompare, you just need to make sure you've done a build so that the
messages_en.properties has been generated from the XML.

Just a usability note, it might be nice for it to compare any
translated files in a directory relative to the source. e.g. if you
pass in java/engine/org/apache/derby/loc/messages_en.properties as the
source file, then it compares all the other messages_*.properties in
the same directory as messages_en.properties and provides a report for
all localized files it finds.


View raw message