Wiki Development Checklist

From Audacity Wiki

Jump to: navigation, search
The text on this page should only be modified by subscribers to Audacity-devel mailing list.

To understand what this page is for and how it is used, please join that list or read the list archives on Sourceforge.
The discussion page can be used by anyone to make suggestions and comments about this page.


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 


Contents

[edit] 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?


[edit] 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?


[edit] Feature Enhancements

  • (W) (M) Upgrade from MediaWiki 1.10.1 (this Wiki) to current 1.15.0. 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).
  • (W) (M) Search is poor on the two Wikis. In particular, pages cannot be found unless the search string entered corresponds with the camel case of the title (a particular problem on the main Wiki). A couple of extensions offer much better search:
    • Lucene-search used on Wikipedia, offers drop-down alternatives for the search term based on user input (note this obscures the buttons), but similar (confusing?) results pages. Example: http://en.wikipedia.org/wiki/Wikimedia
    • SphinxSearch, used on New World Encyclopedia, does not have a suggestions box (though it also finds the correct page in "Go" if you use a different camelcase/spacing), but has a better results page than Lucene and a "did you mean?" link for typos. Example: http://www.newworldencyclopedia.org/
    GA likes Sphinx for the nicer results page (including a search in categories). It also looks simpler to implement. We should implement one of these in the near future, unless someone has a preferred extension or solution. Google is of course a possibility, but seems to involve extending advertisements into audacityteam.org (or at least into results of searches from its pages), which could be controversial.
    I like Sphinx so far (Buanzo)
  • (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.
  • 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.

[edit] 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) Fix spam links filter on main Wiki so it does not block all external links.
    • GA: Nov09 Gale took some blank lines out of it and has enabled it again. It "seems" to be working...
  • (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.
  • (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.
  • (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. There is no good reason to block it that I'm aware of - there are plenty of GIF images on Wikipedia, and this is an un-necessary inconvenience.
  • Bug (in MediaWiki?) : <span style="line-height"> tags rejected as spam though this string is not in our current filters.
    • Gale: It's an extra regex filter that is regarded as "good practice" to add to Wiki because it blocks spam hidden in div tags. I disagree with blocking "height" and will remove that restriction unless someone objects here.


[edit] 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'.


[edit] 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 - e-mail 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


[edit] Done

  • (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) 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.
Personal tools