Wiki Development Checklist

From Audacity Wiki
Jump to: navigation, search


This page is for discussion of ideas for developing both this Wiki and the Manual  wiki, and for monitoring progress of these developments. Relevant topics include security issues, bug fixes and enhanced functionality through installing additional extensions.

The points noted apply to both Wiki and Manual Wiki unless marked (W) for this Wiki only, or (M) for Manual Wiki only. Please move items to the Done section of this page when agreed changes have been implemented.

There is also a companion Forum Development Checklist.


  • A list of the currently installed extensions and functions can be viewed for the Main Wiki and Manual Wiki 


Security

  • (W) GA will write some help text for users who have difficulty with reCAPTCHA and provide some alternative registration method. ReCAPTCHA would seem to offer some difficulties for blind users, even though an audio file can be played to hear a set of digits to enter. For example, you can't tab into the place where you click for the audio file, and the ALT text "Get an audio challenge" over the audio button is hardly clear what it means. Similarly you can't tab to the Help button. GA will also seek further advice from CMU as to the options for navigating without a mouse.
    • CMU's response about accessibility issues is that tabbing into navigational items is disabled because sighted users do so and accidentally press ENTER. Thus they gave such items tabindex=-1 to prevent this. They suggest using the theming API to make the navigational items tab-accessible if preferred, but state that many screen readers have a "navigate to next link" button.
  • Is there any automated way of removing inactive/blocked accounts? There are relatively few active users, but dozens of inactive/blocked ones which make it difficult to find "real" users.
    • Buanzo says: There is a shell-level php script called maintenance/removeUnusedAccounts.php. Not to be called from the web, but from ssh. I can run it. Has no parameters for blocked accounts, nor the word blocked appears on any php script on that directory. Gale: I can see from a search that it removes users with "zero page edits and less than two logins since registration". I can't find out what the period since registration is. So I don't think it will do anything to remove spammers who edited once then were blocked. Having a blocked account prevents re-registration with that name, so might prevent some human spammers re-appearing, but random names like "1767676agghgh" probably would not appear again anyway. Maybe run this script from time to time as maintenance Buanzo, and see how much it reduces the current 3,361 registered users? As another approach, can anything in the statistics be added so that you could see a special page listing active users (however defined)?
  • Should there be some way of recording the IP address of account holders - or is this hidden somewhere?
  • (W) A Regex spam filter is needed for standard text, not just links in text.
  • (W) Buanzo proposes anonymous editing on a trial basis on the main Wiki. Gale's reaction was "go along with it if others strongly agree", but no-one else has commented. Maybe we need a quick test of this anyway? Supposing we said on the front page "Anyone can make edits without registration, though registration is recommended for regular users" or something like that?


Translations

  • (M) GA: The Manual has an ad-hoc method of translating pages by duplicating them with an appropriate suffix such as /fr then translating the duplicate. We expect to move the FAQs from main site to Manual for 2.0 even though that may initially reduce the extent to which they are translated.

    The main problem as I see it with translations is the lack of automation, which doesn't encourage translators to work here. For example, links to page B on a translated page A must be manually updated when page B is finally translated. All translators must monitor "recent changes" to find English pages which have been changed.

    On the main Wiki the few translations that have been done have the title of the translated page in the translated language. This should probably be changed while there are still relatively few translations around, assuming we are keeping the idea of not translating the page titles. If we do keep this idea, shouldn't translated pages be in categories?

    Should there be a more thoroughgoing solution such as creating a new subdomain for each language? Or if we keep the current translation system on the Manual, is there some way to automatically create duplicated pages with various suffixes?

    • Does the Translate extension help us - Possibly it's only for translation of MediaWiki itself?


Feature Enhancements

  • (W) (M) Search is still not good enough in terms of camelcase and finding exact text, even after installing the Sphinx extension. We probably need the Google Custom Search Engine extension without the optional Google Search box. A de facto implementation of this extension with the Google extension as well (possibly not necessary for us) is described on the OpenOffice.org wiki.
  • (W) (MediaWiki bug?) Not able to watch an entire category without subscribing to every page in it individually. Currently, watching the category only notifies if the actual category page changes.
    • Gale 01Nov10: CategoryWatch allows notification when pages are added to/removed from a category. Currently a watch email is only generated if the Category page text itself is physically edited. This extension will at least help with that and should be implemented.
  • (W) There is a problem with users saving every single edit (sometimes two or three a minute) and blocking up Recent Changes. We could install ForcePreview to do this, and modify it to force preview for everyone (except possibly sysops/bureaucrats). Might also be possible to make Preview the default button, though less effective.
    • Hadn't we solved this, as it was a php/server setup thing? (Buanzo)
    • Gale: MediaWiki 1.15 on the Manual gives a warning if you save without an edit summary, and we could customise that warning. So unless you deliberately set this up when upgrading, the feature is on by default.
  • RSS feeds, also proposed for the Forum.
    • I just worry about the extra bandwidth (Buanzo)
  • Some way to open particular links as a new window, like is already done with the "Editing help" link at the bottom of a page when you edit it. There is a suggestion here, but defining a link dynamically looks dangerous?
    • What about using the middle mouse of the button, like in firefox, opens a link in a new tab (Buanzo).
    • Gale: I don't have a middle mouse button, for one.
    • If you don't have a middle mouse button, you can always open a link in a new window by right-clicking (or control-clicking) on it and selecting "Open Link in New Window/Tab". Most mice have had a middle mouse button (clicking the scroll wheel) for quite a while, except older Mac mice. On the Mac, most browsers can open links in a new tab by command-clicking on them.

      Note that the example you gave of "Editing help" specifically has a warning next to it that it will open in a new window, and it does it for the good reason that you could lose your edits in some browsers otherwise. Forcing links to open in a new window is not something that should be done lightly. Search Google for "should links open new window" for lots and lots of articles about why this is usually a bad idea. --Skorpion 14:13, 6 December 2010 (UTC)

      • Gale: Thanks. Of course we would warn if a new window was to be opened. I think a lot of the arguments given against opening a new window are fairly dated now given that many browsers can customise how to handle target="_blank" links e.g. open them in new tabs or the same tab. At any event my main reason for considering this was to preserve the user's edits, rather than lose them, as some browsers do not satisfactorily retain text input when you go to a new page and then hit the back button.
  • Multiple file upload at a time 
  • (W) Notify by the yellow flash when you log in not only when your user talk page is modified, but when any page you are watching is modified. Otherwise you have to rely on the email service, or hang out on recent changes or on your watch list.
  • (W) Uploading and playing audio media (including MP3 if possible). Are there any security implications?
  • (W) Uploading other useful binary file types for via the "image" mechanism, possibly restricted to sysops if that can be done. PDF and zip files (for storage as zip) could be useful.
  • Buanzo proposes the installation of a Whos Online  extension. Helps to promote the Community feeling to see that other people are on the Wiki at the same time you are.
    • Gale: I think that's a nice little addition and matches the "Currently Online" display on the Forum. Looking forward to seeing this.
      • Will do.


Restrictions and Possible bugs

  • (M) Export script for a paged HTML and PDF Manual is broken. See this discussion. There is significant user demand for a PDF version of the Manual. We do have a workable script to do an HTML dump now, giving us individual HTML pages for an installed Manual.
  • (W) User getting continual 403 error (Forbidden) in IE7 (5730-11) with Norton firewall running "with privacy and ad blocker". Norton does not seem to block other pages but requires shutting down before the Wiki can be accessed. If he runs "a vmware version of XP Pro with IE7 (5730-13) with ony the XP firewall on", the Wiki can be accessed. Gale suggested he cleared his browser cache and defaulted his IE privacy settings, but unknown if this helps.


Alternatives to MediaWiki

  • Is MediaWiki the best software, and if not are the problems porting to another Wiki insuperable? For example, although we now support clickable images, Dokuwiki  (GPL) supports many features - a list comparing DokuWiki with MediaWiki is here .
    • James: I'd be very wary of trying to move at this stage because of the time cost in fixing up 'minor differences'.


Extensions rather than Alternatives

  • Here is a List of extensions used on Wikipedia. At some time we might like to review whether we want any of these too. They seem to have a more flexible template system than we do, and that looks interesting. Probably it's a version thing rather than one of the extensions. Compare with our Version and extensions.
  • The wikimedia Extensions Matrix lists available extensions. Some we might consider (stable unless indicated otherwise) are:
    • SecureHtml - Arbitrary html on sysops locked template pages.
    • AllowAnchorTags - was suggested as a solution for clickable image links, but we now support these with some limitations. Also Wiki does support <page element  id=" "> anchors, just not <a name>.
    • (W) CategoryTree - Categories as a clickable tree.
    • EmailAddressImage - email addresses converted to images. Naturally the address can't be copied to clipboard so of limited value - probably better to add underscores in the address and a mailto: as we do now?
    • GeSHiCodeTag - Code syntax highlighting. Or the similar SyntaxHighlight_GeSHi 
    • Glossary - Automated tooltips for glossary items placed on a special sysops locked page. Need to see an example to see whether this is good or not!
    • Hierarchy - Seems to be good for showing where you are in a 'book', providing forward and backward buttons.
    • Pdf Export - PDF Export.
    • Ogg Handler - BETA Ogg Vorbis.
    • Tree View - BETA Possibly nice for contents? (requires javascript? Only of use on live site?) Maybe nice to replace the links in the Sidebar


Done

  • (W) (M) 14May2012: ImageMap extension installed on Manual and Wiki to produce better images where the user can click different parts of an image to go to different links. This lets us make a neater Audacity for the impatient image.
  • (W) (M) $wgAllowDisplayTitle=true; and $wgRestrictDisplayTitle = false; enabled in LocalSettings.php to allow translators to use {{DISPLAYTITLE:your name}} to display a translated page title.
  • (W) (M) Search was very poor on the two Wikis. In particular, pages could not be found unless the search string entered corresponded with the camelcase/capitalisation of the title. Two extensions were investigated back in 2009 (Lucene-search and SphinxSearch). Sphinx was implemented on both Wikis Oct 2010. However out-of-the box Sphinx search as currently implemented only solves the capitalisation issue. Searching for "envelope" returns anything starting with "envelop", and searching for a quoted phrase does not only return pages that have that exact phrase.
  • (W) (MediaWiki bug?) : cannot upload files with .png extension but have to change it to PNG. GIF is blocked, is it a real security risk?
    • James: GIF is a proprietary format. I'm fine with us continuing to block it.
    • Gale: GIF is now open - the worldwide patents owned by Compuserve expired in 2004. Permitted file types as of Nov 2010 are : bz2, png, gif, gz, jpg, jpeg, ny, txt, xml.
  • (W) <span style="line-height"> tags no longer blocked (it was an extra, un-necessary regex filter).
  • (W) (M) Upgraded to current 1.15. This gives a more intuitive way to provide clickable image links, though the syntax in 1.15 does not work completely (e.g. no customised ALT text).
  • (M) Unable to scale images with normal syntax of " [[Image.png|60px]]"
  • (M) Logged-in can now see a navigation sidebar but don't see editors' navigation boxes.
  • (W) Fix logo mouseover to read "Audacity main site, for news, downloads and documentation" (at present it reads "cuac").
  • Added the wgAllowExternalImages setting so we can support clickable images. Syntax is: [<link to page><space><link to image>]
  • (W) Installed TableEdit  extension.
  • (W) Fixed spam links filter on main Wiki blocking all external links by taking some blank lines out.
  • (W) added texvc  so we can support <math> tags. Discussion of this extension here .
  • Checked that although system pages (Special:Allmessages) are in Special Pages for all users, only sysops can edit one of the messages when you click its link.
  • (W) reCAPTCHA  implemented for new user registration and in the event of "brute-force" password cracking. It's also implemented for anonymous edits that contain new external links, but currently anonymous editing is disabled.