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

[cportele]

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]

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]

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]

GitHub-label "NS regulation"