Content Negotiation doesn't mention language as a negotiating point
r12a opened this issue · comments
[from @joconner, and reviewed by the i18n WG]
Section 4.1 Content Negotiation
"It is, however, possible to perform content negotiation by returning an appropriate rel=self URL according to the HTTP headers used in content negotiation. For example, a request to /feed with an Accept header containing application/json could return a rel=self value of /feed.json."
This section mentions content negotiation of mime types but does not mention language as a possible negotiation point. Is that intentional? Overlooked?
I remember this coming up previously, but I cannot find where at the moment. Basically it would work exactly the same way, it would need to return a different rel=self for that specific language
@r12a I believe it was accidentally overlooked. When we were talking about it, I don't recall anyone mentioning language, or thinking of it myself.
It seems easy enough to add to the text a mention that the same approach would also suffice for lang negotiation. Sound good? Is there a good reference for language negotiation? I think some websub implementors will be unfamiliar with it.
@r12a I believe it was accidentally overlooked. When we were talking about it, I don't recall anyone mentioning language, or thinking of it myself.
+1.
And I agree this is probably a trivial change but I have no idea how language negotiation actually works :/
I am not yet convinced that the additional text would be trivial - but that might change when some text is proposed.
Suggested text
For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be able to perform notifications using the same mime-type and language.
It is, however, possible to perform content negotiation by returning an appropriate rel=self URL according to the HTTP headers used in content negotiation. For example, a request to /feed with an Accept header containing application/json and having a language of fr could return a rel=self value of /fr-feed.json.
Applications also have the option of varying the hub URI based upon content negotiation results. Depending upon the situation, this may be preferable
Indeed, as in https://fr.wikipedia.org/wiki/Chat
Resolved to close with text similar to the suggested text https://www.w3.org/wiki/Socialwg/2017-09-19-minutes
Suggestion:
and having a language of fr
->
and having a Content-Language header with the value fr
I'll add this to the i18n WG telecon agenda for tomorrow.
oops, that should have been
having an Accept-Language header with the value fr
doh!
@r12a Why did you re-open? Do you see a problem with https://w3c.github.io/websub/#content-negotiation ?
hi @sandhawke, see my comments above, which were added after the issue was closed. Since feedback had been quick (like your response just now) i thought maybe i needed to reopen the issue for people to see the additional comments. I was unaware that the edits had been made until i just now looked at the link you posted, and saw that you have in fact incorporated the comments. So i think we're good here from my pov. I'll check with other i18n folks before we close our tracker, as usual, but i think we can reclose this issue now. Thanks.
Thanks, sorry for not being more clear about the edits that were made earlier.
During our telecon today, the i18n WG decided it was satisfied with this resolution. Thank you.