Re: Editing in the Wiki

A less high tech solution would be to, *if you know you will want to  
edit a particular page*, export it, leave a note at the top  
indicating that you would like others not to edit it temporarily, and  
edit it off line. One could edit it in a text editor or by importing  
it in to a local installation of a mediawiki.

If you were willing to do merges, if it changed while you were  
editing it, then don't leave the note. Note the version of the page  
when you do the export. When ready to import your new version, note  
the version of the page again.  Reimport the edited page (or edit the  
page and paste the new version over the old). If the version changed  
between when you "checked out" your copy and just before you "checked  
it in", then use the built-in diff to show the differences made when  
you were off line, and merge those changes in to your current version.

I am looking in to what software might be used to create a read-only  
mirror of the site, should that be used. Currently can't get wget to  
do exactly what I want:

wget -k --reject=php -q -np -m http://www.w3.org/2007/OWL/wiki/

Messes up the interfile links, despite the -k switch (it creates  
file: links, but doesn't take into account where it  is dumping the  
downloaded files, instead making the file: links relative to root. I  
suppose I could fix this with sed...

-Alan

On Jan 8, 2008, at 5:03 AM, Rinke Hoekstra wrote:

>
> You could try [1], but it seems to be discontinued, and I don't  
> think it is cross-platform.
>
> Otherwise you could run a local copy of MediaWiki (requires  
> webserver + MySQL) and import/export MediaWiki pages in XML format  
> (see the Special:Export and Special:Import pages)... import is  
> usually only allowed for Sysops.
>
> A full mirroring would require a regular database dump to an  
> accessible location, a dump of the wiki's (non location specific)  
> configuration files, and a dump of the uploaded images and  
> documents etc.
>
> For every offline edit, you would then have to load the database  
> into a locally running MySQL instance, overwrite your local wiki  
> configuration files and the images/documents.
>
> In short: you'll enter maintenance hell.
>
> There are (I believe) other wiki's that allow you to edit wiki  
> pages directly through an RCS compliant version control system  
> (such as CVS or SVN). Google's wiki does this, and (I think) TWiki  
> allows this as well. These wiki's store pages as plain text files  
> (i.e. not in a database).
>
> But I guess moving to a different wiki is not really an option.
>
> -Rinke
>
>
> [1] http://examples.anotherwebcom.com/wikis/MediaWiki/ 
> Category:Offline_MediaWiki_Text_Editor
>
>
> On 7 jan 2008, at 20:52, Ian Horrocks wrote:
>
>>
>> I'm not proposing it as a solution to Peter's problem, but I  
>> wondered how easy it would be to install a local wiki, and perhaps  
>> even a mirror of the WG wiki, so that I could work on wiki pages/ 
>> documents off-line and upload them when I have a connection. This  
>> would solve what is for me one of the more annoying aspects of the  
>> wiki -- the fact that it is useless without network connectivity.
>>
>> Ian
>>
>>
>> On 3 Jan 2008, at 09:50, Peter F. Patel-Schneider wrote:
>>
>>>
>>> I have suffered with editing in the Wiki for quite some time  
>>> now.  Here
>>> are some comments on the Wiki editing process (as opposed to  
>>> editing as
>>> related to the Wiki language) and some suggestions for changes.
>>>
>>>
>>> The Wiki editing system has at least the following problems with  
>>> respect
>>> to editing WD documents:
>>>
>>> - The Wiki diff mechanism does only a textual diff, ignoring the  
>>> fact
>>>  that whitespace can be compressed and that newlines are often just
>>>  whitespace.  So a diff may be much harder to decipher than a simple
>>>  description of a change.
>>>
>>> - The Wiki diffs are only between two versions of the document,  
>>> whereas
>>>  the changes required to implement an issue may be interleaved with
>>>  many other changes.
>>>
>>> - Direct editing (i.e., editing in the provided text box) is not
>>>  adequate.  This leads to the common practice of editing pages or
>>>  sections in an external editor.  The export and import can produce
>>>  non-visible artifacts, which are then picked up in the diffs.
>>>
>>> - The Wiki editing model is not designed for speculative  
>>> editing.  All
>>>  changes are reflected in a single branch.  All editing must be  
>>> made on
>>>  the Wiki itself.  It is not possible to have private copies, e.g.,
>>>  editor's drafts.  This means that it is not possible to "freeze" a
>>>  document (e.g., for publication) and continue to work on it at the
>>>  same time.  No, you cannot use old versions for this - freezing  
>>> does
>>>  *not* mean that the document does not get changed as there may be
>>>  changes needed to support the publication process.
>>>
>>> - The Wiki editing system appears to be designed for light-weight
>>>  concurrent editing.  It is adequate for recording who did what  
>>> when,
>>>  but not adequate for recording why.  It is much too easy to  
>>> forget to
>>>  enter the description of changes.  Contrariwise, it is  
>>> impossible to
>>>  fix these descriptions after the fact.
>>>
>>>
>>> A reaonable editing system would have *at least* the following  
>>> changes
>>> from the Wiki editing system:
>>>
>>> - A user-entered description of the changes would be *required*  
>>> for each
>>>  change.
>>> - The "minor edit" flag would have to be entered for each change.
>>> - Change descriptions could be changed after the fact.
>>> - Speculative changes (i.e., a different branch) would be  
>>> possible, and
>>>  could be merged into the main branch.
>>> - Diffs could be generated based on a set of changes.
>>> - Diffs would be insensitive to non-visible changes in whitespace.
>>>  (Unfortunately the Wiki language makes determination of non- 
>>> visibility
>>>  hard.)
>>>
>>>
>>> If the first two changes above were made to the Wiki editing  
>>> system then
>>> the WG could proceed in the following limping manner:
>>>
>>> - Each change would be for a particular purpose.
>>> - Changes related to an issue would have the issue number in their
>>>  description.
>>> - Changes made solely for editorial reasons would so state, and  
>>> would be
>>>  flagged as minor.
>>> - Other changes would have a description of the purpose of the  
>>> change.
>>> - Issue resolutions would just point to which documents were  
>>> changed.
>>> - Publication would be approved for a document and not a particular
>>>  version of a document.  Non-minor changes to a document during the
>>>  publication process would have to be approved by the WG chairs.
>>>
>>> This proposed process is definitely not ideal, but appears to me  
>>> to be
>>> acceptable and needs only minor changes to the Wiki editing system.
>>>
>>> (It turns out that it is possible for the WG to partly  
>>> "implement" the
>>> first change, by requiring that all WG members change their  
>>> Preferences
>>> -> Editing -> Prompt me when entering a blank edit summary to on.
>>> Unfortunately, the way this preference works is particularly  
>>> annoying,
>>> and much too easy to bypass.)
>>>
>>>
>>> Peter F. Patel-Schneider
>>> Bell Labs Research
>>>
>>>
>>
>
> -----------------------------------------------
> Drs. Rinke Hoekstra
>
> Email: hoekstra@uva.nl    Skype:  rinkehoekstra
> Phone: +31-20-5253499     Fax:   +31-20-5253495
> Web:   http://www.leibnizcenter.org/users/rinke
>
> Leibniz Center for Law,          Faculty of Law
> University of Amsterdam,            PO Box 1030
> 1000 BA  Amsterdam,             The Netherlands
> -----------------------------------------------
>
>
>
>

Received on Tuesday, 8 January 2008 12:41:50 UTC