Re: [classlib]strings externalization
On 8/31/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> Hi, Jimmy!
>
> It's great that you are interested in it!
> Unfortunately there is no automatic externalization generation tool that
> fits our needs. However, you can combine Eclipse externalization tool
with
> some manual work to get what is need. You can take a look into the
> [classlib]strings externalization thread [1] for details. Main points
> briefly:
> 1. Using Eclipse externalization tool you can extract all strings from
the
> sources. When you process certain source file strings that used for
> messages
> should be externalized, others should be ignored (as a result, Eclipse
mark
> them with non-nls tag).
> 2. Eclipse tool by default suggests you to use keep messages from each
> class
> in the separate messages.properties file, and keys in the properties
file
> will looks like .. We've decided to have one messages
list
> for each module with keys . (in your case ==
> instrument
> :)). Thus at first you should change common prefix to ".". Next
> step
> is to configure "Accessor class" field: choose the proper package for
> Messages class and messages.properties file("org.apache.harmony
> ..msgstool").
>
> What is to take care of:
> 1. Continuation of the numeration of messages. For every new source file
> you
> process Eclipse tool will reset enumeration, and you should manually set
> the
> appropriate number for messages. Also it would be better if you avoid
> messages duplication in the list. (Pretty annoying if you have many
> messages
> in the module and some of them are duplicated)
> 2. Messages formatting. If you have message located on the several
source
> code lines - you should concatenate them into one message string and use
> one
> Messages.getString(..) call. Also messages with arguments are supposed
> to be
> converted to strings with places for substitution by parameters being
> arguments in Messages.getString() method. E.g. code:
>
> int param;
> ...
> NullPointerException("foo " + param + " bar");
>
> supposed to be formatted as
>
> NullPointerException(Messages.getString(".1", param));
>
> where ".1=foo {0} bar" in the resource bundle.
>
> I hope now the process is clear.
> You can find examples of internationalized messages in the [sql] module.
>
> As for messages in native code, actually I dealt only with java code.
> You may find something interesting for you from the "[drlvm] proposals
for
> VM c" thread [2].
>
> Regards,
> Ilya.
>
> [1]
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
>
> [2]
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
>
>
Thanks Ilya, I'll apply patch soon. I deal with Java code only this
time, it is simple that I only find 3 strings :) I'll put them in
messages.properties under instrument with name "instrument.1(2,3)" and
update codes.
Instrument also have an console output string, I suggest also put it to
property file so it can be internationalization as well. Then there are
4 total.
And strings in native code may be refactored if we have conclusion of
native internationalization.
You are lucky, some modules have more then 50 different messages to
internationalize:)
I've already uploaded patches for several modules (e.g. auch, archive) you
can take a look for examples there.
If you've finished with instrument you can update HARMONY-1333 issue.
You are right about console output string, it is also "a message".
One note, if there is not so many messages in your module - it would be
great to have comments with message key and it's value before
Messages.getString() call. It will be usefull to have this info right in the
source code not to spend time looking for it in the messages.propertiesfile. (
e.g. it is done in sql module)
Regards,
Ilya.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib]strings externalization
Ilya Okomin wrote:
Hi, Jimmy!
It's great that you are interested in it!
Unfortunately there is no automatic externalization generation tool that
fits our needs. However, you can combine Eclipse externalization tool with
some manual work to get what is need. You can take a look into the
[classlib]strings externalization thread [1] for details. Main points
briefly:
1. Using Eclipse externalization tool you can extract all strings from the
sources. When you process certain source file strings that used for
messages
should be externalized, others should be ignored (as a result, Eclipse mark
them with non-nls tag).
2. Eclipse tool by default suggests you to use keep messages from each
class
in the separate messages.properties file, and keys in the properties file
will looks like .. We've decided to have one messages list
for each module with keys . (in your case ==
instrument
:)). Thus at first you should change common prefix to ".". Next
step
is to configure "Accessor class" field: choose the proper package for
Messages class and messages.properties file("org.apache.harmony
..msgstool").
What is to take care of:
1. Continuation of the numeration of messages. For every new source file
you
process Eclipse tool will reset enumeration, and you should manually set
the
appropriate number for messages. Also it would be better if you avoid
messages duplication in the list. (Pretty annoying if you have many
messages
in the module and some of them are duplicated)
2. Messages formatting. If you have message located on the several source
code lines - you should concatenate them into one message string and use
one
Messages.getString(..) call. Also messages with arguments are supposed
to be
converted to strings with places for substitution by parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException("foo " + param + " bar");
supposed to be formatted as
NullPointerException(Messages.getString(".1", param));
where ".1=foo {0} bar" in the resource bundle.
I hope now the process is clear.
You can find examples of internationalized messages in the [sql] module.
As for messages in native code, actually I dealt only with java code.
You may find something interesting for you from the "[drlvm] proposals for
VM c" thread [2].
Regards,
Ilya.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
Thanks Ilya, I'll apply patch soon. I deal with Java code only this
time, it is simple that I only find 3 strings :) I'll put them in
messages.properties under instrument with name "instrument.1(2,3)" and
update codes.
Instrument also have an console output string, I suggest also put it to
property file so it can be internationalization as well. Then there are
4 total.
And strings in native code may be refactored if we have conclusion of
native internationalization.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Hi, Jimmy!
It's great that you are interested in it!
Unfortunately there is no automatic externalization generation tool that
fits our needs. However, you can combine Eclipse externalization tool with
some manual work to get what is need. You can take a look into the
[classlib]strings externalization thread [1] for details. Main points
briefly:
1. Using Eclipse externalization tool you can extract all strings from the
sources. When you process certain source file strings that used for messages
should be externalized, others should be ignored (as a result, Eclipse mark
them with non-nls tag).
2. Eclipse tool by default suggests you to use keep messages from each class
in the separate messages.properties file, and keys in the properties file
will looks like .. We've decided to have one messages list
for each module with keys . (in your case == instrument
:)). Thus at first you should change common prefix to ".". Next step
is to configure "Accessor class" field: choose the proper package for
Messages class and messages.properties file("org.apache.harmony
..msgstool").
What is to take care of:
1. Continuation of the numeration of messages. For every new source file you
process Eclipse tool will reset enumeration, and you should manually set the
appropriate number for messages. Also it would be better if you avoid
messages duplication in the list. (Pretty annoying if you have many messages
in the module and some of them are duplicated)
2. Messages formatting. If you have message located on the several source
code lines - you should concatenate them into one message string and use one
Messages.getString(..) call. Also messages with arguments are supposed to be
converted to strings with places for substitution by parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException("foo " + param + " bar");
supposed to be formatted as
NullPointerException(Messages.getString(".1", param));
where ".1=foo {0} bar" in the resource bundle.
I hope now the process is clear.
You can find examples of internationalized messages in the [sql] module.
As for messages in native code, actually I dealt only with java code.
You may find something interesting for you from the "[drlvm] proposals for
VM internationalization" thread [2].
Regards,
Ilya.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
On 8/30/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> Tim, great news for me.
>
> Everything looks fine with the patch you've applied, now it's time for
the
> main part of the task.
> I've created HARMONY-1308 issue with task description. This issue is
> devided
> into a set of sub-issues for each module. I'm going to process them one
by
> one. These issues can be processed in a parallel way, so everyone is
> welcomed to take part in the internationalization process :)
>
>
Hi,
Ilya, I'd like to process instrument :) Can you tell me something
about the generation tool, or how can we process these strings? Is there
anything to take care of?
And in fact, in java.lang.instrument, there are some error messages
in native code(AFAIK, there are also many in luni). Is there any tool to
find them out automatic ?
> Thanks,
> Ilya.
>
> On 8/29/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>
>> Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201
>> (I'll check-in the tool when I get back from vacation). So now we can
>> get to work on breaking out the messages into each component's message
>> file.
>>
>> Regards,
>> Tim
>>
>> Ilya Okomin wrote:
>> > On 8/11/06, Tim Ellison <[EMAIL PROTECTED] > wrote:
>> >>
>> >> I took a look at the HARMONY-1041 tool. It is fine, I have only
minor
>> >> comments:
>> >>
>> >> - do you think we need to separate the Message and MsgUtil types?
>> >> Given that they are generated from a template I'd be inclined to
>> combine
>> >> them into a single type now. We have no need to look in that file
in
>> >> general. If you do choose to combine them then I would expect the
>> >> resulting header to be (c) 1998, 2006.
>> >>
>> >> - Minor typo "Better make changes in the teamplate file." ->
template.
>> >>
>> >> Ilya Okomin wrote:
>> >> > I would suggest to split this task into a set of jira sub-issues,
>> one
>>
>> >> > module - one issue. This kind of division would give us an
>> >> > op
Re: [classlib]strings externalization
Ilya Okomin wrote: Tim, great news for me. Everything looks fine with the patch you've applied, now it's time for the main part of the task. I've created HARMONY-1308 issue with task description. This issue is devided into a set of sub-issues for each module. I'm going to process them one by one. These issues can be processed in a parallel way, so everyone is welcomed to take part in the internationalization process :) Hi, Ilya, I'd like to process instrument :) Can you tell me something about the generation tool, or how can we process these strings? Is there anything to take care of? And in fact, in java.lang.instrument, there are some error messages in native code(AFAIK, there are also many in luni). Is there any tool to find them out automatic ? Thanks, Ilya. On 8/29/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201 (I'll check-in the tool when I get back from vacation). So now we can get to work on breaking out the messages into each component's message file. Regards, Tim Ilya Okomin wrote: > On 8/11/06, Tim Ellison <[EMAIL PROTECTED] > wrote: >> >> I took a look at the HARMONY-1041 tool. It is fine, I have only minor >> comments: >> >> - do you think we need to separate the Message and MsgUtil types? >> Given that they are generated from a template I'd be inclined to combine >> them into a single type now. We have no need to look in that file in >> general. If you do choose to combine them then I would expect the >> resulting header to be (c) 1998, 2006. >> >> - Minor typo "Better make changes in the teamplate file." -> template. >> >> Ilya Okomin wrote: >> > I would suggest to split this task into a set of jira sub-issues, one >> > module - one issue. This kind of division would give us an >> > opportunity this work to be done in a parallel mode. >> >> Agreed. I suggest that we run the msgtool on the existing modules and >> commit the generated code and catalog files, then the incoming patches >> can assume they are there and use them to fix the externalization. > > > Hello, Tim! > > I've made changes to the generation tool [1] and also prepared patch with > the set of generated files according to the existing modules set I've > raised > issue for that [2]. Not all modules were included into the generation (full > set can be found in comments to the [2]). E.g. x-net module has package > xnet, also I'm not sure about necessity to make internationalization in > suncompat or rmi2, etc. You can check list of suggested modules and if > something is missed I'll make update. > Waiting for your comments and proposals! > > [1]http://issues.apache.org/jira/browse/HARMONY-1041 > [2]http://issues.apache.org/jira/browse/HARMONY-1201 > > Regards, > Ilya. > > > Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Tim, great news for me. Everything looks fine with the patch you've applied, now it's time for the main part of the task. I've created HARMONY-1308 issue with task description. This issue is devided into a set of sub-issues for each module. I'm going to process them one by one. These issues can be processed in a parallel way, so everyone is welcomed to take part in the internationalization process :) Thanks, Ilya. On 8/29/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201 (I'll check-in the tool when I get back from vacation). So now we can get to work on breaking out the messages into each component's message file. Regards, Tim Ilya Okomin wrote: > On 8/11/06, Tim Ellison <[EMAIL PROTECTED] > wrote: >> >> I took a look at the HARMONY-1041 tool. It is fine, I have only minor >> comments: >> >> - do you think we need to separate the Message and MsgUtil types? >> Given that they are generated from a template I'd be inclined to combine >> them into a single type now. We have no need to look in that file in >> general. If you do choose to combine them then I would expect the >> resulting header to be (c) 1998, 2006. >> >> - Minor typo "Better make changes in the teamplate file." -> template. >> >> Ilya Okomin wrote: >> > I would suggest to split this task into a set of jira sub-issues, one >> > module - one issue. This kind of division would give us an >> > opportunity this work to be done in a parallel mode. >> >> Agreed. I suggest that we run the msgtool on the existing modules and >> commit the generated code and catalog files, then the incoming patches >> can assume they are there and use them to fix the externalization. > > > Hello, Tim! > > I've made changes to the generation tool [1] and also prepared patch with > the set of generated files according to the existing modules set I've > raised > issue for that [2]. Not all modules were included into the generation (full > set can be found in comments to the [2]). E.g. x-net module has package > xnet, also I'm not sure about necessity to make internationalization in > suncompat or rmi2, etc. You can check list of suggested modules and if > something is missed I'll make update. > Waiting for your comments and proposals! > > [1]http://issues.apache.org/jira/browse/HARMONY-1041 > [2]http://issues.apache.org/jira/browse/HARMONY-1201 > > Regards, > Ilya. > > > Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201 (I'll check-in the tool when I get back from vacation). So now we can get to work on breaking out the messages into each component's message file. Regards, Tim Ilya Okomin wrote: > On 8/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> I took a look at the HARMONY-1041 tool. It is fine, I have only minor >> comments: >> >> - do you think we need to separate the Message and MsgUtil types? >> Given that they are generated from a template I'd be inclined to combine >> them into a single type now. We have no need to look in that file in >> general. If you do choose to combine them then I would expect the >> resulting header to be (c) 1998, 2006. >> >> - Minor typo "Better make changes in the teamplate file." -> template. >> >> Ilya Okomin wrote: >> > I would suggest to split this task into a set of jira sub-issues, one >> > module - one issue. This kind of division would give us an >> > opportunity this work to be done in a parallel mode. >> >> Agreed. I suggest that we run the msgtool on the existing modules and >> commit the generated code and catalog files, then the incoming patches >> can assume they are there and use them to fix the externalization. > > > Hello, Tim! > > I've made changes to the generation tool [1] and also prepared patch with > the set of generated files according to the existing modules set I've > raised > issue for that [2]. Not all modules were included into the generation (full > set can be found in comments to the [2]). E.g. x-net module has package > xnet, also I'm not sure about necessity to make internationalization in > suncompat or rmi2, etc. You can check list of suggested modules and if > something is missed I'll make update. > Waiting for your comments and proposals! > > [1]http://issues.apache.org/jira/browse/HARMONY-1041 > [2]http://issues.apache.org/jira/browse/HARMONY-1201 > > Regards, > Ilya. > > > Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 8/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo "Better make changes in the teamplate file." -> template. Ilya Okomin wrote: > I would suggest to split this task into a set of jira sub-issues, one > module - one issue. This kind of division would give us an > opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. Hello, Tim! I've made changes to the generation tool [1] and also prepared patch with the set of generated files according to the existing modules set I've raised issue for that [2]. Not all modules were included into the generation (full set can be found in comments to the [2]). E.g. x-net module has package xnet, also I'm not sure about necessity to make internationalization in suncompat or rmi2, etc. You can check list of suggested modules and if something is missed I'll make update. Waiting for your comments and proposals! [1]http://issues.apache.org/jira/browse/HARMONY-1041 [2]http://issues.apache.org/jira/browse/HARMONY-1201 Regards, Ilya. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo "Better make changes in the teamplate file." -> template. Ilya Okomin wrote: > I would suggest to split this task into a set of jira sub-issues, one > module - one issue. This kind of division would give us an > opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 8/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Ilya Okomin wrote: > Hi to all! > > Today I've started the next step of internationalization - to externalize > messages using Eclipse externalization tool. Right away I was confronted > with some questions to discuss: > > First of all, what should we do with strings that are not supposed to > be internationalized (constants, initiated variables..)? Should we > mark them " //$NON-NLS-%id%$" comment (Eclipse tool skip such strings > during externalization process)? IMHO there is a sence to do this, > marked strings will not be taken into account next time > externalization revision is required. Objections? No objection -- good idea. Reduces ECJ compiler warnings. > Next point, there is a lot of manual work during messages processing > (unite messages that are on the several lines of the source code, > change messages with params to the proper formatted messages). When > doing this work there are changes in source code and > messages.properties files are made. Yep, but we can work through them a module at a time or parallel-ise the work depending on how much help we get. It is a good opportunity for people to contribute to Harmony. I would suggest to split this task into a set of jira sub-issues, one module - one issue. This kind of division would give us an opportunity this work to be done in a parallel mode. As it is manual work - some mistakes could be done, non-critical: > usually wrong message if getString() takes wrong key as a parameter. > Is there supposed a verification that everything is done well? May be > any test cases (at the moment I have no idea how these test cases may > look) or another revision? Probably the better strategy is to wait > if someone who face with wrong message will inform about that:) > Thoughts? We don't have any tests that would catch this at the moment. So unless there are any ideas we have to rely on steady working and peer reviews of the patches and commits. As you point out we would expect it to be noticeable at the point the message is displayed if it were incorrect. The easiest way;-) I'm sure, there will be not so many such exceptional cases. And the last one point. I think the process of internationalization support > must be up-to-date, for this reason after adding new contributions all > messages there are to be internationalized. Probably there is a sence to > make rule to do this routinely after contribution is applied (or even > before, people who are going to make contribution should be acquainted with > internationalization in Harmony to use it in their development process). Yes, once you have figured out the APIs and a couple of examples it would be good to add it as a document to the coding practices. I'm not sure I would reject a patch for non-compliance, but the compiler warnings will remind us to go in and fix it. I'll prepare useful exapmles to support chosen way to internationalize messages. Tim, thank you for comments, no it is clear what to do next. Regards, Ilya. Waiting for comments and suggestions! Sorry they were so late! Regards, Tim > On 8/2/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: >> >> >> >> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > Ilya Okomin wrote: >> > > I share your point of view about Exceptions without description, it >> > > isn't user friendly. But I think it will be another sort of 'manual' >> > > scan :) There is a need to waste time to analyze surrounding code to >> > > provide appropriate message, a bit another sort of work, isn't it? I >> > > think the best way would be if all these Exceptions without info are >> > > being identified before externalization process is to be ran. For >> > > today I'd better postpone the task of initialization 'empty' >> > > exceptions until the externalization is finished. >> > >> > Sure, I agree that it is a different problem, so have no problem >> dealing >> > >> > with it separately. >> > >> > > I've implemented a small tool that generates Message source and >> > > MsgHelp source into a desired module. Tool gets a list of modules >> > > names from property file (you can specify modules class sources to >> > > generate for), then we run over the list and special word '' >> > > in Message and MsgHelp source templates files replaced with the >> > > specified module name. >> > >> > Cool. You may find it easy to do this using Ant's replace task [1]. >> > >> > [1] http://ant.apache.org/manual/CoreTasks/replace.html >> > >> > > Resulting sources are copied to the o/a/h//internal/ >> > > directory. At first I planned to use MsgHelp class from luni but >> > > after a while I've decided to avoid dependency on luni module and >> > > included generation source file of this class to every module. >> > >> > I agree, if you are going to do the template then you might as well >> > duplicate the MsgHelp behavior across the modules. In fact, don't feel >> > obliged to maintain the separation of Message and
Re: [classlib]strings externalization
Ilya Okomin wrote: > Hi to all! > > Today I've started the next step of internationalization - to externalize > messages using Eclipse externalization tool. Right away I was confronted > with some questions to discuss: > > First of all, what should we do with strings that are not supposed to > be internationalized (constants, initiated variables..)? Should we > mark them " //$NON-NLS-%id%$" comment (Eclipse tool skip such strings > during externalization process)? IMHO there is a sence to do this, > marked strings will not be taken into account next time > externalization revision is required. Objections? No objection -- good idea. Reduces ECJ compiler warnings. > Next point, there is a lot of manual work during messages processing > (unite messages that are on the several lines of the source code, > change messages with params to the proper formatted messages). When > doing this work there are changes in source code and > messages.properties files are made. Yep, but we can work through them a module at a time or parallel-ise the work depending on how much help we get. It is a good opportunity for people to contribute to Harmony. > As it is manual work - some mistakes could be done, non-critical: > usually wrong message if getString() takes wrong key as a parameter. > Is there supposed a verification that everything is done well? May be > any test cases (at the moment I have no idea how these test cases may > look) or another revision? Probably the better strategy is to wait > if someone who face with wrong message will inform about that:) > Thoughts? We don't have any tests that would catch this at the moment. So unless there are any ideas we have to rely on steady working and peer reviews of the patches and commits. As you point out we would expect it to be noticeable at the point the message is displayed if it were incorrect. > And the last one point. I think the process of internationalization support > must be up-to-date, for this reason after adding new contributions all > messages there are to be internationalized. Probably there is a sence to > make rule to do this routinely after contribution is applied (or even > before, people who are going to make contribution should be acquainted with > internationalization in Harmony to use it in their development process). Yes, once you have figured out the APIs and a couple of examples it would be good to add it as a document to the coding practices. I'm not sure I would reject a patch for non-compliance, but the compiler warnings will remind us to go in and fix it. > Waiting for comments and suggestions! Sorry they were so late! Regards, Tim > On 8/2/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: >> >> >> >> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > Ilya Okomin wrote: >> > > I share your point of view about Exceptions without description, it >> > > isn't user friendly. But I think it will be another sort of 'manual' >> > > scan :) There is a need to waste time to analyze surrounding code to >> > > provide appropriate message, a bit another sort of work, isn't it? I >> > > think the best way would be if all these Exceptions without info are >> > > being identified before externalization process is to be ran. For >> > > today I'd better postpone the task of initialization 'empty' >> > > exceptions until the externalization is finished. >> > >> > Sure, I agree that it is a different problem, so have no problem >> dealing >> > >> > with it separately. >> > >> > > I've implemented a small tool that generates Message source and >> > > MsgHelp source into a desired module. Tool gets a list of modules >> > > names from property file (you can specify modules class sources to >> > > generate for), then we run over the list and special word '' >> > > in Message and MsgHelp source templates files replaced with the >> > > specified module name. >> > >> > Cool. You may find it easy to do this using Ant's replace task [1]. >> > >> > [1] http://ant.apache.org/manual/CoreTasks/replace.html >> > >> > > Resulting sources are copied to the o/a/h//internal/ >> > > directory. At first I planned to use MsgHelp class from luni but >> > > after a while I've decided to avoid dependency on luni module and >> > > included generation source file of this class to every module. >> > >> > I agree, if you are going to do the template then you might as well >> > duplicate the MsgHelp behavior across the modules. In fact, don't feel >> > obliged to maintain the separation of Message and MsgHelp, you may find >> > that it makes sense to combine them now. Your choice. >> > >> > > Thus Message or MsgHelp source files can be easy regenerated for a >> > > desired set of modules, if anything is changed there. I plan to add >> > > creation of a new empty messages.properties files with copyright >> > > heading if it is absent for the module. >> > >> > Extra credit for that ;-) >> > >> > > Also I think that it make sense to changle location to >> > > o/a/h//inter
Re: [classlib]strings externalization
Hi to all! Today I've started the next step of internationalization - to externalize messages using Eclipse externalization tool. Right away I was confronted with some questions to discuss: First of all, what should we do with strings that are not supposed to be internationalized (constants, initiated variables..)? Should we mark them " //$NON-NLS-%id%$" comment (Eclipse tool skip such strings during externalization process)? IMHO there is a sence to do this, marked strings will not be taken into account next time externalization revision is required. Objections? Next point, there is a lot of manual work during messages processing (unite messages that are on the several lines of the source code, change messages with params to the proper formatted messages). When doing this work there are changes in source code and messages.properties files are made. As it is manual work - some mistakes could be done, non-critical: usually wrong message if getString() takes wrong key as a parameter. Is there supposed a verification that everything is done well? May be any test cases (at the moment I have no idea how these test cases may look) or another revision? Probably the better strategy is to wait if someone who face with wrong message will inform about that:) Thoughts? And the last one point. I think the process of internationalization support must be up-to-date, for this reason after adding new contributions all messages there are to be internationalized. Probably there is a sence to make rule to do this routinely after contribution is applied (or even before, people who are going to make contribution should be acquainted with internationalization in Harmony to use it in their development process). Waiting for comments and suggestions! Thanks, Ilya. On 8/2/06, Ilya Okomin <[EMAIL PROTECTED]> wrote: On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Ilya Okomin wrote: > > I share your point of view about Exceptions without description, it > > isn't user friendly. But I think it will be another sort of 'manual' > > scan :) There is a need to waste time to analyze surrounding code to > > provide appropriate message, a bit another sort of work, isn't it? I > > think the best way would be if all these Exceptions without info are > > being identified before externalization process is to be ran. For > > today I'd better postpone the task of initialization 'empty' > > exceptions until the externalization is finished. > > Sure, I agree that it is a different problem, so have no problem dealing > > with it separately. > > > I've implemented a small tool that generates Message source and > > MsgHelp source into a desired module. Tool gets a list of modules > > names from property file (you can specify modules class sources to > > generate for), then we run over the list and special word '' > > in Message and MsgHelp source templates files replaced with the > > specified module name. > > Cool. You may find it easy to do this using Ant's replace task [1]. > > [1] http://ant.apache.org/manual/CoreTasks/replace.html > > > Resulting sources are copied to the o/a/h//internal/ > > directory. At first I planned to use MsgHelp class from luni but > > after a while I've decided to avoid dependency on luni module and > > included generation source file of this class to every module. > > I agree, if you are going to do the template then you might as well > duplicate the MsgHelp behavior across the modules. In fact, don't feel > obliged to maintain the separation of Message and MsgHelp, you may find > that it makes sense to combine them now. Your choice. > > > Thus Message or MsgHelp source files can be easy regenerated for a > > desired set of modules, if anything is changed there. I plan to add > > creation of a new empty messages.properties files with copyright > > heading if it is absent for the module. > > Extra credit for that ;-) > > > Also I think that it make sense to changle location to > > o/a/h//internal/nls. > > Agreed. > > > Will provide patch with this tool when these changes are to be > > implemented and checked. > > I'll look forward to seeing it. Thanks Ilya! Several times I was trying to make a post with attached zip-file with the tool, but unfortunately this letter was rejected as it is spam!!:( I wonder why?! Nevertheless, I've created a jira issue [1] with suggested implementation of the tool for generation classes to support internationalization. I'd like to notice that all template files are stored in the msgstool.jarfile that is the result of ant build. For this reason this tool will work only if msgstool.jar file is in the user dir. I have to extract resources from the jar file (open jar file) and don't know how to do this if jar file is mentioned in the classpath and isn't located in the user dir. It would be great if someone knew how to deal with this issue... Tim, could you look into this tool, is it what we need? If it's ok, I would start with messages externalization task for module
Re: [classlib]strings externalization
On 8/2/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Hi Ilya, > I'd like to notice that all template files are stored in the > msgstool.jarfile that is the result of ant build. For this reason this > tool will work > only if msgstool.jar file is in the user dir. I have to extract resources > from the jar file (open jar file) and don't know how to do this if jar file > is mentioned in the classpath and isn't located in the user dir. It would be > great if someone knew how to deal with this issue... I've looked into your code. You may probably benefit from using MsgClassGenerator.class.getClassLoader().getResourceAsStream(...). Have you tried this? Suggested sample works, thanks for advice Alexei!! One more issue is resolved :) Thanks, Ilya. Regards, 2006/8/2, Ilya Okomin <[EMAIL PROTECTED]>: > On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > Ilya Okomin wrote: > > > I share your point of view about Exceptions without description, it > > > isn't user friendly. But I think it will be another sort of 'manual' > > > scan :) There is a need to waste time to analyze surrounding code to > > > provide appropriate message, a bit another sort of work, isn't it? I > > > think the best way would be if all these Exceptions without info are > > > being identified before externalization process is to be ran. For > > > today I'd better postpone the task of initialization 'empty' > > > exceptions until the externalization is finished. > > > > Sure, I agree that it is a different problem, so have no problem dealing > > with it separately. > > > > > I've implemented a small tool that generates Message source and > > > MsgHelp source into a desired module. Tool gets a list of modules > > > names from property file (you can specify modules class sources to > > > generate for), then we run over the list and special word '' > > > in Message and MsgHelp source templates files replaced with the > > > specified module name. > > > > Cool. You may find it easy to do this using Ant's replace task [1]. > > > > [1] http://ant.apache.org/manual/CoreTasks/replace.html > > > > > Resulting sources are copied to the o/a/h//internal/ > > > directory. At first I planned to use MsgHelp class from luni but > > > after a while I've decided to avoid dependency on luni module and > > > included generation source file of this class to every module. > > > > I agree, if you are going to do the template then you might as well > > duplicate the MsgHelp behavior across the modules. In fact, don't feel > > obliged to maintain the separation of Message and MsgHelp, you may find > > that it makes sense to combine them now. Your choice. > > > > > Thus Message or MsgHelp source files can be easy regenerated for a > > > desired set of modules, if anything is changed there. I plan to add > > > creation of a new empty messages.properties files with copyright > > > heading if it is absent for the module. > > > > Extra credit for that ;-) > > > > > Also I think that it make sense to changle location to > > > o/a/h//internal/nls. > > > > Agreed. > > > > > Will provide patch with this tool when these changes are to be > > > implemented and checked. > > > > I'll look forward to seeing it. Thanks Ilya! > > > Several times I was trying to make a post with attached zip-file with the > tool, but unfortunately this letter was rejected as it is spam!!:( I wonder > why?! > > Nevertheless, I've created a jira issue [1] with suggested implementation of > the tool for generation classes to support internationalization. > > I'd like to notice that all template files are stored in the > msgstool.jarfile that is the result of ant build. For this reason this > tool will work > only if msgstool.jar file is in the user dir. I have to extract resources > from the jar file (open jar file) and don't know how to do this if jar file > is mentioned in the classpath and isn't located in the user dir. It would be > great if someone knew how to deal with this issue... > > Tim, could you look into this tool, is it what we need? > If it's ok, I would start with messages externalization task for modules. > > [1]https://issues.apache.org/jira/browse/HARMONY-1041 > > BR, > Ilya. > > > > > > > Regards, > > Tim > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > -- > Ilya Okomin > Intel Middleware Products Division > > -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
Hi Ilya, I'd like to notice that all template files are stored in the msgstool.jarfile that is the result of ant build. For this reason this tool will work only if msgstool.jar file is in the user dir. I have to extract resources from the jar file (open jar file) and don't know how to do this if jar file is mentioned in the classpath and isn't located in the user dir. It would be great if someone knew how to deal with this issue... I've looked into your code. You may probably benefit from using MsgClassGenerator.class.getClassLoader().getResourceAsStream(...). Have you tried this? Regards, 2006/8/2, Ilya Okomin <[EMAIL PROTECTED]>: On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Ilya Okomin wrote: > > I share your point of view about Exceptions without description, it > > isn't user friendly. But I think it will be another sort of 'manual' > > scan :) There is a need to waste time to analyze surrounding code to > > provide appropriate message, a bit another sort of work, isn't it? I > > think the best way would be if all these Exceptions without info are > > being identified before externalization process is to be ran. For > > today I'd better postpone the task of initialization 'empty' > > exceptions until the externalization is finished. > > Sure, I agree that it is a different problem, so have no problem dealing > with it separately. > > > I've implemented a small tool that generates Message source and > > MsgHelp source into a desired module. Tool gets a list of modules > > names from property file (you can specify modules class sources to > > generate for), then we run over the list and special word '' > > in Message and MsgHelp source templates files replaced with the > > specified module name. > > Cool. You may find it easy to do this using Ant's replace task [1]. > > [1] http://ant.apache.org/manual/CoreTasks/replace.html > > > Resulting sources are copied to the o/a/h//internal/ > > directory. At first I planned to use MsgHelp class from luni but > > after a while I've decided to avoid dependency on luni module and > > included generation source file of this class to every module. > > I agree, if you are going to do the template then you might as well > duplicate the MsgHelp behavior across the modules. In fact, don't feel > obliged to maintain the separation of Message and MsgHelp, you may find > that it makes sense to combine them now. Your choice. > > > Thus Message or MsgHelp source files can be easy regenerated for a > > desired set of modules, if anything is changed there. I plan to add > > creation of a new empty messages.properties files with copyright > > heading if it is absent for the module. > > Extra credit for that ;-) > > > Also I think that it make sense to changle location to > > o/a/h//internal/nls. > > Agreed. > > > Will provide patch with this tool when these changes are to be > > implemented and checked. > > I'll look forward to seeing it. Thanks Ilya! Several times I was trying to make a post with attached zip-file with the tool, but unfortunately this letter was rejected as it is spam!!:( I wonder why?! Nevertheless, I've created a jira issue [1] with suggested implementation of the tool for generation classes to support internationalization. I'd like to notice that all template files are stored in the msgstool.jarfile that is the result of ant build. For this reason this tool will work only if msgstool.jar file is in the user dir. I have to extract resources from the jar file (open jar file) and don't know how to do this if jar file is mentioned in the classpath and isn't located in the user dir. It would be great if someone knew how to deal with this issue... Tim, could you look into this tool, is it what we need? If it's ok, I would start with messages externalization task for modules. [1]https://issues.apache.org/jira/browse/HARMONY-1041 BR, Ilya. > > Regards, > Tim > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Ilya Okomin wrote: > I share your point of view about Exceptions without description, it > isn't user friendly. But I think it will be another sort of 'manual' > scan :) There is a need to waste time to analyze surrounding code to > provide appropriate message, a bit another sort of work, isn't it? I > think the best way would be if all these Exceptions without info are > being identified before externalization process is to be ran. For > today I'd better postpone the task of initialization 'empty' > exceptions until the externalization is finished. Sure, I agree that it is a different problem, so have no problem dealing with it separately. > I've implemented a small tool that generates Message source and > MsgHelp source into a desired module. Tool gets a list of modules > names from property file (you can specify modules class sources to > generate for), then we run over the list and special word '' > in Message and MsgHelp source templates files replaced with the > specified module name. Cool. You may find it easy to do this using Ant's replace task [1]. [1] http://ant.apache.org/manual/CoreTasks/replace.html > Resulting sources are copied to the o/a/h//internal/ > directory. At first I planned to use MsgHelp class from luni but > after a while I've decided to avoid dependency on luni module and > included generation source file of this class to every module. I agree, if you are going to do the template then you might as well duplicate the MsgHelp behavior across the modules. In fact, don't feel obliged to maintain the separation of Message and MsgHelp, you may find that it makes sense to combine them now. Your choice. > Thus Message or MsgHelp source files can be easy regenerated for a > desired set of modules, if anything is changed there. I plan to add > creation of a new empty messages.properties files with copyright > heading if it is absent for the module. Extra credit for that ;-) > Also I think that it make sense to changle location to > o/a/h//internal/nls. Agreed. > Will provide patch with this tool when these changes are to be > implemented and checked. I'll look forward to seeing it. Thanks Ilya! Several times I was trying to make a post with attached zip-file with the tool, but unfortunately this letter was rejected as it is spam!!:( I wonder why?! Nevertheless, I've created a jira issue [1] with suggested implementation of the tool for generation classes to support internationalization. I'd like to notice that all template files are stored in the msgstool.jarfile that is the result of ant build. For this reason this tool will work only if msgstool.jar file is in the user dir. I have to extract resources from the jar file (open jar file) and don't know how to do this if jar file is mentioned in the classpath and isn't located in the user dir. It would be great if someone knew how to deal with this issue... Tim, could you look into this tool, is it what we need? If it's ok, I would start with messages externalization task for modules. [1]https://issues.apache.org/jira/browse/HARMONY-1041 BR, Ilya. Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
On 7/31/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Hi Ilya, > I was trying to implement generation with > using ant tasks(it seemed to me more elegant solution, than to work with > file streams in Java code) and found that ant can't work with cycles. I can > run replace task for certain file name and can't do this with parametrized > file names for a set of modules IMHO if you write a standalone tool then pure Java or even shell-script is probably the better choice (in comparison with ant). But if you like to incorporate this logic into the current build system - there is a separate build file for each module as you probably know. You don't need to parse the list of modules since the module name is predefined for each build.xml Agree with you, since source files generation won't be executed every build run - ant task (or rather it's appropriateness as the solution of this problem) is not the best choice. Thus I've stopped on the pure Java implementation. Thanks for your comment, Ilya. Regards, 2006/7/28, Ilya Okomin <[EMAIL PROTECTED]>: > On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > Ilya Okomin wrote: > > > I share your point of view about Exceptions without description, it > > > isn't user friendly. But I think it will be another sort of 'manual' > > > scan :) There is a need to waste time to analyze surrounding code to > > > provide appropriate message, a bit another sort of work, isn't it? I > > > think the best way would be if all these Exceptions without info are > > > being identified before externalization process is to be ran. For > > > today I'd better postpone the task of initialization 'empty' > > > exceptions until the externalization is finished. > > > > Sure, I agree that it is a different problem, so have no problem dealing > > with it separately. > > > > > I've implemented a small tool that generates Message source and > > > MsgHelp source into a desired module. Tool gets a list of modules > > > names from property file (you can specify modules class sources to > > > generate for), then we run over the list and special word '' > > > in Message and MsgHelp source templates files replaced with the > > > specified module name. > > > > Cool. You may find it easy to do this using Ant's replace task [1]. > > > > [1] http://ant.apache.org/manual/CoreTasks/replace.html > > > Tim, thanks for hint with ant. I was trying to implement generation with > using ant tasks(it seemed to me more elegant solution, than to work with > file streams in Java code) and found that ant can't work with cycles. I can > run replace task for certain file name and can't do this with parametrized > file names for a set of modules:( There is an extension of ant called > "Ant-Contrib" [2] where cycles are implemented. Do you know if it can be > used in Harmony? Or may be there is a possibility to do replace task for a > set of modules just in pure Ant? > > [2] http://ant-contrib.sourceforge.net/ > > > Thanks, > Ilya. > > > > > > Resulting sources are copied to the o/a/h//internal/ > > > directory. At first I planned to use MsgHelp class from luni but > > > after a while I've decided to avoid dependency on luni module and > > > included generation source file of this class to every module. > > > > I agree, if you are going to do the template then you might as well > > duplicate the MsgHelp behavior across the modules. In fact, don't feel > > obliged to maintain the separation of Message and MsgHelp, you may find > > that it makes sense to combine them now. Your choice. > > > > > Thus Message or MsgHelp source files can be easy regenerated for a > > > desired set of modules, if anything is changed there. I plan to add > > > creation of a new empty messages.properties files with copyright > > > heading if it is absent for the module. > > > > Extra credit for that ;-) > > > > > Also I think that it make sense to changle location to > > > o/a/h//internal/nls. > > > > Agreed. > > > > > Will provide patch with this tool when these changes are to be > > > implemented and checked. > > > > I'll look forward to seeing it. Thanks Ilya! > > > > Regards, > > Tim > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > -- > Ilya Okomin > Intel Middleware Products Division > > -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
Hi Ilya, I was trying to implement generation with using ant tasks(it seemed to me more elegant solution, than to work with file streams in Java code) and found that ant can't work with cycles. I can run replace task for certain file name and can't do this with parametrized file names for a set of modules IMHO if you write a standalone tool then pure Java or even shell-script is probably the better choice (in comparison with ant). But if you like to incorporate this logic into the current build system - there is a separate build file for each module as you probably know. You don't need to parse the list of modules since the module name is predefined for each build.xml Regards, 2006/7/28, Ilya Okomin <[EMAIL PROTECTED]>: On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Ilya Okomin wrote: > > I share your point of view about Exceptions without description, it > > isn't user friendly. But I think it will be another sort of 'manual' > > scan :) There is a need to waste time to analyze surrounding code to > > provide appropriate message, a bit another sort of work, isn't it? I > > think the best way would be if all these Exceptions without info are > > being identified before externalization process is to be ran. For > > today I'd better postpone the task of initialization 'empty' > > exceptions until the externalization is finished. > > Sure, I agree that it is a different problem, so have no problem dealing > with it separately. > > > I've implemented a small tool that generates Message source and > > MsgHelp source into a desired module. Tool gets a list of modules > > names from property file (you can specify modules class sources to > > generate for), then we run over the list and special word '' > > in Message and MsgHelp source templates files replaced with the > > specified module name. > > Cool. You may find it easy to do this using Ant's replace task [1]. > > [1] http://ant.apache.org/manual/CoreTasks/replace.html Tim, thanks for hint with ant. I was trying to implement generation with using ant tasks(it seemed to me more elegant solution, than to work with file streams in Java code) and found that ant can't work with cycles. I can run replace task for certain file name and can't do this with parametrized file names for a set of modules:( There is an extension of ant called "Ant-Contrib" [2] where cycles are implemented. Do you know if it can be used in Harmony? Or may be there is a possibility to do replace task for a set of modules just in pure Ant? [2] http://ant-contrib.sourceforge.net/ Thanks, Ilya. > > Resulting sources are copied to the o/a/h//internal/ > > directory. At first I planned to use MsgHelp class from luni but > > after a while I've decided to avoid dependency on luni module and > > included generation source file of this class to every module. > > I agree, if you are going to do the template then you might as well > duplicate the MsgHelp behavior across the modules. In fact, don't feel > obliged to maintain the separation of Message and MsgHelp, you may find > that it makes sense to combine them now. Your choice. > > > Thus Message or MsgHelp source files can be easy regenerated for a > > desired set of modules, if anything is changed there. I plan to add > > creation of a new empty messages.properties files with copyright > > heading if it is absent for the module. > > Extra credit for that ;-) > > > Also I think that it make sense to changle location to > > o/a/h//internal/nls. > > Agreed. > > > Will provide patch with this tool when these changes are to be > > implemented and checked. > > I'll look forward to seeing it. Thanks Ilya! > > Regards, > Tim > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Ilya Okomin wrote: > I share your point of view about Exceptions without description, it > isn't user friendly. But I think it will be another sort of 'manual' > scan :) There is a need to waste time to analyze surrounding code to > provide appropriate message, a bit another sort of work, isn't it? I > think the best way would be if all these Exceptions without info are > being identified before externalization process is to be ran. For > today I'd better postpone the task of initialization 'empty' > exceptions until the externalization is finished. Sure, I agree that it is a different problem, so have no problem dealing with it separately. > I've implemented a small tool that generates Message source and > MsgHelp source into a desired module. Tool gets a list of modules > names from property file (you can specify modules class sources to > generate for), then we run over the list and special word '' > in Message and MsgHelp source templates files replaced with the > specified module name. Cool. You may find it easy to do this using Ant's replace task [1]. [1] http://ant.apache.org/manual/CoreTasks/replace.html Tim, thanks for hint with ant. I was trying to implement generation with using ant tasks(it seemed to me more elegant solution, than to work with file streams in Java code) and found that ant can't work with cycles. I can run replace task for certain file name and can't do this with parametrized file names for a set of modules:( There is an extension of ant called "Ant-Contrib" [2] where cycles are implemented. Do you know if it can be used in Harmony? Or may be there is a possibility to do replace task for a set of modules just in pure Ant? [2] http://ant-contrib.sourceforge.net/ Thanks, Ilya. > Resulting sources are copied to the o/a/h//internal/ > directory. At first I planned to use MsgHelp class from luni but > after a while I've decided to avoid dependency on luni module and > included generation source file of this class to every module. I agree, if you are going to do the template then you might as well duplicate the MsgHelp behavior across the modules. In fact, don't feel obliged to maintain the separation of Message and MsgHelp, you may find that it makes sense to combine them now. Your choice. > Thus Message or MsgHelp source files can be easy regenerated for a > desired set of modules, if anything is changed there. I plan to add > creation of a new empty messages.properties files with copyright > heading if it is absent for the module. Extra credit for that ;-) > Also I think that it make sense to changle location to > o/a/h//internal/nls. Agreed. > Will provide patch with this tool when these changes are to be > implemented and checked. I'll look forward to seeing it. Thanks Ilya! Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [classlib]strings externalization
Andrew Zhang wrote:
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> The other reason we will need some manual intervention is that
there is
>> plenty of code that throws exceptions without any message describing
the
>> problem, and of course the tooling won't help there.
>
> Tim, do you mean, that Exceptions without any messages supposed to be
> initialized with some corresponding message describing the problem? I
> thought only already existing in modules messages are to be
considered.
> Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
Agree. Meaningful message helps. But all exceptions defined in
java.nio and
java.nio.channels only have a constructor without any parameter. :)
Seems sun is becoming lazy on this issue. :)
Maybe we could think these exceptions are self-explaining, and we will
do nothing about them.
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
>> So once we have the basic framework in place for the message
handling I
>> think it will require a large manual effort to get all the strings
that
>> we want externalized properly. Luckily it is not technically complex
>> work and it is a task that we can easily do in parallel across the
>> modules.
>
> Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Andrew Zhang wrote:
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> The other reason we will need some manual intervention is that
there is
>> plenty of code that throws exceptions without any message describing
the
>> problem, and of course the tooling won't help there.
>
> Tim, do you mean, that Exceptions without any messages supposed to be
> initialized with some corresponding message describing the problem? I
> thought only already existing in modules messages are to be considered.
> Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
Agree. Meaningful message helps. But all exceptions defined in java.nio and
java.nio.channels only have a constructor without any parameter. :)
Seems sun is becoming lazy on this issue. :)
:) Rather call them "clever" than "lazy" in my mind, as an
IllegalArgumentException can enough detail for user to know what is
wrong (and javadoc also offer some information). Only some exception,
like IOException, may need more detail for its cause.
After all, now Harmony can use RI's error message, so it is no longer
necessary to rack our brains to write error message. :)
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
>> So once we have the basic framework in place for the message
handling I
>> think it will require a large manual effort to get all the strings
that
>> we want externalized properly. Luckily it is not technically complex
>> work and it is a task that we can easily do in parallel across the
>> modules.
>
> Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> The other reason we will need some manual intervention is that there is
>> plenty of code that throws exceptions without any message describing
the
>> problem, and of course the tooling won't help there.
>
> Tim, do you mean, that Exceptions without any messages supposed to be
> initialized with some corresponding message describing the problem? I
> thought only already existing in modules messages are to be considered.
> Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
Agree. Meaningful message helps. But all exceptions defined in java.nio and
java.nio.channels only have a constructor without any parameter. :)
Seems sun is becoming lazy on this issue. :)
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
>> So once we have the basic framework in place for the message handling I
>> think it will require a large manual effort to get all the strings that
>> we want externalized properly. Luckily it is not technically complex
>> work and it is a task that we can easily do in parallel across the
>> modules.
>
> Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib]strings externalization
Ilya Okomin wrote: I share your point of view about Exceptions without description, it isn't user friendly. But I think it will be another sort of 'manual' scan :) There is a need to waste time to analyze surrounding code to provide appropriate message, a bit another sort of work, isn't it? I think the best way would be if all these Exceptions without info are being identified before externalization process is to be ran. For today I'd better postpone the task of initialization 'empty' exceptions until the externalization is finished. Sure, I agree that it is a different problem, so have no problem dealing with it separately. I've implemented a small tool that generates Message source and MsgHelp source into a desired module. Tool gets a list of modules names from property file (you can specify modules class sources to generate for), then we run over the list and special word '' in Message and MsgHelp source templates files replaced with the specified module name. Cool. You may find it easy to do this using Ant's replace task [1]. [1] http://ant.apache.org/manual/CoreTasks/replace.html Resulting sources are copied to the o/a/h//internal/ directory. At first I planned to use MsgHelp class from luni but after a while I've decided to avoid dependency on luni module and included generation source file of this class to every module. I agree, if you are going to do the template then you might as well duplicate the MsgHelp behavior across the modules. In fact, don't feel obliged to maintain the separation of Message and MsgHelp, you may find that it makes sense to combine them now. Your choice. Thus Message or MsgHelp source files can be easy regenerated for a desired set of modules, if anything is changed there. I plan to add creation of a new empty messages.properties files with copyright heading if it is absent for the module. Extra credit for that ;-) Also I think that it make sense to changle location to o/a/h//internal/nls. Agreed. Will provide patch with this tool when these changes are to be implemented and checked. I'll look forward to seeing it. Thanks Ilya! Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> The other reason we will need some manual intervention is that there is
>> plenty of code that throws exceptions without any message describing
the
>> problem, and of course the tooling won't help there.
>
> Tim, do you mean, that Exceptions without any messages supposed to be
> initialized with some corresponding message describing the problem? I
> thought only already existing in modules messages are to be considered.
> Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
I share your point of view about Exceptions without description, it isn't
user friendly. But I think it will be another sort of 'manual' scan :) There
is a need to waste time to analyze surrounding code to provide appropriate
message, a bit another sort of work, isn't it?
I think the best way would be if all these Exceptions without info are being
identified before externalization process is to be ran. For today I'd
better postpone the task of initialization 'empty' exceptions until the
externalization is finished.
>> So once we have the basic framework in place for the message handling I
>> think it will require a large manual effort to get all the strings that
>> we want externalized properly. Luckily it is not technically complex
>> work and it is a task that we can easily do in parallel across the
>> modules.
>
> Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
I've implemented a small tool that generates Message source and MsgHelp
source into a desired module. Tool gets a list of modules names from
property file (you can specify modules class sources to generate for),
then we run over the list and special word '' in Message and MsgHelp
source templates files replaced with the specified module name. Resulting
sources are copied to the o/a/h//internal/ directory. At first I
planned to use MsgHelp class from luni but after a while I've decided to
avoid dependency on luni module and included generation source file of this
class to every module.
Thus Message or MsgHelp source files can be easy regenerated for a desired
set of modules, if anything is changed there.
I plan to add creation of a new empty messages.properties files with
copyright heading if it is absent for the module. Also I think that it make
sense to changle location to o/a/h//internal/nls.
Will provide patch with this tool when these changes are to be implemented
and checked.
Thanks,
Ilya.
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib]strings externalization
Ilya Okomin wrote:
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
The other reason we will need some manual intervention is that there is
plenty of code that throws exceptions without any message describing the
problem, and of course the tooling won't help there.
Tim, do you mean, that Exceptions without any messages supposed to be
initialized with some corresponding message describing the problem? I
thought only already existing in modules messages are to be considered.
Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
So once we have the basic framework in place for the message handling I
think it will require a large manual effort to get all the strings that
we want externalized properly. Luckily it is not technically complex
work and it is a task that we can easily do in parallel across the
modules.
Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
Regards,
Tim
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> Hi falks!
>
> I would like to open discussion about the way to extract messages for
> internationalization from the source files (as the continuation of the
> [classlib]internationalization thread [1]).
>
> The task is to scan modules source files, find exception messages,
> extract
> them into the resource bundle and replace these messages in the source
> files with corresponding Messages.getString() call by key parameter
> from the
> resource bundle.
>
> I see three ways to solve this task:
> 1) Do it manually - the less attractive because of the huge amount of
> manual
> work.
> 2) Use Eclipse externalization tool. This tool provide us a
> possibility to
> scan source files and to check strings you would like to externalize.
> Sounds
> reasonable except several issues:
>
> - At first, there is a manual work to choose from the source files
> only messages related to exceptions throwing and avoid duplication of
> messages at list in one class file.(however, this work is much more
> easier
> than one mentioned at 1) point:))
> - Eclipse tool creates resource bundle with messages and Messages
> class to get access to this resources in every package. Also this tool
> suggests to use .id as the key of the message. In our
> previous
> discussion [1] it was decided to use .id as the key and
> keep all
> messages in one resource file per module. Good news: during processing
> source file with Eclipse tool we can set the same resource file for
all
> source files from the module and every time set the prefix of key
> names to
> the module name, also our Messages class implementation can be used
> after
> adding corresponding import statement into a source. Bad news:
> following
> this way of processing sources one can see that there is no tracking
> system
> for key indices numeration, in case of mistakes there can be generated
> different messages with the same keys!!
> - And at last, Eclipse tool processes only separated strings.
> And according to the discussion [1] these messages with arguments
> supposed
> to be converted to strings with places for substitution by
> parameters being
> arguments in Messages.getString() method. E.g. code:
>
> int param;
> ...
> NullPointerException("foo " + param + " bar");
>
> supposed to be formatted as
>
> NullPointerException(Messages.getString(".1", param));
>
> where ".1=foo {0} bar" in the resource bundle.
> I have an optitmistic thought that there are not so many messages with
> parameters to process them manually after the rest of work with just
> strings
> is done.
>
> 3)Write own parser that will do all implement tasks automatic. In my
> opinion
> it's quite a non-trivial task, only if there is no tools that resolves
> similar tasks.
>
> The 2) approach seems to me more reasonable, despite some manual work.
> Parser will help us to easily update bundles and sources after future
> changes, but it will be not so easy to implement it.
>
> Any thoughts on this topic?
>
> Tim, if I'm not mistaken you dealt with strings externalization for SQL
> module, it would be interesting to hear anything about the way you'd
> chosen.
I did a combination of (1) and (2) as you describe above.
I also found that the Eclipse externalization tool was inadequate in a
number of areas, including creating duplicate keys and not dealing with
parameterized messages properly -- so I had to go and fix up the code
manually.
The other reason we will need some manual intervention is that there is
plenty of code that throws exceptions without any message describing the
problem, and of course the tooling won't help there.
Tim, do you mean, that Exceptions without any messages supposed to be
initialized with some corresponding message describing the problem? I
thought only already existing in modules messages are to be considered. Just
want to dispel doubts.
So once we have the basic framework in place for the message handling I
think it will require a large manual effort to get all the strings that
we want externalized properly. Luckily it is not technically complex
work and it is a task that we can easily do in parallel across the
modules.
Yep, I've chosen the same way to do.
Regards,
Tim
>
> [1]
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib]strings externalization
Ilya Okomin wrote:
Hi falks!
I would like to open discussion about the way to extract messages for
internationalization from the source files (as the continuation of the
[classlib]internationalization thread [1]).
The task is to scan modules source files, find exception messages,
extract
them into the resource bundle and replace these messages in the source
files with corresponding Messages.getString() call by key parameter
from the
resource bundle.
I see three ways to solve this task:
1) Do it manually - the less attractive because of the huge amount of
manual
work.
2) Use Eclipse externalization tool. This tool provide us a
possibility to
scan source files and to check strings you would like to externalize.
Sounds
reasonable except several issues:
- At first, there is a manual work to choose from the source files
only messages related to exceptions throwing and avoid duplication of
messages at list in one class file.(however, this work is much more
easier
than one mentioned at 1) point:))
- Eclipse tool creates resource bundle with messages and Messages
class to get access to this resources in every package. Also this tool
suggests to use .id as the key of the message. In our
previous
discussion [1] it was decided to use .id as the key and
keep all
messages in one resource file per module. Good news: during processing
source file with Eclipse tool we can set the same resource file for all
source files from the module and every time set the prefix of key
names to
the module name, also our Messages class implementation can be used
after
adding corresponding import statement into a source. Bad news:
following
this way of processing sources one can see that there is no tracking
system
for key indices numeration, in case of mistakes there can be generated
different messages with the same keys!!
- And at last, Eclipse tool processes only separated strings.
And according to the discussion [1] these messages with arguments
supposed
to be converted to strings with places for substitution by
parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException("foo " + param + " bar");
supposed to be formatted as
NullPointerException(Messages.getString(".1", param));
where ".1=foo {0} bar" in the resource bundle.
I have an optitmistic thought that there are not so many messages with
parameters to process them manually after the rest of work with just
strings
is done.
3)Write own parser that will do all implement tasks automatic. In my
opinion
it's quite a non-trivial task, only if there is no tools that resolves
similar tasks.
The 2) approach seems to me more reasonable, despite some manual work.
Parser will help us to easily update bundles and sources after future
changes, but it will be not so easy to implement it.
Any thoughts on this topic?
Tim, if I'm not mistaken you dealt with strings externalization for SQL
module, it would be interesting to hear anything about the way you'd
chosen.
I did a combination of (1) and (2) as you describe above.
I also found that the Eclipse externalization tool was inadequate in a
number of areas, including creating duplicate keys and not dealing with
parameterized messages properly -- so I had to go and fix up the code
manually.
The other reason we will need some manual intervention is that there is
plenty of code that throws exceptions without any message describing the
problem, and of course the tooling won't help there.
So once we have the basic framework in place for the message handling I
think it will require a large manual effort to get all the strings that
we want externalized properly. Luckily it is not technically complex
work and it is a task that we can easily do in parallel across the modules.
Regards,
Tim
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib]strings externalization
Hi falks!
I would like to open discussion about the way to extract messages for
internationalization from the source files (as the continuation of the
[classlib]internationalization thread [1]).
The task is to scan modules source files, find exception messages, extract
them into the resource bundle and replace these messages in the source
files with corresponding Messages.getString() call by key parameter from the
resource bundle.
I see three ways to solve this task:
1) Do it manually - the less attractive because of the huge amount of manual
work.
2) Use Eclipse externalization tool. This tool provide us a possibility to
scan source files and to check strings you would like to externalize. Sounds
reasonable except several issues:
- At first, there is a manual work to choose from the source files
only messages related to exceptions throwing and avoid duplication of
messages at list in one class file.(however, this work is much more easier
than one mentioned at 1) point:))
- Eclipse tool creates resource bundle with messages and Messages
class to get access to this resources in every package. Also this tool
suggests to use .id as the key of the message. In our previous
discussion [1] it was decided to use .id as the key and keep all
messages in one resource file per module. Good news: during processing
source file with Eclipse tool we can set the same resource file for all
source files from the module and every time set the prefix of key names to
the module name, also our Messages class implementation can be used after
adding corresponding import statement into a source. Bad news: following
this way of processing sources one can see that there is no tracking system
for key indices numeration, in case of mistakes there can be generated
different messages with the same keys!!
- And at last, Eclipse tool processes only separated strings.
And according to the discussion [1] these messages with arguments supposed
to be converted to strings with places for substitution by parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException("foo " + param + " bar");
supposed to be formatted as
NullPointerException(Messages.getString(".1", param));
where ".1=foo {0} bar" in the resource bundle.
I have an optitmistic thought that there are not so many messages with
parameters to process them manually after the rest of work with just strings
is done.
3)Write own parser that will do all implement tasks automatic. In my opinion
it's quite a non-trivial task, only if there is no tools that resolves
similar tasks.
The 2) approach seems to me more reasonable, despite some manual work.
Parser will help us to easily update bundles and sources after future
changes, but it will be not so easy to implement it.
Any thoughts on this topic?
Tim, if I'm not mistaken you dealt with strings externalization for SQL
module, it would be interesting to hear anything about the way you'd chosen.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
