Arne Kepp wrote: > Hi, > > I've been tasked to go through the i18n stuff for Wicket again. But I > think we need to lay down the ground rules before I edit any further. > > > 1) Our i18n framework? > > http://jira.codehaus.org/browse/GEOS-2707 mentions the need to document > "our custom i18n framework (how to use it)" > > What is meant by "our i18n framework" ? ( In contrast to the one wicket > ships with.) Plugin support ? > Well, essentially with wicket, the way i18n is done is that you have a property file for each component class. This would mean quite a bit of .property files to keep in sync. So we did some teaking of the GeoServerApplication class to enable one .properties file per module. So you will see things like "WMSAdminPage.foo". Our "lookup framework" will match a lookup of "foo" when the WMSAdminPage is being rendered to the above key. > > 2) Message ids > > Example: > wfs.maxFeatures = Per-Request Feature Limit > maxFeatures = Maximum number of features > > This strikes me as arbitrary and makes it difficult to translate the > application. The only way we can avoid this is if the key actually > contains the entire message. Without getting into a discussion about the > path prefix, I think the above should be: > wfs.perRequestFeatureLimit > maximumNumberOfFeatures > > Agreed? I'm not sure what to do about really long strings. While i agree it is arbitrary I think it would be tough to pull off for paragraphs. I would be cool with sticking to this schemes for titles and labels, and making an exception for paragraphs perhaps? > > > 3) Message id prefixes > > Example: > "geosearch.enable" in > web2/wms/src/main/java/org/geoserver/wms/web/publish/GeoSearchLayerConfigPanel.htm > vs > "wms.data.style.name" in > web2/wms/src/mainjava/org/geoserver/wms/web/data/StyleEditPage.html > > The WFS module doesn't seem to use paths at all. > > Regardless of what is currently used in the code (it varies), do we have > an idea of how we want to do the paths for messages?
I would say the only need for a prefix is the component class name in order to localize the string to that component. Examples WMSAdminPage.title vs WFSAdminPage.title. Prefixing everything with a module prefix does not seem too useful since the .property files themselves are now "componentized". > > > 4) Random submit buttons: > > Example: > <input type="submit" value="Submit!"></input> > in web2/wms/src/main/java/org/geoserver/wms/web/publish/WMSLayerConfig.html > > Are those leftovers from when we were doing a tab-intensive design? > Should they just be deleted, or am I missing something? Probably just the result of not establishing conventions. Feel free to change. > > > 5) Syntax for labels > > A few places we use > <label for="maxFeatures"><wicket:message ... > > What does the for="maxFeatures" do, and do we want it for all labels ? > It's used some places, but far from all. The for attribute is used to layout and align our forms so that we don't have to wrap them in html tables. I am pretty sure we always want to use this. > > > > > That's all for now, I'm sure there will be more, > -Arne > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
