Considering that mobile relies on the API for a large percentage of it's UI and
currently serves about half of our traffic, I'm pretty surprised this change
was not discusses with the mobile team. I'm on a bus right now and haven't been
able to test things thoroughly, but it looks like some part
On Tue, Nov 4, 2014 at 11:25 AM, Daniel Kinzler
wrote:
>
> 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?
>
No. The plan there is that e
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
It's simple enough for clients. It's still a breaking change, though,
and every client has to be touched. For example, right now I try to
work with ApiSandbox, and it does not support or use uselang yet.
Sure, it's easy enough to fix, but there are lots of clients out
there, and most of them are no
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 t
Hi all!
It seems that during the current efforts to modernize the API, the default
language (as represented by $wgLang) was changed to always be the content
language [1][2] instead of the user language. This may not be a problem for most
of the core modules, but broke some essential wikibase API m
