harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Okomin" <ilya.oko...@gmail.com>
Subject Re: [classlib]strings externalization
Date Thu, 10 Aug 2006 14:42:32 GMT
On 8/10/06, Tim Ellison <t.p.ellison@gmail.com> 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 <ilya.okomin@gmail.com> wrote:
> >>
> >>
> >>
> >> On 7/27/06, Tim Ellison <t.p.ellison@gmail.com> 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
> '<module>'
> >> > > 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/<module>/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/<module>/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: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> --
> >> Ilya Okomin
> >> Intel Middleware Products Division
> >>
> >
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
--
Ilya Okomin
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message