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: translation checker...
Date Wed, 01 Nov 2006 21:51:11 GMT
On 10/31/06, Rajesh Kartha <kartha02@gmail.com> wrote:
> Myrna van Lunteren wrote:
> > Hi,
> >
> > I wrote a silly translation check program (LocCompare.java) that flags
> > possible trouble between the current english locale files and possible
> > new translations.
> > You'd have to build the class, add it to the classpath, put the
> > possible new translations files in two (one top, and a subdir for the
> > drda ones) directories and run the class like so:
> >
> > - java  -Dderbysvntop=<top of trunk or source> -Dtranslations=<temp
> > location topdir> LocCompare pt_BR > checkBR.out 2>&1
> >
> > I used the current Brazilian translations because they're the most up
> > to date...I copied them to the temporary location.
> > I'm attaching the output (with the actual location edited out manually).
> >
> > 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?
> >
> > Thx,
> > Myrna
> 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?
> Another question:
> - The outfile - is it possible to print the  English reference message
> and the respective locale message in question - to make
>   the errors more clearer. (something like a diff utility).
Yes, that's possible. In fact, it's one of the things that gets spit
out when you run with the additional -Dtvtdebug=true. It's not going
to attempt an actual 'diff', but it prints out the messages it's
comparing (first english, then translated).

>  - Why do we need the argument -Dtranslations=<temp location topdir>,
> can't we use the locale files (patched/checked out ones) in the codeline.
>   Can we avoid this, copying the files to a temp location for verifying
> seems a bit cumbersome.
>    Something like: java  -Dderbysvntop=<top of trunk or source>
> LocCompare pt_BR > checkBR.out 2>&1
Sure, we could do this...It would mean modifying some of the path
dependencies inside the file.

> About the location,  I suppose  this utility needs to be run only when
> the locales files are updated or to find messages that are not
> translated (?).
Yes, those would be the times. (Although, actually, the file that I
attached actually returns on the first missing message & goes on to
the next locale file. I've modified that in a newer version).

> In that case, I would think it can reside under the
> trunk/java/derbyTesting/locale/utils (?) directory with the appropriate
> package name.  We
> would also need a Readme/HowTo that mentions what the utility does and
> how to use it etc.
> If anyone else have other suggsestions  please send a mail to the list.

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.

> -Rajesh
Thx for your reply.


View raw message