Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 27 Apr 2010 23:19:46 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [Math] What about issue 361?
Message-ID: <20100427211946.GE18833@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20100427200627.GD18833@dusk.harfang.homelinux.org>
 <2103425184.5400331272400480658.JavaMail.root@spooler6-g27.priv.proxad.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <2103425184.5400331272400480658.JavaMail.root@spooler6-g27.priv.proxad.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: hel 20002; Body=1 Fuz1=1 Fuz2=1

> > > [...]
> > > 
> > > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org