ui2t5v002 wrote:

*** Bug 1447 has been marked as a duplicate of this bug. ***

gangleri wrote:

Product: should probably be "MediaWiki"

christoffer1989 wrote:

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?

ui2t5v002 wrote:

(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.

asdf wrote:

how difficult is it to add a namespace?

brian.klug wrote:

Please note that this is the first step in roadmap for implementing a Table Editor. This is a burning need for
this feature.

robchur wrote:

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?

jporter wrote:

There's a learning curve for tables in wikisyntax, but "a burning need"?

ui2t5v002 wrote:

(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.

brian.klug wrote:

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.

robchur wrote:

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]?

ingoolemo wrote:

(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.

avarab wrote:

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.

ui2t5v002 wrote:

(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?

rowan.collins wrote:

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.

ui2t5v002 wrote:

(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.

ui2t5v002 wrote:

Currently you see this

Attached:

ui2t5v002 wrote:

To insert a table in an article, you will use this instead

Attached:

ui2t5v002 wrote:

and in the future will see this when editing tables

Attached:

ingoolemo wrote:

Okay, now I understand exactly what Omegatron means. I wholely endorse this proposal,
especially as a path to a table editor.

TheMuuj wrote:

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

ayg wrote:

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.

ui2t5v002 wrote:

(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

ayg wrote:

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.

ui2t5v002 wrote:

(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.

ui2t5v002 wrote:

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.

ui2t5v002 wrote:

(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

river wrote:

created "Table" namespace on enwiki.

christoffer1989 wrote:

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. ;)

ui2t5v002 wrote:

Ok, but should we start another feature request for the image syntax
functionality? I was considering it part of this one.

ayg wrote:

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.

ssanbeg wrote:

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.

ayg wrote:

Good point. How is that dealt with? It should also be a content namespace, if
it isn't now.

ui2t5v002 wrote:

(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.

ui2t5v002 wrote:

(In reply to comment #37)

No such issues.

Hmm?

(Reopening as the namespace no longer exists.)

jeluf wrote:

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.

ui2t5v002 wrote:

(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: ..."

jeluf wrote:

changed categorization, keywords and description to reflect that this is not a request for just another namespace but a feature request.

ingoolemo wrote:

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.

ui2t5v002 wrote:

(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?

ingoolemo wrote:

(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.

ui2t5v002 wrote:

(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.

ptw007 wrote:

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.

Re-reading this bug, it does seem that events have overtaken it.

Basic table editing is now simple with visual editor, and as I understand it what can't be done currently will happen at some point (see e.g. T54180 for bg-color and other formatting).

Given this, there wont in most circumstances be a need to transclude the table from outside the current page, but where there is this can be done with a page in the template namespace (which is how the route diagram templates work currently).

The only other aspect of this task I think is the comment "and eventually allowing the download/upload of spreadsheet files". Which sounds like a good idea, but would be better discussed as a separate task I think (as it isn't really the focus of this request, and has been overlooked since 2007).

So in summary, I support @Qgil's suggestion to WONTFIX this.

The only other aspect of this task I think is the comment "and eventually allowing the download/upload of spreadsheet files". Which sounds like a good idea, but would be better discussed as a separate task I think (as it isn't really the focus of this request, and has been overlooked since 2007).

T120452: Allow structured datasets on a central repository (CSV, TSV, JSON, GeoJSON, XML, ...)