[OSGeo-Discuss] multi-lingual WMS-legends

[Geoff Hay]

Hi
In my project I am using Web Ontology Language (OWL W3C.org) to sort out multi lingual labels (among other things). I have found it works extremely well and allows this specific stuff to be managed separately from any of the aps that might require this. I manage the actual labels with Protege.
Geoff


________________________________________
From: discuss-bounces at lists.osgeo.org [discuss-bounces at lists.osgeo.org] on behalf of Adrian Custer [acuster at gmail.com]
Sent: Wednesday, 25 May 2011 11:03 a.m.
To: discuss at lists.osgeo.org
Subject: Re: [OSGeo-Discuss] multi-lingual WMS-legends

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
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss