addition of language metadata

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Daniel Morissette
> Sent: 02 November, 2006 3:02 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] addition of language metadata
> 
> Kralidis,Tom [Burlington] wrote:
> > 
> > In the context of Exceptions, maybe we can (at this point) set to 
> > English?  But which one?  en-US?  en-CA?  en-GB?
> > 
> 
> Does the region part of the language code really matter? If 
> we used "en-US" as the default, would that break any client?
> 

Not really.  We just need to agree on one language for exceptions, so
"en-US" would be fine with me unless there are objections.  That is,
until if/when we start doing internationalization for MapServer error
messages :)

> > In terms of content, I think this would be valuable in 
> preparation for 
> > OWS Common support.
> > 
> 
> But since exceptions are hardcoded in English then we'd need 
> two ows_language settings: one for exceptions and one for content.
> 
> Let's say I setup a OGC service with in French, I would set 
> "ows_content" to "fr-CA" and this value could be used in the 
> header of the GetCapabilities response, but we do *not* want 
> this value used for exceptions which are hardcoded in English.
> 

OK, so what about agreeing on hardcoding OWS Common XML ExceptionReport
messages with "en-US", and "ows_language" for the language for things
like stuff like DataIdentification (which msOWSGetLanguage would be
applied)?

> Will clients get confused if they get the capabilities in one 
> language and the exceptions in another language?
> 

They *shouldn't*, seeing that they should check the @language attribute
of the XML response for ExceptionReport and DataIdentification.

HTTP headers would get more complex, since the client may ask for a
specific language (i.e. Accept-Language=en-US,en;q=0.5), and the server
would respond with Content-Language=ows_language).

What is MapServer's current stance on HTTP header responses for
outputting language?  It looks like this isn't implemented yet (mind
you, it would need more discussion).

> Daniel
> 
> P.S. It's funny to see our roles reversed: I have switched to 
> the user side asking the tough design questions and you are 
> now on the developer side having to find solutions to answer 
> them. Either way we keep arguing which is good. ;)

My sentiments exactly! :)