Wikipedia talk:Lua

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:Lua requests)
Jump to navigation Jump to search
 WP:Lua
Project
 WT:Lua
Project talk
 Help
 
 To do
 
 Resources
en: m: mw: external
 

Module request[edit]

I request that the code at Module:Sandbox/BrandonXLF/2 should be moved to Module:Module link. The purpose of this module is to create modules links. It is planned to be used on {{ml}}, {{mli}}, {{mlix}} and {{mlx}}. The advantage of the module is the error message (can be helpful) and it let's you use as many parameters are you need. BrandonXLF (t@lk) 18:36, 25 November 2018 (UTC)

@BrandonXLF:  Done, although to my knowledge you should have been able to do this yourself (bar some technical error). Jc86035 (talk) 16:21, 5 December 2018 (UTC)
@Jc86035: The reason he couldn't do this is an editing restriction banning him from template and module namespace. {{3x|p}}ery (talk) 19:29, 21 February 2019 (UTC)

List of parameters as one parameter[edit]

I have a general design/coding question which I hope someone here could shed some light on. I've seen several table modules which work in the style of 1 module for the table-header and 1 module for the table-rows with corresponding templates. I was wondering, is there a way for a template to accept a list of parameters as one parameter? So for example, instead of calling the table-row template for each row and passing it the parameters |a=, |b= and |c=, have a |row= parameter that gets the row parameters |a=, |b= and |c=? --Gonnym (talk) 08:05, 13 December 2018 (UTC)

It's not possible to do exactly what you suggest—you can't bundle parameters a=one, b=two, c=three together except by a redesign. I rewrote {{Football manager history}} because it used separate templates for the header, footer, and each row with the result that the crazy navboxes seen, for example here generated more than 2 megabytes of "Post‐expand include size". The template now calls Module:Football manager history to do all the work. The module has to parse each row to extract the implied row parameters. That can be messy and fragile although it has worked well in this reasonably simple case. Another example of a module doing a bunch of work to parse data is Module:Val/units which uses a giant text string to define required units, one per line, rather than a traditional Lua table. It turns out that parsing a giant string can be more efficient than using nested tables, and can be easier for editing the wikitext which was the motivation for Val. If you have a specific example I'll have a look. Johnuniq (talk) 08:44, 13 December 2018 (UTC)
Gonnym, Template:Routemap uses a similar approach, and Module:TemplatePar sends in the entire list of parameters as an "=" delimited list. so, it really depends on what you know about the values of |a=, |b= and |c=. for example, if you know they will never contain a "/" then you could use that as a delimiter, for example see Module:Sports rbr table. Frietjes (talk) 12:24, 13 December 2018 (UTC)
Module:Chart uses similar approach, passing multiple values as delimited list. by default the delimiter is colon, ":", but the module allows using any other delimiter, including "=", by supplying a "delimiter" parameter (this is so, in case someone needs to us the colon as part of one of the values). to use =, one would have to call the module with | delimiter = = |. personally, since mw introduced JSON parser, i find it more beneficial to bundle everything in a single json string and pass it as is. the module can then call something like local paramTable = mw.text.jsonDecode(args['your param name']). peace - קיפודנחש (aka kipod) (talk) 23:35, 27 December 2018 (UTC)

Requested move 16 December 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: Moved all except RexxS: Pppery: I cannot use pageswap.js nor perform a manual round-robin move on this particular one because of technical restrictions owing to the fact the page already exists and is in the Module namespace. However, as consensus has been determined, please feel free to submit a technical request for the remaining one and somebody with a higher power level can come along and do it. (closed by non-admin page mover) SITH (talk) 02:03, 27 December 2018 (UTC)



– Centralize personal lua modules under Module:Sandbox {{3x|p}}ery (talk) 23:27, 16 December 2018 (UTC)

(Module:Sandbox/Angr pukhlya and Module:Sandbox/Shah Jahan Ishaq already exist, so the modules that I would otherwise move there are given a ? target. ) {{3x|p}}ery (talk) 23:27, 16 December 2018 (UTC)

  • Pinging @Angr pukhlya, Lotje, MjolnirPants, RexxS, and Shah Jahan Ishaq:. {{3x|p}}ery (talk) 23:29, 16 December 2018 (UTC)
    • There's also a number of pages under Module:Module:Sandbox/* and Module:User:* , so not everything is under Module:Sandbox/* , but yes, it's good to move those listed from where they currently are. -- WOSlinker (talk) 23:45, 16 December 2018 (UTC)
      • What should be done about naming conflicts (the cases I marked with a ?)? {{3x|p}}ery (talk) 23:48, 16 December 2018 (UTC)
        • Make sure all links are in the style of "Module:Sandbox/<username>/<module name>" - if there is a naming conflict and the author has not commented here with a name, then just add "1" and "2". --Gonnym (talk) 12:14, 21 December 2018 (UTC)
  • Oppose Sandboxes are useful for testing and trying out content. It makes sense for modules that are tests to be subfolders of Module:Sandbox. However, when it comes to other content, a registered user has their own userspace for essays, demos, etc. in addition to their user sandboxes for development work, but there is no user-modulespace. I'm quite happy to do development work in a subfolder of Module:Sandbox, but for completed projects and mature code, there is no user space where they can reside. I see reason why Module:Username should not serve that purpose for a user's completed work. What benefit is there in moving them? All that happens is that there going to be conflicts between Module:Username and Module:Sandbox/Username when the user already makes use of these titles for different purposes. In my case, I use Module:Sandbox/RexxS as a demonstration for students of Google Code-In, not as repository for completed work, which I use Module:RexxS to store. --RexxS (talk) 00:46, 17 December 2018 (UTC)
  • Support - the documentation at Module:Sandbox does indeed say to use the /sandbox/username/modulename naming style. For RexxS's specific scenario I really don't know what to say, but it really doesn't seem that using Module:sandbox/RexxS/completed/name or Module:sandbox/RexxS/name directly would change what you're trying to achieve, while still keeping the module namespace clean. --Gonnym (talk) 11:16, 17 December 2018 (UTC)
    • The documentation at Module:Sandbox makes it clear that "It exists to provide a convenient pseudo-namespace for code testing, and I'm all in favour of that – and I make regular use of it with about 30 demo and test modules in that namespace. What it does not imply is that finished, functional code, which is in use in areas of the wiki should be kept in the Module:Sandbox pseudo-namespace. This RM is being used to generate a naming policy for usable, completed modules by the back-door. I would be normal on wiki that such a decision should be taken as a result of informed, well-advertised debate. The alternative to having a Module:Username space would be to break out each individual function into main Module space once it is working and in use. I don't see that such a course would do anything but increase the proliferation of small modules, and ironically do the opposite of keeping the module namespace clean. --RexxS (talk) 15:30, 21 December 2018 (UTC)
      • I thought about making a comment below, but if it is ready for use, it shouldn't be kept under one's 'namespace' (e.g. Module:RexxS) or in the sandbox 'namespace' (e.g. Module:Sandbox/RexxS), it should be published with an appropriate name so people can find and use it. We can worry about where specific functions live later if we decide there are too many small modules. --Izno (talk) 17:03, 21 December 2018 (UTC)
  • Support. The subspace of Module:Sandbox is the module equivalent of the user space and if editors would like to make distinctions between different kinds of user modules they can use subsubspaces of that, as suggested by Gonnym. Just a note: given that moving a module doesn't leave a redirect, the moves have the potential to break things elsewhere (Rexx's comment above seems to suggest these might not all be on-wiki); therefore it seems best that when this discussion is closed, all the contributors are notified on their talk pages and given a grace period of a couple of weeks before the moves are performed, in case there are workflows they need to change. – Uanfala (talk) 11:53, 17 December 2018 (UTC)
    • No, the subspace of Module:Sandbox is the module equivalent of the user sandbox space as its documentation makes clear ("a convenient pseudo-namespace for code testing"). The off-wiki use in my case would be confined to Google Code-In, which has now ended for 2018, giving almost 12 months to sort out external incoming links before GCI 2019, so off-wiki use won't pose me a problem. On the other hand, I assume that whoever moves a module is responsible for fixing on-wiki all of the incoming #invoke instances which it will break? --RexxS (talk) 15:30, 21 December 2018 (UTC)
      • I think the relevant distinction is not between sandbox and everything else, but between modules that are ready for general consumption, and modules that aren't (regardless of whether they are mere experiments or not). – Uanfala (talk) 17:04, 21 December 2018 (UTC)
      • I wonder if someone shouldn't get a bot together or be on call for module name/function renaming so that we can make replacements. That seems like a broader issue. --Izno (talk) 17:08, 21 December 2018 (UTC)
  • support, easier to keep track of modules which are not ready for broader use. Frietjes (talk) 12:07, 21 December 2018 (UTC)
  • I support efforts for consistency, so I support these moves in the general case. --Izno (talk) 15:17, 21 December 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Requested move 27 December 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: consensus not to move the modules at this time, per the discussion below, which might also imply that the discussion above should be revisited at some point. Dekimasuよ! 08:27, 3 January 2019 (UTC)


– Centralize personal lua modules under Module:Sandbox (I nominated this one separately from the previous batch as these follow a consistent convention as Module:User:..., whereas the other batch didn't) {{3x|p}}ery (talk) 03:21, 27 December 2018 (UTC)

Module:Sandbox/WOSlinker already exists. {{3x|p}}ery (talk) 03:21, 27 December 2018 (UTC)
I've deleted both of my pages as they are no longer needed. -- WOSlinker (talk) 12:00, 27 December 2018 (UTC)
Pinging participants of previous discussion: @RexxS, WOSlinker, Gonnym, Izno, Uanfala, and Frietjes: {{3x|p}}ery (talk) 03:23, 27 December 2018 (UTC)
Pinging users whose modules I requested be renamed: @AmazingJus, Anomie, Awesomemeeos, Dcoetzee, DePiep, Doc Taxon, Dragons flight, Fred Gandt, Happy5214, Kephir, Ketil3, Legoktm, Lesser Cartographies, Martijn Hoekstra, Mr. Stradivarius, Mr rnddude, Mxn, Plagiat, TelComNasSprVen, Vuh, and Yair rand: {{3x|p}}ery (talk) 03:27, 27 December 2018 (UTC)
Discussion in Archive1 (2013), inconclusive. -DePiep (talk) 15:59, 27 December 2018 (UTC)
  • Oppose My WikiWork module in particular is not a sandbox. It is a module which backs a report in my userspace. -happy5214 03:53, 27 December 2018 (UTC)
    Do you oppose the renaming/moving of all the listed modules or only of the one you mentioned? Fred Gandt · talk · contribs 07:07, 27 December 2018 (UTC)
    I oppose renaming modules which are not sandboxes as sandboxes. The module I mentioned is such an example. Most of the modules listed are clearly sandboxes. I just wish the nominator had distinguished between user modules which are clearly sandboxes and those which possibly implement userspace templates, instead of a blanket move request. -happy5214 07:50, 27 December 2018 (UTC)
  • Weak support as long as everything works correctly afterwards; standardization is good IMO, but not at the expense of functionality, simplicity or efficiency. I should note though that several of the modules I created for various tests and demos should have been speedily deleted by now and were up unto this flurry of activity blanked. I never could figure out how to request their deletion due to the appropriate procedure (application of {{db-author}}) not working so I just blanked them and hoped that the next time they were noticed, they'd be killed. Purely to give a heads up - Module:User:Fred Gandt/sandbox/ chessDemo/move, data2, data3, data4 and data5 should be deleted not moved. Fred Gandt · talk · contribs 07:07, 27 December 2018 (UTC)
    @WOSlinker: could you help me out with deleting the unneeded Modules mentioned above? As I say above, I can't figure out how to add the usual template to submit them to the speedy deletion queue. Fred Gandt · talk · contribs 12:21, 27 December 2018 (UTC)
    @Fred Gandt: I've deleted them. -- WOSlinker (talk) 12:54, 27 December 2018 (UTC)
    Thank you WOSlinker :) Fred Gandt · talk · contribs 14:27, 27 December 2018 (UTC)
    @Fred Gandt: the easiest way I've found to ask for deletion of a user module is to put the {{db-author}}) on the talk page of the module, along with a polite note reminding the admin to delete the associated module page as well. It works most of the time. --RexxS (talk) 15:23, 27 December 2018 (UTC)
    Good idea RexxS; thanks :) Fred Gandt · talk · contribs 15:48, 27 December 2018 (UTC)
  • I don't really care what it's named as long as I have some place to put my sandbox/experiments. To me it seems pretty logical to have them under the pseudo userspace but whatever works for everyone else is fine by me... Legoktm (talk) 08:24, 27 December 2018 (UTC)
  • Oppose. Existing name is (also) a clear reference to user space, strongly stating that it is under control of the user. (Of course techically not possible in straight user space). Removing this indicator could leave others to think one can freely edit. Which is not exactly so for user space. OTOH, one could check for such name-constructs used in mainspace, which is undesirable. -DePiep (talk) 10:42, 27 December 2018 (UTC)
I add: name pattern "Module:Foo/sandbox" allows to automatically detect the sandbox page (and so to adds box message 'This is a sandbox etc.' in top) This is nicely similar with template space. The pattern is also used in {{Sandbox other}} e.g. to prevent categorising the /sandbox page). Examples: Module:Track gauge vs. Module:Track gauge/sandbox. Canonising the proposed pattern "Module:Sandbox/..." breaks this. And complementary, it does not allow to recognise the userpage-intention or -owner. So the new names will always pop up as weirdly used pages without explanation for the page's status or background. Expect lots of "MfD, because not used" claims, requiring to be argumented by the Username. -DePiep (talk) 16:21, 27 December 2018 (UTC)
  • Support - per the documentation at Module:Sandbox, which does indeed say to use the /Sandbox/<username>/<modulename> naming style, and per previous the just closed discussion in which consensus has agreed with the move to a more standard naming convention. If anyone has any issues, the most simple solution would be to add a sub-page of /Sandbox/<username>/completed/<modulename>. --Gonnym (talk) 10:58, 27 December 2018 (UTC)
    Then let's change that page instruction. As I described above, that pattern breaks (automatic) recognition of both ".../sandbox" page and "User:Example/subpage". Sandboxes are not an (informal) subnamespace as "Module:Sandbox" suggests, they are subpages in a 'userspace' or of a specific (parent) module. Parallel behaviour as with template space or userspace is best. --DePiep (talk) 16:25, 27 December 2018 (UTC)
    I'm not sure the "break" is actually really an issue. Why would you even categories a work-in-progress sandbox module? But even if that were a legitimate issue, {{Sandbox other}} does a simple check if two values are equal - changing that to check for Module/Sandbox shouldn't be any harder. --Gonnym (talk) 17:04, 27 December 2018 (UTC)
    No need to say "break" (i.e., use "so-called" quoting). It actually breaks stuff. -DePiep (talk) 22:15, 27 December 2018 (UTC)
    Then could you explain again what it breaks because I might have missed it as I only saw you mentioning the sandbox else template, which isn't an issue. --Gonnym (talk) 10:18, 28 December 2018 (UTC)
    Proposal breaks:
    1. Detecting sandbox pages: pagename ends with /sandbox. Used in {{Sandbox other}}, {{documentation}} (adds top box message, adds links to subpage .../sandbox page (create/edit) in bottom box). 1b. And introduces difference with Templatespace usage.
    2. Detecting module is in pseudo-userspace: per pattern Module:User:... (no examples of automated usage known to me). Module:Sandbox/FooBar/... is ambivalent wrt having a username.
    3. Proposed changes into name pattern Module:Sandbox/<Username>/... says it is a sandbox, which may not be the case (examples mentioned in this thread).
    -DePiep (talk) 14:51, 28 December 2018 (UTC)
    @Gonnym: Let's be absolutely clear about this. (1) The documentation at Module:Sandbox has no more force than any user-created essay. There is no policy yet created for naming modules beyond what can be extrapolated from WP:AT. (2) The documentation at Module:Sandbox actually states

    It exists to provide a convenient pseudo-namespace for code testing ...

    Please name your experimental modules in the following format

    Note the use of the words code testing and experimental modules. Of course it makes sense to test code and write experimental modules in sandbox space; but there is no sense in keeping working code in sandbox space, or even in a sub-subspace of sandbox space. The alternative of splitting out the 20+ working functions from Module:RexxS into 20+ separate modules just to satisfy some misguided sense of "tidiness" is laughable. The whole point of modules is that they allow multiple functions with something in common to be kept in a single container. The thing that the functions in a user: module have in common is that they are being maintained by the same editor, and that seems a perfectly good reason to me – at least until such time as the number of Lua programmers increases to the point where modules are no longer being maintained by a single editor. --RexxS (talk) 23:18, 27 December 2018 (UTC)
    Well since we don't have anything else, and that documentation has not been changed from the moment it was written 5.5 years ago and just now stood a RM, it is pretty compelling argument, even if you don't think so. Just to be clear, I don't technically mind a change of guideline, but if I have to choose between wild-west style creations (as can be seen from the nominated modules) and a naming style which bothers a few people, I'll go with the naming style. --Gonnym (talk) 10:18, 28 December 2018 (UTC)
    Have you considered the possibility that the suggestion in the documentation has remained since its inception because it's sensible advice for test code and experimental modules? – which is what the pseudo-namespace is supposed to contain. However, it says nothing about how we should name code which is no longer under test and modules which are not experimental, so it's unlikely a closer is going to find that relevant, let alone "compelling". All of the nominated modules have the consistent style Module:User:<Your User Name> and subfolders, completely analogous to the proposed renaming scheme, so are we swapping one "Wild-West style" naming convention for an equally "Wild-West" one? You're right on one point: when it comes to naming conventions for userspace modules, we don't have anything. --RexxS (talk) 13:01, 28 December 2018 (UTC)
    As has been shown by the list above, the above aren't all completed code, and in-fact most are sandboxes. Also finding a consistent style is not a new "Wild-west", it's the exact opposite. --Gonnym (talk) 13:20, 28 December 2018 (UTC)
    It would be more accurate to say that the above aren't all sandbox code, and in fact most are completed code. The style Module:User:<Your User Name> is consistent. You're the one who called it "Wild-West". --RexxS (talk) 14:10, 28 December 2018 (UTC)
    No, it would not be accurate to say that, I've spot checked a few and they were all "test" modules. Also, it's pretty amazing looking at this list and calling it consistent, when the whole list itself is the one which is inconsistent with all other modules (and even in this specific list, you have some using Module:<user>/sandbox). End note, since you seem to want to WP:BLUDGEON your point here, I ask you politly to stop commenting on my posts as I'm not going to reply. --Gonnym (talk) 14:33, 28 December 2018 (UTC)
    Yes, it would be accurate to say that, and my spot checks come to the opposite conclusion to yours. There's no problem with moving sandbox modules to Module:Sandbox/ space, but that isn't what this proposal aims to achieve, and you should recognise that and oppose changes that confuse userspace with modulespace for no good reason. The list entries all start Module:User:<user>, not Module:<user> as you claim, and the only thing that's amazing is that you don't seem to realise that everybody can see that. If you don't want to enter into a discussion, that's fine with me, but it does beg the question what you expected when you joined in the debate in an RfC. --RexxS (talk) 20:37, 28 December 2018 (UTC)
    This isn't a RfC, this is a RM which is attracting an atypically large amount of comments. {{3x|p}}ery (talk) 04:59, 29 December 2018 (UTC)
    Oh, but it is. You're trying to make policy by the back-door, and you shouldn't be surprised if the policy gets debated. Read the header for this RM and you'll see that it's a discussion, not just a parade of !votes. --RexxS (talk) 10:38, 29 December 2018 (UTC)
    I never claimed it wasn't a discussion, but the term "RfC" has a formal meaning referring to a specific type of discussion, which this isn't. By "atypically large number of comments", I meant "more comments than RMs usually receive", and didn't indicate I was surprised. {{3x|p}}ery (talk) 16:01, 29 December 2018 (UTC)
    Yes, an RfC is a request for comment, and that's the formal way we make policy. When you tried to create policy by using a RM, you really ought to have expected it to turn into an RfC, rather than a typical RM that decides requests based on already established policy. There is no policy specifically on titling modules; and certainly no policy that would underpin your requested move. --RexxS (talk) 18:04, 30 December 2018 (UTC)
  • Oppose. I'm not in favor of moving SuggestBot's two module pages into a sandbox, partly because as far as I know they've been tested and worked, and I'm hoping to find time in 2019 to start using them. The previous discussion about moving modules into the sandbox makes a reference to them being ready to be used broadly, but I'm not sure I understand how that would be determined for a user space module like this one? It seems to allude to some kind of approval process, which goes counter to the idea of user space modules, but maybe I'm reading too much into it? Cheers, Nettrom (talk) 13:44, 27 December 2018 (UTC)
  • Oppose the general migration of "Module:User:…" to "Module:Sandbox/…" per the arguments that they're not all "experiments". Those that are or were could be moved without my complaint, but those that would be more correctly categorized as "user-space" modules should either remain as named or I suggest a "Module:Userspace/…" prefix for tidiness, continuity and clarity. Speaking purely of my own that remain in the above list; they're not something I'm likely to work on again for a while but they're also not temporary experiments and given the ability to create them in my user-space, I would have. It wouldn't make sense for them to be recategorized as "sandboxy". Fred Gandt · talk · contribs 05:51, 28 December 2018 (UTC)
  • Oppose The pseudo-namespace Module:Sandbox performs a perfectly good service in providing a space for test code and experimental modules. The pseudo-namespace Module:User: provides an equally convenient and useful space for modules containing collections of functions that are now tested and working, but which would not benefit from being split into multiple tiny modules directly in the Module: namespace. These modules are invariably maintained by a single user, and labelling them by that username makes sense. What does not make sense is to move fully functional code into sandbox space. --RexxS (talk) 13:01, 28 December 2018 (UTC)
  • don't understand the value of suggested move. why is Module:Sandbox/Username/blah better than Module:User:Username/blah? looks like busywork to me. peace - קיפודנחש (aka kipod) (talk) 15:04, 28 December 2018 (UTC)
  • Oppose As noted above, moving Module:User:Jimbo/example to Module:Sandbox:Jimbo/example would have zero benefit. Some good reasons for the former have been given and they override any desire to impose "neatness". Johnuniq (talk) 22:59, 28 December 2018 (UTC)
  • Oppose I think "Module:User:Anomie/..." is more appropriate for "module userspace" purposes than the "Module:Sandbox/..." being pushed here. Anomie 15:55, 29 December 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Lua pattern issue with en dash[edit]

I'm trying to create a pattern to capture two sets of digits group that can be separated by various means such as "11-12", "11, 12", "11 / 12", "11 <hr /> 12".

This works for most of these:

local _, _, num1, num2 = episodeNumber:find("(%d*)%s*%p*%a*%s*%p*%s*(%d*)")

However I ran into two problems. The first was, why does

episodeNumber:find("(%d*)%s*.*%s*(%d*)")

or even

episodeNumber:find("(%d*)%s*.*%s*(%d*)")

not work? The documentation says that "%." is all characters, so shouldn't that catch them?

The second was, that when I tried "11–12" (En dash) did not work. Does %p not cover it as well? If it's possible, would appreciate some insights into this as I'm really confused. Thanks. --Gonnym (talk) 20:54, 9 January 2019 (UTC)

ndash is a unicode character so to find it use mw.ustring.find('12–23', '%p')
It might be better to look for single character separators and failing that look for <hr /> or <hr/>:
num1, num2 = mw.ustring.match (episodeNumber, '(%d+)%s*[%-–,/]%s*(%d+)') or episodeNumber:match ('(%d+)%s*<hr */>%s*(%d+)')
Trappist the monk (talk) 21:09, 9 January 2019 (UTC)
That actually doesn't quite work; the or operator only operates on the first of the two captures. So this instead:
num1, num2 = mw.ustring.match (episodeNumber, '(%d+)%s*[%-–,/]%s*(%d+)')
if not num1 then
	num1, num2 = episodeNumber:match ('(%d+)%s*<hr */>%s*(%d+)')
end
Trappist the monk (talk) 21:49, 9 January 2019 (UTC)

The cheat's way of extracting two (and only two) unsigned integers is:

    num1, num2 = episodeNumber:match('^%D*(%d+)%D+(%d+)%D*$')
  • %d+ matches one or more digits
  • %D* matches zero or more non-digits (including en dash)

The above works well for the given inputs but would be trickier if signed integers or numbers with decimal digits were wanted. Using (%d*) is no good because it matches zero or more digits so would often end up as an empty string. %. is an actual dot (period, full stop). Your last pattern includes .* which matches zero or more of any character (actually, any byte since using standard Lua functions), as many as possible. That will match everything up to the end of the string. You would have better luck with .- which matches zero or more of any byte, as few as possible. Johnuniq (talk) 01:30, 10 January 2019 (UTC)

Thanks both, helped a lot! --Gonnym (talk) 09:19, 10 January 2019 (UTC)

Followup question - I've ran into a problem if the range is more than 2. If it is possible, I'd like to catch the start and end of the range. So my current code is this:

		local num1
		local num2
		if (episodeNumber:match('(%d+)%s*<hr */%s*>%s*(%d+)')) then
			num1, num2 = episodeNumber:match('(%d+)%s*<hr */%s*>%s*(%d+)')
			--divider = "<hr />"
		else
			num1, num2 = mw.ustring.match(episodeNumber, '(%d+)%s*[%s%-–,/&]%s*(%d+)')
			--divider = "–"
		end

I also have an alphanumeric block for figures like A, B, or A1, B1:

				if (episodeNumber:match('(%w+)%s*<hr */%s*>%s*(%w+)')) then
					num1, num2 = episodeNumber:match('(%w+)%s*<hr */%s*>%s*(%w+)')
					--divider = "<hr />"
				else
					num1, num2 = mw.ustring.match(episodeNumber, '(%w+)%s*[%s%-–,/&]%s*(%w+)')
					--divider = " – "
				end

What I'm hoping is possible is that if the range is 1-2-3 (or 11-12-13-14, A-B-C, A1-B1-C1) to make it 1-3. --Gonnym (talk) 08:09, 11 January 2019 (UTC)

You might try this:
if (episodeNumber:match('^(%w+)%s*<hr */%s*>%s*(%w+)$')) then
	num1, num2 = episodeNumber:match('^(%w+)%s*<hr */%s*>%s*(%w+)$')
	--divider = "<hr />"
elseif (episodeNumber:match('^(%w+)%s*<hr */%s*>.-<hr */%s*>%s*(%w+)$')) then	-- 3 or more elements
	num1, num2 = episodeNumber:match('^(%w+)%s*<hr */%s*>.-<hr */%s*>%s*(%w+)$')
	--divider = "<hr />"
elseif mw.ustring.match(episodeNumber, '^(%w+)%s*[%s%-–,/&]%s*(%w+)$') then
	num1, num2 = mw.ustring.match(episodeNumber, '^(%w+)%s*[%s%-–,/&]%s*(%w+)$')
	--divider = " – "
else
	num1, num2 = mw.ustring.match(episodeNumber, '^(%w+)%s*[%-–,/&].-[%-–,/&]%s*(%w+)$')	-- 3 or more elements
	--divider = " – "
end
The ^ and $ anchors prevent false matches. This same can be accomplished by reordering to that the three-or-more-element tests are done first. You can also do mw.text.split() on separator patterns; if number of items in the resulting table is greater than 1 then take the first and last items and set divider to a string that matches the split pattern.
Neither of these solutions contemplate the possibility of episodeNumber separated by both %s*[%s%-–,/&]%s* and %s*<hr */%s*>%s*.
Trappist the monk (talk) 11:55, 11 January 2019 (UTC)
Thanks again, worked great! --Gonnym (talk) 17:03, 11 January 2019 (UTC)

If various kind of separator are equivalent, a good approach is to replace all possible separators with something simple, before splitting. This is fast and works en dashes (the last line) and more. Example:

episodeNumber = episodeNumber
    :gsub('%s*<hr%s*/?%s*>%s*', '-')
    :gsub('%s*–%s*', '-')

After the above, split episodeNumber on hyphens. Johnuniq (talk) 00:49, 12 January 2019 (UTC)

I like that, I'll test it out. Thanks! --Gonnym (talk) 09:45, 13 January 2019 (UTC)

Patterns: cannot use literal pipe character %|[edit]

When using a pattern, it seems impossible to use the pipe-symbol as a literal. I expect the pattern to recognise %| as the literal character to recognise.

A. {{#invoke:string|match|s=[[Main_page|wikihome]] |pattern=(%[) |plain=false |replace=%1}}
B. {{#invoke:string|match|s=[[Main_page|wikihome]] |pattern=(%|) |plain=false |replace=%1}}
A. [
B. Lua error: malformed pattern (ends with '%').

Anyting I am missing? -DePiep (talk) 10:40, 22 January 2019 (UTC)

This does not have to do with Lua but MediaWiki's interpretation of the wiki code. Use {{!}}. AFAIK you don't have to escape the pipe, by the way, since it's not a magic character in Lua patterns. Nardog (talk) 10:45, 22 January 2019 (UTC)
OK, that solves it (and indeed, writing (%{{!}}) gives same result):
C. {{#invoke:string|match|s=[[Main_page|wikihome]] |pattern=({{!}}) |plain=false |replace=%1}}
C. |
-DePiep (talk) 10:51, 22 January 2019 (UTC)

Requested move 28 January 2019[edit]

(Whoever moves Module:Italian provinces/data, please do remember to update Template:ProvinciaIT)

 Done, but for future reference the right venue was WP:RMTR. {{3x|p}}ery (talk) 01:22, 9 February 2019 (UTC)
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: Moved all but Module:Italian provinces/data as it's template-editor protected, I'm lighting up the admin batsignal for help moving that. (closed by non-admin page mover) SITH (talk) 17:37, 8 February 2019 (UTC)



– Move these modules to subpages of the modules that use them to make them not meet G8. (I am open to some flexibility on the new name, but these seem like the most logical start. {{3x|p}}ery (talk) 22:58, 28 January 2019 (UTC)

  • I put this here because (a) it affects two different modules and there's no reason to put it on one's talk page over the other and (b) neither Module talk:Data nor Module talk:Region topic exists. {{3x|p}}ery (talk) 23:00, 28 January 2019 (UTC)
    • What is the rationale for moving some to subpages of Module:Data and others under Module:Region topic? I'm sure there is an historical reason but in practical terms for future maintenance, why not have all data pages under Module:Data? FWIW I checked Special:PrefixIndex for the existing pages minus "/data". There are no pages with those prefixes other than the ones listed above. For people puzzling over what's happened in the future, it would be nice if there were a list of TfDs for the (I assume) deleted parent modules. Johnuniq (talk) 01:26, 29 January 2019 (UTC)
      3/4 of them never had parent modules (just US, Italy, and... London?) Primefac (talk) 02:06, 29 January 2019 (UTC)
      @Johnuniq: Because some of the modules are invoked via Module:Region topic and others of them are invoked via Module:Data. For instance Template:Europe topic/sandbox 2 has {{#invoke:Region topic|main | data = Module:Europe topic/data}}, so Module:Europe topic/data belongs as a submodule of Module:Region topic, whereas the non-"XXX topic" modules are invoked by passing their name as a parameter to Module:Data {{3x|p}}ery (talk) 02:33, 29 January 2019 (UTC)
      • That makes sense, thanks. However, now I'm wondering why at least some of them appear to be unused (US, Asia, Africa). Johnuniq (talk) 02:45, 29 January 2019 (UTC)
        • The latter two have been used in the respective template sandboxes ({{Asia topic/sandbox}} and {{Africa topic/sandbox}}), but those have since been overwritten for testing edits to the current non-Lua versions. SiBr4 (talk) 14:28, 31 January 2019 (UTC)
  • Support I created the continent-topic data modules considering them "subpages" of the corresponding templates they were/are to be used in ({{Europe topic}} etc.), despite them being in a different namespace. Moving them under Module:Region topic is probably the best solution; it could be helpful to keep the word "data" in the titles, but I don't oppose the proposed names. I'm not familiar with the other three modules, but it seems sensible to make them subpages of Module:Data, since two of their parent modules were deleted for being redundant to it ([1] [2]). SiBr4 (talk) 14:28, 31 January 2019 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Template:Gcd[edit]

Anyone have any idea what template is Template:Gcd replaced with? It has a few pages still using it. --Gonnym (talk) 08:24, 6 February 2019 (UTC)

Prolog added the "deprecated" notice (diff) so maybe they can explain. I wouldn't have thought there was much use for calculating GCD but perhaps there is a reason somewhere. Johnuniq (talk) 08:39, 6 February 2019 (UTC)
The template simply applies Module:Math#Gcd, so deprecation is questionable.
Answering Gonnym: you can still use the template (legally & correctly), or use the module directly. When someone wants to delete this template, they will have to take care of your usage. -DePiep (talk) 08:46, 6 February 2019 (UTC)
I'm not using it; just doing some housecleaning. If this is a usable template, the deprecation notice should be removed, if it is replaced by a better template, then I'll nominate it for deletion. This limbo state is just strange. I'll wait for Prolog to see if they can shine new information here. --Gonnym (talk) 08:49, 6 February 2019 (UTC)
It seems to have been this post that prompted me to look into the template. I can't remember the details so I'm fine with removing the notice. Prolog (talk) 09:14, 6 February 2019 (UTC)

Proposal to make TfD more RM-like, as a clearinghouse of template discussions[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Templates for discussion#RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions.  — SMcCandlish ¢ 😼  05:21, 27 February 2019 (UTC)

Move request[edit]

Opinions at Template talk:Weather box#Requested move 3 March 2019 would be welcome. I'm posting here because it involves significant refactoring of a couple of modules. Johnuniq (talk) 08:37, 8 March 2019 (UTC)

upload / file determination[edit]

(Not sure where to ask, feel free to redirect me)

The template {{IPAc-en}} offers an "audio" parameter. But no matter how I study the underlying module, I cannot understand how the parameter gets translated to the actual URL for the ogg file.

Let's take an example, from the Supercalifragilisticexpialidocious page. It contains this: {{IPAc-en|audio=Supercalifragilisticexpialidocious.ogg|ˌ|s|uː|p|ər|...}}

How does "Supercalifragilisticexpialidocious.ogg" turn into [1] (which turns the web page to just an audio playback widget).

And how is one supposed to connect this to commons:File:Supercalifragilisticexpialidocious.ogg, which (presumably?) is the same file, now with all relevant details (file history, talk page etc)?

I mean, if I visit the Supercali... page and find the audio, how am I supposed to find the file details (such as who uploaded the file, who is the speaker, and so on).

Completely lost here. Regards CapnZapp (talk) 23:06, 9 March 2019 (UTC)

The module simply calls {{Audio}} to render the audio link, which uses the "Media" pseudo-namespace. Click on the speaker icon to see the file's description. (WP:VPT is usually the optimal place to ask about this sort of thing.) Nardog (talk) 23:15, 9 March 2019 (UTC)
Thank you - will do! And did! CapnZapp (talk) 10:05, 11 March 2019 (UTC)

Location of test cases[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

Not moved. See general agreement that these changes should not be made. There is a possibility as noted by the nom – "I am trying to set a guideline rather than enforce one, but given that the entire substance of the content dispute is about page naming, so RM does seem like the proper venue," – that there is a better venue for this discussion; however, noting the vehemence from other Lua experts on this subject, there seems little hope of making these potentially widely ranging changes part of a guideline. I could be wrong. Kudos to editors for your input, and Happy Publishing! (nac by page mover) Paine Ellsworth, ed.  put'r there  17:37, 25 March 2019 (UTC)


– Talk pages are intended to be for discussion, not for testing Lua modules. {{3x|p}}ery (talk) 02:47, 17 March 2019 (UTC)
This is admittedly an unusual requested move, as I am trying to set a guideline rather than enforce one, but given that the entire substance of the content dispute is about page naming, so RM does seem like the proper venue. For background, see Wikipedia:Edit filter noticeboard#Filter 694 is too strict, which made the move I am requesting possible. {{3x|p}}ery (talk) 02:47, 17 March 2019 (UTC)

Pinging participants in that discussion: @RexxS, Suffusion of Yellow, DannyS712, ToBeFree, and Galobtter:. {{3x|p}}ery (talk) 02:48, 17 March 2019 (UTC)
  • Talk pages are generally intended for use in improving an article. Discussions to that effect take place in the principal talk page. So for [Module:Xyz] the discussion takes place at [Module talk:Xyz] and nowhere else to avoid fragmenting discussion.
    That leaves the talk pages of any sub-pages free for other use.
    Because [Module:] namespace conventionally contains code, and [Module talk:] conventionally contains wikitext, it is convenient to use talk pages such as [Module talk:Xyz/testing] to keep simple wikitext-based tests for [Module:Xyz].
    Sub-pages titled [Module:Xyz/testcases] are conventionally used to hold the code used to generate module test cases that compare standard outputs between the principal module and its sandbox. The results of those comparisons are stored in sub=pages titled [Module talk:Xyz/testcases].
    So I'd like to keep Module:WikidataIB/testcases, Module:Diacritics/testcases, and Module:Alexa/testcases free for the code that generates those comparisons in case I or someone else wants to write them.
    Therefore I use Module talk:WikidataIB/testing, Module talk:Diacritics/testing, and Module talk:Alexa/testcases to keep the testing that I write for the modules that I write, and I'd really rather you didn't fuck about with my work any further.
    You have a compulsion to order everything in the template and module namespace into the way you feel it should be organised, and I'm telling you now that your obsession is causing me to waste far too much time that I would much rather spend creating, improving and testing the code that I write.
    You have made no significant contribution to improving Wikipedia, and your meddling is disruptive to those who are attempting to do that.
    You can't make policy by messing about with page moves, and the discussion to make new policy requires far more notification than pinging a handful of editors.
    Now, I'm going to ask you nicely to pack up this circus of a RM, withdraw it, and keep well away from me and the modules and templates that I curate in future. --RexxS (talk) 03:41, 17 March 2019 (UTC)
    (edit conflict) It's of course the case that the separate discussions shouldn't usually happen on the talk pages of subpages (AnomieBOT even has an approved task to create some of those redirects), but that's irrelevant here. Module:Xyz/testcases pages are conventionally used to test the module at Module:Xyz, which programming language it is in is a meaningless trifle. Unless you want to argue that Module:WikidataIB should have some test cases written in Lua and some in Wikitext (which isn't the case, because the module exports no functions intended to be called from other modules), then the argument of trying to keep the /testcases name free is entirely meritless. And, finally, saying that I have made no significant contribution [sic] to Wikipedia is simply false. {{3x|p}}ery (talk) 04:03, 17 March 2019 (UTC)
  • Oppose wasting time Pppery you know how to do things, so please do them rather than fiddling with complex work performed by others. Wikipedia relies on a collaborative community and mucking around with stuff you barely understand is unhelpful. If RexxS is damaging the encyclopedia, take him to ANI. Otherwise, stop harassing him by mucking around with the great work that he performs. Johnuniq (talk) 03:59, 17 March 2019 (UTC)
    RexxS, Johnuniq, these replies are almost useful but tainted by unnecessary personal attacks. I had seen the ping earlier and just came back to write "+1, why not". Unexpectedly, I received a wall of drama in my face. ~ ToBeFree (talk) 05:38, 17 March 2019 (UTC)
    Poking good contributors (RexxS) is drama, not the above sharp but accurate comments. This pointless move request is just the latest chapter. If some problem can be identified, by all means identify it, but saying that the rules mean that anything that is a test of a module must be in module space is just make-work with no possible benefit for the encyclopedia. As usual, the issues are not concisely explained but as I understand, the outcome would be that certain pages with wikitext would end up in the module namespace and that would baffle most onlookers. Johnuniq (talk) 06:18, 17 March 2019 (UTC)
    The fact that it is possible for wikitext pages to be in module namespace was already decided at Wikipedia:Edit filter noticeboard#Filter 694 is too strict. {{3x|p}}ery (talk) 14:00, 17 March 2019 (UTC)

As far as I can recall, Wikipedia:Lua#Unit testing has always advocated invoking tests from a module talk page. I don't see any compelling reason to go back and change all the module tests that have followed this advice. isaacl (talk) 17:11, 17 March 2019 (UTC)

@Isaacl: That advice was written in 2013. It became possible to have non-Lua pages in module namespace in 2016. Therefore, that advice is not relevant (and, in any case, that advice implies that the testcases are written in Lua, which isn't the case here). Given that test cases for these modules were written in Wikitext, they're more like template test cases (which are both stored and ran as Template:XXX/testcases) than module testcases. {{3x|p}}ery (talk) 18:10, 17 March 2019 (UTC)
Regardless of what you personally believe is relevant today, as I said, I don't see any compelling reason to change past module test cases. If you want to change the advice for new modules going forward, I suggest you start a discussion on this first. isaacl (talk) 18:34, 17 March 2019 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Help at Template:Article history[edit]

I have a request open at Template talk:Article history#DYK subpage parameter. It would appear to be a fairly uncomplicated request, but given my unfamiliarity with Lua, this may not be the case. Any assistance would be much appreciated. Ergo Sum 01:51, 18 March 2019 (UTC)

Emoji module[edit]

Can someone help me create a module that converts alphanumeric emoji codes (e.g. joy) into hex codes for use with {{emoji}}? This would make that template a lot easier to use – for example, you would be able to use {{emoji|joy}} instead of {{emoji|1F602}}. Note that the logic for this module should be fairly simple, but adding all of the emoji codes will be mad work.

Most sites use the emoji codes listed at Emoji Cheat Sheet, the GitHub repository for which is available here. I don't see a license for the emoji code list (if it can be considered eligible for copyright), but I can ask the maintainers to license the list under ISC or similar (or waive database rights). Qzekrom 💬 theythem 02:36, 23 March 2019 (UTC)

There are several sets of emojis available on Commons; see c:Emoji and c:Emoji/Table and I assume that Template:Emoji deals picking which set. The only remaining work is in mapping an emoji name to its hex code. Unfortunately the cheat sheet (and the github repo) doesn't give that mapping. I can see a set of mappings between code and "CLDR short name" at http://www.unicode.org/emoji/charts/full-emoji-list.html, but they don't seem to be the same thing that you're looking at. Are the alphanumeric emoji codes (e.g. joy) standard? If so, is there somewhere that contains a table of equivalence?
In any case, a Lua function to return a hex code from an emoiji name is straightforward. You simply have to create a table of the mapping with the name as the key and the hex code as the value. It would look something like this:
local emotbl = {
	grin   = "1f600",
	beam   = "1f601",
	joy    = "1f602",
	-- and so on ...
	smiley = "263A"
}
local p= {}
function p.emocode(frame)
	local emoname = mw.text.trim(frame.args[1] or "smiley")
	return emotbl[emoname]
end
return p
If you put the code in Module:Emoji, you could then use {{#invoke:Emoji |emocode |the-name-of-the emoji-you-want}} to return the hex code ready for use in {{emoji}}. I could make the whole emotbl table for you from the "CLDR short names" if you wanted to use those. --RexxS (talk) 16:01, 23 March 2019 (UTC)
@RexxS: Sure, thanks! There is a list of the ECS codes and hex codes, which seems to be mostly accurate.
One modification: emocode should return the original string if it doesn't find a match in emotbl. Qzekrom 💬 theythem 20:42, 23 March 2019 (UTC)
Just a note that the list you gave does not have names for emojis which use ZWJ to set color or gender. --Gonnym (talk) 22:10, 23 March 2019 (UTC)
@Gonnym: I thought Template:Emoji handled the set, colour, etc. with separate parameters? Do those have different basic hexcodes? --RexxS (talk) 22:43, 23 March 2019 (UTC)
Color tones and ZWJ were created so there wouldn't be a need to create new Unicode entries for variations. So take raised hand - black for example. It uses "Raised Back of Hand" and "Dark Skin Tone" to create that character. "Man: Blond Hair" uses "Person With Blond Hair" and "Male Sign", combined using ZWJ. (I'm pretty sure about what I just said, but I could be mistaken as this isn't really my field of expertise). --Gonnym (talk) 22:55, 23 March 2019 (UTC)
@Gonnym: The request was for a module to use with Template:Emoji, so I was relying on that template to handle variations.
  • {{emoji | {{emocode|smiley}} | size=24}}&#x 1f603 ;
  • {{emoji | {{emocode|smiley}} | size=24 | theme=noto}}&#x 1f603 ;
  • {{emoji | {{emocode|smiley}} | size=24 | theme=noto 8.0}}&#x 1f603 ;
Before we start worrying about what the module can return, I think we need to get the functionality you want in {{emoji}} first. I don't see anything in the documentation to indicate that {{emoji}} has any capability to handle all the variations you describe. We're stuck with what's available on commons, of course. I don't know how to get all of the images available on Commons at c:Emoji/Table in a consistent manner using {{emoji}}. I can get:
  • {{emoji | 1f9b8-1f3ff-200d-2640-fe0f |theme=twitter | size=24}}&#x 1f9b8-1f3ff-200d-2640-fe0f ;
But not File:Noto Emoji Pie 1f9b8 1f3ff 200d 2640.svg → Noto Emoji Pie 1f9b8 1f3ff 200d 2640.svg
  • {{emoji | 1f9b8 1f3ff 200d 2640 |theme=noto | size=24}}24px
I'm guessing that there's some more coding to do in Template:Emoji to use the "Noto Emoji Pie" set and there needs to be some consistency in file naming on Commons (spaces vs hyphens). --RexxS (talk) 23:51, 23 March 2019 (UTC)
Yeah, it's the base template and files that need work, I was just letting Qzekrom know where his request won't work. --Gonnym (talk) 07:30, 24 March 2019 (UTC)
@Qzekrom: I managed to extract 1221 names (although 32 had no unicode - I left them in as I think they will have codes at some point). I've sorted them alphabetically and put them into the module. Annoyingly, some of the names had hyphens in them, so I can't use the shorthand notation for a key which is a string value, and I've had to use the full notation (["keyname"] = instead of keyname = ).swit
I've also added a demonstration of the reverse lookup function. That's most efficient when you only have one invoke per page, otherwise it's better to generate the inverse table local to the module and simply index into that, as the inverse table will probably be cached for subsequent calls. There are options to separate out the data into a sub-module of its own, but that's not really necessary for a simple application.
  • {{#invoke:Emoji | emocode | smiley}}1f603
  • {{#invoke:Emoji | emoname | 1f603}}smiley
  • {{emoji |{{#invoke:Emoji | emocode | smiley}} }}😃 ;
  • {{emoji |{{#invoke:Emoji | emocode | 8ball}} }}🎱 ;
I've created a convenience wrapper template for Module:Emoji's emocode function, called Template:Emocode. So we can use:
  • {{emocode | smiley}}1f603
  • {{emoji | {{emocode | smiley}} }}&#x 1f603 ;
  • {{emoji | {{emocode | 8ball}} }}&#x 1f3b1 ;
If you find better lists, let me know. --RexxS (talk) 22:43, 23 March 2019 (UTC)
@RexxS: I just added the invoke code directly to {{emoji/sandbox}}. Qzekrom 💬 theythem 23:39, 23 March 2019 (UTC)
I moved the data table into Module:Emoji/data so that it is loaded only once per page rather than with every {{#invoke:}}.
These seem wrong to me:
local emoname = mw.text.trim(frame.args[1] or "smiley")
local emocode = mw.text.trim(frame.args[1] or "1f603")
'smiley' would seem to suggest that all is well yet, used here as an 'error' indicator when frame.args[1] is nil or empty string, is contradictory. I don't speak emoji but surely there is a better face or indicator; if not, then real words should be used. Perhaps though, words should be used because editors expect an emoji, see an emoji, even though its the wrong emoji, and are happy. If they see words where they expect an emoji, they should notice that and fix it.
Trappist the monk (talk) 10:41, 24 March 2019 (UTC)
In this use smiley is a default, not an error. The code could be cleaned up to indicate as such, I suppose. --Izno (talk) 15:33, 24 March 2019 (UTC)
@Trappist the monk: it's really just a matter of personal taste on my part. I had no specification for how {{#invoke:Emoji | emocode }} should behave. You can either treat the lack of a parameter as an error and flag it as such, or assume a default (I picked the "smiley") and return that. I usually prefer the latter, but naturally it could be altered to whatever was wanted. Cheers --RexxS (talk) 22:06, 24 March 2019 (UTC)
@Qzekrom: As the data is now in a separate sub-module, I've demonstrated how we can cheaply generate the reverse lookup table inside the data module. Because mw.loadData() loads the data once per page, the processing is also done only once per page and the main module "sees" the reverse table just as if we had written out the entire reversed data table manually. --RexxS (talk) 22:25, 24 March 2019 (UTC)
@RexxS: Is the reverse table dynamically created if emoname is not used? Qzekrom 💬 theythem 00:05, 25 March 2019 (UTC)
Qzekrom Yes, but before you start worrying about performance, it's taking a few milliseconds of CPU time and 40KB of memory. If you think that nobody will ever want to get the smiley name from the hex code, then you can remove the code that does that, of course, but nobody's going to notice any difference. --RexxS (talk) 00:17, 25 March 2019 (UTC)
@RexxS: Makes sense. For emoji and invocations of emoname, pre-generating the reverse table reduces the time complexity from to . Qzekrom 💬 theythem 00:30, 25 March 2019 (UTC)
Module:Emoji, as it's currently coded, is redundant to Module:Data and should be deleted as such. (ref: Module:London ward populations, Module:Italian provinces, Module:U.S. States, all of which were deleted at TfD) {{3x|p}}ery (talk) 03:04, 25 March 2019 (UTC)
@Pppery: Thanks for pointing this out! Where should the data table be moved? Qzekrom 💬 theythem 03:07, 25 March 2019 (UTC)
@Qzekrom: The convention appears to be Module:Data/Emoji per #Requested move 28 January 2019 above. {{3x|p}}ery (talk) 03:09, 25 March 2019 (UTC)
@Qzekrom: I don't think the module is redundant to Module:Data at all:
  • {{#invoke:Emoji | emocode | smiley}}1f603
  • {{#invoke:Emoji | emoname | 1f603}}smiley
  • {{#invoke:Emoji | emocode }}1f603
  • {{#invoke:Emoji | emoname }}smiley
  • {{#invoke:Data|Module:Emoji/data|smiley}}
  • {{#invoke:Data|Module:Emoji/data|1f603}}
  • {{#invoke:Data|Module:Emoji/data}} → table
It clearly has none of the functionality of Module:Emoji.
@Pppery: I thought I told you to stop fucking about with things you don't understand. --RexxS (talk) 00:06, 26 March 2019 (UTC)
@RexxS: You just have to add emotbl and emorevtbl as params.
  • {{#invoke:Data|Module:Emoji/data|emotbl|smiley}} → 1f603
  • {{#invoke:Data|Module:Emoji/data|emorevtbl|1f603}} → smiley
This is because it's returning p.emotbl.smiley and p.emorevtbl.1f603. Qzekrom 💬 theythem 01:32, 26 March 2019 (UTC)
@Qzekrom: Thanks for the syntax, but that's only part of it. It doesn't seem to have any default handling.
  • {{#invoke:Emoji|emoname}} → smiley
  • {{#invoke:Emoji|emocode}} → 1f603
  • {{#invoke:Emoji|emoname|1=}} → smiley
  • {{#invoke:Emoji|emocode|1=}} → 1f603
  • {{#invoke:Data|Module:Emoji/data|emotbl}} → table
  • {{#invoke:Data|Module:Emoji/data|emorevtbl}} → table
  • {{#invoke:Data|Module:Emoji/data|emotbl|1=}}
  • {{#invoke:Data|Module:Emoji/data|emorevtbl|1=}}
I mean, that's not a crucial problem, it just doesn't seem to me to have the flexibility to handle all the cases that we've been discussing. Why degrade functionality for no gain? --RexxS (talk) 02:05, 26 March 2019 (UTC)
As it happens, the defaults don't work. See test cases. --Izno (talk) 12:04, 25 March 2019 (UTC)
because frame.args[1] is an empty string which counts as true when ORed with 'text'; lua operates left to right so empty string being 'true', the empty string was assigned to emocode or emoname. I hacked the module a bit.
Trappist the monk (talk) 12:51, 25 March 2019 (UTC)
Unfortunately frame.args[1] and mw.text.trim(frame.args[1]) is nil when there's no parameter supplied, so testing it against the empty string fails. I've hacked it a bit further. --RexxS (talk) 00:06, 26 March 2019 (UTC)
this is one case where scribuntu seems (or at least, seems to me...) the wrong choice. as far as i understand, all you need is {{#switch as explained in mw:Help:Extension:ParserFunctions##switch. it's not necessarily "illegal" or "bad" to use scribuntu when you don't have to, but it usually makes the <whatever> less accessible to other editors, than a vanilla template (i believe there are many more wikipedians who are fluent in templating than in "lua-ing"), and, especially in the case of emojis, i'd imagine that ppl will want to add ones the original author left out, so, unless i am missing something, i think you should implement this w/o scribuntu, using "switch" (imagine Template:Emojiji, whose internal code looks something like so):
{{#switch:{{{1}}}
| happy = <code>
| sad = <another code>
... etc. maybe even "| #default = <some default emoji, e.g., "can't understand what you want from me" icon >
}}
you can pass to the switch something other then {{{1}}}, e.g., to make the template case insensitive, so "Happy" and HAPPY will also work, transform the parameter to lowercase, so maybe in the backdoor, scribuntu will participate anyway... peace - קיפודנחש (aka kipod) (talk) 16:56, 26 March 2019 (UTC)
I completely disagree in this case. If anyone is having difficulty in seeing how to add another entry to Module:Emoji/data, then I'd have to question whether they are competent to be editing Wikipedia at all. While we attempt to retain a mystique about modules compared with templates, we're discouraging capable coders from getting started on using Scribunto. The argument that we have more template-coders than Scribunto-coders then becomes self-reinforcing. We should not be acting like the Wizard of Oz, but doing whatever we can to ease potential coders into using Scribunto. Template functions come a very poor second to Scribunto for solutions to all but the most trivial of problems; in this case, the job of doing the reverse lookup is simple using Scribunto, a nightmare using templates. It's almost 2020 and it's time we stopped trying to turn the clock back to the 2000s. --RexxS (talk) 17:31, 26 March 2019 (UTC)
Agree 100%. No one today would design the template language system we currently use it is archaic, even barbaric. The right way is assume users are intelligent and capable instead of fighting to maintain a dark ages of unenlightenment, which is self-reinforcing. -- GreenC 18:33, 26 March 2019 (UTC)