Add ability to internationalize title and abstract/description in layers, layer groups and service descriptions, use it in OGC Capabilities documents, based on OWS commons AcceptLanguages parameter, as well as INSPIRE's LANGUAGE parameter.

Andrea Aime

This proposal funding is bound to backport ability on GeoServer 2.19.

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Several services need multi-language support, be it because they are meant for an international audience, or because the target users are from a country speaking multiple languages. Currently GeoServer is able to generate legends in multiple languages, this proposal expands it to capabilities documents. Further work will also extend GetMap support, but that does not require a API change, so it's not discussed here.

We want to add multi-language support to GeoServer without breaking users that do not need this capability, and retain ability to backport the changes. As a result, a direct change to the data type returned by the title, abstract and description properties is not advisable, as it would be an API break and change the representation of resources in the REST API.

We are proposing instead to add parallel properties, internationalTitle, internationalAbstract and internationalDescription (as well as internationalRootLayerTitle and internationalRootLayerAbstract for WMS service info), all of InternationalString type, that would be populated only when using i18n support. In case only the internationalized property is available, getTitle/getAbstract properties would return the internationalized default language value. The international properties would do the same in the symmetric situation.

GrowableInternationalString will be used as the actual implementation, with a dedicated XStream converter producing a representation like the following one, using the ISO lang as the key.

<internationalTitle>
  <en>My title<en>
  <fr>Mon titre<fr>
  <it>Il mio titolo</it>
</internationalTitle>

GUI wise, the layer, layer group and service pages will get a new international string capable editor, which the interested users will opt-in into.

The drop-down will be populated using Java own Locale language dictionary (it should also contain country specific variations, such as, for example, en vs en-US and en-CA).

GrowableInternationalString will be modified slightly, to use internally a LinkedHashMap, in order not to change the order of languages entered by the user (as that might have a meaning/importance to them). This will also allow to choose the first entry as the "default language" one.

The capabilities generator of WMS 1.1, 1.3, WFS 2.0 and WCS 2.0 will be modified, so that they respond to the standard OWS "AcceptLanguages" parameter of the GetCapabilities request, and encode the response using that specific language (or, according to the specs, the server preferred language in case there is no match). See also the OGC Web Service Common Implementation Specification for details.

The INSPIRE directive demands for usage of a LANGUAGE parameter, in order to choose the service specific language. Also, the list of language names does not follow the ISO prefixes, e..g, ger is used in place of de. A DispatcherCallback implementation will take care of turning the languages back into ISO prefixes and amend the parameter name difference.

We want to add multi language support also to Contact Informations. As for title and abstract, a direct change of the data type of existing getters and setters in the ContactInfo interface will be avoided using parallel properties of InternationalString types for all the fields ( with the exception of id). Again GrowableInternationalString will be used as the actual implementation.

UI wise, the ui component used for title and abstract in Services and Resources configuration will be reused. The Capabilities generators of WMS 1.1 and 1.3, WFS 2.0 and WCS 2.0.1 will be modified to handle the new i18n content, as has already been done for title and abstracts, to correctly encode values according to the AcceptLanguages parameter.

As all the new properties are optional, there should not be any backwards compatibility concern.

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime: +1
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini: +1
• Torben Barsballe:
• Nuno Oliveira: +1

• Email Discussion
• Pull Request 123
• GeoTools / GeoServer Meeting 2019-03-01