Content language negotiation?

[r12a]

[sent on behalf of Addison Phillips]
There is no use of the Content-Language or Accept-Language HTTP headers as a means of possibly negotiating language. Should there be?

[csarven]

For Discovery, literal content is not used (only URI following).

The spec only has a MAY for Receivers to add additional descriptions, otherwise the payloads are stored and retrieved back as is. There is no example where the receiver enriches the content in the spec. Receivers are not required to do language translations of the content nor create new resources with alternative languages.

I've added Accept-Language and Content-Language to some examples, so that if there is to be any language negotiation, that'd be it.

[aphillips]

Per our discussion in the I18N teleconference today, and my action, I'd suggest the addition of a new subsection of Section 5. My proposal would be something like:

== Section 5.x Natural Language Content ==
Building an international base of users is important in a federated network. Some
LDN interactions can return content with natural language text, such as HTML fragments,
or summary fields. Providing multiple language representations of each item might not
be feasible in all circumstances. Implementations are encouraged to provide means of
discovering the available languages and/or negotiating the language returned, such as
using the HTTP Accept-Language header to negotiate and select the most appropriate
language representation to send for a given request.

[csarven]

@aphillips Added your suggestion as is. Works for me. Thanks! This is a good (and much needed) addition to the Consideration section. Feel free to close this issue if satisfied.

[aphillips]

@csarven I'm satisfied (obviously) by this fix.

I don't have close permission on this repo. Feel free to close this item or @r12a, please do the honors?