db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: Re: translation checker...
Date Thu, 02 Nov 2006 14:46:03 GMT
On 11/1/06, Andrew McIntyre <mcintyre.a@gmail.com> wrote:
> 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.
> andrew
Thx for your response.
On the last comment, Rajesh made the same comment, and it does make
sense. I will
 - open a JIRA
 - rework the program
   - investigate detecting the non-US-ASCII characters
   - maybe changing to ISO-8859-1 instead of UTF8
   - change the location of non-en locale properties files to be same
as en locale properties files

I had come to the same conclusion re
messages_en.properties/messages.xml. If anyone adjusts the translated
files to being xmls also, then we need to rewrite this program
too...(change file names, ensure it's not checking for < or >...)


View raw message