> > They are, in the files posted on the JIRA page of the issue.
> >  The sample code is fully working.
> 
> There don't seem to be any properties files.
> It would be helpful to have say French and English files for testing.

You are right; sorry. I've just attached an example.

> >  [...]
> >  > Not sure why you need multiple jars.
> >
> >
> > To enable runtime selection of the L10N implementation, letting the user
> >  choose whether he wants to depend on the CAL10N external library or whether
> >  he is happy with the default (English) message text.
> 
> Might be possible to do that by checking if the CAL10N jar is present
> - if not, fall back on the default.

The advantage of the proposed "trick" is that you don't have to write any
checking code.

> But I'm not sure it's worth having special processing just some users
> of the English version don't have to download the additional jar.

What special processing?

The flexibility is to account for user who don't want a runtime dependency.

> AIUI, the English messages will need to be defined both in the
> standalone NoDepFramework class and in the math_messages_en.properties
> file.

That's true. But I don't think it's a big problem. Again, that's the (small)
price to pay for being able to propose a library without localization and
zero dependency while allowing a "pluggable" translation feature.

> That is just making extra work.

I'm willing to do it (it's just writing a few words!). Moreover part of
the proposed changes involves a drastic reduction of the number of messages
(without loosing anything).

> Either we do this and include the CAL10N dependency, or we don't use
> this method at all.
> 
> >  The functionality is probably not easily figured out from a quick glance at
> >  the code, that's why I'm asking how we can proceed from here so that people
> >  can try it out without too much extra work (such as I did to test the files
> >  I uploaded to JIRA).
> >
> 
> That's why I suggested a sandbox project.

Yes, and how do I do that?


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to