Wikidata

Wikidata:Article placeholder

Development plan Usability and usefulness Status updates Development input Contact the development team

For the software feature that was developed and deployed on several smaller Wikipedias after this discussion page had been started, see mw:Extension:ArticlePlaceholder

This page is for gathering input on the article placeholder feature (sometimes called m:Filling red links with Wikidata). The idea is to show something to the user if they search for a topic that is not covered by an article in their Wikipedia (or sister project) but that has information on Wikidata.

Some important points:

  • Wikidata does not aim to replace article writing. The development team has no ambition to try to have Wikidata write articles about complex topics that need more than just data to be fully understood.
  • We do want to give people access to information in their language to the best of our abilities.
  • Wikipedias and co will need to have a way to opt out.
  • This is especially important for small projects with a small contributor base.
  • It is unclear when we will get to implementing anything like this. I want to provide a place to gather input though.

--Lydia Pintscher (WMDE) (talk) 17:55, 29 December 2014 (UTC)[reply]

Example of how this could work edit

Suppose that some Wikipedia article does not exist in some language, but there is data about the topic in Wikidata. For example, Wikidata might have biographical information and genealogies on rulers of a small kingdom from centuries ago, but in a given Wikipedia, no one has made an article for these people.

If someone searches for any one of these people in a Wikipedia, or if someone follows a redlink to their name, then despite there being no Wikipedia article about them, the person seeking information would get information from Wikidata. Among the information given might be whatever information can be translated, like date and place of birth, and notice if the article exists in some other language.

The "article placeholder" in this proposal would be whatever people find when they look for information which exists in Wikidata but not on their Wikipedia.

Note this article placeholder is not a stub article in the wiki's database. It is generated on the fly from latest Wikidata statements (and cached for performance).

Things we definitely need to avoid edit

  • Only focusing on the English Wikipedia or only the bigger Wikipedia's. Multichill (talk) 20:57, 29 December 2014 (UTC)[reply]
  • A non-standard (and therefore sub-standard) i18n system. Must use translatewiki.net and CLDR, creativity will be needed. --Nemo 21:39, 29 December 2014 (UTC)[reply]
  • Creating (pseudo)articles which make it harder, rather than easier, to click "edit" locally as well. --Nemo 21:39, 29 December 2014 (UTC)[reply]
  • Killing red links. Red links must keep encouraging the creation of target pages (or their expansion from placeholder status). --Nemo 21:39, 29 December 2014 (UTC)[reply]
  • Making, or leaving, millions of (pseudo)articles where we confirmed there is no demand. For instance, if we create a million placeholders on Volapuk Wikipedia, and they get 10 non-bot visits per month, we must pull them down. --Nemo 21:39, 29 December 2014 (UTC)[reply]
  • Sorry but the more I think about this the less I like it. Creating a "placeholder article" which duplicates the information in wikidata but as text is, I am convinced, a bad idea. Each of these articles will, I presume, have an infobox. The 'placeholder article' will have the same information as the infobox - that is the only info wikidata knows - but the placeholder info will not update automatically as wikidata is updated. This means the placeholder article will mostly be wrong. A much better use of your time would be:
  1. automatic generation of descriptions in 200 languages based on statements (needs similar auto language generation as the placeholder articles).Generate these on the fly so they update as statements are added.
  2. internationalisation of infoboxes so these can be easily (automatically?) localised. If the localisation can use wikidata labels even better.
  3. Replace stubs in projects which have small teams with Reasonator pages, generated on the fly, always up to date.
  4. A reasonator for wikivoyage info, accessed via a map on your phone and generating infoboxes about tourist destinations on the fly in 200 languages. There are only about a dozen different wikivoyage info templates so it shouldn't be hard - doesn't that sound better than 'placeholder articles' that no one will ever see?
Joe Filceolaire (talk) 03:02, 3 September 2015 (UTC)[reply]
I've said it many times before but I'll say it again: We're not going to write articles. There will not be text at the end of this. --Lydia Pintscher (WMDE) (talk) 11:27, 3 September 2015 (UTC)[reply]
Good. Better to change the name then as calling the output an "Article" makes it sound like it's text. Joe Filceolaire (talk) 23:41, 4 September 2015 (UTC)[reply]
@Joe Filceolaire, "automatic generation of descriptions" is related. I improved the page Wikidata:Automating descriptions -- SPage (WMF) (talk) 21:58, 6 September 2015 (UTC)[reply]

Things we definitely should do edit

  • Give people an easy way to immediately start writing an article about the topic. --Lydia Pintscher (WMDE) (talk) 17:55, 29 December 2014 (UTC)[reply]
    • Do you mean whenever a wiki shows the generated placeholder, provide a link to create the actual page? That seems reasonable, but I think also the generated placeholder should make it possible to add and correct its underlying facts. Replacing a dynamic improving placeholder with static wiki page just because, e.g. the subject's birthday is wrong or missing is not desirable. -- SPage (WMF) (talk) 23:46, 9 September 2015 (UTC)[reply]
  • Where an Infobox is standard in a specific language Wikipedia, complete the Infobox from Wikidata along with a message. Example: [Language] Wikipedia does not have an article on [subject]. You can start the article by clicking here. - - 69.231.36.92 19:00, 29 December 2014 (UTC)[reply]
  • If there is an article about the same topic in another language, there should be an entry point to ContentTranslation to start translating. This may even become the most important entry point to ContentTranslation, but I can only imagine it working if a lot of items have labels and aliases in a lot of languages, cause otherwise it would be impossible to find them. I am not familiar with an easy way to add translated labels to items that miss them (see T64695 by Micru). --Amir E. Aharoni (talk) 19:01, 29 December 2014 (UTC)[reply]
  • Easy to customize per topic, language etc. Multichill (talk) 20:59, 29 December 2014 (UTC)[reply]
  • Harness the power of Wiki editors with local edit prompts suggested on disambiguation pages - I am thinking of large disambiguation pages that may even be split in some languages, but non-existant in other languages. Jane023 (talk) 09:47, 30 December 2014 (UTC)[reply]
    • I just had this idea again, along with lists. So it would be nice to introduce this concept by item type and if the item is a disambiguation page or Wikipedia list, then enable it for all redlinks. Such pages generally do not allow redlinks. --Jane023 (talk) 10:15, 21 January 2016 (UTC)[reply]
  • Collect literature references from the projects in Wikidata (perhaps by extracting this from the ref tags and Cite templates) and present this in the article placeholder. --AFBorchert (talk) 19:14, 24 March 2015 (UTC)[reply]
  • Start with the low hanging fruit - infoboxes and reasonator pages generated on the fly localised using wikidata labels in that language. These will have the same information as these 'placeholder' articles but much clearer that it is automatically generated. They should still have a 'create article' button which will generate an outline with an infobox, ready for the user to edit (using the visual editor). Don't generate the article until the user hits 'save'. Joe Filceolaire (talk) 03:16, 3 September 2015 (UTC)[reply]
  • Reasonator is already doing part of what we want to achieve: give info to the reader. What we miss, is a tool to pre-connect a red link to a wikidata-entry. When we can connect such a link from a red link, reasonator can then give the information, plus the links to existing languages. When you want to encourage editing/creation of the missing language, the reasonator-info should maybe be given along the edit window that already pops up right now. Edoderoo (talk) 09:52, 10 September 2015 (UTC)[reply]
  • your input and signature

This is how I think this should work edit

  • Perhaps test this idea in a specific subject area initially? I think species articles may be a good place to start --Mrjohncummings (talk) 18:32, 29 December 2014 (UTC)[reply]
  • People come for information (in their own language, preferably). In case of no item, we can show them what Reasonator already knows about the subject, this offers basic info and links to available languages that the reader might be able to read as well. An option to write an article? I guess people come to read about something, not to write about something. Remember they started with a search. But a hint (and a link) that they can write the article in their own language based on the info on their screen. But I guess we should keep it optional. Edoderoo (talk) 18:40, 29 December 2014 (UTC)[reply]
  • Wikidata should be able to do the boring part of formatting a biography stub (name in bold, with aliases, birth date/place, death date/place, was a [nationality] [occupation]). We might do that much automatically, or only when a user chooses to start the article. - PKM (talk) 19:12, 29 December 2014 (UTC)[reply]
  • Pre-formated articles have an obvious way to be implemented in Mediawiki that works right now : Templates. There is already templates that shows infobox in a lot of language, we should be able to use them. The only missing thing needed imho is a way to know wich template we have to use for a specific kind of items. There is (will be) a way : queries. The rules that choose the template to use for specific items should be of type "if the title of the article is associated to an item that is in the set of this query, then that template will do the job". One way to build the associations for users could be to propose to add a template for a language/project on the query page. One thing to figure out is "how to handle cases where the item match several queries". One other is "should the wikipedia&all project use the label of the items as article title or should we be able to create link to redlinks in the wikidata items list, otherwise how do we handle same label items". This only use existing mediawiki and wikibase concepts. TomT0m (talk) 20:25, 29 December 2014 (UTC)[reply]
  • We could establish a form of pre-article called "datasheet". For example: White page = written article, light blue (or any other color) = datasheet. This datasheet would work only with templates. (One single template or multiple templates for persons, places, works etc.) Every Wikipedia could decide how extensive this page will be. Instead of writing a full article a user can start with creating a datasheet page. Later this page can be replaced by a full article. This would be a good alternative to the bot created articles that are spamming small Wikipedias. (Technically you could use a badge as for "good" and "featured article". In this case it would be a badged called "datasheet" or "pre-article".) --Kolja21 (talk) 21:26, 29 December 2014 (UTC)[reply]
  • A lot of sports articles are very data heavy (especially league seasons, tournaments etc.). While most of this data has not yet been entered in wikidata it shouldn't be that big a deal to add and, as I understand it, there is a lot of interest in football articles in some less spoken languages. ~~~~
  • Provide MediaWiki with a string-WikidataID table & display red links accordingly (e.g. append a link to Resonator, or add a logo that upon hover will indicate that additional information such as an infobox will be displayed on the red link's page). —Tinm (d) 19:31, 20 January 2016 (UTC)[reply]
  • your input and signature
  • The idea that this is all about Wikipedia is a problem here. The feature is brilliant if we use it for things we would never want to do with a Wikipedia article. Imagine a page on a person of interest - let us say a 19th-century author or painter - and here you can create a page with all the addresses he has lived, all the places he has seen on journeys, all the people he has ever met. It is unlikely that this totality of available information will meet the Wikipedia notability criteria yet it is cool if you want to compare personal networks or if you are working on the person's written correspondence. You might date an undated letter with information about stations of a journey. All this has the advantages of a structured CV over an arbitrary article. One would want expandable chronological/alphabetical list-outputs so that one can have a short view over the headlines and all the available information for anyone interested on a second click. We should have someone who knows how to construct these pages in our joint-project at https://blog.factgrid.de/ --Olaf Simons (talk) 15:35, 20 September 2017 (UTC)[reply]

Other relevant stuff edit

  • Maybe related: http://meta.wikimedia.org/wiki/A_proposal_towards_a_multilingual_Wikipedia - TobKuhn (talk) 20:00, 29 December 2014 (UTC)[reply]
  • recently I was thinking about a way to "reserve" a red link in one language to a WikiData item that has links to other languages already. A lot of geographical articles exist as red links, and this red link can be pre-attached to other languages over WikiData... we only miss a mechanism to do this currently. This might need a new article status, where a red link will change color once it is connected to WikiData. Edoderoo (talk) 20:33, 29 December 2014 (UTC)[reply]
    • I like the idea of "reservation". It could be implemented in Wikidata as simple Wikipedia links. Currently any sister or localized project knows nothing about other. However if we do an exception for Wikidata, that is the Wikidata knows if the link is red, blue or green, then the solution would be transparent for any other Wikipedia. Providing specific template on each Wiki to get such functionality is too complicated for editors. Paweł Ziemian (talk) 08:33, 2 September 2015 (UTC)[reply]
  • It's important not to forget that Wikidata's main tactic goal right now is being used more by clients on existing articles. It's crucial for the community to push more here, and perhaps for Wikimedia organisations to offer some technical help for the templates used on tens/hundreds of thousands articles (e.g. offer the w:it:template:bio maintainers to help implement data fetching from Wikidata person data). Initiatives to work more on Wikidata items are held back by the limited usage of the data: as long as I have to add information to Wikidata in addition to filling a local template, the Wikidata adventure hasn't even started. --Nemo 21:48, 29 December 2014 (UTC)[reply]
  • The second most important tactic goal is being used for search (like wdsearch). Filling the gap in "failed searches" means gaining visibility by providing a clearly useful service, as well as encouraging users to use their own language first. This builds trust on the intention to encourage local editing, rather than to centralise. --Nemo 21:48, 29 December 2014 (UTC)[reply]
  • Even before we get to summaries, there are things that could be implemented sooner in the page name/search pages, and would lay the groundwork for automatic summaries later:
    • If the page name doesn't exist on a project, perhaps show any exact/very close Wikidata label or alias matches on the "Wikipedia does not have an article with this exact name" page. (Which "other" label/alias languages also counted as matches would probably be different for each project. For example, on en.wp, it would probably be confusing to match anything other than en and en-* variations.) --Closeapple (talk) 23:02, 29 December 2014 (UTC)[reply]
    • Projects could also choose to use something like {{Redirect with Wikidata}} or {{R Wikidata}} on redirects, to tell users that there is already both a Wikidata item and a parent topic redirect available. Since wiki projects already have guidelines for how links to redirects look, this wouldn't be much more unusual than a usual redirect: That is, it wouldn't be creating "artificial" blue links on projects, since the link style is already known on every project. When placeholder summarization is available, redirects with this tag would already be good candidates for summaries. Also, once we start allowing redirects as page links in Wikidata, we'd already have the Wikidata item numbers for lots of items. --Closeapple (talk) 23:02, 29 December 2014 (UTC)[reply]
    • When doing searches on other projects, in the advanced options underneath the namespaces, have an option for "also show Wikidata matches", in which case Wikidata labels and aliases for that language would count as alternate titles (as in intitle:"search term"), and the description would match the text. When "also show Wikidata" is checked, show the Q number next to any match, including matches to local pages, so the user knows which local page matches have Wikidata and which don't. Even though I mention this as an advanced option checkmark, maybe "also show Wikidata" should be the default in some projects that don't have many articles. --Closeapple (talk) 23:02, 29 December 2014 (UTC)[reply]
    • Since I mentioned that last one: On Wikidata itself, I'd like to see something (like intitle:) match labels and aliases. Wikidata's Special:ItemDisambiguation works only on exact complete string matches to labels — and only in one language, for that matter: If you don't specify a language, it will force it. Maybe I should mention that back on Wikidata:Project chat instead. --Closeapple (talk) 23:02, 29 December 2014 (UTC)[reply]
  • We need to figure out what to do when multiple items match the label that was searched for. --Lydia Pintscher (WMDE) (talk) 09:22, 30 December 2014 (UTC)[reply]
We can steal a page from Reasonator and disambiguate using automated descriptions. Thanks, GerardM (talk) 05:58, 3 September 2015 (UTC)[reply]
  • your input and signature

We already have most of what it takes in ReasonatorReasonator DOES provide information in any language about ANY subject that has a Wikidata item. edit

  • When labels are added, it will use those labels where applicable.
  • It will show a red underlined label when there is no label in that language
  • It will always show a label so that people have at least a chance to understand what it is about
  • Through WIDAR it is possible to add labels (for the primary language shown)
  • It does link to both Wikidata and any other project
  • It includes search, in any language for any label including aliases
  • It makes use of the almost half a million more labels than en.wp has articles
  • It is used in many Wikipedias through Wikidata search
  • It is used in en.wp for redlinks
  • It does provide a platform for autogenerated text. This is to be preferred over bot generated text
  • It could be cached
  • IT WORKS NOW
unsigned by GerardM 08:42, 30 December 2014 (--Atlasowa (talk) 20:30, 1 January 2015 (UTC))[reply]
Sure. I understood Lydia's question as "how do we transclude reasonator in our wikis?". :) --Nemo 08:38, 31 December 2014 (UTC)[reply]
If we're in a hurry, we could just run Reasonator on node.js to generate pages server-side... --Magnus Manske (talk) 15:15, 16 January 2015 (UTC)[reply]
I agree with GerardM. We should be getting rid of substubs and replacing them with reasonator pages not creating more substubs. The easiest way for speakers of minority languages to improve the information available in those languages is to translate labels on wikidata (not descriptions, they can be generated from statements). Translating the label for one property helps localise every statement using that property. The tool they need is a list of the most used properties and items which don't have labels in their language. Joe Filceolaire (talk) 22:07, 1 September 2015 (UTC)[reply]

Next step: pilot edit

Just an update: There is currently discussion about doing a pilot project for this on German Wikipedia in the biology area. The discussion is happening at User:Achim Raschka/Pilot article placeholder input. --Lydia Pintscher (WMDE) (talk) 18:58, 31 March 2015 (UTC)[reply]

Bachelor project Article Placeholder edit

As part of my bachelor thesis I will concern myself with the Article Placeholders and started writing an extension that will have some of the functionalities discussed here. The project page can be found here mw:Extension:ArticlePlaceholder and will be regularly updated as the development progresses. I'll be happy to get any input even if I can't implement all of it as part of the bachelor thesis! --Frimelle (talk) 15:08, 24 August 2015 (UTC)[reply]

Candidate wikis edit

(I can't tell where the ArticlePlaceholder project is discussed, so I'm reusing this page.) I noticed there are quite a few wikis which create empty placeholders for articles, like w:yo:Martin Luther or w:new:मार्टिन लुथर. Such wikis would be great candidates for an expansion of the pilot. --Nemo 20:03, 13 November 2017 (UTC)[reply]

Ruthenian language (Ruthenian (Q13211)) edit

In the Grand Duchy of Lithuania, in the Ruthenian Voivodeship of the Kingdom of Poland and in the Principality of Moldavia, the language of the population (in whole or in part) and the official language of the office was Ruthenian. How to make it possible to indicate it as the native language of a person, the official language of the state, the language of chronicles. Example Vasile Lupu (Q220653): Ruthenian is listed as the native language for spelling a name. In Russian Wikipedia (Vasily Lupu) it looks awful. How can this be fixed? --Лобачев Владимир (talk) 11:52, 22 May 2021 (UTC)[reply]

Copy: Wikidata:Contact the development team. --Лобачев Владимир (talk) 12:48, 22 May 2021 (UTC)[reply]

See also edit

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Article_placeholder&oldid=1426372781"