Hi,
recently we started thinking on how to support internationalized OWS services
in GeoServer, and I wanted to share some considerations with the community
and gather some feedback (btw, no, don’t hold your breath on it just yet, this is just preliminary
research).
The first bit would be to make the capabilities documents generated by GeoServer
respect the lang parameter and return caps documents in a specific language.
While the layer/feature type names would not change, this would require metadata
like title and abstract, as well as some parts of
the service description to be available not as simple strings, but as list of values
in different languages (maps).
Keywords already seem to support the language concept, and I’m wondering if
metadata links may need internationalization support too.
Configuration wise I’d see this as a change from using String to use GeoTool’s
own InternationalString interface, XML storage wise the change would be similar,
e.g. from:
to:
buildings edifici batimentsThe XStream reading code would be backwards compatible and associate
the eventual single string to the default language.
And oh, there would be some place in GeoServer (global settings I guess)
where the list of supported languages would be made configurable.
GUI wise I’m picturing a situation in which multilanguage fields would appear
in all the different supported languages at the same time.
The idea of having some sort of combo, either local to the text field or the
page, allowing to switch the current language, has been taken into consideration
as well, but there are downsides:
- the field local one is a bit tedious, as one would have to switch it for every field
- the page global one makes it difficult/impossible to locate the few fields that need to be
internationalized - either case would make it difficult to see if all the languages have been filled in.
A setup where the field is repeated for all the configured languages, each version clearly
labelled with the language, is better in all the above respects, even if it would eat quite
a bit of space.
Maybe we could have only the configured languages appear, with a button to add a
field for any of the missing languages… but I mean, the point of having a internationalize
server is really to fill all the metadata in the various languages anyways, so one would
have to expand all the languages anyways.
Internationalizing the other requests presents greater difficulties: GetMap should
report labels in the requested language, GetFeatureInfo and GetFeature should
return strings in the proper language.
Now, I imagine a database structure having columns such as name_en,
name_fr, name_it, and GeoServer needs to expose those as “name” picking
the right column from the data source based on the currently requested language.
And we’d need to make this “attribute grouping” configurable too from the UI.
I believe this could be doable using the TransformFeatureStore I’ve been working
on last year, now available as a community module in GeoTools,
by creating a filter function that is language aware… special optimizations for
this one would be nice too, so that the code only ends up reading the string
we need from the database.
The GUI for the name field would then associate it with a CQL expression like:
“internationalize(env(‘lang’), ‘en’, name_en, ‘fr’, name_fr, ‘it’, name_it)”
(maybe for this one a custom GUI could be made to simplify the setup…).
Making sure that also all filters work fine against these fields, and be efficient
too, might prove to be “loads of fun” ™ :-p
Anyways, what do you think? Opinions welcomed
Cheers
Andrea
–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it