Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49D478CB.1080403@student.ethz.ch>
Date: Thu, 02 Apr 2009 10:35:23 +0200
From: Stefan Ackermann <acki@student.ethz.ch>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [GSOC] Questions about harmony i18n
References: <op.uroesxbn8otnuk@c2d>
 <5c8e69f0903312236g6eed4ffayefbf41df59793035@mail.gmail.com>
In-Reply-To: <5c8e69f0903312236g6eed4ffayefbf41df59793035@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

(I did send this message yesterday, but my mail client was temporarily wrong configured)

Hi,

Ok so I misunderstood the purpose of this.
>From my first trials I think it is very hard to try to guess which
Strings should be translated or not. The resulting tool has to be
extremely configurable.

>From my short observation I already got this list of types of Strings
that can appear hardcoded in a program, that should not be translated:
filenames
sql queries
xml
urls
formats
class names
system properties keys
parts of any of the above

Then there can also be application specific identifiers defined, like
for example names of settings. For this I would allow to filter the
strings with a simple interface like: public boolean filter(String s);
However, I played around with a simple program that just counted the
whitespace in each String and that is quite a good start, for
recognizing almost all of the above (not sql queries though).

I think for a useful tool it would need a GUI to try out different
parameters for the heuristics. There should definitely be a stop list, a
list of strings which are never translated.
But if I were to write such a tool, I would probably do it as an eclipse
plugin, because for some analysis a fully powered AST would be nice.
With an AST one could for example transform more easily:
String a = "Number of users: "+users+" on the server: "+server;
to a more i18n friendly:
String a = String.format("Number of users: %1s on the server:
%2s",users,server);
(or what ever format function you want to use)

With an AST a developer could then also define that he does not want to
translate Strings within log calls, or any kind of specific calls for
that matter. Also eclipse already is able to write property files and do
other tedious tasks around this.

However I am too involved with my other application, so maybe this will help someone.

Cheers,
Stefan


Jimmy,Jing Lv wrote:
> Hi Stefan,
>
>      Yes Harmony Project has already made an infrastructure there, and I
> believe it's good and we do not need to replace it. Jilkit seems the similar
> with the infrastructure. However the project harmony i18n tool does not
> focus on the translation and i18n itself, but on the overall solution of any
> Java projects i18n. Which requires a tool, which automatically extract the
> messages in source code, analysis if necessary to localized, then translate
> and adjust, and at last inject into the source code and apply the
> localization. So with this tool, any developer of a Java projects can use it
> to make his non-i18n project to a localized one. This processing may help
> projects to be easy to be used by customers thus is valuable.
>      And I believe some of the messages are welcomed by customers if they
> see a error message "out of memory "(maybe he know how to configure the -Xmx
> etc), rather than some un-readable messages for him "blablala". What's more,
> there's many output information for one java application need to be i18n.
>
>      Yes to tell if some Strings should be localized or not is one of the
> key design in this project. The students can raise their ideas and show
> their elaboration in their proposal, and discuss with the mentors about this
> issue.
>
> 2009/4/1 Stefan Ackermann <acki@student.ethz.ch>
>
>   
>> Hi again,
>>
>> I am a bit puzzled about this project. A lot of bundles seem to use a tool
>> named jilkit. At least thats the impression I get when looking at:
>>
>> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/org/apache/harmony/x/swing/internal/nls/Messages.java?revision=500804&view=markup
>> which after a bit of googling (msgtool) led me to jilkit but no further...
>> Are we supposed to replace that mechanism?
>>
>> Some other thoughts anyway:
>> Eclipse already has a feature externalize Strings.
>>
>> http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/reference/ref-wizard-externalize-strings.htm
>> If EPL is compatible that would most likely make a good starting point.
>>
>> I also dont know which Strings should be localized and which not. Of course
>> if it changes the semantics of the program it should not, but what about the
>> text in Exceptions? Those are usually only read by developers, not as much
>> by end users so the time it takes to translate them may be in excess to the
>> use of it.
>>
>> I think this task needs more elaboration.
>>
>> Thanks in advance for replies,
>> Stefan
>>
>>     
>
>
>
>