Wikidata:Property proposal/Wikipedia infobox field

From Wikidata
Jump to navigation Jump to search

Wikipedia infobox field[edit]

Return to Wikidata:Property proposal/Sister projects

   Under discussion
Descriptionname of a field in the infobox of the Wikipedia in the same language, e.g. use English for a field on English Wikipedia.
Data typeMonolingual text
Domaingenerally Wikimedia infobox template (Q19887878), maybe some other Wikimedia template (Q11266439)
Example 1Template:Infobox film (Q6171351) → "film name"@en
Example 2Template:Infobox film (Q6171351) → "director"@en
Example 3Template:Infobox film (Q6171351) → "producer"@en
Planned useadd from Wikidata:WikiProject_Movies/Tools#Wikipedia_infobox_mapping

Motivation[edit]

Following a similar suggestion by @ElanHR: on project chat and describing_templates_and_their_fields. Allows to query infobox fields and map to properties. If there is interest, a similar property could be created for other projects (Add your motivation for this property here.) --- Jura 10:57, 29 January 2020 (UTC)

Discussion[edit]

  • GA candidate.svg Weak support I think the datatype should be "string" instead of "monolingual text". The parameter identifier actually doesn't have to match any language, and could be any alphabetical sequence. --Tinker Bell 02:35, 2 February 2020 (UTC)
    • The idea is that the language matches the Wikipedia's. Otherwise, there is no way of knowing which WP this relates to. --- Jura 07:57, 3 February 2020 (UTC)
      • Then oppose as we have no language code for 'simple', for the various Wikisources, nor Wiktionaries, for Wikispecies, for Commons, nor, indeed, for Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 8 February 2020 (UTC)
        • @Pigsonthewing: My understanding is that this property's scope is limited to Wikipedia (Wiktionaries, Wikispecies, etc. would use an equivalent property) and therefore the only ambiguity is between English Wikipedia and Simple Wikipedia. Fortunately (in my experience) templates from SimpleWiki tend to mirror those from EnWiki (e.g. Infobox:Person(en) and Infobox:Person(en)). Additionally I would not be too worried about this ambiguity as a problem only arise if one site used the same infobox key as another site but used it to represent different semantics. I have yet to see this case and I would imagine it occurs extremely infrequently. ElanHR (talk) 03:42, 21 February 2020 (UTC)
          • "Wiktionaries, Wikispecies, etc. would use an equivalent property" That I also oppose. And it does not address the case of simple.Wikipedia. Your supposition about the mirroring of parameter names between that project and en.Wikipedia is overly optimistic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 21 February 2020 (UTC)
  • Pictogram voting comment.svg Comment I've been thinking about something similar, but I'm not sure this will work. Users will probably try to translate the entries, and not check what they actually are, users will not keep the entries updated, and the entries will diverge from actual entries in the templates. To keep the entries synchronized there must be some technical measure to do so, for example through TemplateData. A property should not be for an infobox, but for a template. That would also make it simpler to implement as part of the TD extension. Jeblad (talk) 15:58, 8 February 2020 (UTC)
    • When doing Wikidata:WikiProject Movies/Tools#Wikipedia infobox mapping, I was worried about that too, but finally they proved quite stable. I think they are still used to do imports from Wikipedia. Obviously, depending on the use, some additional checks and re-sync needs to be done. I think the maintainers of TemplateData had declined to host a field for corresponding properties. --- Jura 16:13, 8 February 2020 (UTC)
      • It is the same problem as maintaining sitelinks, they slowly disintegrate unless there are some way to automate the maintenance. (I wrote the original code for creating sitelinks, and the problem you try to solve is virtually the same.) Jeblad (talk) 16:54, 8 February 2020 (UTC)
        • I think the granularity of the information, impact of changes, purpose and update pattern(s) are very different when compared to sitelinks. --- Jura 17:02, 8 February 2020 (UTC)
        • @Jeblad: with TemplateData#API, we could check if the field list is current. Shall we move ahead with this proposal? --- Jura 10:59, 11 February 2020 (UTC)
          • I believe this belongs in the server, not in the browser, and if you would put it in the browser, then you must enforce it in all clients. You would probably not be able to enforce use of it in the clients anyhow. Thatis in all language editions of Wikipedia. Jeblad (talk) 13:26, 12 February 2020 (UTC)
            • @Jeblad: I think it depends on the purpose. To replace pages like the one of WikiProject Movies, it can easily live here. If a client wiki actually links an infobox to Wikidata, definitions could be moved there or more easily synced. As it hasn't happened in the last (decade), it might not happen soon though. --- Jura 17:07, 12 February 2020 (UTC)
              • Sorry, but I'm pretty sure this will not work. Jeblad (talk) 21:23, 12 February 2020 (UTC)
            • @Jeblad: Np. I know it works for the movies project. --- Jura 21:26, 12 February 2020 (UTC)
              • We can't even get the communities to maintain TemplateData, which has a clear local effect, how should we enforce maintenance of an off-site value that has nearly no local effect? I don't see how that will happen. Jeblad (talk) 21:34, 12 February 2020 (UTC)
                • Users regularly import data based on fields also listed on WikiProject Movies. Contrary to sitelinks, there is no point in adding all fields/all infoboxes if nothing is done with it here. --- Jura 21:41, 12 February 2020 (UTC)
  • GA candidate.svg Weak support. Not only infoboxes need mapping between parameter names. Many other templates (and modules) need it, too. I have a vague recollection that Pigsonthewing tried to propose something similar once, although I might be wrong. The proper solution for this problem is Global templates. In the proposal I've written, I intentionally didn't specify how exactly will this be stored: maybe some kind of global TemplateData, maybe a different JSON structure, maybe something in Wikibase, and maybe something entirely different. However, this proposal here can be a step towards proper global templates. --Amir E. Aharoni {{🌎🌍🌏}} talk 18:20, 8 February 2020 (UTC)