GeoTools already host a small extension of ResourceBundle in
org.geotools.resources.i18n, called IndexResourceBundle. It is not an elaborated
class (seems less elaborated than what you describe), the only benefit I was
looking for (compared to the default ResourceBundle) being:
* compile-time safety
* automatic usage of java.text.MessageFormat
* convenience static methods
but this is not committed API. In theory everything in org.geotools.resources is
internal mechanic, and in theory no user are expected to use that. So in theory
again we are free to change or expand it as we want.
On the question about whatever GeoTools is the home for such non-geospatial
stuff, I'm neutral. We already have a bit of non-geospatial stuff. Maybe the
question could be whatever GeoTools wants to commit itself to such i18n API, or
whatever it would stay an internal-only package. Maybe also we should see what
would be the benefit compared to current (not elaborated, internal only)
framework.
Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
