Commons talk:Lua

Ok so now that we are actually using Lua and Module namespace. We should start thinking about standards (policies?) related to it. Many of the standards can be borrowed from other projects, but even then we need to link to them. As I see it we need:

1. external documentation standards
2. internal documentation and style guide
3. testcases, sandbox, unit testing, etc.
4. categorization ?
5. editnotices
6. other?

I would propose to follow EN Wikipedia standards, whenever possible, and import modules whenever possible. --Jarekt (talk) 19:45, 25 November 2013 (UTC)[reply]

I would agree with following en.wikipedia standards, but I am not clear with what should go to the /doc page. Perhaps a list of callable functions with a short description ? For many things, it seems simpler and more maintainable to just add internal comment (and, at least with a little experience, Lua code is easier to browse than a template page). --Zolo (talk) 21:17, 25 November 2013 (UTC)[reply]

1. Some examples: Module:HtmlBuilder, Module:HTMLParser, Module:Fallbacklist, en:Module:Admin board archives, de:Module:URLutil (Vorlagenprogrammierung - a page in project namespace explaining how to use the module in templates and from other lua modules, Diskussionen - talk page about the module; translations of the first, tests). At Commons, I do currently miss an edit button or link for the documentation.
2. While reading style guide, for example, I observed that the first sentence is wrong. Code editor now indents with a tab, after a MediaWiki developer and volunteer found it counter-productive that MediaWiki's styleguide demanded a tab-indent and Code editor used four spaces; continuing with Avoid extraneous whitespace when calling a function seems to be also problematic to me as the MediaWiki-styleguide (for JS and PHP) requests that. I would be opposed to any whitespace convention; the only criterion should be readable code, including not too long lines, avoiding fanciness when possible in favour for intuitive-constructions. If possible, I would even ask for an automated formatting of Lua-code to some conventions but wasting volunteer's time and cluttering revision histories for caring about some obscure whitespace rules is not the proper way to go, I believe. Something that should be done by a machine, if at all.
3. Unit testing is a good point. I would go further and would like to see some central registry where tests of the most critical modules are summarized. This way it is done with MediaWiki's JavaScript tests. I could imagine that each module could provide a standard API for testing and that we just have to drop-in the module name into that registry. Note that not all modules and functions are intended being {{#invokeed.
4. by type (program code or data), whether contains functions that can be invoked by templates or just utility, by functionality/topic, what else would be useful?
5. Yes. As soon as we have something to write-in there. -- Rillke^(q?) 21:20, 25 November 2013 (UTC)[reply]

1. For me the external code documentation should be similar as our template documentation, may be even reuse {{TemplateBox}} or parts of it. It Should be fill-the-form style and should document functions and their purpose, input/output, dependencies, and how to call them. Internal documentation should be similar and should also include hints to others as what is going on, purpose of variables, etc. I am not looking for stiff requirements, but rather an agreement on "best practices". External documentation can be edited by anybody while internal one should not be changed much. Rillke, thanks for the examples - they are great.
2. I guess en:Wikipedia:Lua style guide should be kept up to date. And I agree that "style" improvements should be considered as "minor" edits done while other important edits are done. I am all for automated formatting of the code, and have no opinion on tabs vs. spaces. But I would like to adopt a "best practices" for size of the indentation and number 4 from en:Wikipedia:Lua style guide seems like a reasonable amount.
3. Sounds good, but I think we should start by importing current Wikipedias standards
4. Wikipedia modules are mostly uncategorized, and the only exception seem the be template-added-categories. I guess the categories have to be added to the documentation pages with <includeonly>, as in it:Modulo:Linguaggi/man. There is en:Category:Wikipedia modules and equivalents in many other wikipedias.
5. I copied Template:Editnotices/Namespace/Module from en-wiki and started adding hooks like MediaWiki:Editnotice-829, but I do not think it is working yet. We should at least have links to create, see and edit documentation, sandbox and test pages.

--Jarekt (talk) 14:11, 26 November 2013 (UTC)[reply]

I think we could systematically review how wikis treat modules and code. Some kind of table would be great. And, perhaps we, wikidata:, and meta: (all multilingual) could accept and adopt common standards. -- Rillke^(q?) 17:09, 26 November 2013 (UTC)[reply]

I noticed varying standards for naming internal function (accessible from other Lua code) as oppose to external functions (accessible from templates through {{#invoke}}). We have :

1. Module:Linguistic with internal function conj and external function conjfromWiki
2. Module:Math with internal functions like _order or _precision and external functions like order or precision. Module:Navbox and most other modules copied from en-wiki follow the same convention.
3. others?

I would like to propose to adopt en.wiki convention (#2). --Jarekt (talk) 15:04, 5 December 2013 (UTC)[reply]

I had used "fromWiki" because I thought I had seen a "fromLua" somewhere, and I thought in many cases, the Lua version should be the one with the simplest name (I would think we should avoid calling the "conj" or "langSwitch" from other templates like {{Conj}} and {{LangSwitch}}), but I am fine with solution 2 if it is to preferred solution on en.wikipedia. --Zolo (talk) 19:07, 5 December 2013 (UTC)[reply]

We recommend against using Creative Commons licenses for software. - I would be glad if we could encourage some endorsement of real software licenses for compatibility. Not that I expect that something really usable outsite Wikimedia being produced on-wiki but one never knows. -- Rillke^(q?) 17:09, 26 November 2013 (UTC)[reply]

So what do you propose? Add in the comments or in the /doc pages a license section with GPL, LGPL and/or some other "real software licenses". --Jarekt (talk) 14:48, 5 December 2013 (UTC)[reply]

CC0? --SamB (talk) 01:24, 3 March 2014 (UTC)[reply]

Please add! May be copied over to Meta?

I applied Module:UnitTests to several modules I am familiar with and added them to Category:Testcases modules. Also created Commons:Lua/Testing, a single page with all unit testing subpages. It can serve as "central registry where tests of the most critical modules" are done. Please add similar testcases to as many modules as we can. In addition to testing I find them very useful for understanding capabilities of the modules. --Jarekt (talk) 15:48, 4 December 2013 (UTC)[reply]

We should use the native HTML library instead.

The following modules need to be converted (example):

• Module:Navbar
• Module:Navbox

--Ricordisamoa 20:29, 24 February 2014 (UTC)[reply]

Our copy is just a clone of the English version. You might want to suggest it there and if they correct than copy it here, or we can change our version, but I am not sure we have people here who are familiar with it and who are willing to maintain it afterwards. --Jarekt (talk) 20:45, 24 February 2014 (UTC)[reply]

@Ricordisamoa and Jarekt: The enwiki versions of these have been updated. Jackmcbarn (talk) 16:00, 3 December 2014 (UTC)[reply]

@Jackmcbarn and Ricordisamoa: Copy&Past from enwp is enough? The Modules are highly used. --Steinsplitter (talk) 10:20, 21 December 2014 (UTC)[reply]

I talked with Ebraminio on irc, synchronizing the modules from enwiki shouldn't break nothing. Therefore i copied the Modules from enwiki to commons.  Done --Steinsplitter (talk) 11:20, 21 December 2014 (UTC)[reply]

Next week's software update, which will be deployed December 9th, will change the way that mw.text.unstrip works. It will kill general strip markers instead of unstripping them. Nowiki strip markers will still be unstripped as normal. This change will break the following modules:

• Module:Background
• Module:MyUploads
• Module:Page
• Module:Page/sandbox

The following other modules also use unstrip, but this change shouldn't break them:

• Module:Diff
• Module:POTY
• Module:TemplateBox
• Module:TemplateBox/test

@Darklama, Rillke, and Cmuelle8: Ping, as each of you are the author of at least one of the modules that will need to be fixed. Please let me know if you have any questions on how to fix these modules. Jackmcbarn (talk) 15:58, 3 December 2014 (UTC)[reply]

The code editor has long been somewhat broken for Commons modules, but now I can't even edit Module:Linguistic. Does anyone have an idea ? -Zolo (talk) 09:13, 11 August 2016 (UTC)[reply]

The code editor did not work for me for more than a year. I do all the editing in Notepad++ and cut and paste the code. --Jarekt (talk) 12:06, 11 August 2016 (UTC)[reply]

Here it's not just the code editor that does not work, I can't even edit or paste anything. --Zolo (talk) 13:00, 11 August 2016 (UTC)[reply]

Zolo that is probably because the page is protected. Save your code in Module:Linguistic/sandbox and use {{Edit protected}} or ping me. --Jarekt (talk) 18:05, 11 August 2016 (UTC)[reply]

@Jarekt: oh sure I had forgotten that. I have created a sandbox module, where I have made function local as they should be, and created and added a small function, can you port them to the module ? -Zolo (talk) 13:55, 13 August 2016 (UTC)[reply]

 Done--Jarekt (talk) 11:44, 17 August 2016 (UTC)[reply]