Jody Garnett a écrit :
> Martin did we ever write down how the geotools i18n support works? I
> cannot remember what to do here.
There is no general rule there; each module do as they wish, usually using
java.util.ResourceBundle. For the module that I wrote, I added some helper
classes but nobody is required to use them. I do the following:
* Write .properties file exactly as we usually do for ResourceBundles.
* Instead of querying the properties by String keys, I generate automatically
a set of constants in an interface using ResourceCompiler. I did that mostly
because I wanted compile time check for my keys. As an opportunist side effet,
I get integers compiled instead of Strings because they generate more compact
class files.
* ResourceCompiler copies the .properties content into .utf file (this is just
a dump of .properties values), which is the file loaded by my custom resource
bundle. But maybe I should drop this part and stick to the properties files...
I created this step only in an attempt to use less memory, but I'm not sure
that it is worth the trouble.
* In addition of the standard 'getString(String)' method, I overloaded it with
'getString(String, Object, Object, Object...) convenience method that format
the string using java.text.MessageFormat.
* By convention, I put a "_$n" suffix in my key names where "n" is the number
or arguments expected. This is just a reminder of how many objects I should
put in my 'getString(...)' (or the convenience 'format(...)' static method).
If you want to fix a localized String, you can just edit the .properties file. I
need to document how to launch ResourceCompiler (or yet better, it should be a
Maven plugin), but in the main time I can just launch it when I see that a
.properties file has been modified.
Like everything in org.geotools.resources, this stuff is not a commited part of
GeoTools and could change - it has been designed with the assumption that I was
the only one to care about i18n in GeoTools. If you don't need too, maybe it is
better to avoid this package until we ask to other developpers if they have any
advice about how we should handle i18n geotools-wide.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
