Last modified: 2014-04-17 05:30:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2194 - Special handling for Tables and Charts
Special handling for Tables and Charts
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement with 25 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
: 1447 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-17 14:36 UTC by Omegatron
Modified: 2014-04-17 05:30 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Currently you see this (37.08 KB, image/png)
2005-09-29 06:05 UTC, Omegatron
Details
To insert a table in an article, you will use this instead (45.03 KB, image/png)
2005-09-29 06:06 UTC, Omegatron
Details
and in the future will see this when editing tables (54.62 KB, image/png)
2005-09-29 06:08 UTC, Omegatron
Details

Description Omegatron 2005-05-17 14:36:04 UTC
Tables clutter up the wiki markup and make it confusing and difficult to edit
for newcomers.  Large tables do not follow the philosophy of "easy to edit" wiki
markup at all.  

I propose that a Table: namespace be created to house tables and charts and
such, similar to the Image: namespace.  Table code can then be moved there and
included in articles with the same markup as images, and a lot of the same
options.  (Images and tables are treated similarly in printed work as well.) 
The differences have already been detailed at the Wikipedia proposal page listed.  

This feature request is specifically about point 1 on the roadmap (and nothing
else, so we can move one step at a time):

http://en.wikipedia.org/wiki/Wikipedia:Proposal_for_intuitive_table_editor_and_namespace#Roadmap

I would be glad to help the developers design this, though my coding skills are
not too great...
Comment 1 Omegatron 2005-05-17 14:37:54 UTC
*** Bug 1447 has been marked as a duplicate of this bug. ***
Comment 2 lɛʁi לערי ריינהארט 2005-06-04 09:58:25 UTC
Product: should probably be "MediaWiki"
Comment 3 Hymyly 2005-08-29 19:42:35 UTC
But isn't there a Table: namespace already? There is a small table at "Table:test". Shouldn't this bug be 
marked FIXED, or have I overseen something?
Comment 4 Omegatron 2005-08-29 19:53:12 UTC
(In reply to comment #3)
> But isn't there a Table: namespace already? There is a small table at
"Table:test". Shouldn't this bug be 
> marked FIXED, or have I overseen something?

That's just an example I made for demonstration purposes.  It's not really in
its own namespace as far as the software is concerned; it's just the title of
the article.  
Comment 5 maxim 2005-08-30 01:46:32 UTC
how difficult is it to add a namespace?
Comment 6 Brian Klug 2005-09-27 20:44:07 UTC
Please note that this is the first step in roadmap for implementing a Table Editor.  This is a burning need for 
this feature.
Comment 7 Rob Church 2005-09-27 20:55:42 UTC
>> how difficult is it to add a namespace?

It's not difficult to add a namespace. What is difficult is weighing up the pros and cons of 
having one, and making a decision about whether or not it will benefit us at all in the long 
run.

>> this is a burning need for this feature

How?
Comment 8 JDPorter 2005-09-27 21:04:42 UTC
There's a learning curve for tables in wikisyntax, but "a burning need"?
Comment 9 Omegatron 2005-09-27 21:43:21 UTC
(In reply to comment #7)
> It's not difficult to add a namespace. What is difficult is weighing up the
pros and cons of 
> having one, and making a decision about whether or not it will benefit us at
all in the long 
> run.

Really??  I was under the impression that it was dragging because it required
major changes to the software.

There's already a page for discussion and pros and cons.  Most everyone agrees
that it's a good idea.
 
(In reply to comment #8)
> There's a learning curve for tables in wikisyntax, but "a burning need"?

Well, only if you care about the wiki being easy to edit.  :-)  

There's a learning curve for HTML, too.  I doubt the 'pedia would be anywhere
near where it is today if it weren't for the markup language.  Pipe markup is
just a shortcut version of HTML; not a genuine easy-to-use input method.  

Removing editing barriers for people from varied backgrounds helps beat systemic
bias, one of our biggest criticisms.
Comment 10 Brian Klug 2005-09-28 21:05:38 UTC
> There's a learning curve for tables in wikisyntax, but "a burning need"?

I am proficient with wiki tables.  However, it is very time consuming for me to make several arbitrary changes 
to a given table.  With WikiMedia, it takes 1 minute to do what takes only a couple seconds in Excel.

I am not exaggerating the order of magnitude.  Imagine a table with a few columns and 100 rows.  Each column has 
enough content that each row wraps in the edit box.  The columns don’t line up.  When there are similar rows, it 
is very difficult to tell what row you are on.  It is difficult to tell how many columns are in the row without 
counting.

Adding or deleting a column is a nightmare.  

Editing tables without a table editor is inefficient and prone to errors.  Users shouldn’t have to spend 90% of 
their time and energy on formatting tables – it should be spent on contributing to article content.

Let’s get the politics done with to make this a reality.  Unfriendly tables are a major barrier to new user 
adoption.  
Comment 11 Rob Church 2005-09-28 21:34:31 UTC
>> this is a burning need for this feature

I meant, how is "this" [a separate namespace for tables and charts] a burning
need for "this feature" [a table editor]?
Comment 12 Karl Dickman 2005-09-28 22:56:28 UTC
(In reply to comment #11)
> >> this is a burning need for this featureI meant, how is "this" [a separate namespace for 
tables and charts] a burningneed for "this feature" [a table editor]?

The way I understand Omegatron's proposal is that each table functions as a sort of template, 
and is edited like a template, using the table editor.  I'm personally not completely certain 
why they need to be entwined, but in Omegatron's proposal, they are.  I heartily agree that the 
feature is needed, and if a 'Table:' namespace is needed for the feature, then I support the 
table namespace as well.
Comment 13 Ævar Arnfjörð Bjarmason 2005-09-28 23:11:29 UTC
This bug should be split in two, a request for a table namespace (presumably at
Wikimedia web sites) and for a table editor (part of the MediaWiki software) are
two entirely different things.
Comment 14 Omegatron 2005-09-29 00:15:01 UTC
(In reply to comment #12)
> The way I understand Omegatron's proposal is that each table functions as a
sort of template,

More like an image.  Just like content in the Image: namespace has its own
unique image-related functionality, content in the Table: namespace would have
different functionality, too.  This first step is just to create the namespace
and get it working, then advanced editor features can be added to it in later
steps, as listed in the roadmap on the discussion page.

> and is edited like a template, using the table editor.  I'm personally not
completely certain 
> why they need to be entwined, but in Omegatron's proposal, they are.  

Maybe they don't.  Feel free to suggest alternate ideas.  I can't envision how
else it would work, though.

(In reply to comment #13)
> This bug should be split in two, a request for a table namespace (presumably at
> Wikimedia web sites) and for a table editor (part of the MediaWiki software) are
> two entirely different things.

This is only a request for:

* The namespace
* The functionality to include tables from this namespace in articles with the
same markup as images

Table editors and such will come later.  If these two requests are independent,
then split it.  I would think they are intertwined, though.  Maybe it should be
done on a test wiki first to play around with the idea?
Comment 15 Rowan Collins [IMSoP] 2005-09-29 03:48:25 UTC
I think the thing that's got people in a knot here is that what's being asked
for is *not* just a namespace - adding a new namespace, in general, really is a
trivial configuration option.

What's actually being asked for here, though, is a new built-in namespace with
its own special magic properties - as a start, the ability to do "extended image
syntax" style linking, but eventually a different Edit page (the table editor)
as well. That is *not* trivial, and really needs someone committed to carrying
this through further to be worthwhile.
Comment 16 Omegatron 2005-09-29 04:42:18 UTC
(In reply to comment #15)
> What's actually being asked for here, though, is a new built-in namespace with
> its own special magic properties - as a start, the ability to do "extended image
> syntax" style linking,

Exactly.

> but eventually a different Edit page (the table editor)
> as well. That is *not* trivial, and really needs someone committed to carrying
> this through further to be worthwhile.

Not really.  Each step is independent and useful on its own.  Moving tables to
their own namespace with image-like functionality is a significant improvement
and keeps the messy table code out of the articles, allowing tables to be
treated like images, as they are in print, etc.  Table editors and such are not
part of this bug, though they can be built off of it, and not necessarily the
ultimate goal.
Comment 17 Omegatron 2005-09-29 06:05:46 UTC
Created attachment 920 [details]
Currently you see this
Comment 18 Omegatron 2005-09-29 06:06:50 UTC
Created attachment 921 [details]
To insert a table in an article, you will use this instead
Comment 19 Omegatron 2005-09-29 06:08:19 UTC
Created attachment 922 [details]
and in the future will see this when editing tables
Comment 20 Karl Dickman 2005-09-29 17:44:16 UTC
Okay, now I understand exactly what Omegatron means.  I wholely endorse this proposal, 
especially as a path to a table editor.
Comment 21 Matthew W. Jackson 2006-08-31 19:02:18 UTC
I fully back this idea, and would love to see an editor specifically for tables.

If a specific table-editor is out of the question, there could be support for
uploading/downloading the tables as spreadsheets.  You could start with simple
CSV support, but seeing as it's lacking many features that Wiki-tables support,
something like ODS might be better (at least if you ignore advanced formatting
and calculations).
Comment 22 SJ 2007-04-20 08:01:05 UTC
Another small vote of support.  SJ
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-20 20:54:59 UTC
This is not the proper place to discuss the issue.  Please don't post anything
further until there has been a discussion on the English Wikipedia and the
proposal has consensus support.  No configuration changes will normally be made
without either community consensus or direction by Jimbo/the Board/other
important people.  Proposals like this are vanishingly unlikely to attain the
latter criterion.

If/when consensus is unequivocally reached, you can reopen this request.
Comment 24 Omegatron 2007-04-20 21:04:52 UTC
(In reply to comment #23)
> This is not the proper place to discuss the issue.  Please don't post anything
> further until there has been a discussion on the English Wikipedia and the
> proposal has consensus support.

It was discussed before the feature request was even filed:

http://en.wikipedia.org/wiki/Wikipedia:Proposal_for_intuitive_table_editor_and_namespace#Opinion_poll
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-20 21:26:48 UTC
Sorry, my bad.  I'll leave it up to the shell users to decide whether they want
to implement this based on a 10-month-old poll, then.  It probably wasn't
noticed for so long because it wasn't keyworded shell . . . although shell
requests haven't been batch-fulfilled for a couple of months now.
Comment 26 Omegatron 2007-04-20 21:53:00 UTC
(In reply to comment #25)
> Sorry, my bad.  I'll leave it up to the shell users to decide whether they want
> to implement this based on a 10-month-old poll, then.  It probably wasn't
> noticed for so long because it wasn't keyworded shell . . . although shell
> requests haven't been batch-fulfilled for a couple of months now.

Notably, this was proposed before templates were invented, and they've fixed
some of the problems that this was supposed to address (infobox clutter,
navigation templates, etc.)  I still think it would be a valuable addition,
though, especially if it led to a dedicated table editor someday.  A newer
poll/discussion would be good.
Comment 28 Antoine "hashar" Musso (WMF) 2007-05-05 14:34:42 UTC
I am closing this bug. Please open a NEW one once the community
has made a choice.
Comment 29 Omegatron 2007-05-05 14:48:12 UTC
(In reply to comment #28)
> I am closing this bug. Please open a NEW one once the community
> has made a choice.

Can you explain what that means?  Everyone on the proposal page in 2005 supports
it, and everyone on the village pump thread I started a few weeks ago supports
it.  If filing a feature request isn't how things like this are done, then what is?

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive#Splitting_out_tables_into_their_own_namespace
Comment 30 River Tarnell 2007-05-08 14:27:40 UTC
created "Table" namespace on enwiki.
Comment 31 Hymyly 2007-05-08 15:14:25 UTC
We were only nine days away from the two-year anniversary of this thread. Thanks a lot River, now 
we've got nothing to celebrate. ;)
Comment 32 Omegatron 2007-05-08 15:22:59 UTC
Ok, but should we start another feature request for the image syntax
functionality?  I was considering it part of this one.
Comment 33 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-08 16:34:59 UTC
That's a separate issue in terms of the backend, which is very unlikely to be
fixed anytime soon, unless someone feels like centralizing and totally revamping
the namespace code (see bug 9845).  You'll have to use template syntax for the
indefinite future.
Comment 34 Steve Sanbeg 2007-05-08 17:03:28 UTC
Does this also need to be added in the backup scripts?  It would break the
pages-articles dump, which only includes article namespaces, if this isn't
included there.
Comment 35 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-08 17:14:18 UTC
Good point.  How is that dealt with?  It should also be a content namespace, if
it isn't now.
Comment 36 Omegatron 2007-05-08 17:39:30 UTC
(In reply to comment #33)
> That's a separate issue in terms of the backend, which is very unlikely to be
> fixed anytime soon, unless someone feels like centralizing and totally revamping
> the namespace code (see bug 9845). 

Well that's kind of the whole point; treating tables like images, with similar
syntax and formatting.

> You'll have to use template syntax for the
> indefinite future.

Hmm..  Kind of pointless by itself, but if it opens the door for other changes,
I guess it's a start.
Comment 37 Brion Vibber 2007-05-08 17:48:51 UTC
No such issues.
Comment 38 Omegatron 2007-07-26 15:15:29 UTC
(In reply to comment #37)
> No such issues.

Hmm?

(Reopening as the namespace no longer exists.)
Comment 39 JeLuF 2007-08-29 15:54:30 UTC
As long as there's no code to handle magic tables, there's not much sense in setting up a namespace for it. Request the namespace as soon as the code is there.
Comment 40 Omegatron 2007-08-29 16:16:33 UTC
(In reply to comment #39)
> As long as there's no code to handle magic tables, there's not much sense in
> setting up a namespace for it. Request the namespace as soon as the code is
> there.

This request is for both the code and the namespace, as described in the link.

"Tables should be treated like images, with the same markup [[Table:test|right|framed|This is a test table]] and similar options: ..."
Comment 41 JeLuF 2007-08-29 20:27:15 UTC
changed categorization, keywords and description to reflect that this is not a request for just another namespace but a feature request.
Comment 42 Karl Dickman 2007-08-29 23:00:29 UTC
Admittedly, the usefulness of a new namespace without the accompanying code is only limited.  Still, it at least has the advantage of moving huge, intimidating table code from the articles and into their own namespaces.  Perhaps others have different priorities, but I believe that such a separation of concerns would be useful at least enough to justify the new namespace.
Comment 43 Omegatron 2007-08-30 03:40:57 UTC
(In reply to comment #42)
> Still, it at least has the advantage of moving huge,
> intimidating table code from the articles and into their own namespaces. 

And transcluding them as templates?
Comment 44 Karl Dickman 2007-08-30 03:50:19 UTC
(In reply to comment #43)
> (In reply to comment #42)
> > Still, it at least has the advantage of moving huge,
> > intimidating table code from the articles and into their own namespaces. 
> 
> And transcluding them as templates?
> 

The functionality of the table namespace as I've always understood it is more similar to the image namespace than the template namespace.  For example, it is quite reasonable to upload an image that is used in only one article, but quite unreasonable to create a template for use in only one article.  Moving tables from the articles into templates is probably little different than moving them into a table namespace in terms of server load, but there are semantic differences that are, to my mind, important.

The way I think of tables and images versus template calls is this: when I type {{Template}}, I want the content of [[Template:Template]] to be transcluded to that page.  When I type [[Image:ImageName]] or [[Table:TableName]], I see that as a kind of placeholder or shorthand.  Just like when typesetting a book: first you set aside space for images and tables, then you insert the text, then the tables and images.  I concede that the difference between a template and a placeholder is something that other's may consider unimportant.  All I would like to say is that the distinction matters to me.
Comment 45 Omegatron 2007-08-30 04:02:59 UTC
(In reply to comment #44)
> The functionality of the table namespace as I've always understood it is more
> similar to the image namespace than the template namespace.

That's the idea for this request, yes, but just adding the new namespace doesn't provide that functionality, which is what JeLuf was talking about.  You'd still have to transclude the tables by typing {{Table:TableName}} until the special handling was added, making it kind of pointless for now (just use a template like {{Table of whatever}} instead).

> The way I think of tables and images versus template calls is this: when I type
> {{Template}}, I want the content of [[Template:Template]] to be transcluded to
> that page.  When I type [[Image:ImageName]] or [[Table:TableName]], I see that
> as a kind of placeholder or shorthand.  Just like when typesetting a book:
> first you set aside space for images and tables, then you insert the text, then
> the tables and images.

Yes. That's what this request is all about (and eventually allowing the download/upload of spreadsheet files, online editing of tables without editing wiki markup, etc.)  I tried to break it up into concrete, independent steps on the proposal page, of which this request is only step 1, but they're telling me that step 1 is actually made up of two steps:

1a. Special handling for the Table: namespace that enables markup like [[Table:Tablename|right]]
1b. The Table: namespace itself

And 1b is kind of pointless without 1a, which is apparently not going to happen anytime soon.
Comment 46 Patrick Warren 2010-06-22 08:58:08 UTC
update redirects
Comment 47 Chris McKenna 2013-08-06 21:03:52 UTC
Will there still be a need for this when VisualEditor gets WYSIWYG editing of tables?

That will remove the need to edit the wikicode for the table, but it will still leave the code seen when using the source editor. So I guess it depends on what the aim of this request is?
Comment 48 Quim Gil 2014-04-17 05:30:26 UTC
Even if this discussion might had some sense nine years ago, I would venture to say that creating namespaces for Tables: and Charts: would go against the current plan of enhancing VisualEditor with plugins for tables, charts, etc.

Proposing a WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links