One of the reasons everyone and their sockpuppet scream "WYSIWYG editor" is the accumulation of intricate wiki markup on even otherwise simple pages. Coincidentally, this is also what prevents a WYSIWYG editor at the moment ;-) It is also said that the template hell and other things scare away newbies, or lead to their accidental breaking of pages.
Once Upon A Time (TM), I wrote a function into MediaWiki that would separate some of the meta content into a separate editing area, thus reducing the clutter in the actual edit box. The code's still there, deactivated, and probably broken right now.
Today, I rewrote the thing in JavaScript. It separates * templates, images, and horizontal lines at the top of a page * templates and some magic words at the end of a page * categories * language links into text boxes of their own. This happens automatically right after loading the edit page, and it all gets reconstructed into a single text the moment you save, preview, or diff the edit. On preview or diff, everything gets separated again.
It is only enabled for the article namespace. Top and bottom edit boxes can be hidden (I could add an option to hide either as default), and everything can be reset to "standard", giving the normal edit page for the moment.
Besides better structuring of article body and "meta" content, it does clean up whitespace, sort categories and language links alphabetically, etc.
A demo of what it does to [[Stevan Faddy]], a short, regular biography, is here: http://www.magnusmanske.de/wikipedia/less_page_clutter.png
Finally, the script: http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js
It seems that there is no "withJS" option on en.wikipedia, which would allow for a transient demo. To use, add the usual incantation to your monobook.js: importScript('User:Magnus Manske/less edit clutter.js');
Cheers, Magnus
Smart!
On Mon, Mar 10, 2008 at 4:59 PM, Magnus Manske magnusmanske@googlemail.com wrote:
One of the reasons everyone and their sockpuppet scream "WYSIWYG editor" is the accumulation of intricate wiki markup on even otherwise simple pages. Coincidentally, this is also what prevents a WYSIWYG editor at the moment ;-) It is also said that the template hell and other things scare away newbies, or lead to their accidental breaking of pages.
Once Upon A Time (TM), I wrote a function into MediaWiki that would separate some of the meta content into a separate editing area, thus reducing the clutter in the actual edit box. The code's still there, deactivated, and probably broken right now.
Today, I rewrote the thing in JavaScript. It separates
- templates, images, and horizontal lines at the top of a page
- templates and some magic words at the end of a page
- categories
- language links
into text boxes of their own. This happens automatically right after loading the edit page, and it all gets reconstructed into a single text the moment you save, preview, or diff the edit. On preview or diff, everything gets separated again.
It is only enabled for the article namespace. Top and bottom edit boxes can be hidden (I could add an option to hide either as default), and everything can be reset to "standard", giving the normal edit page for the moment.
Besides better structuring of article body and "meta" content, it does clean up whitespace, sort categories and language links alphabetically, etc.
A demo of what it does to [[Stevan Faddy]], a short, regular biography, is here: http://www.magnusmanske.de/wikipedia/less_page_clutter.png
Finally, the script: http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js
It seems that there is no "withJS" option on en.wikipedia, which would allow for a transient demo. To use, add the usual incantation to your monobook.js: importScript('User:Magnus Manske/less edit clutter.js');
Cheers, Magnus
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
This seems like a pretty clear improvement in the interface, at least for novice users, and as you say it can be deactivated for more experienced people. As a proof of concept it looks pretty great. I would say if this were going live, make the defaults be to not show the header or footer, and only have this active in the mainspace. As people are experienced more they could turn on the full editing view in their preferences.
Brilliant - I personally feel that this should be included in the gadgets seciton of the user properties, and enabled by default for all new users.
Stwalkerster
On 11/03/2008, Judson Dunn cohesion@sleepyhead.org wrote:
This seems like a pretty clear improvement in the interface, at least for novice users, and as you say it can be deactivated for more experienced people. As a proof of concept it looks pretty great. I would say if this were going live, make the defaults be to not show the header or footer, and only have this active in the mainspace. As people are experienced more they could turn on the full editing view in their preferences.
Judson http://en.wikipedia.org/wiki/User:Cohesion
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On 11/03/2008, Judson Dunn cohesion@sleepyhead.org wrote:
This seems like a pretty clear improvement in the interface, at least for novice users, and as you say it can be deactivated for more experienced people. As a proof of concept it looks pretty great. I would say if this were going live, make the defaults be to not show the header or footer, and only have this active in the mainspace. As people are experienced more they could turn on the full editing view in their preferences.
I haven't looked to see how it works, but if the header/footer are going to be hidden by default, it needs to be very easy to work out how to view them - having parts of the page that you can't easily edit would be a very bad thing.
On 10/03/2008, Magnus Manske magnusmanske@googlemail.com wrote:
One of the reasons everyone and their sockpuppet scream "WYSIWYG editor" is the accumulation of intricate wiki markup on even otherwise simple pages. Coincidentally, this is also what prevents a WYSIWYG editor at the moment ;-) It is also said that the template hell and other things scare away newbies, or lead to their accidental breaking of pages.
Once Upon A Time (TM), I wrote a function into MediaWiki that would separate some of the meta content into a separate editing area, thus reducing the clutter in the actual edit box. The code's still there, deactivated, and probably broken right now.
Today, I rewrote the thing in JavaScript. It separates
- templates, images, and horizontal lines at the top of a page
- templates and some magic words at the end of a page
- categories
- language links
into text boxes of their own. This happens automatically right after loading the edit page, and it all gets reconstructed into a single text the moment you save, preview, or diff the edit. On preview or diff, everything gets separated again.
It is only enabled for the article namespace. Top and bottom edit boxes can be hidden (I could add an option to hide either as default), and everything can be reset to "standard", giving the normal edit page for the moment.
Besides better structuring of article body and "meta" content, it does clean up whitespace, sort categories and language links alphabetically, etc.
A demo of what it does to [[Stevan Faddy]], a short, regular biography, is here: http://www.magnusmanske.de/wikipedia/less_page_clutter.png
Finally, the script: http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js
It seems that there is no "withJS" option on en.wikipedia, which would allow for a transient demo. To use, add the usual incantation to your monobook.js: importScript('User:Magnus Manske/less edit clutter.js');
Cheers, Magnus
Great work. Would it be possible to adapt this into a tool to separate the source of an article into: references and everything else?
Slightly different: would it be possible to have an editing interface where tags of the form "<ref name="">{{template}}</ref>" in the body are pulled out to a separate text box, leaving a token in the body text (e.g. <ref name="" />)? Separating the content of these tags would clean up the body when editing and the token left in the body would indicate that there is a tag here and that it has this name (see ref text box).
On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill oldakquill@gmail.com wrote:
Great work. Would it be possible to adapt this into a tool to separate the source of an article into: references and everything else?
Slightly different: would it be possible to have an editing interface where tags of the form "<ref name="">{{template}}</ref>" in the body are pulled out to a separate text box, leaving a token in the body text (e.g. <ref name="" />)? Separating the content of these tags would clean up the body when editing and the token left in the body would indicate that there is a tag here and that it has this name (see ref text box).
Technically, yes, should be possible (in the article namespace, there should be no "funny" nowiki constructs etc.).
But would that really help? I can see where it would be good to have a reference replaced with, say, some tiny red number that one can click on an that expands into the reference. But in a plain text editor, there'd still be the "empty" reference; I'd have to make up some ID for "unnamed" ones; then make some pseudo-text-table edit box somewhere.
I could try to whip up some "monitoring script" that constantly checks where your cursor is and somehow highlights the appropriate reference in a list box. Might be worth a shot.
That's another thing that came to mind. Currently, I strip "[[", "]]", and category prefix from categories and language links, and put them in separate textboxes. But, as these are always single lines (actually, key:value pairs), would it be more appropriate to change these into list boxes? Then I could add pretty buttons ("Delete category", "Add category", etc.). Of course, I could do that for the current textareas as well.
Cheers, Magnus
Magnus Manske wrote:
On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill oldakquill@gmail.com wrote:
Great work. Would it be possible to adapt this into a tool to separate the source of an article into: references and everything else?
Slightly different: would it be possible to have an editing interface where tags of the form "<ref name="">{{template}}</ref>" in the body are pulled out to a separate text box, leaving a token in the body text (e.g. <ref name="" />)? Separating the content of these tags would clean up the body when editing and the token left in the body would indicate that there is a tag here and that it has this name (see ref text box).
Technically, yes, should be possible (in the article namespace, there should be no "funny" nowiki constructs etc.).
But would that really help? I can see where it would be good to have a reference replaced with, say, some tiny red number that one can click on an that expands into the reference. But in a plain text editor, there'd still be the "empty" reference; I'd have to make up some ID for "unnamed" ones; then make some pseudo-text-table edit box somewhere.
What'd help, IMO, is not requiring the actual body of the reference to be inline at the point of the first use, which results in a bunch of messy markup in the middle of a paragraph. If all the inline references could be of the form <ref name="foo" />, and the actual definition of reference "foo" were somewhere else (above the main text, below it, wherever), that'd make the references a lot more intrusive. It seems this would be a markup/parser change, not requiring any sort of interface-side change.
-Mark
On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill oldakquill@gmail.com wrote:
Great work. Would it be possible to adapt this into a tool to separate the source of an article into: references and everything else?
Slightly different: would it be possible to have an editing interface where tags of the form "<ref name="">{{template}}</ref>" in the body are pulled out to a separate text box, leaving a token in the body text (e.g. <ref name="" />)? Separating the content of these tags would clean up the body when editing and the token left in the body would indicate that there is a tag here and that it has this name (see ref text box).
OK, I took the challenge. I integrated a reference management tool. Works like this: * It extracts all <ref></ref> tags from the text * It replaces them with "<<REF1>>", "<<REF2>>", etc. * These special tags are valid only during editing; upon preview, diff, or save, they are replaced with the original * This is /not/ done if the text already contains something like "<<REFX>>" (X being any number), so it won't mess up texts * It also does not touch "repeated refs" (<ref name="xyz"/>)
Below the normal text box, there is now a list box, one line per reference, containing number, name (if set), and text of the reference. You can * select a line, and it will highlight the corresponding <<REF>> in the text (no scrolling there yet; working on it) * double-click the line, and edit name and text in a dialog * select a reference and delete it
In the text boxes, you can * select the <<REF>> tag (double-clicking it will do), and it shows the corresponding reference in the list * insert a new reference at the current position (name and text dialogs again)
I have taken care to "default to standard", that is, things will not be changed (even temporarily) unless it's safe to do so.
Also, new screenshot, editing yesterday's article of the day, [[John Knox]], with the reference management: http://www.magnusmanske.de/wikipedia/less_page_clutter.png
Even in this huge, real-life example, the only changes the script would do (as seen in a diff) are alphabetical reordering of language links and categories.
Cheers, Magnus
On 12/03/2008, Magnus Manske magnusmanske@googlemail.com wrote:
On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill oldakquill@gmail.com wrote:
Great work. Would it be possible to adapt this into a tool to separate the source of an article into: references and everything else?
Slightly different: would it be possible to have an editing interface where tags of the form "<ref name="">{{template}}</ref>" in the body are pulled out to a separate text box, leaving a token in the body text (e.g. <ref name="" />)? Separating the content of these tags would clean up the body when editing and the token left in the body would indicate that there is a tag here and that it has this name (see ref text box).
OK, I took the challenge. I integrated a reference management tool. Works like this:
- It extracts all <ref></ref> tags from the text
- It replaces them with "<<REF1>>", "<<REF2>>", etc.
- These special tags are valid only during editing; upon preview,
diff, or save, they are replaced with the original
- This is /not/ done if the text already contains something like
"<<REFX>>" (X being any number), so it won't mess up texts
- It also does not touch "repeated refs" (<ref name="xyz"/>)
Below the normal text box, there is now a list box, one line per reference, containing number, name (if set), and text of the reference. You can
- select a line, and it will highlight the corresponding <<REF>> in
the text (no scrolling there yet; working on it)
- double-click the line, and edit name and text in a dialog
- select a reference and delete it
In the text boxes, you can
- select the <<REF>> tag (double-clicking it will do), and it shows
the corresponding reference in the list
- insert a new reference at the current position (name and text dialogs again)
I have taken care to "default to standard", that is, things will not be changed (even temporarily) unless it's safe to do so.
Also, new screenshot, editing yesterday's article of the day, [[John Knox]], with the reference management:
http://www.magnusmanske.de/wikipedia/less_page_clutter.png
Even in this huge, real-life example, the only changes the script would do (as seen in a diff) are alphabetical reordering of language links and categories.
Thank you! This should really help with references. It makes the body in the edit window look a lot cleaner (hopefully less confusing for newbies). Should help most users with readability of text being edited.
On 3/13/08, Magnus Manske magnusmanske@googlemail.com wrote:
Also, new screenshot, editing yesterday's article of the day, [[John Knox]], with the reference management:
Could you install this on testwiki or something so we can all play with it? (without having to keep hacking our js files, that is...)
Steve
On 3/13/08, Magnus Manske magnusmanske@googlemail.com wrote:
In general, I really like the goal here - removing metadata from the body of the wikitext. However, I"m a bit torn by the idea of then separating and reformatting some of that metadata. It's nice to display categories in a list and allow them to be manipulated directly, if the underlying data structure is a list. But the underlying data structure is really just a number of embedded elements:
[[category:foo]] blah [[category:x]]
etc. The same arguments against wysiwyg apply, in weaker form, here: the underlying text is rearranged, people may have had reasons for ordering categories in a certain way etc. For example, how will this be resaved:
[[Category:Martian rock singers]] <!-- as per lengthy discussion, DO NOT REMOVE --> [[Category:Jewish Martian golfers]]
Will the comment be trimmed? etc.
Since there is very little consensus over the "correct" ordering of metadata, any tool which reformats metadata in some rigid format is bound to step on some toes. Which is probably just an argument for *reaching* some consensus on metadata formatting, of course.
Perhaps one solution to this is to make the GUI dynamic, reflecting the contents of the wikitext. That is, this: ---- {{hatnote}} Some text<ref>RRR</ref> Foo [[Category:blah]]
{{template}}
[[Category:foo]] <references /> ----
Could produce an editing environment as follows:
* Edit box for header stuff, containing {{hatnote}} * Edit box for main text, containing "Some text <<ref>> / Foo" * List box for categories, containing blah * Edit box for footer stuff, containing {{template}} * List box for categories, containing foo * List box for references
That is, the wikitext is effectively decomposed into sections, and edit boxes of the appropriate types assembled in order.
Someone is bound to mention that since it's javascript, anyone can customise it however they want, but I think that's the wrong approach. We should be trying to find a good solution that satisfies almost everyone, and end up with almost all users of Wikipedia using it.
Steve
On 17/03/2008, Steve Bennett stevagewp@gmail.com wrote:
Since there is very little consensus over the "correct" ordering of metadata, any tool which reformats metadata in some rigid format is bound to step on some toes. Which is probably just an argument for *reaching* some consensus on metadata formatting, of course.
Yes, I've been using the tool for actual editing and that's already happened; somebody claimed that there was a 'right' way to order the interwiki language markups and rearranged it after I submitted.
The other problems I've had have been that one time the tool took an image on the end of a section I was editing and placed it in the interwiki language box. It kinda confused me because the image wasn't where I expected. ;-)
I also have been having issues with the references; this is one area where the editing tool shows great potential, but there's currently no way to edit a reference, without entirely deleting it and recreating it from scratch, which is a *huge* nuisance.
But other than that it looks promising. Oh and the 'header section and templates' section is much too big- it should be about 2-3 lines tall at most, they can always scroll if they need to.
Perhaps one solution to this is to make the GUI dynamic, reflecting the contents of the wikitext. That is, this:
Not sure, perhaps simply a smaller box in each case might be a simpler and more straightforward idea.
Steve
(sorry for the late reply; was on vacation)
On Mon, Mar 17, 2008 at 3:44 AM, Ian Woollard ian.woollard@gmail.com wrote:
On 17/03/2008, Steve Bennett stevagewp@gmail.com wrote:
Since there is very little consensus over the "correct" ordering of metadata, any tool which reformats metadata in some rigid format is bound to step on some toes. Which is probably just an argument for *reaching* some consensus on metadata formatting, of course.
Yes, I've been using the tool for actual editing and that's already happened; somebody claimed that there was a 'right' way to order the interwiki language markups and rearranged it after I submitted.
If there's a "right" way, the tool can be altered to use it.
The other problems I've had have been that one time the tool took an image on the end of a section I was editing and placed it in the interwiki language box. It kinda confused me because the image wasn't where I expected. ;-)
Uh. I'll fix that...
I also have been having issues with the references; this is one area where the editing tool shows great potential, but there's currently no way to edit a reference, without entirely deleting it and recreating it from scratch, which is a *huge* nuisance.
Did you double-click on the entry in the list box? That should do it.
Cheers, Magnus
On 26/03/2008, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Mar 17, 2008 at 3:44 AM, Ian Woollard ian.woollard@gmail.com wrote:
Yes, I've been using the tool for actual editing and that's already happened; somebody claimed that there was a 'right' way to order the interwiki language markups and rearranged it after I submitted.
If there's a "right" way, the tool can be altered to use it.
There is apparently a "right" way, and AutoWikiBrowser uses it too - see http://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/IW for the list AWB accesses at startup.
- d.
On 26/03/2008, David Gerard dgerard@gmail.com wrote:
On 26/03/2008, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Mar 17, 2008 at 3:44 AM, Ian Woollard ian.woollard@gmail.com wrote:
Yes, I've been using the tool for actual editing and that's already happened; somebody claimed that there was a 'right' way to order the interwiki language markups and rearranged it after I submitted.
If there's a "right" way, the tool can be altered to use it.
There is apparently a "right" way, and AutoWikiBrowser uses it too - see http://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/IW for the list AWB accesses at startup.
And the canonical list is at http://meta.wikimedia.org/wiki/Interwiki_sorting_order .
- d.
On 26/03/2008, David Gerard dgerard@gmail.com wrote:
On 26/03/2008, David Gerard dgerard@gmail.com wrote:
On 26/03/2008, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Mar 17, 2008 at 3:44 AM, Ian Woollard ian.woollard@gmail.com wrote:
Yes, I've been using the tool for actual editing and that's already happened; somebody claimed that there was a 'right' way to order the interwiki language markups and rearranged it after I submitted.
If there's a "right" way, the tool can be altered to use it.
There is apparently a "right" way, and AutoWikiBrowser uses it too - see http://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/IW for the list AWB accesses at startup.
And the canonical list is at http://meta.wikimedia.org/wiki/Interwiki_sorting_order .
Interestingly from an ongoing poll there is no clear consensus.
http://en.wikipedia.org/wiki/Wikipedia:Language_order_poll
Peter
On 26/03/2008, Peter Ansell ansell.peter@gmail.com wrote:
Interestingly from an ongoing poll there is no clear consensus. http://en.wikipedia.org/wiki/Wikipedia:Language_order_poll
And moreover, there's a bug to allow it to be ordered for all articles on a per-wiki basis!
However, when it's done in the "wrong" order people fuss to the AWB maintainers, so they have that list set up and it seems to keep people happy enough.
- d.
This is a great tool, but when I was trying to fix the reference format on [[Daniel Pipes]] (article is in sad shape...) I was searching and couldn't find a way to undo the reference formating thing without turning the whole tool off. In the reference box, it didn't look like it had the source text with tags and whatnot - can a switch be added (like the ones already there) that turns it on and off? Perhaps the current switch that removes the two boxes can also turn off the ref moving?
Again, very handy tool, nice work Magnus.
Nathan
On Wed, Mar 26, 2008 at 5:24 PM, David Gerard dgerard@gmail.com wrote:
On 26/03/2008, Peter Ansell ansell.peter@gmail.com wrote:
Interestingly from an ongoing poll there is no clear consensus. http://en.wikipedia.org/wiki/Wikipedia:Language_order_poll
And moreover, there's a bug to allow it to be ordered for all articles on a per-wiki basis!
However, when it's done in the "wrong" order people fuss to the AWB maintainers, so they have that list set up and it seems to keep people happy enough.
- d.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Wed, Mar 26, 2008 at 4:24 PM, David Gerard dgerard@gmail.com wrote:
However, when it's done in the "wrong" order people fuss to the AWB maintainers, so they have that list set up and it seems to keep people happy enough.
This seems crazy, what's wrong with alphabetical by code?
On 26/03/2008, Judson Dunn cohesion@sleepyhead.org wrote:
On Wed, Mar 26, 2008 at 4:24 PM, David Gerard dgerard@gmail.com wrote:
However, when it's done in the "wrong" order people fuss to the AWB maintainers, so they have that list set up and it seems to keep people happy enough.
This seems crazy, what's wrong with alphabetical by code?
It is DEEPLY OFFENSIVE to the NATIONAL CHARACTER of er someone. Or something.
- d.
On Wed, Mar 26, 2008 at 6:10 PM, David Gerard dgerard@gmail.com wrote:
On 26/03/2008, Judson Dunn cohesion@sleepyhead.org wrote:
On Wed, Mar 26, 2008 at 4:24 PM, David Gerard dgerard@gmail.com wrote:
However, when it's done in the "wrong" order people fuss to the AWB maintainers, so they have that list set up and it seems to keep people happy enough.
This seems crazy, what's wrong with alphabetical by code?
It is DEEPLY OFFENSIVE to the NATIONAL CHARACTER of er someone. Or something.
Which is why this tool should display them alphabetically for the editor's sake, but when you go to save shuffle the list so that everyone is offended equally.
Dammit, why is WP:POINT policy -- there are just so bloody many fun ways to break it!
On 17/03/2008, Steve Bennett stevagewp@gmail.com wrote:
On 3/13/08, Magnus Manske magnusmanske@googlemail.com wrote: Since there is very little consensus over the "correct" ordering of metadata, any tool which reformats metadata in some rigid format is bound to step on some toes. Which is probably just an argument for *reaching* some consensus on metadata formatting, of course.
There is very little consensus about people making a point of having categories or interwiki links in a specific order or in separate parts of the document. What ordered metadata can you describe, other than the example with the comment that is used solely for ease of freetext editing and could be better defined in a permanent section on the discussion page? Unless there is any actual reason for wanting to have one category declared between a template and something else, when infact the position of declaration is completely meaningless, it seems like a distraction to talk about it being a lack of consensus.
- Edit box for header stuff, containing {{hatnote}}
- Edit box for main text, containing "Some text <<ref>> / Foo"
- List box for categories, containing blah
- Edit box for footer stuff, containing {{template}}
- List box for categories, containing foo
- List box for references
That is, the wikitext is effectively decomposed into sections, and edit boxes of the appropriate types assembled in order.
Someone is bound to mention that since it's javascript, anyone can customise it however they want, but I think that's the wrong approach. We should be trying to find a good solution that satisfies almost everyone, and end up with almost all users of Wikipedia using it.
Still don't quite see what your point is with two interleaved list boxes to accommodate a preference to define categories in a meaningless order. As far as the rest is concerned, it would be nice to have a place just for references, which may facilitate a movement away from the unwieldy system of intext full citations that we currently endure because there is no better alternative.
Overall looks promising to me.
Peter
On 3/17/08, Peter Ansell ansell.peter@gmail.com wrote:
There is very little consensus about people making a point of having categories or interwiki links in a specific order or in separate parts of the document. What ordered metadata can you describe, other than the example with the comment that is used solely for ease of freetext editing and could be better defined in a permanent section on the discussion page? Unless there is any actual reason for wanting to have one category declared between a template and something else, when infact the position of declaration is completely meaningless, it seems like a distraction to talk about it being a lack of consensus.
I'm primarily talking about the crucial issue of whether interwiki links come before categories or after them. This matters a *lot*. To some people. It's one of those sort of irrational situations we have where X is ok, Y is ok, but changing X to Y is not ok. British English is ok. American English is ok. Converting British to American English is not ok. Interwikis then categories is ok. Cats then interwikis is ok. Moving interwikis before categories is not ok.
The issue of the ordering of categories themselves is probably best solved by not reordering. Since category ordering affects the visual presentation, it's not really safe to just arbitrarily reorder them.
Still don't quite see what your point is with two interleaved list boxes to accommodate a preference to define categories in a meaningless order. As far as the rest is concerned, it would be nice
The interleaved example is probably contrived. I don't think the free variation of order can be just ignored though. As Ian found out.
Steve
On 17/03/2008, Steve Bennett stevagewp@gmail.com wrote:
On 3/17/08, Peter Ansell ansell.peter@gmail.com wrote:
There is very little consensus about people making a point of having categories or interwiki links in a specific order or in separate parts of the document. What ordered metadata can you describe, other than the example with the comment that is used solely for ease of freetext editing and could be better defined in a permanent section on the discussion page? Unless there is any actual reason for wanting to have one category declared between a template and something else, when infact the position of declaration is completely meaningless, it seems like a distraction to talk about it being a lack of consensus.
I'm primarily talking about the crucial issue of whether interwiki links come before categories or after them. This matters a *lot*. To some people. It's one of those sort of irrational situations we have where X is ok, Y is ok, but changing X to Y is not ok. British English is ok. American English is ok. Converting British to American English is not ok. Interwikis then categories is ok. Cats then interwikis is ok. Moving interwikis before categories is not ok.
People argue about the most petty things. As I didn't realise about the ability to order the way categories are displayed I may be missing a dependency between interwiki's and categories, or it might just be people not realising their preference doesn't actually get displayed differently to anyone elses preference and hence they should just focus on the meaningful parts of the article.
The issue of the ordering of categories themselves is probably best solved by not reordering. Since category ordering affects the visual presentation, it's not really safe to just arbitrarily reorder them.
I stand corrected, I didn't realise that one could change the ordering of the categories by declaring them in a different order. I was under the naive impression that they were alphabetised and output generically (and that interwiki's did not interfere with categories or vice versa for that matter)
Peter
On 3/18/08, Peter Ansell ansell.peter@gmail.com wrote:
People argue about the most petty things. As I didn't realise about the ability to order the way categories are displayed I may be missing a dependency between interwiki's and categories, or it might just be people not realising their preference doesn't actually get displayed differently to anyone elses preference and hence they should just focus on the meaningful parts of the article.
Yeah. In case it's not clear, I think we should fix people here - by definining a preferred order for metadata.
I stand corrected, I didn't realise that one could change the ordering of the categories by declaring them in a different order. I was under the naive impression that they were alphabetised and output generically (and that interwiki's did not interfere with categories or vice versa for that matter)
I don't think interwikis interfere with categories, or vv.
Steve
On Mon, Mar 10, 2008 at 6:59 PM, Magnus Manske magnusmanske@googlemail.com wrote:
One of the reasons everyone and their sockpuppet scream "WYSIWYG editor" is the accumulation of intricate wiki markup on even otherwise simple pages. Coincidentally, this is also what prevents a WYSIWYG editor at the moment ;-) It is also said that the template hell and other things scare away newbies, or lead to their accidental breaking of pages.
Once Upon A Time (TM), I wrote a function into MediaWiki that would separate some of the meta content into a separate editing area, thus reducing the clutter in the actual edit box. The code's still there, deactivated, and probably broken right now.
Today, I rewrote the thing in JavaScript. It separates
- templates, images, and horizontal lines at the top of a page
- templates and some magic words at the end of a page
- categories
- language links
into text boxes of their own. This happens automatically right after loading the edit page, and it all gets reconstructed into a single text the moment you save, preview, or diff the edit. On preview or diff, everything gets separated again.
It is only enabled for the article namespace. Top and bottom edit boxes can be hidden (I could add an option to hide either as default), and everything can be reset to "standard", giving the normal edit page for the moment.
...
Cheers, Magnus
I'm using it now. I really like it, but after a few minutes a few things strike me:
# How about a box for External links sections? It makes quite as much sense as one for References or headers. # When there's nothing for a particular section, it would be great if your script could collapse the box until opened; and then if you add stuff into it, it could insert it into the article with the appropriate header in the appropriate place. That would be neat.
-- gwern
On Mon, Mar 17, 2008 at 4:03 PM, Gwern Branwen gwern0@gmail.com wrote:
I'm using it now. I really like it, but after a few minutes a few things strike me:
# How about a box for External links sections? It makes quite as much sense as one for References or headers.
External links are much less structured and thus harder to recognize. Also, they can be intermixed with a variety of templates that link to Commons, PG, etc. But, I might add this eventually...
# When there's nothing for a particular section, it would be great if your script could collapse the box until opened; and then if you add stuff into it, it could insert it into the article with the appropriate header in the appropriate place. That would be neat.
Should be easy to do.
Cheers, Magnus