> > > [...] > > > > > > 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. > > I think I may have missed something here. Do you say that if we go this > way it will mean people should either have to have an additional > dependency or no translation at all ? This would be a very bad thing > to me. My previous understanding was that the external dependency > simply improved development and languages plugin, but that the system > could still work without it.
Well, my point (cf. the lengthy mail referred to on the JIRA page) was that "translation" is an additional functionality layer. Now, the library "CAL10N" offers: - easy testing of translation coverage (compile-time or, more exactly, development-time if end-users don't want to be able to run the Junit tests) - translation at runtime (i.e. a runtime external dependency) So I don't see why we should re-invent the wheel just to avoid an optional dependency on a tiny special-purpose external library. Of course, if you insist on doing that, you will always be able to provide a "home-made" implementation of the "Framework" (i.e. in place of using "CAL10N"). But this implementation must also be optional, so that it must be provided in a separate JAR which the user can declare in his dependencies if he wants to use it instead of the default error handling (which will be: no dependency, no translation). I think that this is arguably the most flexible position: You don't impose translation while providing an easy, free software, means to get functionality. Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
