[Geoserver-devel] Wicket i18n questions

GeoServer GeoServer Developer
1

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 ?

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.

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?

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?

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.

That's all for now, I'm sure there will be more,
-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org<input type="submit" wicket:message="value:page.search"/>
Expert service straight from the developers

2

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.