Wikipedia:Wikipedia Signpost/2013-01-07/Technology report

Technology report

Looking ahead to 2013

2013: Wikidata, Lua and VisualEditor expected to headline

Following on from last week's reflections on 2012, this week the Technology report looks ahead to 2013, a year that will almost certainly be dominated by the juggernauts of Wikidata, Lua and the Visual Editor.

The Wikidata client (phase 1, at least) launches this week on the Hungarian Wikipedia, making almost all "manual" inter-language links obsolete. With phase 2 (infobox-style data items) yet to be reviewed, however, and the code behind phase 3 (dynamic lists) not yet written, the possibility that the developers will wrap up in late March without phase 3 being deployed remains a significant risk. Even so, the project could well be the biggest success of 2013.

The other contender for that title is the Visual Editor (VE), assuming that its development schedule does not slip further. The current target is for the VE to be enabled by default "for (almost) every Wikimedia/MediaWiki instance" by the end of July, probably requiring (at a minimum) references, images and table support to have been added, as well as some category and inter-language link functionality: an ambitious goal.

Also likely to capture headlines are the Lua and Echo projects. Lua, set to launch in the first half of the year, is an attempt to introduce a proper template programming language, though questions about code duplication could well give existing {{#if:{{{image|{{{image_name|}}}}}}|[[File:{{{image|{{{image_name|}}}}}}|thumb|{{{image_size|250px}}}]]}}-style code a reprise. Echo, also in its early testing phase, is a similarly ambitious project to develop a series of Facebook-style notifications to track everything from new messages to being mentioned by a third party.

Because material on smaller WMF-sponsored projects is somewhat less centralised than this year, and describes a shorter timespan – most plans only run until the end of June for budgetary reasons – it is difficult to see past these big projects. Certainly, mobile uploading is now firmly on the agenda after the success of the Wiki loves Monuments app, which included a specialised version of the same functionality. There is also the Toolserver migration to consider, introducing the possibility of a stand-off in the latter half of the year between the WMF and any Toolserver developers who do not wish to migrate. Other smaller projects up for debate at the moment include tweaking the API and deleting little-used preferences, though they are (counter-intuitively) probably less likely to make it to fruition.

So much for the WMF-led development. Volunteer developers, now with up to nine months of experience of Gerrit development under their belt, should continue contributing in 2013 as they have done in previous years, though it remains to be seen whether reform of WMF staff's 20% time can finally eradicate code review complaints (answer: probably not, though any amelioration would no doubt be warmly welcomed). In short, then, it is set to be a very exciting 2013 for Wikimedians, or, perhaps, a very disappointing one indeed.

In brief

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.

Page view data revised downwards: Page view data from late December and early January had to be revised downwards after it appeared to show a 44% month-on-month increase in the number of visitors to the mobile site. The figures, eventually given as 5% increase month-on-month, nevertheless still show a 77% increase in visitors to the mobile site over the last year. Mobile views have been boosted by the Wikipedia Zero project, which currently allows 200–300 million mobile subscribers (incorrectly reported last week as approaching a billion) to access the project for free.

← Previous "Technology report"

Next "Technology report" →

In this issue

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

What exactly does "obsoleting almost all inter-language links" mean, please? Peridon (talk) 12:55, 9 January 2013 (UTC)[reply]
- I rephrased to "making almost all inter-language links in pages obsolete". 81.175.123.154 (talk) 12:58, 9 January 2013 (UTC)[reply]
  - Thanks. I've further tweaked the wording slightly. - Jarry1250 ^{[Deliberation needed]} 13:28, 9 January 2013 (UTC)[reply]
    - 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? --Waldir ^talk 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 ^{[Deliberation needed]} 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 ^{[Deliberation needed]} 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? --Waldir ^talk 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 ^{[Deliberation needed]} 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. --Waldir ^talk 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 ^{[Deliberation needed]} 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. --Waldir ^talk 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 ^{[Deliberation needed]} 11:28, 10 January 2013 (UTC)[reply]

Keep up with The Signpost on Twitter, Facebook or Mastodon.

Home

About