[i18n] Basic architecture/component usage

[Mattias J <ma...@expertsystem.se>]

[was "Re: [i18n PATCH] Adding provider qualifying"]

At 2005-05-19 16:41, you wrote:
>But, to be honest, I'm a bit disappointed at how this project is being 
>developed.  I feel that i18n would benefit tremendously by reusing instead 
>of reinventing.

Since Commons Resources and i18n seems to basically solve the same problem, 
my very first post to this list a month ago included the question whether 
i18n and Resources were going to continue to co-exist, and what was the 
relationship between them. After getting the impression they would continue 
to co-exist i18n was the natural choice because of our prerequisites.

In our project we store the language specific texts in a database. Among 
60+ tables there are a few that contain several columns to provide - for 
example - text, abbreviated text and detailed description for a single ID + 
language/locale entry. So supporting multiple texts per ID is a basic 
requirement for us.

>As was pointed out months ago, there's just too much you get for free by 
>leveraging other components and communities.
>
>With all do respect to those of you working on i18n, I'm not currently 
>using this component in my own work, but I plan to in the near future.  At 
>that time I'll most likely fork the code, strip out the bottom half 
>(dealing with message retrieval) and plug in commons-resources.

To be honest I haven't really considered building i18n *on top of* 
commons-resources before. But - even though I have not studied the 
Resources API in details - I must disapprove since I do not see an 
obvious/useful way to handle the above scenario using Resources.
For this to be supported by Resources in a useful manner, Resources needs 
to be extended. And if Resources is extended in such a way, we might just 
as well move what is left in i18n into the Resources component as well.

>I have no interest in trying to redo my work from Commons Resources or 
>reimplement the 3 Database-based impls of such.
>
>And what about the hundreds of JUnit tests. One thing I've been working on 
>lately is getting Resources to 100% test coverage.  I would hate to ask 
>someone to redo their work because I "didn't want to depend on another 
>project".

Another idea would be to add a CommonsResourcesProvider wich you could opt 
to use with i18n.

FYI, I have assured i18n has 100% test coverage.
The coverage report is not currently included in the build, but if somebody 
would add emma.jar and emma_ant.jar to the lib dir, I could provide an 
updated build.xml.

  /Mattias Jiderhamn 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org