On 28/04/2010, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > > > The advantage of the proposed "trick" is that you don't have to write any > > > checking code. > > > > > > > But it's more effort to build the code, > > > Is your computer threatening to go on strike? ;-)
No, but you already said that you don't know how to update the Maven builds to cope with the extra jars. Also, the standard commons download page generation may need to be changed to deal with the extra jars. > > > and possibly more effort for the user. > > > Certainly: he'll have to add 1 "dependency" line... > > > > > > 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? > > > > Creating the extra jars. > > > Several JARs are already created (classes, javadoc, sources). > Would it be overly complicated to add the appropriate invocations > to create one other set, for the bridge to "CAL10N"? See above. > > > Maintaining two copies of the English messages. > > > I'll do it. [I bet that arguing on this has already taken more time than > several revisions of these files.] This is getting a bit away from the the point. I think we should either go for CAL10N entirely, or not at all. Having a fallback that is not essential AND requires ongoing extra work does not seem sensible to me. > I must add that maintaining these 2 copies is still *much* less work that > the current way of having a "bundle" for each language, repeating the > English message text in each language file. Well, in fact, there is already > 2 copies of the English messages (one in the code and one in the > "messages_fr" file). So from this particular point-of-view, right now my > proposal is on a par with the current way, and it wan only be better as more > translations are added! Yes, but why make it less efficient than it need be? > > > > 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!). > > > > But AFAICT some of the work is ongoing - every new English message has > > to be added to two files; any changes likewise. > > > It seems that you over-estimate the work, because of the current way of > doing it in CM (cf. the original mail of my proposal). > In the new way, only the creator of a new exception class will have to deal > with the text messages (1 default in the Java code + 1 in the English file > + 1 for each other language file). From that point on, developers will just > deal with the constructor of that exception class (no text message > involved). I think this will all become a lot clearer when the sandbox project is established. We can then see how many SVN updates are needed to maintain the code. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
