> > 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? ;-) > 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"? > 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.] 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! > > 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). > > Yes, and how do I do that? > > I think you can just create it; best to ask in a separate thread. I can create a project??? Or is it a svn branch? Even so, I don't think I have the rights to do it. Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
