> > 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