User:RoyZuo

Babel user information

yue-N	呢位用戶嘅母語係粵語。

en-3	This user has advanced knowledge of English.

/1

tools

thoughts

Get rid of page title

Inflexible mw:Manual:Page title causes endless unnecessary troubles.

Files should be identified and reused with a unique number like [[File:M56856129|thumb|example]]. This would eliminate 1 of 3 things doing roughly the same thing: filename, caption, description; and all the rules and maintenance tasks about filename like Category:Media requiring renaming.
Categories should become something like tags or wikidata properties. Each category should deal with 1 specific concept. When categories behave like wikidata items, then they can take on multilingual labels and aliases. Users can therefore no longer be troubled with which name to use, which name needs to be disambiguated, etc. Intersection categories also become useless. Instead of searching for Category:Yellow houses users can search "depicts=houses; colour=yellow"; "location=london; type=photograph; date=2010-03-01" instead of Category:London photographs taken on 2010-03-01...
Previously written: Commons:Requests_for_comment/Categories_of_photographs_by_country_by_date#c-RoyZuo-20240510175700-Limitation_of_mediawiki_search_engine.
Further, even "(article)" (main) namespace pages on wikipedia etc. should also become something like wikidata items. Then its title can take on lowercase initial, or any illegal characters, just like how file caption has no such limitation.

It has been quite some time (writing as of 20:39, 7 December 2024 (UTC)) since I started avoiding nominating categories for discussion or moving categories, even if they have obviously unsuitable titles, as long as they dont interfere with the categories I use, because it's a waste of all users' effort and time. As I now recognise, all these problems about mw:Manual:Page_title (be it filename, or category title) can be solved by a different technical design.--RoyZuo (talk) 12:23, 5 January 2025 (UTC)

Commons needs its own software

Commons needs its own software, instead of a variant of mediawiki. Patchworks on an unsuitable software cannot make it work.
Users and editors have rather different needs, so there could be two modes: an editing mode specifically for editors.
Photos, artwork scans, books, videos, audios... all have rather different kinds of metadata and need different viewing tools, so there can be different webpage design depending on the kind of content.
Mediawiki cant do the above. It tries to create a one-fits-all page design, but ends up falling short of everything.--RoyZuo (talk) 08:59, 11 May 2025 (UTC)

Reimagined file management and storage

currently,

deletion is not really deletion, but just hiding from any user who is not sysop+.
all files, all revisions, are stored forever on the servers, regardless of their nature.

all the reasons for which files are deleted can be summarised as:

useless.
copyright has not expired.
non-copyright legal reasons.

spam, test edits, vandalism are all "useless" so they are deleted, but still remain on the servers. but for example, sometimes users crop and overwrite a file several times to achieve their final desired result. these intermediate file revisions are also useless and remain on the servers.

sometimes uploads contain personal info. those files are deleted or "oversighted", but still remain on the servers. these fall under "non-copyright legal reasons".

reimagined 3-tier file management
type	visibility and editability	stay on server
trashed files	super users (and maybe advanced users) and the files' uploaders	for limited time
hidden files	advanced users and the files' uploaders	forever
public files	all users	forever

if files have the prospect of being unhidden in the future (basically all the "quality files but copyright or personality rights have not expired"), they are just hidden and set with a future date, when they will be reviewed for unhiding or automatically unhidden.
all the useless files can just go to the trash (visible to advanced users). (default) expiration can be set so they will be deleted from the servers. it could be 1 month, 10 years, or whatever.
all the legally problematic files also go to the trash (visible only to super users).
hiding/unhiding is not done like the current "deletion/undeletion", but rather like changing "who can see" on other content hosting sites e.g. https://www.flickr.com/photos/organize https://studio.youtube.com .
"advanced users" can see and edit the hidden files.
normal users can also see and edit their own "hidden" uploads. so for example photos of copyright protected buildings can still be worked on by editing descriptions or uploading new versions.
normal users can also set their own uploads to hidden with the future review date. this encourages self curation and reduces work load for "advanced users".
normal users can send their own uploads to trash within a certain period of time.
trashing can be done to file revisions rather than the whole file, so useless intermediate versions can be cleaned from the servers.

benefits:

this "advanced user" group specialising in file management can be greatly expanded. basically all com:licence reviewers or even com:autopatrol can work on this.
normal users being able to edit their own hidden files' descriptions com:sdc etc. improves curation of all these files that are supposed to be unhidden in the future.
discussion of whether a file should be unhidden can happen with the file remaining visible to their uploaders and many more users than the current sysops. it can exist in the form of notes/remarks related to a file page so all previous opinions are kept tracked of. much better than Commons:Undeletion requests/Current requests.
free servers from garbage that everyone agrees on.
with hidden files being visible and editable to many more users and their own uploaders, for example com:GLAM can still work on those files. they dont need to avoid uploading still-copyright-protected items. users dont need to wait until they are undeleted to improve their curation.
there is no more "urgency to delete" files. right now com:deletion requests are often full of animosity. in this reimagined system, basically all files that have copyright concerns can be hidden immediately, and discussion on their copyright can continue with the files being visible and editable to their uploaders and many more "advanced users". i believe users will have much less resistance and resentment when files hidden from the public view remain visible to them, so they dont feel that their work is discarded or not respected.
file management roles are dissociated from other sysop functions (deleting pages in general, blocking users, protecting pages).

--RoyZuo (talk) 19:27, 17 May 2026 (UTC)

Doctrine: website maintenance borne by website operator

Website maintenance should be solely borne by the website operator.

To elaborate, it means volunteers' contributions to improve website maintenance are appreciated, but should never become volunteers' responsibility.

Example. Commons users actively patrol uploads to detect copyright violations. As User:AFBorchert pointed out, an essential tool for this task is MediaWiki:Gadget-GoogleImagesTineye.js. However, recently this tool was broken due to actions by the operator of Commons. See MediaWiki_talk:Gadget-GoogleImagesTineye.js#c-Masur-20251229182900-Reverse_Image_Search_-_Google_and_TinEye_failing_to_retrieve_source_images_from.

Volunteers have generously put their time and skills into developing essential tools to maintain the website, but when the operator's actions break those essential tools, very often it's left to the volunteers to fix them.

Those tools essential for the maintenance of the website should have been the operator's responsibility to develop in the first place, not to mention, to fix.

As other users have said in the past, don't contribute to the technical aspect of Commons; don't take over those responsibilities from WMF and make them your own.--RoyZuo (talk) 11:34, 19 May 2026 (UTC)

Extended content

Templates

Dont design templates, modules or gadgets that are so complicated that only the author can easily understand.

Keep code simple and readable.

Because you should think, one day when you cannot continue maintenance, how to let other users easily take over your codes? We are all volunteers here, so dont expect users to invest a lot of time just to understand your codes. My personal style of designing templates:

avoid recursive transclusion of other templates. (hard to follow through layers of templates called in other templates.)
keep neat indentation.
write explicit documentation.
avoid setting unnecessary style (font colour, background colour, etc.), so that the look can change according to users' preferences instead of designers' choices.

Cfd

Cfd has been dysfunctional for a long time (as of 18:32, 9 February 2025 (UTC)).

Commons:Categories for discussion/2010/11/Category:Videos by display resolution was raised 1 month after these cats first emerged. Yet nothing could be done, despite another Commons:Categories for discussion/2017/06/Category:Videos by display resolution. Now they've grown to 10k junk cat pages.

Maintenance category

Leave sufficient documentation and instructions so that other users can easily understand the original purpose for which you create new maintenance categories.

Ways to offer additional tools to users

Ways to offer additional tools to users
method	turning on/off	availability (logged-out)	availability (logged-in)	editing	self configuration
Commons:Gadgets	Special:Preferences#mw-prefsection-gadgets min. 5 clicks	❌ (generally) unless turned on by default (i.e. community consensus required)	if they turn it on, or if on by default (i.e. community consensus required)	❌ (generally) only Commons:Interface administrators can edit	❌ (generally) unless it includes settings
user scripts loaded in user's own common.js	always on editing common.js to turn on/off	❌	if they load it in their common.js	❌ (generally) only the script creator and interface administrators can edit	❌ (generally) unless it includes settings
user scripts loaded in browser extensions browser extensions	browser settings	if they install it in their browsers	if they install it in their browsers	users (because they control the source code)	high (because they control the source code)
templates transcluded on pages	always on (only if transcluded)	always	always	all commons editors (except protected templates)	❌
external websites (including toolforge)	depends on the website	depends on the website	depends on the website	website creator	depends on the website

Quick guide on each kind of providers.

Over the years I've developed the same utility in different forms, e.g. Template:Category helper Template:DeepcatSearch to be transcluded on the page for anyone (no account needed) to use, and MediaWiki:Gadget-DeepcatSearch.js as a gadget, which can only be used by logged-in users who know it and turn it on.--RoyZuo (talk) 06:45, 26 April 2026 (UTC)

Tool design for dummies or pros

I'd say there are two kinds of tool making: for dummies and for pros.

TIL from Commons_talk:Structured_data#c-Lucas_Werkmeister-20260320205800-Herzi_Pinki-20260320191900 that there's this thing called mw:Wikidata Query Service/User Manual/MWAPI. That is an example of a tool for pros.

Commons:Wise is a tool for dummies.

People should recognise that most users will only remain dummies. They just dont have the knowledge or patience or motivation to learn something terribly complicated, when all they want is just find a nice looking picture of a flower, or a building, or a person...

Key points for dummy tools:

must be intuitive.
GUI as much as possible.
simplify rules/techniques needed to use the tool.
minimise clicks users have to do.
approximation is often good enough for most cases. no need to be perfect. prioritise user experience over getting perfect results.

--RoyZuo (talk) 00:19, 16 May 2026 (UTC)

Legends

to-do list

to-do list: commons maintenance that I cant do due to lack of time.
universal archive calendar template in new to old order
Commons:File requests map https://de.wikipedia.org/wiki/Benutzer_Diskussion:DB111#Geogroup_fuer_Seite_auf_Commons ; header
v or a up guide
- v graphic guide
  - "using v2c, you cant overwrite; you cant even upload to a used filename"
-deepcategory:"pagename" neartitle:"300m,fullpagename"
2 js, for logged in and out users, cat search aid links
- deepcat, any assessment. as alternative to Help:FastCCI.
Template:Category helper modularise and make fully customisable
photo challenge vertical table
1 click to https://xtools.wmcloud.org/topedits/commons.wikimedia.org/username/4/Sandbox
link from coord to nearcoord search
- Commons:Village pump#c-Alfrejg-20260217071800-Is there a kind of geographic search?
1 click to ocr
language skill where to help template
- Category:Needing transcription

coding exercises

MediaWiki:Gadget-Cat-a-lot.js make a fork with input container at bottom not top
cat move bot capable of suppressing redirect (User:SteinsplitterBot moves cats without option to suppress, i think?)
target doesnt exist? easy
redirect yes: SteinsplitterBot

redirect no: new bot

target exists? compare create dates -> new bot/script
target older? easy. redirect (then optionally delete)

target newer? delete target for a super short period, then bot moves cat.
tool to show what changed in the move, in the style of Template:Move or Template:rename. e.g. https://commons.wikimedia.org/w/index.php?title=File:Archives_de_l%27Op%C3%A9ra-Comique)_-_(journal_de_r%C3%A9gie_(manuscrit_autographe)_-_Victor_Avocat_r%C3%A9gisseur_-_btv1b53196111k_(323_of_514).jpg&action=history
fork https://github.com/Flickr-Foundation/flickypedia to enable upload of any image? useful for pd.
script reinvent wheel
latin cjk mix. bot to monitor new cat pages that contain both a-z and cjk chars.