Last modified: 2014-04-17 05:30:26 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...
*** Bug 1447 has been marked as a duplicate of this bug. ***
Product: should probably be "MediaWiki"
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?
(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.
how difficult is it to add a namespace?
Please note that this is the first step in roadmap for implementing a Table Editor. This is a burning need for this feature.
>> 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?
There's a learning curve for tables in wikisyntax, but "a burning need"?
(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.
> 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.
>> 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]?
(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.
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.
(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?
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.
(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.
Created attachment 920 [details] Currently you see this
Created attachment 921 [details] To insert a table in an article, you will use this instead
Created attachment 922 [details] and in the future will see this when editing tables
Okay, now I understand exactly what Omegatron means. I wholely endorse this proposal, especially as a path to a table editor.
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).
Another small vote of support. SJ
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.
(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
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.
(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.
Attempt to start a new discussion: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Splitting_out_tables_into_their_own_namespace
I am closing this bug. Please open a NEW one once the community has made a choice.
(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
created "Table" namespace on enwiki.
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. ;)
Ok, but should we start another feature request for the image syntax functionality? I was considering it part of this one.
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.
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.
Good point. How is that dealt with? It should also be a content namespace, if it isn't now.
(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.
No such issues.
(In reply to comment #37) > No such issues. Hmm? (Reopening as the namespace no longer exists.)
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.
(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: ..."
changed categorization, keywords and description to reflect that this is not a request for just another namespace but a feature request.
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.
(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?
(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.
(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.
update redirects
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?
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.
