My preference would be for a client initiated approach that automatically took effect on September the 19th.

A conforming client SHOULD perform an HTTP request for the feed with the Accept-Language header set to "en-pirate" (or whatever the standard RFC 3066 language tag for the pirate dialect of english). A conforming server SHOULD return the pirate version of the feed with the Content-Language header set to "en-pirate" and/or the xml:lang attribute set to "en-pirate" in the root element.

Any feed items that the client had previously received (based on matching atom:id and atom:updated elements) MAY be kept as is (i.e. in their original source language). However any new messages received would be in the pirate dialect.

Future downloads of the feed (after the 19th September) SHOULD return to using an Accept-Language header of "en-us" (or whatever the user's prefered language), but any messages that had been received on the 19th MAY remain in the client database in the pirate dialect (assuming their atom:id and atom:updated elements remain unchanged).

IMHO ;)

Reply via email to