clarify support for language

[tomkralidis]

OGC API - Records defines a properties.language property which we are able to use in WCMP2 as needed (see https://docs.ogc.org/DRAFTS/20-004.html#sc_record_language_handling for more information). In short:

• properties.language is the language of the actual record
• properties.languages is a list of languages that the record is available (for example, a GDC could do content negotiation to return the requested language of a multilingual metadata record)
• properties.resourceLanguages is a list of languages that the actual data is available as/in

Should we make this more explicit in WCMP2 (i.e. requirement/recommendation, and what [if any] languages would be required)?

[josusky]

I have read the draft of the OGC specification that @tomkralidis provided. I would say that it is described from the point of view of the catalog. That is, if the users requests record in language A (and the language is supported) the response will be in that language. But we are describing metadata record, that is a document. Should that document combine all languages in one? Or should the data provider publish multiple records, each in one language? The latter makes sense, and is more inline with the presented OGC specification, but how will the catalog distinguish those records? Should they have different IDs or will the GDC distinguish records by looking at the language property too? And what if the provider updates a record for one language but not for the other?
I mean, as a non-native english speaker, I fully understand the desire to have records in more languages, but as I think about it, it seems to me, er, more and more challenging.

[antje-s]

Since multi-language is always a challenge, I would be in favor of the metadata for international exchange being in English.
This can always be expanded at a later stage, but as already mentioned, this also involves the risk that the records of the individual languages are not up to date. That's why English records should always be seen as the "master" and the other language versions only as nice-to-have. The other language records could then only be displayed if they have the same update date as the English metadata record.

[tomkralidis]

In WCMP2, we can also define additional languages as rel=alternate links with:

{
    "title": "metadata record in French",
    "type": "application/json",
    "rel": "alternate",
    "hreflang": "fr-CA",
    "href": "https://example.org/fr/data.json"
},
{
    "title": "metadata record in German",
    "type": "application/json",
    "rel": "alternate",
    "hreflang": "de-DE",
    "href": "https://example.org/de/data.json"
}

[antje-s]

Linking from the English metadata record sounds like a good solution.
When publishing a new version of the English metadata record, it is then up to the originator center to check/update the linked documents (like all included links). In the event of differences in content (e.g. due to a forgotten update of a language variant), it is clear in this way that the internationally exchanged English metadata record is the binding one.

[tomkralidis]

+1 for specifying English an explicit requirement given the nature of WIS 2.0 data exchange; allow for multiple languages through links as specified in OGC API - Records. Note that this is also consistent with WCMP1 behaviour/requirements. cc @amilan17 for any comments on any WMO policy / directives in this regard.

[tomkralidis]

Proposal for languages for review:

• Language to be specified as RFC-5646 (per OGC API - Records)
• English SHALL be the required default language
• all languages in which the WCMP2 record is made available MAY be put forth via properties.languages
• all languages in properties.languages SHALL have a matching link with rel=alternate and hreflang=<RFC-5646>