search

INSPIRE-MIF / gp-ogc-api-features

Good Practice document for INSPIRE download services based on OGC API - Features
13 stars 12 forks source link

/rec/pre-defined/accept-language-header #13

Open cportele opened 4 years ago

cportele commented 4 years ago

In our experience, it is a question what "supported languages" are. In reality there may be a mix, in particular, if HTML is a supported encoding. An example:

Some parts of the response to .../collections/{collectionId} or .../collections/{collectionId}/items will be provided by the software and some parts will be provided by the dataset or its metadata. Each of them will support different languages. For example, ldproxy currently supports English and German for the texts provided by the software, but the content may be in any language.

curl -i "https://services.interactive-instruments.de/t15/daraa/collections/CulturePnt/items/1" -H "Accept-Language: de" -H "Accept: application/geo+json" will return a response with the ldproxy controlled texts in German (just the link titles in this case) and some attribute value in Arabic, some in English or even a mix (because these are the values in the dataset).

What should the API return as "supported languages" in this case (and why)?

heidivanparys commented 4 years ago

I guess this problem should be documented as a part of proposed action 2020.1 for the MIG, see also document MIG/11/2020/DOC7 (action to be discussed at the 11th MIG meeting).

alexanderkotsev commented 4 years ago

Indeed so!

I guess this problem should be documented as a part of proposed action 2020.1 for the MIG, see also document MIG/11/2020/DOC7 (action to be discussed at the 11th MIG meeting).

heidivanparys commented 4 years ago

GitHub-label "NS regulation"