Change Details

**Feature summary** (what you would like to be able to do and where): Allow users to store JSON-based page lists in (both //local// and Commons) data namespace (see: T252711, T305571). A page list is a JSON list, which each entries having the following information: (either Title or QID is required) * Title - The displayed name of the entry (without disambiguation); by default the label of the Wikidata item * QID - The Wikidata QID of the topic * page name - Name of local pages of the entry; by default the sitelink of the Wikidata item (may be non-existent, see T123021), or if QID is not defined, the title * Any other fields users may define, including free-form Wikitext ({T134658}) ** This may include some fields that are populated by Wikidata, but can be overrided locally **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): To populate lists like https://en.wikipedia.org/wiki/List_of_2016_United_States_presidential_electors. A more complex case is https://zh.wikipedia.org/wiki/%E7%AC%AC%E5%8D%81%E5%9B%9B%E5%B1%8A%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E4%BB%A3%E8%A1%A8%E5%90%8D%E5%8D%95, which is a table-based list, and https://zh.wikipedia.org/wiki/%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E5%B1%B1%E4%B8%9C%E7%9C%81%E4%BB%A3%E8%A1%A8%E5%9B%A2 contains an extract of one of its section in plain list form. This will allow user to create lists like https://en.wikipedia.org/wiki/Comparison_of_text_editors. Currently they can only be edited as raw Wikitext (and there are cases that some careless edits will mess up the wikitable syntax). Wikitable is not machine-readable either. With a JSON-based page list, spreadsheet-like cell editing can be used ({T134618}) **Benefits** (why should this be implemented?): * Allow the same list be included in different pages * Allow building navboxes from a given list, or a part thereof (e.g. most of navboxes in https://en.wikipedia.org/wiki/Chuck_Schumer can be extracted from Wikipedia articles) * A more user-friendly editing interface * Wikidata-based error checking (both ways - a report of inconsistency may indicate errornous or outdated data in local wiki or Wikidata) * List will be machine-readable, and importable/exportable ({T134617}) * Reduce the workload of disambiguation (e.g. if a name exists in 10 lists, moving the page will require changes to 10 pages; also see the list of navboxes of Chuck Schumer above, if the page is moved all navboxes must be updated manually) * Some lists may potentially use a large numbers of Wikidata items, which may touch the entityAccessLimit or expensive function call limit. Introduce an intermediate page will make such Wikidata usage indirect (if it is stable, data may be duplicated in the JSON page; otherwise, a cache layer may be introduced) so that performance may be improved. Note this is different from Wikidata-based automatic list ({T67626}) in the following ways: * Wikidata does not allow user to store free form Wikitext but many lists such as https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols contains free form Wikitext. * Wikidata-based automatic list require users to match all entries to Wikidata items (and create one if not exists), which is difficult for existing lists (e.g. list of members of organizations, such as List of 2016 United States presidential electors above) with hundreds of entries. (In Chinese Wikipedia, there are hundreds of such navboxes.) * Some lists are either stable (such as List of 2016 United States presidential electors above; the actual entries never changes, though the page names may be moved due to disambiguation), or updated very infrequently (such as list of US presidents). Use a stable list will reduce the potential of vandalism.

**Feature summary** (what you would like to be able to do and where): Allow users to store JSON-based page lists in (both //local// and Commons) data namespace (see: T252711, T305571). A page list is a JSON list, which each entries having the following information: (either Title or QID is required) * Title - The displayed name of the entry (without disambiguation); by default the label of the Wikidata item * QID - The Wikidata QID of the topic * page name - Name of local pages of the entry; by default the sitelink of the Wikidata item (may be non-existent, see T123021), or if QID is not defined, the title * Any other fields users may define, including free-form Wikitext ({T134658}) ** This may include some fields that are populated by Wikidata, but can be overrided locally **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): To populate lists like https://en.wikipedia.org/wiki/List_of_2016_United_States_presidential_electors. A more complex case is https://zh.wikipedia.org/wiki/%E7%AC%AC%E5%8D%81%E5%9B%9B%E5%B1%8A%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E4%BB%A3%E8%A1%A8%E5%90%8D%E5%8D%95, which is a table-based list, and https://zh.wikipedia.org/wiki/%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E5%B1%B1%E4%B8%9C%E7%9C%81%E4%BB%A3%E8%A1%A8%E5%9B%A2 contains an extract of one of its section in plain list form. This will allow user to create lists like https://en.wikipedia.org/wiki/Comparison_of_text_editors. Currently they can only be edited as raw Wikitext (and there are cases that some careless edits will mess up the wikitable syntax). Wikitable is not machine-readable either. With a JSON-based page list, spreadsheet-like cell editing can be used ({T134618}) **Benefits** (why should this be implemented?): * Allow the same list be included in different pages * Allow building navboxes from a given list, or a part thereof (e.g. most of navboxes in https://en.wikipedia.org/wiki/Chuck_Schumer can be extracted from Wikipedia articles) * A more user-friendly editing interface * Wikidata-based error checking (both ways - a report of inconsistency may indicate errornous or outdated data in local wiki or Wikidata) * List will be machine-readable, and importable/exportable ({T134617}) * Reduce the workload of disambiguation (e.g. if a name exists in 10 lists, moving the page will require changes to 10 pages; also see the list of navboxes of Chuck Schumer above, if the page is moved all navboxes must be updated manually) * Some lists may potentially use a large numbers of Wikidata items, which may touch the entityAccessLimit or expensive function call limit. Introduce an intermediate page will make such Wikidata usage indirect (if it is stable, data may be duplicated in the JSON page; otherwise, a cache layer may be introduced) so that performance may be improved. Note this is different from Wikidata-based automatic list ({T67626}) in the following ways: * Wikidata does not allow user to store free form Wikitext but many lists such as https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols contains free form Wikitext. * Wikidata-based automatic list require users to match all entries to Wikidata items (and create one if not exists), which is difficult for existing lists (e.g. list of members of organizations, such as List of 2016 United States presidential electors above) with hundreds of entries. (In Chinese Wikipedia, there are hundreds of such navboxes.) * Some lists are either stable (such as List of 2016 United States presidential electors above; the actual entries never changes, though the page names may be moved due to disambiguation), or updated very infrequently (such as list of US presidents). Use a stable list will reduce the potential of vandalism. * A list with defined fixed membership can reduce calls to potentially expensive WDQS queries (cf T67626#9553372). Note WDQS queries are still useful in consistency checks, but calling WDQS on visit with result displayed on-the-fly and calling it only for consistency check are totally different things.

**Feature summary** (what you would like to be able to do and where): Allow users to store JSON-based page lists in (both //local// and Commons) data namespace (see: T252711, T305571). A page list is a JSON list, which each entries having the following information: (either Title or QID is required) * Title - The displayed name of the entry (without disambiguation); by default the label of the Wikidata item * QID - The Wikidata QID of the topic * page name - Name of local pages of the entry; by default the sitelink of the Wikidata item (may be non-existent, see T123021), or if QID is not defined, the title * Any other fields users may define, including free-form Wikitext ({T134658}) ** This may include some fields that are populated by Wikidata, but can be overrided locally **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): To populate lists like https://en.wikipedia.org/wiki/List_of_2016_United_States_presidential_electors. A more complex case is https://zh.wikipedia.org/wiki/%E7%AC%AC%E5%8D%81%E5%9B%9B%E5%B1%8A%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E4%BB%A3%E8%A1%A8%E5%90%8D%E5%8D%95, which is a table-based list, and https://zh.wikipedia.org/wiki/%E5%85%A8%E5%9B%BD%E4%BA%BA%E6%B0%91%E4%BB%A3%E8%A1%A8%E5%A4%A7%E4%BC%9A%E5%B1%B1%E4%B8%9C%E7%9C%81%E4%BB%A3%E8%A1%A8%E5%9B%A2 contains an extract of one of its section in plain list form. This will allow user to create lists like https://en.wikipedia.org/wiki/Comparison_of_text_editors. Currently they can only be edited as raw Wikitext (and there are cases that some careless edits will mess up the wikitable syntax). Wikitable is not machine-readable either. With a JSON-based page list, spreadsheet-like cell editing can be used ({T134618}) **Benefits** (why should this be implemented?): * Allow the same list be included in different pages * Allow building navboxes from a given list, or a part thereof (e.g. most of navboxes in https://en.wikipedia.org/wiki/Chuck_Schumer can be extracted from Wikipedia articles) * A more user-friendly editing interface * Wikidata-based error checking (both ways - a report of inconsistency may indicate errornous or outdated data in local wiki or Wikidata) * List will be machine-readable, and importable/exportable ({T134617}) * Reduce the workload of disambiguation (e.g. if a name exists in 10 lists, moving the page will require changes to 10 pages; also see the list of navboxes of Chuck Schumer above, if the page is moved all navboxes must be updated manually) * Some lists may potentially use a large numbers of Wikidata items, which may touch the entityAccessLimit or expensive function call limit. Introduce an intermediate page will make such Wikidata usage indirect (if it is stable, data may be duplicated in the JSON page; otherwise, a cache layer may be introduced) so that performance may be improved. Note this is different from Wikidata-based automatic list ({T67626}) in the following ways: * Wikidata does not allow user to store free form Wikitext but many lists such as https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols contains free form Wikitext. * Wikidata-based automatic list require users to match all entries to Wikidata items (and create one if not exists), which is difficult for existing lists (e.g. list of members of organizations, such as List of 2016 United States presidential electors above) with hundreds of entries. (In Chinese Wikipedia, there are hundreds of such navboxes.) * Some lists are either stable (such as List of 2016 United States presidential electors above; the actual entries never changes, though the page names may be moved due to disambiguation), or updated very infrequently (such as list of US presidents). Use a stable list will reduce the potential of vandalism. * A list with defined fixed membership can reduce calls to potentially expensive WDQS queries (cf T67626#9553372). Note WDQS queries are still useful in consistency checks, but calling WDQS on visit with result displayed on-the-fly and calling it only for consistency check are totally different things.