Change Details

* Affected components: Classic MW API generators * Engineer(s) or team for initial implementation: Policy change, no implementation. If needed, Search Platform and Structured Data. * Code steward: Policy change, no code steward needed. ### Motivation https://www.mediawiki.org/wiki/API:Query#Additional_notes states that "Generators only pass page titles to the query module and do not output any information themselves. Setting parameters like gcmprop will therefore have no effect." While I understand this POV to some extent, it also undermines the use of generators. The search API, for example, can be used both as list and generator. As list, it includes additional search information that it does not when used as generator: via `srinfo`: rewrittenquery, suggestion, totalhits via `srprop`: categorysnippet, extensiondata, isfilematch, redirectsnippet, redirecttitle, sectionsnippet, sectiontitle, size, snippet, timestamp, titlesnippet, wordcount, hasrelated, score As generator, the result simply contain mostly the same things as other generators: pageid, ns & title (and index, which indicates the order of the search result) It essentially means that - if you need any of that search-specific data, if basically becomes useless as a generator because you can't access the data that way. You're then forced to fetch the rest of the (non-search, other API) properties you're interested in via a separate request, the old fashioned way. In recent months, while building out an alternative search results UI for Commons, we have had 3 use cases where we could really have used the additional search data: - the matched search snippet (srprop=sectionsnippet|titlesnippet|snippet) - the word count (srprop=wordcount) - the "did you mean" term suggestion (srinfo=suggestion) This would only be a change in policy and would not require significant changes in code (see [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/394120) - already possible with existing infrastructure and would not change or take away existing functionality or data.) //In a way, the search API is already doing this with the addition of the 'index' key to convey the order of search results.// ##### Requirements - https://www.mediawiki.org/wiki/API:Query#Additional_notes is updated to reflect that "generators always pass page titles to the query module, but may also output information themselves" ------- ### Exploration - If generators are allowed to start adding additional data, should they default to no data at all (and require all props to be requested explicitly) or use the same existing set of (non-generator) defaults?

* Affected components: Classic MW API generators * Engineer(s) or team for initial implementation: Policy change, no implementation. If needed, Search Platform and Structured Data. * Code steward: Policy change, no code steward needed. ### Motivation https://www.mediawiki.org/wiki/API:Query#Additional_notes states that "Generators only pass page titles to the query module and do not output any information themselves. Setting parameters like gcmprop will therefore have no effect." While I understand this POV to some extent, it also undermines the use of generators. The search API, for example, can be used both as list and generator. As list, it includes additional search information that it does not when used as generator: via `srinfo`: rewrittenquery, suggestion, totalhits via `srprop`: categorysnippet, extensiondata, isfilematch, redirectsnippet, redirecttitle, sectionsnippet, sectiontitle, size, snippet, timestamp, titlesnippet, wordcount, hasrelated, score As generator, the result simply contain mostly the same things as other generators: pageid, ns & title (and index, which indicates the order of the search result) It essentially means that - if you need any of that search-specific data, if basically becomes useless as a generator because you can't access the data that way. You're then forced to fetch the rest of the (non-search, other API) properties you're interested in via a separate request, the old fashioned way. In recent months, while building out an alternative search results UI for Commons, we have had 3 use cases where we could really have used the additional search data: - the matched search snippet (srprop=sectionsnippet|titlesnippet|snippet) - the word count (srprop=wordcount) - the "did you mean" term suggestion (srinfo=suggestion) This would only be a change in policy and would not require significant changes in code (see [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/394120) - already possible with existing infrastructure and would not change or take away existing functionality or data.) //In a way, the search API is already doing this with the addition of the 'index' key to convey the order of search results.// ##### Requirements - https://www.mediawiki.org/wiki/API:Query#Additional_notes is updated to reflect that "Generators always pass page titles to the query module. Unlike lists (which may include additional data by default), generators should not output any information themselves, unless when explicitly requested via the generator module's query parameters." ------- ### Exploration - If generators are allowed to start adding additional data, should they default to no data at all (and require all props to be requested explicitly) or use the same existing set of (non-generator) defaults?

* Affected components: Classic MW API generators * Engineer(s) or team for initial implementation: Policy change, no implementation. If needed, Search Platform and Structured Data. * Code steward: Policy change, no code steward needed. ### Motivation https://www.mediawiki.org/wiki/API:Query#Additional_notes states that "Generators only pass page titles to the query module and do not output any information themselves. Setting parameters like gcmprop will therefore have no effect." While I understand this POV to some extent, it also undermines the use of generators. The search API, for example, can be used both as list and generator. As list, it includes additional search information that it does not when used as generator: via `srinfo`: rewrittenquery, suggestion, totalhits via `srprop`: categorysnippet, extensiondata, isfilematch, redirectsnippet, redirecttitle, sectionsnippet, sectiontitle, size, snippet, timestamp, titlesnippet, wordcount, hasrelated, score As generator, the result simply contain mostly the same things as other generators: pageid, ns & title (and index, which indicates the order of the search result) It essentially means that - if you need any of that search-specific data, if basically becomes useless as a generator because you can't access the data that way. You're then forced to fetch the rest of the (non-search, other API) properties you're interested in via a separate request, the old fashioned way. In recent months, while building out an alternative search results UI for Commons, we have had 3 use cases where we could really have used the additional search data: - the matched search snippet (srprop=sectionsnippet|titlesnippet|snippet) - the word count (srprop=wordcount) - the "did you mean" term suggestion (srinfo=suggestion) This would only be a change in policy and would not require significant changes in code (see [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/394120) - already possible with existing infrastructure and would not change or take away existing functionality or data.) //In a way, the search API is already doing this with the addition of the 'index' key to convey the order of search results.// ##### Requirements - https://www.mediawiki.org/wiki/API:Query#Additional_notes is updated to reflect that "g"Generators always pass page titles to the query module. Unlike lists (which may include additional data by default), generators should not output any information themselves, but may also output information themselves"unless when explicitly requested via the generator module's query parameters." ------- ### Exploration - If generators are allowed to start adding additional data, should they default to no data at all (and require all props to be requested explicitly) or use the same existing set of (non-generator) defaults?