This page is currently a draft. More information pertaining to this may be available on the talk page.Translation admins: Normally, drafts should not be marked for translation.
This note describes the major workflows for phase I on Wikidata – that is, how to create and maintain language links. This document, a set of storyboards, resolves Bug #36435 is completely revised from the original set, so that they are more generic and able to work with either the current way of showing interlanguage links (sidebar) or with the proposed universal language selector widget (or whatever that ends up being).
Use cases include:
- Connect Wikipedia page to existing Wikidata item
- Connect Wikipedia page to Wikidata, with no existing item (create new item)
- Edit interlanguage wiki links on Wikipedia, which are in Wikidata
- Edit interlanguage wiki links which come from Wikidata and include interwiki links in the local wikitext.
For more complicated cases, such as migrating interlanguage links from current wikitext to Wikidata, at least initially we do not intend trying to create a complex user interface in Wikipedia. We assume that mostly bots and advanced users will do this, with help from gadgets perhaps.
Connect Wikipedia page to existing Wikidata itemEdit
Connect Wikipedia page to new Wikidata itemEdit
Note: the wording of "local language links" needs to be improved, but not yet sure what is the best way to word that.
Suggested new itemsEdit
- Needs to be reworked.
- Client API: Forward requests to the client on to Wikidata
- Client: Ensure the languages section in the sidebar is always displayed and the own language is displayed in bold
- Client: Add language link
- Client: Edit and remove a language link
- Client: Detailed view in the language link
- Client: Fix Bugzilla:5231: Mouseover explanations for interlanguage links in native languages. This should be easily done with the CLDR extension which is live on the WMF cluster. There exists a nice function (see rev:90900) to get the translated language name. Would be best in user language, otherwise content language would be fine too.
- Client: Generalize the functionality beyond inter-language links to open links within the page, including potentially links to stubs. When hovering over an open link, offer a simple way to call functions that "partially fill" a link - for instance finding an article in a sister wiki, marking it a stub and submitting it as a first edit. Or return a page of search results from a general purpose search engine, permitting the most relevant ones to be selected by checkbox, and submitting a page of those links, anchor-texted with title, as a stub. Ideally mark such generated pages, and potentially stubs, as something "between" a full and open link, with a different color or typeface (as determined by CSS), perhaps integrating this with FlaggedRevs (standard way to indicate which links may deserve/require more attention).
- Server: Specify a policy by which inter-language or stub pages may be automatically generated without user intervention or a priori approval. For instance, a list or proper names associated with email, Facebook or LinkedIn can be reasonably stubbed with a simple page indicating all such links, straight from an address book. Or, a specified directory in a filesystem can automatically populate namespace only as the names are referred in pages as open links. Or, a corporate name that consistently appears at the top of several search engines and matches the aboutus.org entry on that name, can be linked as the authoritative site on that name. Or, an open link that is a resolved URL (like [[eBay.com]]), can be directly linked with a link indicating that most/all root DNS resolve to that domain.
- Server: Specify some default policies including transclusion of pages from public wikis, or caches of public wikis, similar to the wikinfo.org functionality, or a private intranet / public web division of function, in which public pages are mirrored in the private wiki that maintains a much more extensive version of them.