Wikisource:Maintenance/Admin to do

Latest comment: 10 years ago by George Orwell III in topic Review of current core settings
Wikisource:Maintenance
Administrators' to do list

A list of things to be done that require admin tools. Anyone can add something to this list. Any admin should be able to implement any item and can claim one by simply adding a comment after the item. Once an item has been done, it can be archived.

Review of current core settings edit

... primarily those found in our MediaWiki:Common.css & MediaWiki:Common.js but generally anything currently found in the MediaWiki namespace.

As most of us are already aware of, the development of the core wmf code has increased dramatically in 2012 compared to the previous years. From what I've gleamed during this period of change is a nice chunk of "stuff" has been folded into the code itself or made part of the defaults in the files the code calls upon - the overall point here being these are all handed down to us from the servers regardless of local inclusions or exclusions. This means it is possible we are carrying "lines" in our local domain's files and/or settings that may no longer be necessary, are redundant or outright conflict with the system generated defaults.

I propose a step by step review of what we currently have locally, compare that to the "new" defaults currently trickling down to us from the source code / upgrades and contrast that to what other principle sister-sites have (and why) to see if we can't streamline our usage flow to be more in-line with current or future developments. Eventually, the review will become a chance to submit proposals to better define our most common & frequently used (and re-used) of settings found in our template applications via CSS definitions instead. (i.e. achieving a better distribution across pre & post processing as well as template include & expand sizes). Thoughts? -- George Orwell III (talk)

Allmessages edit

Progress edit

Initial break-out of common.css into

... subsets done -- George Orwell III (talk) 16:57, 24 April 2013 (UTC)etsReply

Better sorting out gadgets edit

Need to rationally

  • reorganise gadgets to understandable clusters
  • promote gadgets that are usable and remove those that are not User preference statistics
  • review help text so that it makes sense.

billinghurst sDrewth 01:44, 18 November 2012 (UTC)Reply

MediaWiki:Gadget-UTCLiveClock edit

Uses MediaWiki:Gadget-UTCLiveClock.js

I suspect most folks using this gadget do so more for the purge ability than the time zone feature. With all the updates to the wmf code taking place, it comes in handy to be able to purge any given page (though we know the results vary depending upon the situation). Still, I don't see why we can't make the 'Purge' option permanently part of the popdown menu holding 'Move', 'Delete' and 'Protect' under the vector skin or its own tab for those still using monobook rather than keeping this Gadget around. I propose we apply for the purge feature being a permanent part of our menu/tab options across all the namespaces and ween users off the Gadget (unless having UTC time is helpful to them somehow) afterwards. -- George Orwell III (talk) 00:10, 24 November 2012 (UTC)Reply

Keep the clock gadget, some of us see UTC on user pages, so it helps to not have to do mental gymnastics of when the message was left. — billinghurst sDrewth 03:05, 16 December 2012 (UTC)Reply
Maybe I overstated my intentions... I don't really want to delete the gadget - I just want to make it do one thing and one thing only. We can keep the clock but trim the Purge ability. I've since added the stand-alone gadget that creates a action-tab or action-option to Purge a page without the clock. Even better - I'd much rather make the abilty to Purge part of the universal-default, skin-generated coding rather than by applying one of these gadgets. -- George Orwell III (talk) 04:45, 16 December 2012 (UTC)Reply
We call a universal script as the gadget. — billinghurst sDrewth 11:21, 21 February 2013 (UTC)Reply
You are missing the point. Loading from a .php as part of the universal defaults & skin(s) loads "differently" than something called locally. IMO, we do too much of this localized bs (ex. calling the character/symbol menu to an expanded state only to further gadgetize again it to collapsed state). At some point the regular changes to the wmf have caused the manner and order of the local based stuff to become more and more inconsistant (i.e. the same loss of cursor focus to insert one thing or the other into the sub-textbox creations of the noinclude header and/or footer fields in the Page: namespace no longer works, the same is becoming true when trying to hold a specific place in the text-field to insert a symbol or character -- the insertion jumps from where the cursor was to the first position in the textedit area instead). My guess is this is because a local gadget or local setting is superseded in the [local] load order - in effect nullifying or detracting functionality in the process

Either we moderate what we call locally to avoid this "load order" quirk or address the "real" problem -- update Page: Index: & Dynamic Layouts to be (re-)written to co-exist with current coding and practices. -- George Orwell III (talk) 23:15, 21 February 2013 (UTC)Reply

Document management and configuration of Ebooks edit

Some text at User talk:Tpt#Typo in About page of epub export