RE: All The Tropes Wiki Project, Part XXI
08-15-2021, 03:13 AM (This post was last modified: 08-15-2021, 03:31 AM by GethN7.)
08-15-2021, 03:13 AM (This post was last modified: 08-15-2021, 03:31 AM by GethN7.)
Need to discuss something important before I continue doing wiki cleanup, would like comments on the feasibility before I continue further, as this involves major changes to our category organization:
https://allthetropes.org/wiki/Category:Funny
If you see this category, it has no subcategories, and the main page is a dumping ground of unsorted examples I've been parceling off to dedicated subpages to trim down repetition and duplicated effort, so far, so good.
The problem is with categories that have sub categories, like these:
https://allthetropes.org/wiki/Category:Heartwarming
https://allthetropes.org/wiki/Category:Nightmare_Fuel
Now, the subcategories are generally, if you ask me, an artifact of the PmWiki organization we had to partially preserve when we first started due to having a poor idea of how we wanted to structure things, but that no longer makes sense now we have a better idea how to sort things. I'd like to depreciate the subcategories because there are two other ways to make this easier to search through, and we could even use a mix of both if we like:
1. AdvancedSearch would allow a far more discrete "drill down" of certain items once CirrusSearch has been implemented, most of the issues discussed on Phabricator are generally technical issues with loadbalancing it on the servers in order to leverage it's usefulness for wikis that choose to use it (not all will need it and can use the default search engine adequately for most purposes, our content base would benefit the most from this). This would still be useful if we go with option two, but is not currently able to fully used due to the technical issues Miraheze is still hashing out, and it finally working would be a fine compliment to our other solutions:
2. The Cargo extension:
Cargo is a lightweight (and Miraheze friendly) alternative to the Semantic MediaWiki suite, and bundles most of the core functions in a simpler manner. The one we would need is here:
https://www.mediawiki.org/wiki/Extension..._interface
This is a simplified version of Semantic DrillDown, a feature that would autogenerate drill down lists of pages that fit known criteria without requiring manual effort.
For example, if we enter a form to generate a drilldown for all pages that fit having the "Work", "Comics" and "Funny" categories, it would auto generate a full, fine grained list of all pages that match that criteria, and we could make sure this generates on the Category:Funny page to fulfill the same need as manual category tagging, only it requires no human effort (outside of setting up the initial drill-down list query) and is far more efficient in terms of accuracy over hand tagging certain pages with categories manually.
Miraheze does not allow the full version of Semantic MediaWiki for technical complexity concerns and is not needed, as Cargo can do the same work for less effort and get the same results.
I looked into Wikibase, but highly disrecommend considering it because it is immensely technical for our needs.
We could also try DynamicPageList3 in a similar manner as we use on the community portal to generate specific lists of pages belonging to certain categories for the subcategories display we would like to search through. This would require we establish some incredibly precise criteria for what to strip out and likely would be hard to sort unless our DPL calls were incredibly specific.
Alternatively, we can fully depreciate the subcategories like "Film/Funny" and just preserve them only as a dumping ground for unsorted examples that need their own subpages only.
This is something I highly prefer to solicit advice on because we could have a lot of tedious work to do no matter how we resolve this, and I'd prefer we hash out in advance what we will do going forward, given the scale of page content this will affect and our sorting schemas going forward.
P.S.: Page categories are determined either by manual tags (in cases where {{worksubpagefooter}} hasn't been set), or by the Lua scripting of said template where it has on the relevant subpages for works. Some modification of said template to inherit certain category tags from the base page depending on the category of work genre is another solution that could work, but that would require Brent's intervention, as Lua scripting is not my forte.
https://allthetropes.org/wiki/Category:Funny
If you see this category, it has no subcategories, and the main page is a dumping ground of unsorted examples I've been parceling off to dedicated subpages to trim down repetition and duplicated effort, so far, so good.
The problem is with categories that have sub categories, like these:
https://allthetropes.org/wiki/Category:Heartwarming
https://allthetropes.org/wiki/Category:Nightmare_Fuel
Now, the subcategories are generally, if you ask me, an artifact of the PmWiki organization we had to partially preserve when we first started due to having a poor idea of how we wanted to structure things, but that no longer makes sense now we have a better idea how to sort things. I'd like to depreciate the subcategories because there are two other ways to make this easier to search through, and we could even use a mix of both if we like:
1. AdvancedSearch would allow a far more discrete "drill down" of certain items once CirrusSearch has been implemented, most of the issues discussed on Phabricator are generally technical issues with loadbalancing it on the servers in order to leverage it's usefulness for wikis that choose to use it (not all will need it and can use the default search engine adequately for most purposes, our content base would benefit the most from this). This would still be useful if we go with option two, but is not currently able to fully used due to the technical issues Miraheze is still hashing out, and it finally working would be a fine compliment to our other solutions:
2. The Cargo extension:
Cargo is a lightweight (and Miraheze friendly) alternative to the Semantic MediaWiki suite, and bundles most of the core functions in a simpler manner. The one we would need is here:
https://www.mediawiki.org/wiki/Extension..._interface
This is a simplified version of Semantic DrillDown, a feature that would autogenerate drill down lists of pages that fit known criteria without requiring manual effort.
For example, if we enter a form to generate a drilldown for all pages that fit having the "Work", "Comics" and "Funny" categories, it would auto generate a full, fine grained list of all pages that match that criteria, and we could make sure this generates on the Category:Funny page to fulfill the same need as manual category tagging, only it requires no human effort (outside of setting up the initial drill-down list query) and is far more efficient in terms of accuracy over hand tagging certain pages with categories manually.
Miraheze does not allow the full version of Semantic MediaWiki for technical complexity concerns and is not needed, as Cargo can do the same work for less effort and get the same results.
I looked into Wikibase, but highly disrecommend considering it because it is immensely technical for our needs.
We could also try DynamicPageList3 in a similar manner as we use on the community portal to generate specific lists of pages belonging to certain categories for the subcategories display we would like to search through. This would require we establish some incredibly precise criteria for what to strip out and likely would be hard to sort unless our DPL calls were incredibly specific.
Alternatively, we can fully depreciate the subcategories like "Film/Funny" and just preserve them only as a dumping ground for unsorted examples that need their own subpages only.
This is something I highly prefer to solicit advice on because we could have a lot of tedious work to do no matter how we resolve this, and I'd prefer we hash out in advance what we will do going forward, given the scale of page content this will affect and our sorting schemas going forward.
P.S.: Page categories are determined either by manual tags (in cases where {{worksubpagefooter}} hasn't been set), or by the Lua scripting of said template where it has on the relevant subpages for works. Some modification of said template to inherit certain category tags from the base page depending on the category of work genre is another solution that could work, but that would require Brent's intervention, as Lua scripting is not my forte.