headers
Angela | 1 Jun 2010 01:00
Picon
Gravatar

Re: [Mediawiki-l] a wysiwyg editor for wikipedia?

On Tue, Jun 1, 2010 at 8:55 AM, David Gerard <dgerard <at> gmail.com> wrote:
> How installable and workable is this on, say, any random work intranet
> with a fairly generic MW 1.16 installation? I may give it a go at work

As far as I know, the problem right now is that Wikia's rich text
editor requires core changes, rather than simply being an extension
you can install. The code is all available at
https://svn.wikia-code.com/ but it still needs to be packaged up to
make it easier for third-party use.

> ... and the problem with the wikitext being mangled is that diffs show
> a 100% text change for any alteration

Luckily this is now a rare bug, and not the norm. Work is ongoing to
resolve the remaining causes of this. The aim is for diffs to work in
exactly the same way as they do with wikitext-only.

Angela
Permalink | Reply | 7 comments |
headers
Conrad Irwin | 1 Jun 2010 01:13
Picon
Gravatar

Re: a wysiwyg editor for wikipedia?

On 31 May 2010 23:37, David Gerard <dgerard <at> gmail.com> wrote:
> On 31 May 2010 23:31, Aryeh Gregor <Simetrical+wikilist <at> gmail.com> wrote:
>
>> Wiki syntax is too complicated for this to be feasible.  It also
>> doesn't have a one-to-one mapping to HTML.  It's been tried before,
>> but what you end up with is that it doesn't round-trip: if you open in
>> the WYSIWYG editor and save with no changes, it saves totally
>> different wikicode, confusing anyone who's using actual wikitext.  The
>> only feasible solutions are to either drastically simplify wikitext,
>> or switch to WYSIWYG only, and those would both be very disruptive.
>

The other solution is to use a proper MVC framework, and define
everything in terms of modifications to the wikitext (and you can then
constrain what those modifications are to avoid mangling) and run that
through a parser to generate the html preview. Alternatively, if your
wikitext modifications are constrained enough, it is possible to
implement modifications as a pair of functions, one of which edits the
wikitext and the other edits the HTML (this is the method used by
English Wiktionary for the translation adding interface - and makes
undo/redo really easy). Building such a thing is time-consuming -
particularly if you have to ensure that the wikitext modification and
the HTML modification are the same - as there's  a pretty large number
of things people would like to do with wikitext. That said, it's
pretty possible to use a wysiwyg for editing the contents of a
paragraph, so you could have one action for "change the content of" in
addition to actions for inserting/deleting and moving things around
(in a perfect world, a wysiwyg would trigger constrained actions based
on user-interaction - that is the "hard" part of this - the rest is
just complicated). As there's already a javascript thing for general
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jacopo Corbetta | 1 Jun 2010 04:09
Picon
Gravatar

Re: a wysiwyg editor for wikipedia?

On Tue, Jun 1, 2010 at 00:31, Aryeh Gregor
<Simetrical+wikilist <at> gmail.com> wrote:
> Wiki syntax is too complicated for this to be feasible.  It also
> doesn't have a one-to-one mapping to HTML.  It's been tried before,
> but what you end up with is that it doesn't round-trip: if you open in
> the WYSIWYG editor and save with no changes, it saves totally
> different wikicode, confusing anyone who's using actual wikitext.  The
> only feasible solutions are to either drastically simplify wikitext,
> or switch to WYSIWYG only, and those would both be very disruptive.

Another solution would be to identify a "simple" subset of wikitext
for which the mapping to XHTML is one-to-one and refuse to work on
anything else (i.e. revert to the standard editor). The rationale here
is that a visual editor would (probably) be aimed at new editors, and
they should probably avoid complicated syntax anyways. That's the
approach we took on MeanEditor
<http://www.mediawiki.org/wiki/Extension:MeanEditor>.

In our experience, the biggest obstacle is to get the different
browsers to reliably make the same changes to HTML. The editor
interface is non-standard, and browsers sometimes disagree on encoding
rules, escaping, choice of tags, etc.

Anyways, there is a survey of existing approaches at
<http://www.mediawiki.org/wiki/WYSIWYG_editor>. This might be useful
to new editor developers, and if you find a cool idea it would be nice
to contribute to the page. The usability project also did a survey
last year: <http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/Results>.
In the end, I think the FCKeditor developers did an amazing work, but
I am still convinced that a simple (and hopefully reliable) HTML-based
(Continue reading)

Permalink | Reply | 3 comments |
headers
Danese Cooper | 1 Jun 2010 08:03
Picon

Re: [Mediawiki-l] a wysiwyg editor for wikipedia?

Just noting that we at WMF have been talking to Wikia about taking a 
look at their code to see if it can be made useful for WMF properties. 
Expect to hear more about Rich Text Editing soonish.

Danese

On 5/31/10 4:00 PM, Angela wrote:
> On Tue, Jun 1, 2010 at 8:55 AM, David Gerard<dgerard <at> gmail.com>  wrote:
>    
>> How installable and workable is this on, say, any random work intranet
>> with a fairly generic MW 1.16 installation? I may give it a go at work
>>      
> As far as I know, the problem right now is that Wikia's rich text
> editor requires core changes, rather than simply being an extension
> you can install. The code is all available at
> https://svn.wikia-code.com/ but it still needs to be packaged up to
> make it easier for third-party use.
>
>    
>> ... and the problem with the wikitext being mangled is that diffs show
>> a 100% text change for any alteration
>>      
> Luckily this is now a rare bug, and not the norm. Work is ongoing to
> resolve the remaining causes of this. The aim is for diffs to work in
> exactly the same way as they do with wikitext-only.
>
> Angela
>
> _______________________________________________
> Wikitech-l mailing list
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ilmari Karonen | 1 Jun 2010 09:23
Gravatar
Subject: Re: [gsoc] splitting the img_metadata field into a new table

Re: [gsoc] splitting the img_metadata field into a new table

bawolff wrote:
> 
> However, if I do implement a new table as part of this, it will
> probably use page_ids to identify the image - I don't see any reason
> to artificially restrict it to just the file namespace.

Do remember that we'll also want to store metadata for old versions of 
images.  And yes, I'm aware that our database schema isn't likely to 
lend itself to easy and elegant solutions to that.  (My advice: try to 
go for simplicity at the expense of elegance, as long as it doesn't end 
up _too_ ugly.)

--

-- 
Ilmari Karonen
Permalink | Reply | 1 comment |
headers
Dmitriy Sintsov | 1 Jun 2010 12:58
Picon
Favicon

Re: [Mediawiki-l] a wysiwyg editor for wikipedia?

Hi!
Another approach is to reduce the complexity of wikitext editing by 
using syntax highlighting and javascript dialogs. There is wikEd editor 
which is being developed with such approach in mind:
http://en.wikipedia.org/wiki/User:Cacycle/wikEd
I does diffs, too.
Dmitriy
Permalink | Reply | 0 comments |
headers
bawolff | 1 Jun 2010 12:59
Picon
Subject: Re: [gsoc] splitting the img_metadata field into a new table

Re: [gsoc] splitting the img_metadata field into a new table

Yes, I'll definitly keep that in mind. Currently I'm thinking that for
deleted images and old versions of images I'll keep all the metadata
inside img_metadata as serialized php, since most of the use cases for
having metadata in a different table really only apply to the current
version of images.

Cheers,
bawolff

On Tue, Jun 1, 2010 at 1:23 AM, Ilmari Karonen <nospam <at> vyznev.net> wrote:
> bawolff wrote:
>>
>> However, if I do implement a new table as part of this, it will
>> probably use page_ids to identify the image - I don't see any reason
>> to artificially restrict it to just the file namespace.
>
> Do remember that we'll also want to store metadata for old versions of
> images.  And yes, I'm aware that our database schema isn't likely to lend
> itself to easy and elegant solutions to that.  (My advice: try to go for
> simplicity at the expense of elegance, as long as it doesn't end up _too_
> ugly.)
>
> --
> Ilmari Karonen
>
Permalink | Reply | 0 comments |
headers
Marco Schuster | 1 Jun 2010 15:22

Re: a wysiwyg editor for wikipedia?

On Tue, Jun 1, 2010 at 4:09 AM, Jacopo Corbetta
<jacopo.corbetta <at> gmail.com> wrote:
> In our experience, the biggest obstacle is to get the different
> browsers to reliably make the same changes to HTML. The editor
> interface is non-standard, and browsers sometimes disagree on encoding
> rules, escaping, choice of tags, etc.
We could do the really hard way, like Google did with Google Docs
(http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html):
make *everything* via JS by capturing keystrokes and mouse movements.
This way a consistent and reproducible user experience on all
platforms can be achieved. And by doing it all in JS, the editor could
also generate a wikitext-delta right away and doesn't need to transfer
the whole page's wikitext.

Marco

--

-- 
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Permalink | Reply | 2 comments |
headers
David Gerard | 1 Jun 2010 15:30
Picon
Gravatar

Re: [Mediawiki-l] a wysiwyg editor for wikipedia?

On 1 June 2010 07:03, Danese Cooper <dcooper <at> wikimedia.org> wrote:

> Just noting that we at WMF have been talking to Wikia about taking a
> look at their code to see if it can be made useful for WMF properties.
> Expect to hear more about Rich Text Editing soonish.

:-D :-D

Weeks, months?

- d.
Permalink | Reply | 0 comments |
headers
Chris Thomas | 1 Jun 2010 16:33
Picon

problem with Maps extension

I'm running MW 1.12 on Debian Lenny and I installed the Maps 0.5.5
extension. It works, however I get this message for random points when
I refresh. The list of points that aren't geocoded change with each
refresh.

"The following addresses could not be geocoded and have been omitted
from the map"

When the 0.6 version of Maps came out (yesterday) I installed it and,
immediately I get this error:

Fatal error: Call to undefined method Parser::getOutput() in
/var/lib/mediawiki/extensions/Maps/Services/GoogleMaps/Maps_GoogleMaps.php
 on line 217

Any thoughts?

-Chris
Permalink | Reply | 11 comments |

Gmane