Re: Request for i18n review of PubSub

Hello Amay,

I haven't seen any reply to your mail, so I'm giving it a try
(personal opinion only).

On 2016/11/11 11:13, Amy G wrote:
> Hi Addison, Richard, and everyone,
>
> PubSub (previously known as PubSubHubbub, and possibly facing a new name
> change soon) recently entered FPWD. It's been incubated for several years,
> and so we think the current state of the draft will be fairly stable.
>
> https://www.w3.org/TR/pubsub
>
> We would very much appreciate an i18n review at your convenience.
>
> Protocol summary:
>
> The subscriber discovers the target's *hub*, and sends a form-encoded POST
> request containing values for *hub.mode* ("subscribe"), *hub.topic* and
> *hub.callback*. The hub verifies this request. When the target posts new
> content, the target's server sends a form-encoded POST to their hub with
> values for *hub.mode* ("publish") and *hub.url* and the hub checks the URL
> for new content and subsequently delivers updates to the subscriber's
> callback URL.
>
> You'll notice it's based around a finite set of English language strings
> for both keys and values which are passed around. Given this is entirely an
> internal data passing mechanism, I don't know if it raises i81n problems.

I haven't actually looked at the spec, but from your description, it 
sounds to me as if you should be (mostly) safe.

> Maybe it does. The editor (Julien) went through the self-review checklist
> and noted:
>  * The checklist seems to be strongly oriented toward HTML/formats when we
> are mostly providing a “transport" protocol.

There is nothing saying that formats have to be internationalized but 
protocols don't, but in general, protocols have less needs for 
internationalization than formats. The traditional needs in protocols 
are clear identification of (and possibly negotiation of) character 
encodings and languages.

>  * It is not clear whether it’s ok to have English word in our syntax. It
> would not make sense to have parameters “translated” here.

HTTP doesn't have translations e.g. for GET/PUT/POST/..., and that's 
perfectly okay.

>  * Error messages are returned in English - they're intended only for
> developers to see, do they need a localization mechanism?

Not all developers read English. In certain regions/countries, it may be 
required to provide products with error messages in other languages. So 
I'd tend to say YES here.

Regards,   Martin.

Received on Wednesday, 16 November 2016 06:00:00 UTC