Still not certain what's going on. Does this mean the sidebar 'other language' links, or links in the text like fr:squidge or both or something else altogether? Does 'making obsolete' mean they're no longer needed, or that they no longer will work? Technology's your business - words are mine... Peridon (talk) 14:43, 9 January 2013 (UTC)[reply]
We will be able to get "other language" links in the sidebar from Wikidata. (e.g. one copy of the list of links for all the wikipedias, vs. hundreds now) The current interwiki language links (in the sidebar), coming from wikitext will still work but I expect bots to "migrate" them to wikidata and then remove them as they will then be "obsolete" or not needed. If some wants to override an interwiki link coming from Wikidata, that can still be done with regular wikitext on a Wikipedia page, and there is the ability also to suppress them with a magic word or parser function. (see mw:Extension:Wikibase Client#noexternallanglinks) --Aude (talk) 17:54, 9 January 2013 (UTC)[reply]
So what will this mean for someone who on occasion adds interwiki links to articles here and places like the Breton, Marathi and Swedish Wikipedias (to name but three? I'm not sure about what you mean about 'not needed'. How can wikilinks not be needed? Peridon (talk) 19:32, 9 January 2013 (UTC)[reply]
There will still be interwiki links. You can add them in Wikidata, and there will be a widget in Wikipedia for editing them without going to Wikidata. It just means if you add a interwiki link, say to Breton, then other wikipedias can also fetch the links from Wikidata. (vs. bots going around and adding them everywhere). --Aude (talk) 20:21, 9 January 2013 (UTC)[reply]
It's the adding links in wikitext is what won't be needed. Add them in Wikidata or with the widget instead. --Aude (talk) 20:22, 9 January 2013 (UTC)[reply]
So it's going to be easier than typing fr:squidge or en:thingy inside square brackets? Peridon (talk) 21:11, 9 January 2013 (UTC)[reply]
Yes, and in a couple months, infoboxes may get a little bit easier too as we'll have a central location for basic facts like population that are probably the same on all Wikipedias. The links help to know which pages are connected and the pages will be able to use data from Wikidata. --Aude (talk) 23:01, 9 January 2013 (UTC)[reply]
This will probably cause a problem for some mathematics pages which have ambiguous interwiki links. For example, see Talk:Aleph number#Interwikis. JRSpriggs (talk) 16:21, 10 January 2013 (UTC)[reply]
If there is not a one-to-one relationship for particular interwiki links, then we can stick to the current system for particular pages. There also are some interwiki links that link to a subsection of another wiki's page, for example. Wikidata doesn't handle that scenario.Either add no connection to Wikidata (no sitelinks from Wikidata to X wikipedia) or use the magic word or parser function to switch the Wikidata stuff off for a page. --Aude (talk) 18:27, 10 January 2013 (UTC)[reply]
I don't think I understand what "questions about code duplication could well give existing {{#if:{{{image|{{{image_name|}}}|[[File:{{{image|{{{image_name|}}}|thumb|{{{image_size|250px}}}]]|}}-style code a reprise" means. Can someone clarify? --Waldirtalk 16:41, 9 January 2013 (UTC)[reply]
I think it means they're trying to get rid of things like that, but aren't too sure about success. The problem with experts explaining things is that they (usually) know what they're talking about, but outsiders don't speaka da lingo and end up more puzzled. Sorry, folks, it's a standard thing in many fields and compulsory in manuals... Peridon (talk) 17:23, 9 January 2013 (UTC)[reply]
On the meta point, the Technology Report has a varied audience of approximately 1000, including completely non-tech-savvy users, people who are IT but not programming literate, developers, system administrators, Wikipedia insiders with technical expertise, template experts, user script writers... I'm always open to suggestions on how to improve the offering -- this report was relatively rushed, so probably worse than usual -- but unfortunately it is the nature of the beast that some readers will not be able to understand some bits. I do my best to respond to comments, however, and am happy to explain further there :) - Jarry1250[Deliberationneeded] 18:02, 9 January 2013 (UTC)[reply]
Peridon more or less has it. The project is to make blocks of code like the one provided - which are completely unintelligible to anyone but a template expert - a thing of the past, but questions about code duplication (i.e. the prevention of users having to copy and paste code between wikis) may prevent the project coming to fruition as early as previously hoped. - Jarry1250[Deliberationneeded] 18:02, 9 January 2013 (UTC)[reply]
And why would users be prevented from copy-pasting code between wikis? Is Lua going to be deployed only to a few wikis? --Waldirtalk 20:27, 9 January 2013 (UTC)[reply]
Well, there are many problems with copied and pasted code, mostly related to the fact that updates to one don't find their way into the other. Thus we have wikis at the moment running versions of gadgets en.wp was running back in 2007. Allowing this to happen again with Lua is undesirable; rather, you want to have a strong system of centralisation (Wikimedia Commons-style) in place, so that changes propagate. - Jarry1250[Deliberationneeded] 23:18, 9 January 2013 (UTC)[reply]
Still, how does that bias things towards template-like code rather than Lua code (as the sentence seems to suggest)? Both are equally vulnerable to the unsync problem. --Waldirtalk 01:06, 10 January 2013 (UTC)[reply]
Oh, they're not, but this is a once in a decade opportunity to drastically increase the amount of template-code centralisation. Many will be prepared for Lua to be held up to ensure that that opportunity isn't missed. - Jarry1250[Deliberationneeded] 11:28, 10 January 2013 (UTC)[reply]
Ok, I get it (and agree, btw). But I think the original passage should be rewritten, as I could hardly extract anything resembling what you explained in this thread. --Waldirtalk 20:11, 10 January 2013 (UTC)[reply]
From where I stand, things look a lot less monolithic and a lot more vibrant, but I'm not quite sure how to convey it. I suspect that the data produced by our Git and Gerrit workflow, being a mixture of machine-readable data and high-level descriptions (in the form of commit messages and comments), could be used to programmatically generate summaries of ongoing development activity. We get a little bit for free by mirroring our code on GitHub. You can get a lot of useful information out of GitHub's dashboards (extensions, core). Let me know if you have other ideas on how to raise the visibility of smaller projects (or of development work generally). --Ori.livneh (talk) 09:56, 10 January 2013 (UTC)[reply]
Yes. I tend to get a lot more on the smaller projects into my précises of the monthly reports. An annual roundup is bound to be a simplification by comparison. - Jarry1250[Deliberationneeded] 11:28, 10 January 2013 (UTC)[reply]
