Community Wishlist Survey 2022/Larger suggestions/Computer-aided document authoring
| This proposal is a larger suggestion that is out of scope for the Community Tech team. Participants are welcome to vote on it, but please note that regardless of popularity, there is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency to the broader movement. |
Computer-aided document authoring
- Problem: Wiki projects presently depend upon users and their client-side tools for checking language use. An unknown percentage of edits are users correcting one another’s language use.
- Proposed solution: MediaWiki software could support and interoperate with an extensible set of server-side document-processing tools.
- There are two flavors of server-side document-processing tools:
- Firstly, server-side document-processing tools can be of use for computer programming languages. Tools, in these regards, include parsers and compilers which can output annotations such as informational, warning, and error messages about portions of source code.
- Secondly, server-side document-processing tools can be of use for natural languages. Tools, in these regards, include, but are not limited to: spellchecking, grammar checking, readability analysis, sentiment analysis, analysis of subjectivity and objectivity, fact-checking, reasoning checking, and argument verification and validation.
- The outputs of document-processing tools can be represented as annotations. Annotations are data structures which reference selections of, or portions of, documents. Annotations from multiple document-processing tools can be merged, aggregated, and presented to editors and readers as they edit, view, or view more information about wiki documents.
- Were MediaWiki software to support server-side document-processing tools, this might result in a new type of extension.
- Some projects which would be benefited by computer-aided document authoring include:
- Wikifunctions. This project would be benefitted by the first flavor of server-side document-processing tools, wrappers for various server-side parsers and compilers, e.g., Python.
- Wikipedia and Wikinews. These projects would be benefitted by the second flavor of server-side document-processing tools, natural-language document-processing tools.
- Downstream projects. Users of MediaWiki software would be able to create new solutions were MediaWiki to support computer-aided document authoring and server-side document-processing tools.
- More discussion about computer-aided document authoring is available here: Wikianswers/Technical_discussion/Computer-aided_document_authoring.
- Who would benefit: All editors, readers, and downstream users of MediaWiki software.
- More comments:
- Phabricator tickets:
- Proposer: AdamSobieski (talk) 20:52, 10 January 2022 (UTC)
Discussion
- This is similar to something that was sitting in my head for a longer time. I think we need to take "wikitext" or wiki technology to the next level. Regarding annotations, I personally regret that Purple numbers got deleted from English Wikipedia, I think this was a quite early annotation proposal coming from wikipedia:en:Douglas Engelbert. Would like to work on this item, too. « Saper // talk » 14:11, 16 January 2022 (UTC)
- This seems likely to be too large for the team. --Izno (talk) 21:17, 18 January 2022 (UTC)
- Yes, as it's written now it's a bit too broad I think. @AdamSobieski: Would you be able to narrow this down to one particular type of processing (e.g. there's already a grammar editor proposal). Perhaps you could focus it just on readability analysis or another of your ideas? Thanks! SWilson (WMF) (talk) 03:11, 19 January 2022 (UTC)
- While a first server-side document-processing tool to focus on could be either spelling, grammar, or readability analysis, I think that this could be an architectural project which provides opportunity for a new type of third-party extension. That is, ideally, server-side spelling, grammar, readability, and other tools would each involve modular third-party extensions. Yes, I can refine the proposal upcoming to include development of a first server-side document-processing tool. This first server-side document-processing tool could be useful to design while considering architectural topics and could have additional eventual use as a coding example, illustrating to developers how to build the new type of extension. What do you think about modular extensions-based architecture for server-side document-processing tools? Which first tool do you think that the proposal should narrow to focus on? You mentioned readability analysis? AdamSobieski (talk) 09:16, 19 January 2022 (UTC)
- I am updating the technical discussion document per our discussion. There, I mention that implementing a first instance of the proposed new type of extension is a good idea and that it could be either a wikitext linter or an English language spellchecker, grammar checker, or readability analyzer. AdamSobieski (talk) 05:40, 20 January 2022 (UTC)
- @AdamSobieski: Thanks for clarifying. As it sounds like this is a larger architectural proposal, I've moved it to the relevant category (which is where the existing grammar editor proposal is too). SWilson (WMF) (talk) 02:26, 28 January 2022 (UTC)
- I am updating the technical discussion document per our discussion. There, I mention that implementing a first instance of the proposed new type of extension is a good idea and that it could be either a wikitext linter or an English language spellchecker, grammar checker, or readability analyzer. AdamSobieski (talk) 05:40, 20 January 2022 (UTC)
- While a first server-side document-processing tool to focus on could be either spelling, grammar, or readability analysis, I think that this could be an architectural project which provides opportunity for a new type of third-party extension. That is, ideally, server-side spelling, grammar, readability, and other tools would each involve modular third-party extensions. Yes, I can refine the proposal upcoming to include development of a first server-side document-processing tool. This first server-side document-processing tool could be useful to design while considering architectural topics and could have additional eventual use as a coding example, illustrating to developers how to build the new type of extension. What do you think about modular extensions-based architecture for server-side document-processing tools? Which first tool do you think that the proposal should narrow to focus on? You mentioned readability analysis? AdamSobieski (talk) 09:16, 19 January 2022 (UTC)
- Yes, as it's written now it's a bit too broad I think. @AdamSobieski: Would you be able to narrow this down to one particular type of processing (e.g. there's already a grammar editor proposal). Perhaps you could focus it just on readability analysis or another of your ideas? Thanks! SWilson (WMF) (talk) 03:11, 19 January 2022 (UTC)
Voting
Support Stombari8 (talk) 18:59, 29 January 2022 (UTC)- Support This is an inclusive proposal, as many volunteers may have access to a computer, but not the tools required to do more advanced editing. Hires an editor (talk) 00:29, 2 February 2022 (UTC)
- Support Thingofme (talk) 14:53, 5 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 20:21, 6 February 2022 (UTC)
- Support Daniel Case (talk) 03:43, 8 February 2022 (UTC)
- Support – it would be really good to have such tools at our disposal, though this doesn't look like the sort of thing we realistically can expect in the near future. Uanfala (talk) 01:33, 10 February 2022 (UTC)
