Am 04.11.2014 16:26, schrieb Brad Jorsch (Anomie):
The disadvantage of using the user language is that it reduces cacheability: all responses have to be marked anon-public-user-private instead of public where public would otherwise be allowed. True, there are a number of other reasons that an API response may not be cached, but adding one more to the pile doesn't improve the situation.
My complaint related to the user language, which is only relevant for logged in users - which means web caching doesn't apply anyway. I don't see how caching is relevant here.
When a client really does need output in the user language, it seems simple enough for that client to specify "&uselang=user".
Yes, but this is still a breaking change that should have been announced and discussed first.
By the way - once we support localized error messages (soon, I hope), does this change mean that bots will always see localized error messages, unless they add the uselang parameter to all requests?
I note that, while adding uselang as an official parameter was done along with the help change, it was only done then because uselang was on my list anyway and without it I would have had to add uselang to both action=help and action=paraminfo (only to remove it later).
I'm all for supporting uselang. I' just against changing the default.
The new behavior is inconsistent with the behavior of the main entry point and UI, and breaks existing clients. The caching seems rather hypothetical to me (it seems more realistic to go for a proper REST API for that). Please restore the old behavior.
-- daniel