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
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
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
Brian Wolff bawo...@gmail.com writes:
From the list:
Check for vulnerabilities
That could use clarification...
https://phabricator.wikimedia.org/T1076
--
Mark A. Hershberger
NicheWork LLC
717-271-1084
___
Wikitech-l mailing list
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
On Tue, Nov 4, 2014 at 11:25 AM, Daniel Kinzler dan...@brightbyte.de
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
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
On Mon, Nov 3, 2014 at 11:26 PM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
Hoi,
I do not get it. It says, it will eventually put this information into
Wikidata ... WHY NOT NOW ?
:)
Soon! It's just that in the early days of building this, we've been doing
lots of usability testing and
There's a long-standing request for Scribunto to provide library functions
for JSON encoding and decoding.
The advantage of this would be improved interoperability with the growing
number of extensions that use JSON (e.g. JsonConfig, Graph).
The disadvantages include:
* People may store data in
Disclaimer, Obviously as the developer of JsonConfig Graph, I am strongly
in favor of Json capabilities in Lua. That being said, would the new Lua
functions be any more in danger of misuse than the powerful raw HTML
generation library, or the capability of pulling content of may pages in a
list
I think we should do it. The disadvantages aren't really disadvantages,
since users could just write their own JSON-processing module if we don't
give them one, and then those could both be issues anyway.
Jackmcbarn
On Tue, Nov 4, 2014 at 3:45 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
On Tue, Nov 4, 2014 at 1:02 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote:
On Tue, Nov 4, 2014 at 3:45 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
There's a long-standing request for Scribunto to provide library functions
for JSON encoding and decoding. [Advantages: lots of use
On 4 November 2014 20:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote:
* People may store data in JSON blobs that must be parsed where a module
using mw.loadData would be more appropriate.
* People may write templates that attempt to bypass the normal MediaWiki
parameter handling
13 matches
Mail list logo
