<div class="quote"><i> <p>Dessamator wrote: The infoboxbuilder and its modules are an exception to the general rule. I don't particularly see the point of adding a redirect page for them. So maybe the "external" parameter should make use of Module:Links and determine whether to make it local or external automatically. </p> </i></div>
<p>I'd rather remove Module:InfoboxBuilder, Module:HF, Module:InfoboxBuilderView, and Module:LuaInfobox from the list, since they're all deprecated now. </p>

<div class="quote"><i>DarthKitty wrote:
<div class="quote"> <p>Dessamator wrote: The infoboxbuilder and its modules are an exception to the general rule. I don't particularly see the point of adding a redirect page for them. So maybe the "external" parameter should make use of Module:Links and determine whether to make it local or external automatically. </p> </i></div>
<p>I'd rather remove Module:InfoboxBuilder, Module:HF, Module:InfoboxBuilderView, and Module:LuaInfobox from the list, since they're all deprecated now. </p> </div> <p>They are not necessarily deprecated since the parser function still exists. It is just another way of doing the same thing, although we could remove them because they are explained and linked to from the main infoboxbuilder page.  </p>

<p>If copying modules from wikipedia becomes a thing, I'd be inclined to copy documentation over from the point it was ported, but have a permalink back to the original, i.e. ?oldid=123456 so maintainers can tell what's changed. I'd do the same for the module code itself to be honest. </p>

<div class="quote"><i>Cqm wrote:
If copying modules from wikipedia becomes a thing, I'd be inclined to copy documentation over from the point it was ported, but have a permalink back to the original, i.e. ?oldid=123456 so maintainers can tell what's changed. I'd do the same for the module code itself to be honest.</i></div>
<p>So you mean that we copy the whole module's documentation here based on the revision id? That sounds reasonable, I'm not sure the wayback machine will always work anyway. </p><p>The question is where do we actually put the link, in our list of lua modules or in the module documentation page itself, or both? </p><p>As far as code is concerned, I typically attribute the code in a revision summary using the revision's old-id. In many cases we have to change the original module so that it works  because of things that Wikia's scribunto version lacks.  </p><p>It will be interesting if/when we get an API for these infoboxes,  it will make it rather easy to query them and update a lot of information automatically, so we don't have to duplicate documentation or links. </p>

<div class="quote"><i> <p>Cqm wrote: If copying modules from wikipedia becomes a thing, I'd be inclined to copy documentation over from the point it was ported, but have a permalink back to the original, i.e. ?oldid=123456 so maintainers can tell what's changed. I'd do the same for the module code itself to be honest. </p> </i></div>
<p>That only works if the module was ported from another wiki. For example... </p>

• I ported Module:Inspect from kikito/inspect.lua on GitHub
• Dessamator ported Module:Json from http://json.luaforge.net/

<p>How do you think we should deal with modules like those two? </p>

<div class="quote"><i>DarthKitty wrote:
<div class="quote"> <p>Cqm wrote: If copying modules from wikipedia becomes a thing, I'd be inclined to copy documentation over from the point it was ported, but have a permalink back to the original, i.e. ?oldid=123456 so maintainers can tell what's changed. I'd do the same for the module code itself to be honest. </p> </i></div>
<p>That only works if the module was ported from another wiki. For example... </p>

• I ported Module:Inspect from kikito/inspect.lua on GitHub
• Dessamator ported Module:Json from http://json.luaforge.net/

<p>How do you think we should deal with modules like those two? </p> </div> <p>Interestingly enough, both those modules have been implemented in scribunto's libraries by the WMF. So depending on Wikia those could be eventually be deprecated along with their documentation: </p>

•  mw.dumpObject -> module:inspect

• mw.text.jsonEncode -> Module:Json

<p>Right now Lua is probably very low priority, so I do understand why they aren't likely to implement the json library. But there is probably little to no coding required to simply backport  mw.logObject or mw.dumpObject. </p><p>If the site with the documentation uses https, then we may need to document it here, and also if the original documentation is very complex. Those two modules you linked have simple documentation, but module:date for example is very long and complex. </p>

<p>In terms of backporting, I'd rather get Module:CheckTypeMulti and the rest of the frame object first. I know Wikia's busy with security and mobile ATM, but it would probably take ~10 minutes to add that stuff. *grumble grumble* </p>

<p>Anyway, I've finished providing simple documentation and testcases for all modules I created or imported from other wikis. The rest I'm leaving to their authors or importers, because some seem like demo modules but could conceivably be improved. </p><p>Edit: </p><p>WOW, Template:Script Install is incredibly disorganized and confusing. Might as well rewrite it as a lua module. </p>

<p>I created / forked Module:Codedoc and updated it to be used to document a couple of modules. It works really well, and might be a good idea to incorporate into the style guide. Either using its syntax or potentially the syntax from LDoc: </p><p>https://github.com/stevedonovan/LDoc </p><p>The two documentation tools are very similar so it should be possible to either do a quick find and replace, or adopt Codedoc, which frankly looks way simpler and easier to localize because it doesn't use language specific symbols (for the most part). </p>

<div class="quote"><i>DarthKitty wrote:
In terms of backporting, I'd rather get Module:CheckTypeMulti and the rest of the frame object first. I know Wikia's busy with security and mobile ATM, but it would probably take ~10 minutes to add that stuff. *grumble grumble*</i></div>
<p>Just saw this again, you're in luck, they've recently backported frame:getTitle(). The only one left that is particularly useful for debugging anyway, in my opinion, is frame:newChild , and possibly making the frame object work in the lua console. Although I'm not holding my breath for any such miracles. </p>