[OSGeo-Discuss] multi-lingual WMS-legends

[Adrian Custer]

Hey Cameron, all,

On 05/25/2011 12:12 AM, Cameron Shorter wrote:
> OGC standards people,
> Have there been any discussions at the OGC level about specifying
> language support within OGC standards?

Yes, we have had discussions; no we have not yet found solutions.

As part of our work cleaning up the "WMS mess" for 2.0, I have looked at 
the language rules given by 'OWS Common' (the proposed base layer for 
all OGC Web Services). Those rules seem both restrictive and broken (due 
to mutually incompatible requirements). The broken can be fixed, however 
the fundamental approach itself is problematic for WMS.

The approach of OWS Common forces any OGC web service that wishes to 
advertise that it supports a particular language to offer *all* its text 
strings in all of its resources in that language. The bar is therefore 
exceedingly high---it seems to argue that if any layer of labels on the 
service cannot be obtained with all its labels in a particular language, 
that language cannot be said to be supported by the service. For WMS 
labels of, say, place names, this all or nothing approach seems 
needlessly restrictive; it is hard enough to get labels of any kind for 
a country or continent without trying to get them all in a single 
language (let alone several). I suspect the current approach sets an 
impossibly high requirement. Regardless, it seems like it would be 
useful to have some language mechanism, presumably using an additional 
but complimentary approach, based on a best effort contract. (Note that 
INSPIRE too seems to use the 'everything must be fully translated' 
approach, if I remember correctly.)

Then there are a few technical difficulties that will need to be 
resolved---e.g. OWS Common requires that each and every string which is 
localized to have its localization labelled directly on the XML element 
without explaining if/how this labelling should work on non XML 
elements. Also, there are many strings which should *not* be localized 
so it would be better if the various OWS services identified which 
fields were expected to contain human readable, textual content. There 
is also the problem that INSPIRE seems to be using its own particular 
language identifiers different from those commonly found in the world of 
the Web. There are other issues as well that are not coming to mind 
right now but will need to be addressed.

So it seems there are two needs for language support: one in which 
Servers indicate they have full and complete support for a particular 
language, another through which they may indicate a best effort support 
for a given language. As to the details of the mechanisms of how a 
client indicates its particular language preference and how a server 
indicates the particular languages in which it has offerings, they are 
part of our ongoing work cleaning up the 'what a mess' of WMS.

Easy, pragmatic solutions which solve anyone's particular needs can 
readily be found (and the '&lang=' parameter seems to be one such 
solution); solving the general need for all OGC Services needs someone 
to wade through the problem space, discover alternative solutions, 
evaluate those alternative solutions, develop a mechanism to enable the 
best of these solutions, and finally develop the injunctions which will 
make it work. For our work on WMS 2.0, we have accumulated notes on the 
language issues but not yet progressed to develop alternative possible 
solutions nor decided on how to implement the best of those solutions. 
We did decide that our contribution to fixing OWS Common would come 
after we had done the bulk of the work on WMS 2.0.

   ~adrian