On Mon, Feb 18, 2013 at 1:20 PM, Lydia Pintscher <lydia.pintscher(a)wikimedia.de> wrote: Sorry current version is at http://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

For later. As discussed before, access via HTTP is probably hardly an option for the Wikimedia wikis (and they are our priority), but for other wikis that will be crucial. Cheers, Denny 2013/2/18 Yuri Astrakhan <yuriastrakhan(a)gmail.com> -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Totally agree about the wikidata interface convenience, but I suspect it might not cover all usages, in which case it will be a good way for users to start implementing workarounds, and for us to notice the need and meet it with new features. I don't know enough about template performance impact, although I do hope that a low-limit API call does not impact much more than a complex template with many links/templates/categories. In any case, lets put this on back-burner for later evaluation. On Mon, Feb 18, 2013 at 7:29 AM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote:

On Mon, Feb 18, 2013 at 7:24 AM, Yuri Astrakhan <yuriastrakhan(a)gmail.com> wrote: Personally, I'd be extremely wary of allowing Lua (which is run in the middle of the page parse, remember) to be issuing HTTP requests on WMF sites. Especially after seeing how slow using ForeignAPIRepo for file accesses makes my local test wiki.[1] IMO it would be better for accesses to go through interfaces designed for the access, where the back end for the interface can optimize and cache and explicitly limit the access, instead of opening it up to arbitrary API calls in the middle of the parse. This back end could of course have options to work like ForeignDBRepo on WMF sites and ForeignAPIRepo on non-WMF sites, which would be transparent to the end user. On Mon, Feb 18, 2013 at 7:48 AM, Yuri Astrakhan <yuriastrakhan(a)gmail.com> wrote: "Workarounds" like enwiki's Template:Str sub?[2] There will probably be some of that anyway, but we don't need to encourage people to do so. [1]: For those that don't know, ForeignAPIRepo allows one MediaWiki wiki to include files from another by making calls to the prop=imageinfo API, in a similar manner to how WMF wikis use ForeignDBRepo to include Commons images by looking directly in Commons's database. [2]: It's possible to implement {{str left|text|len}} using the {{padleft}} parser function. So enwiki has a template {{str index|text|pos}} that "gets" the character at 'pos' by basically taking {{str left|text|pos}} and seeing whether it's equal to {{str left|text|pos-1}}A, {{str left|text|pos-1}}B, {{str left|text|pos-1}}C, {{str left|text|pos-1}}D, and so on. And then {{str sub|text|start|len}} is implemented by calling {{str index|text|pos}} for every position between start and start+len.