<p>The move to structured data is going rather well, but there are a few limitations  because there isn't complete isolation between data and presentation and processing. For example, the VisualEditor infobox insertion tool doesn't simply add the infobox markup, it also adds any content in the template, unlike the gallery which simply inserts agallery, and nothing else. </p><p>So my questions are: </p>

1. Are there plans to complete separate the markup (e.g. portable infobox), e.g. in a separate subpage?
2. Are there plans to remove the [[category:]] meta data from the page?
3. Any thoughts on making it easier to import content from other pages (not transclusion), e.g. csv, xml, json, etc ?

<p>For question 3 the rationale is that even within a single wikia, many pages depend on the same content that may be used to populate tables, infoboxes, navboxes, or even be re-used to generate regular content for a page. I do this myself, and have seen many wikias, including paradise-bay, and runescape doing this too. </p><p>Another idea that I came across is the concept of VE visual templates that could be automatically portable, thoughts?: </p>

• https://phabricator.wikimedia.org/T114454
• http://community.wikia.com/wiki/Thread:608403

<p>Edit: </p><p>Also any thoughts on replacing "{{PAGENAME}" with something like, many infoboxes use this: </p>

<infobox >

<title currentTitle=true/>

<p>Answer time! Going to answer Dessamator first, who asked: are we planning to move categories, infoboxes and other similar into separate "continers"?  </p> <p style="line-height:inherit;">Yes, that is certainly the direction we want to head in! In fact, we've already stared this process in a small way with the Help:Flags.</p> <p style="line-height:inherit;">For the benefit of other readers, let me explain why this is useful.</p> <p style="line-height:inherit;">For one thing, it clearly separates content from, well, not content. Categories are not content, they are information <i>about</i> the content (they say: "This page is about a character"), flags are also <i>about</i> the content (they say: "This page is incomplete" or "This page is a spoiler"). So separating them lets you focus on the writing when you want to write, and on "aboutness" when you want to categorize or flag things.</p> <p style="line-height:inherit;">Secondly, separating all the "other stuff" from the article space opens up a ton of awesome possibilities. Imagine if you could re-categorize a set of 100 pages with one click (note: not promising a feature here, don't quote me on this part ;)) or re-use information, say the damage of Frostmourne, from its infobox on many pages, while the data sits in just one, in the infobox -- no need to update stuff all over the place! This is almost exactly what you hinted at, Dessamator, and yes -- we're heading that way.</p> <p style="line-height:inherit;">Here's the deal, though: before we engineers can really & truly start working on the awesomeness hinted at above, we need to understand what all (or at least most) pages are made of. That's what portability is ultimately about: understanding what the pieces of a page are. We can't separate pieces out if our code doesn't know what they are, because then we it won't know where to put each piece, so to speak.</p> <p style="line-height:inherit;">That's why We (and this is the big Wikia-the-company + Wikia-the-community We) need to move toward portability first. Using Portable Infoboxes and Template Types are great first steps for any community, and we'll have more advice for you soon on the nitty-gritty of getting to 100% portability.</p>

<p>Now for the simplified infobox title idea that Dessamator mentioned. It's a good idea, with one small tweak: </p> <div dir="ltr" class="mw-geshi mw-content-ltr"><div class="xml source-xml">

<span class="sc3"><span class="re1"><infobox<span class="re2">></span></span></span>
<span class="sc3"><span class="re1"><title</span> <span class="re2">/></span></span>
<span class="sc-1"><!-- other infobox stuff goes here --></span>
<span class="sc3"><span class="re1"></infobox<span class="re2">></span></span></span>

</div></div> <p>We try not to add new "words" like currentTitle to the Infobox markup if we can get away with it. This would be one more thing to remember for humans and understand for machines. ;) </p><p>There is a small reason why we may not want to have this shorthand, though: it is a little bit more difficult to understand what is going to happen. One of our main goal for the new Infobox markup was to make it more understandable to everybody, easier to read and modify. Making the markup more explicit by always requiring <default> means you write a bit more, yes, but it's also less "magical" and you don't have to remember "If the title tag is empty, then {{PAGENAME}} will be used". </p><p>So: we'll chat about it and see which way we lean here. Stay tuned. ;) </p>

<p>OK, additional questions, Tor: We've been compiling some ideas for how we think Portable elements could work in the future. We know that you've got some good things cooking and have done some great work so far. This wikia and Wikia collaborate quite a bit on this project. No promises, but are we headed in similar directions with Portable Elements (beyond Infobox) and Infobox Syntax Improvement? </p>

<p>Next question: Tabbers are great for images, but some wikias (Final Fantasy Wiki for example) use them in data items or at the top-level (multiple Infoboxes, effectively, with different information per game platform). Tabbers, admittedly, don't work well on mobile. What are some things that you might suggest for organizing these in a portable way, or can Tabber be expanded in the future for others in this situation? </p>

<div class="quote"><i> <p>FishTank wrote: One of the most requested features is CSS "class" in <data>. Is this a feature under consideration OR is there a reason why it might not be implemented in future syntax? </p> </i></div>
<p>Good question! We're thinking hard about how best to enable customising the look & feel of infoboxes. </p><p>The trick here is we want styling to be easy first, and versatile & powerful second. I hope you'd agree that adding classes would do the trick for goal #2 but not quite for #1. </p><p>The option is still on the table, though we want to think hard on this before we add it, to make sure the decision doesn't come back to haunt us. </p><p>Rather than add a band aid now, we'd like to solve the styling problem completely and efficiently. </p><p>Hope that makes sense. :) </p>

<div class="quote"><i>FishTank wrote:
OK, additional questions, Tor: We've been compiling some ideas for how we think Portable elements could work in the future. We know that you've got some good things cooking and have done some great work so far. This wikia and Wikia collaborate quite a bit on this project. No promises, but are we headed in similar directions with Portable Elements (beyond Infobox) and Infobox Syntax Improvement?</i></div>
<p>Yes, on some things. :) I'll call out two great examples here. </p><p>Infobox input validation (what you called "masks") is something that has come up in discussions for later phases (once most big wikias are mostly portable). We know this would save admins a lot of sweat and tears trying to get all their infobox to use the same way of displaying the height and weight of all of Spider-men in Marvel's many universes, as well as helping standardise many other types of information. </p><p>Data types would also come in handy for some of the between-page data sharing I wrote about above. </p><p>Personally, I can't wait to get to do these, and more, but again: portability comes first. </p><p>Also, no promises, these things could change and we don't quite have plans for 2016 yet. ;) </p>

<p>I think the template types idea is really good, and while I understand it was a MVP it could have carried with it a bit of the "wow" factor : </p>

• Stats, stats, stats - where are they used, how many times, what types?
• Showing wrong templates in certain namespaces - e.g. Template:Documentation should never be transcluded into main namespace.

<p>Some future thoughts: </p>

• Template control, tracking when wrong (meta-)templates are transcluded in the main space , or requiring certain templates for certain namespaces, e.g. if Theme was a namespace, all pages in it could require infoboxes.
• Template dependency tree - this would help identify extremely badly nested templates that affect performance.
• Showing portable templates - templates that are portable, e.g. portable infoboxes, flags, etc.

<p>I'm also wondering if perhaps future tools could employ the power of LUA to augment them? </p><p>If you look at this page and module:xp you'll note that the "portable" infobox is entirely generated by lua, and I can easily make it change from a three column style to 2 columns by changing a single parameter. Doing that with wikitext or a regular portable infobox is incredibly painful.  </p><p>Anyway, thanks for all the answers and thorough explanations! </p>

<div class="quote"><i>Dessamator wrote:</i></div>
<p></p><blockquote>I'm also wondering if perhaps future tools could employ the power of LUA to augment them? <p>If you look at this page and module:xp you'll note that the "portable" infobox is entirely generated by lua, and I can easily make it change from a three column style to 2 columns by changing a single parameter. Doing that with wikitext or a regular portable infobox is incredibly painful. </p></blockquote> Ideally, since the <infobox> parser is a tag extension it would invoke the Lua from inside it, not use Lua to generate extension tags. BUT, <format module="" function="function(args)"> would be helpful.

<div class="quote"><i>FishTank wrote:
<div class="quote">Dessamator wrote:</i></div>
<p></p><blockquote>I'm also wondering if perhaps future tools could employ the power of LUA to augment them? <p>
If you look at this page and module:xp you'll note that the "portable" infobox is entirely generated by lua, and I can easily make it change from a three column style to 2 columns by changing a single parameter. Doing that with wikitext or a regular portable infobox is incredibly painful.  </p></blockquote> Ideally, since the <infobox> parser is a tag extension it would invoke the Lua from inside it, not use Lua to generate extension tags. BUT, <format module="" function="function(args)"> would be helpful. </div> <p>It isn't a particularly good idea to add lua code directly in templates because it may become confusing for non-developers. Using <format module="modulename"> is a good approach, although it still wouldn't be able to do what module:xp does because the format tag is nested. Anyway that is an edge case that doesn't need to be supported. </p>