Wikipedia talk:Lua Archive 8

This is an archive of past discussions on Wikipedia:Lua. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

Archive 6

Archive 7

→

Requested move 16 December 2018

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)
      - Done {{3x|p}}ery (talk) 13:52, 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)
    - I agree, Izno. In fact, our guidelines say that the onus falls on the closer: "It is important that you clean up after any move you perform." - Wikipedia:Requested moves/Closing instructions #Cleaning up after the move. We could also do with documenting a policy for module naming conventions via Wikipedia:Article_titles #Proposed naming conventions and guidelines and updating WP:RMCLOSE to reflect the issues unique to modules, such as the inability to create redirects and the lack of tools analogous to "What links here" to find incoming calls to modules. --RexxS (talk) 20:44, 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.

List of parameters as one parameter

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 27 December 2018

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. -happy 5214 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. -happy 5214 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

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 %|

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)

Template:Gcd

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)

Requested move 28 January 2019

This edit request to Module:Italian provinces/data has been answered. Set the |answered= parameter to no to reactivate your request.

(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. SiBr₄ (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]). SiBr₄ (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.

Module request

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)

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

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

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

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

Help at Template:Article history

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)

Location of test cases

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.

Module to rationalise image scales

I'm looking for a system that can make a group of images (not necessarily contiguous) all display to the same scale without using an absolute unit like pixels. The upright= parameter can rescale an image, but the effect on displayed scale is different for images with different native widths. I need something like a parameter scale= which is used to calculate and set the upright parameter. Someone should check, but I think the calculation would be upright=scale × image native width ÷ reference width. The reference width could default to whatever is considered the most common image size or be set to reference a specific image like scaleto=<filename>. Thanks for considering. SpinningSpark 17:56, 31 March 2019 (UTC)

See Wikipedia:Help desk#Making images display at the same height (permanent link) for a discussion leading here. PrimeHunter (talk) 18:13, 31 March 2019 (UTC)

To avoid any confusion here, my request at the Helpdesk was regarding a special case where I had created a set of diagrams all at the same height and scale but with different widths. In that special case, same height would also result in same scale, but a more general solution should address same scale directly. SpinningSpark 19:09, 31 March 2019 (UTC)

@Spinningspark: To keep things general, I've simply adapted the 'getdimensions' call from Module:Multiple image and put it in Module:Sandbox/Imagesize. It has three functions: getWidth, getHeight, getDimensions. They take a filename, with or without the "File:" prefix, and return the width, or the height, or both dimensions (WIDTHxHEIGHT), respectively. It works with files on Commons or local ones, and works with animated gifs using the dimensions of the first image. Here are some examples:

{{#invoke:Sandbox/Imagesize|getDimensions|Example.jpg}} → 300x300
{{#invoke:Sandbox/Imagesize|getWidth|Example.jpg}} → 300
{{#invoke:Sandbox/Imagesize|getHeight|Example.jpg}} → 300
{{#invoke:Sandbox/Imagesize|getDimensions|File:Bishzilla Lucia Looking Right.gif}} → 100x103

You can use it to do whatever calculations you want using parser functions, so the code won't need to be re-written for other applications. Note: this is an expensive call, so use it sparingly. --RexxS (talk) 20:43, 31 March 2019 (UTC)

Actually, I dislike parser functions, so I've added a getScale function to the sandbox module. Using it is illustrated in the second row of the table below, with the first row using equal widths, for comparison.

There is a caveat: upright will not upscale an image above its natural dimensions. Have a look at the third row of the table below, where the scale is set to 2, which would make the Example.jpg bigger than 275x297px.

{{#invoke:Sandbox/Imagesize|getDimensions|File:Doorway from Moutiers-Saint-Jean MET DP255158.jpg}} → 3042x3887
{{#invoke:Sandbox/Imagesize|getScale|File:Doorway from Moutiers-Saint-Jean MET DP255158.jpg|scale=1}} → 0.78260869565217

Same width, upright=1

Same height, scale=1

Same height, scale=2

As far as I can see, there's no way around that because of the way that the upright parameter is implemented. Cheers --RexxS (talk) 21:50, 31 March 2019 (UTC)

I made a template to do exactly the same before seeing your post: {{Scale height}} PrimeHunter (talk) 22:00, 31 March 2019 (UTC)

Thank you, PrimeHunter. Editors will have the option of using whichever style they are comfortable with now. I was going to suggest a wrapper template for getScale anyway.

I need to add one more note: upright seems to round the width to the nearest 10 pixels, so you don't always get exactly the same height, but I don't think the difference will be noticeable on normal sized images. --RexxS (talk) 22:12, 31 March 2019 (UTC)

IMO, the right way to show images and let some code determine dimension is the gallery tag. even if it _is_ possible to find a file's aspect ratio and make some calcs based on it using scribuntu, it's still the wrong thing to do. use gallery, use "mode=packed" (if it was up to me, it would have been the default), and use heights and widths to control the dimension. this is especially true when you want to display more than 2 or 3 images in one line: gallery will handle different browser window widths, mobile view, and other display options you may not think of (print?), and oh, by the way, unless there is a really really good reason not to, gallery will show all images (or "thumbnails") with equal heights. i know it's not a very lua-ish response, but then again, even if you have a hammer, not everything you see is a nail. (gallery example below).

oh - and one more thing: the correct term for the ratio between the height and width of a picture is "aspect ratio", not "scale". "scale" standard meaning (when discussing photos) is the ratio between the size of the actual object, to the size of its image. peace - קיפודנחש (aka kipod) (talk) 18:20, 1 April 2019 (UTC)

what is it, why is it here? some text (not mandatory) describing the image
with gallery, use pseudo-parameters heights and widths (notice the plural form) to control display size.

That is entirely not useful. As I said in the request, this needs to handle images that are not contiguous, so anything with galleries will not help. As I understand it, heights= and widths= are set in pixels and absolute units are deprecated nowadays. Also, a bunch of images that all have different aspect ratios cannot possibly all end up at the same scale if height an width is specified (assuming the native scales were all identical). SpinningSpark 18:43, 1 April 2019 (UTC)

heights= and widths= are set in pixels and absolute units are deprecated nowadays. Not for images except where you are using |upright= in a solo image. --Izno (talk) 20:59, 1 April 2019 (UTC)

The examples shown above have radically different content and its hard to judge the effect scaling is having on them. I'm a little confused where we currently are. Could someone please demonstrate how these two examples are made to display at the same scale. This is taken from Power dividers and directional couplers but I'm not saying anything actually needs doing in that article. It is not the one I am currently working on. I chose it because the image sizes are hugely different, but they both contain the same elements making it easy to judge scaling by eye. SpinningSpark 22:50, 1 April 2019 (UTC)

"The same scale" in this context means to display at the same height but with that height depending on user settings. I added a table below. PrimeHunter (talk) 23:25, 1 April 2019 (UTC)

Same height, scale=1, using module

Same height, scale=1, using template

Nooooo! That's not what "same scale" means at all. It means that the same object drawn to the same native size in two different files is rendered with the same dimensions when transcluded on to a page. I think you may have been misled by my request on the helpdesk. That related to a special case where I was planning a sequence of diagrams all the same native height. In that particular case, same height and same scale get the same result, but not in the general case. SpinningSpark 13:37, 2 April 2019 (UTC)

Perhaps you can explain how you might accomplish this task manually? One way would be to re-size images based on their dots per inch (DPI) settings. This would depend on the settings being based on the same norm for all images, though, which often is not the case. DPI settings tend to have some default value that no one bothers with setting accurately afterwards. Plus accuracy may not be what you want; if one diagram was drawn on a larger scale than another and yet you want the same size for one of the common components in both photos, you'd want the DPI setting to be based on that common component, rather than the actual physical measurement. (Also if trying to do this with Lua, I don't think the DPI property can be accessed.) So I think for a reliable solution you'd have to specify an individual scaling factor for each image. A Lua module might be able to help you express this factor in a simpler way, but in the end you'd still have to figure it out by trial-and-error.

I suppose what would be nice is some kind of web-based tool where you could draw a "unit length" on each photo, and have the tool figure out the required scaling factors for each photo to make the unit length the same. Or perhaps the tool could let you resize each photo until you were happy with them, and output the necessary scaling factors. It might be possible with a Javascript gadget. isaacl (talk) 15:57, 2 April 2019 (UTC)

not entirely the same, but the multiple image module has logic for displaying a sequence of images with the same height (see here). Frietjes (talk) 15:51, 2 April 2019 (UTC)

I'm not bothered about comparing random images. We are talking about images that a user has deliberately created on the same scale. The manual computation I am using is upright = scale factor × image width / reference width. Either that or trial and error till it looks right. SpinningSpark 15:58, 2 April 2019 (UTC)

OK, the problem is "reference width" (which is the equivalent of the "unit length" I mentioned in the hypothetical tool). It's not a property of the photo (and even if it were, Lua can only access a few properties, as far as I know). But perhaps you just need a template that takes a reference width parameter that you can play around with? isaacl (talk) 16:09, 2 April 2019 (UTC)

I want the user to be able to specify a reference image, from which the reference width is then extracted by the algorithm. Use some reasonable default value if nothing specified. The way I would use it in a series of diagrams like this is to reference everything to the first diagram created in the series. That way the subsequent diagrams will all display to the same scale. SpinningSpark 17:10, 2 April 2019 (UTC)

Thanks, the motivating example helps a lot. The formula basically calculates the scaling factor needed to preserve the relative sizes between the image and the reference image, with the reference image rendered at the default thumbnail size. I'll let @RexxS: or @PrimeHunter: have the first chance to encode the algorithm into their modules. isaacl (talk) 17:31, 2 April 2019 (UTC)

so, call me stupid (it's ok - i'm used to it), but i still think this is way too complex way to accomplish a very simple task. why muck around with aspect ratio at all? mediawiki allows you to demand that an image will display with a given height, so i understand you have some need to do some calcs to find the "reference height" that someone wants, but you really don't have to then use "aspect ratio" (or, as you call it, "scale") x "image width" - you can simply display your image with this given/calculated height.

(short explanation of something you probably already know): with mediawiki, you can demand width (e.g., 123px), or width and height (e.g. 123x456px). when you demand both, mediawiki will calculate the limiting dimension, and use it, while preserving the image aspect ratio, so if the aspect ratio is 2, say width=2000 and height=1000, and you ask to display with 100x100px, mediawiki will display with width=100 (limiting factor in this case), and height=50. if the aspect ratio was 0.5, say width=1000 and height=2000, image would show with height=100 and width=50. if you omit the width (e.g. x456px - note the "x"), mediawiki will show the image with the height you asked for. so, if you want to show 5 photos with different aspect ratio with same height, calculate what height you want, and use x<calculated height>px:

height = 200 pixels	another image at 200px
or, without "thumb" (250 px height this time, just for kicks) :

also works with calculated height (e.g., value returned from a template, #expr, #invoke, etc.)

peace - קיפודנחש (aka kipod) (talk) 19:03, 2 April 2019 (UTC)

Nope, I don't mean aspect ratio when I say scale. Read what I said it means and follow the link. Nor do I want a given height, or calculated height. Try using the examples I am giving you rather than your own examples then you might stand a chance of seeing the problem. Yes, I can manually do a calculation, but I have to look up the native size of the reference and the native size of the image I'm inserting time and remember what scale factor I used last time. In the current article being developed there are a dozen such images which all need a consistent scale. That's a lot of messing about to get it right. It's not the only article. I commonly write articles that need this. I can point to FAs where it would have been useful. SpinningSpark 20:01, 2 April 2019 (UTC)

as i said, call me stupid. i read this section, and i still can't comprehend what do you mean when you say "scale", or, more generally, i can't understand what are you trying to do. wish you best of luck, and i'm sure, with all the intelligent people here, someone will understand what you need (if they don't already), and help you get it. sorry for wasting your time. peace - קיפודנחש (aka kipod) (talk) 22:43, 2 April 2019 (UTC)

@kipod: no, you're not stupid, But it's possible you're missing a piece of information. Current best practice here is to deprecate the use of pixels when setting the size of images. That is done to allow registered users the ability to compensate for any visual deficiencies by changing the default thumbnail size in their preferences. Without any size given, a thumbnail will default to 220px wide, unless the user has set it to one of the available sizes between 120px and 400px. That will render at the same size if the parameter |upright=1 is used. So we much prefer using the upright parameter because it allows each user to set the base size they are most comfortable with, whereas if we use a size in pixels, the size is fixed and they no longer have that ability. So what Spinningspark wants to do is set sizes only using |upright=. But |upright= only sets the width of an image, so we need to do some computation on each image to find the width that corresponds to a given height, so that we can set |upright= to the respective values that yield the same height. Of course that height will now be variable with the user's preference, which it cannot be if we work in pixels. I hope that helps. --RexxS (talk) 00:21, 3 April 2019 (UTC)

As far as I understand, the intent is not to have the same height, but to maintain the same relative size ratio between the two photos in question. So if image B is twice the width of image A, then it should be displayed at twice the width of the size at which the thumbnail of image A was rendered. isaacl (talk) 01:41, 3 April 2019 (UTC)

Yes, that is precisely the requirement. Only I am more concerned with diagrams than photographs. I want the annotation on the whole series to be in the same point size and equivalent symbols to be congruent. I've had a thought, this would all be a lot simpler if the reference width was specified in pixels in the call rather than having to extract it from another diagram – it's not a great hardship to look that up only once. It would be a bit of a pain anyway to type the reference filename over and over. My next request would be a system that could remember the setting for the next diagram, which I imagine is difficult. So I am suggesting something like upright={{scale|<upright factor>|<reference width>}}|. And the calculation in {{scale}} is upright factor * image width ÷ reference width. SpinningSpark 10:24, 3 April 2019 (UTC)

@RexxS: thanks for the education. feel free to substitute "ignorant" for "stupid". :) peace - קיפודנחש (aka kipod) (talk) 17:06, 3 April 2019 (UTC)

Convenience editing heading

"scale" is too generic for such a specialized purpose. A template or module would not have access to the name of the displayed file so it has to be repeated as a parameter. We could make this work: upright={{scale original size|<file name>|<upright factor>|<reference width>}}. In addition, I suggest the module functions getDimensions, getWidth, getHeight add an optional scale parameter to multiply by scale and round to an integer. Callers can do it with parser functions but it's hard for many editors and they have to remember rounding if it's used to specify px size (decimals are disallowed). PrimeHunter (talk) 11:25, 3 April 2019 (UTC)

Can the module not generate [[File:<filename>|<parameters>]] to save the user having to type the filename twice? Agreed on "scale", but can we get the name down to just two words? SpinningSpark 12:13, 3 April 2019 (UTC)

There are many possible image parameters and their wikitext can be processed by some tools. Wikipedia:Extended image syntax says: [[File:Name|Type|Border|Location|Alignment|Size|link=Link|alt=Alt|page=Page|lang=Langtag|Caption]]. I don't think we should try to make a module wrapper for this. Things can go wrong in calls, editors will get more to learn, it's hard to translate to other Wikipedia languages, and some tools will be less helpful. Many image parameters are unnamed and can occur anywhere with their meaning determined by their text, e.g. "if it says left then it's a location". This goes against principles for templates and modules where the meaning of unnamed parameters is determined by their position among all unnamed parameters. If a template or module requires names for unnamed image parameters, or that they occur in a specific order, then it becomes harder for editors than normal image syntax. PrimeHunter (talk) 13:13, 3 April 2019 (UTC)

Although the current request is to preserve the relative widths of the images, it might be desirable to generalize the template to support preserving either relative heights or widths. Alternatively, the template should be named to clarify that it is calculating a scaling factor based on relative widths. isaacl (talk) 16:05, 3 April 2019 (UTC)

I was thinking spit out the entire string again without any attempt to process it, other than to append upright=foo. The module only needs to extract the filename from the string, which will always be the first parameter. But if you say that is fraught with problems, I can only take your word for it. SpinningSpark 16:12, 3 April 2019 (UTC)

after getting some education from User:RexxS, i think i understand the challenge now, and i think you can do this, by passing to the module the whole [[File:....]] shebang .

the "secret ingredient" here would be the fact that you pass it _enclosed in nowiki tags_, get the module to add its thing, and then parse it. so your template will look maybe like so:

{{ calcUpright
| refimage = <ref image name>
| refwidth = <reference image width. only one of "refimage" or "refwidth" should be used>
| content = <nowiki>[[File:<image file name> | bla bla bla | bli bli bli | etc. etc. etc.]]</nowiki>
}}

it should be easy enough for the lua code to extract the file name, make the required calcs, add the | upright = XXX pseudo-parameter, send the whole shebang to wikicode parsing (basically counteracting the "nowiki"), and return the result. peace - קיפודנחש (aka kipod) (talk) 17:18, 3 April 2019 (UTC)

Wikitext should only be parsed by MediaWiki unless there are strong reasons for something else. Issues can always be expected otherwise. For example, the image editor in VisualEditor couldn't be used on the above image code, and it wouldn't be displayed as image code by source code syntax highlighters which respect nowiki. And could the image code be processed correctly if it uses templates, e.g. in the caption? PrimeHunter (talk) 20:23, 3 April 2019 (UTC)

totally agree. the question is really "is this a strong enough reason" to justify the "unless".

as to editing with visual editor: i don't see it as an issue: VE will show the template editor instead, and the user will be able to edit the parameters of the template. not as convenient as editing the caption of a thumb directly, but this is true for anything displayed by a template, and VE is no reason to avoid using templates.

as to "could the image code be processed correctly if it uses templates" - yes. see frame:preprocess(). it will even parse correctly templates that depend on the page name or namespace. peace - קיפודנחש (aka kipod) (talk) 23:52, 3 April 2019 (UTC)

Show a sequence

I wish to get a Template and Lua module that shows a sequence, for example the sequence of primes, to be shown in the article Prime number. It will show the first number of the sequence, pause for a second, show the second number, pause for a second, etc. It will contain a play/pause button and a back to the beginning button. You can see a example at the bottom of this page. Thanks, David Shay דוד שי (talk) 17:59, 8 April 2019 (UTC)

Templates and modules don't work that way – they are processed only when wikitext is 'compiled' into the html that your browser displays. To do what you want to do you will need to use javascript.

—Trappist the monk (talk) 18:35, 8 April 2019 (UTC)

Indeed, modules are read-only. --Izno (talk) 18:47, 8 April 2019 (UTC)

Module help request: Ancient Greek transliteration

Hi, I need help from someone who understands Lua to edit Module:Ancient Greek (ALA-LC). I've copied Module:Ancient Greek and made a couple of tiny adjustments. The module converts Ancient Greek text into Latin characters using the ALA-LC standard (see Romanization of Greek#Ancient Greek)

The original module converted υ to u. The new version converts it to y. However, υ needs to convert to u following Α/α, Ε/ε, Η/η, Ο/ο or Ω/ω and before ι (and variations of all Greek vowels with diacritical marks).
Ρ/ρ converts to R/r. It needs to convert to Rh/rh when at the start of a word.
All diacritical marks in the input should be ignored, except ῾ before Α/α, Ε/ε, Η/η, Ι/ι, Ο/ο, Υ/υ or Ω/ω, where it should convert to H/h.
There should be no diacritical marks in the output, except Η/η (and variations with diacritical marks) converting to Ē/ē and Ω/ω (and variations with diacritical marks) converting to Ō/ō.

Cheers, M.Clay1 (talk) 08:36, 29 March 2019 (UTC)

It seems to me that the better solution to your problem would be to make Module:Ancient Greek handle all three of the transliterations listed at Romanization of Greek#Ancient Greek rather than to fork slightly different variants of the same module. I would recommend that you consult with Editor Erutuon to accomplish this.

—Trappist the monk (talk) 11:47, 29 March 2019 (UTC)

If that provides a simpler solution, then that sounds like a good idea. The new module can be redirected to the old one when the new code is complete. @Erutuon: Is this something you could do? M.Clay1 (talk) 06:41, 30 March 2019 (UTC)

The other transliterations detailed at Romanization of Greek#Ancient Greek probably aren't useful for a template. Scientific transliteration is not mentioned in the article for some reason. M.Clay1 (talk)

I don't have time to help but will make a couple of comments. First, when copying material in Wikipedia (WP:CWW), an edit summary like "copy from Module:Ancient Greek" should be used. Second, I agree with TTM above that the module should only be forked if absolutely required. Third, tests are always helpful both when writing a module, and when testing it. That is, you should create a sandbox page with examples of the points you mention above to show what the module should do (example input and expected output). Johnuniq (talk) 08:23, 30 March 2019 (UTC)

Module:Ancient Greek was based on Module:grc-translit on English Wiktionary. There, we used to implement at least one of the features of ALA-LC transliteration, transliterating upsilon as u in diphthongs but y as a monophthong, so maybe some useful code can be scrounged from the edit history.

Similar to what Johnuniq says, could you (Mclay1) provide the ALA-LC version of each of the examples in Module talk:Ancient Greek/testcases? That would give me a better idea of what changes need to be made, because I'm not familiar with this transliteration system, and eventually the testcases can be expanded to test both transliteration systems. — Eru·tuon 23:04, 9 April 2019 (UTC)

@Erutuon: Module talk:Ancient Greek (ALA-LC)/testcases — M.Clay1 (talk) 06:08, 10 April 2019 (UTC)

@Mclay1: Thanks. I've implemented the diacritic removal part. But are rough breathings on vowels meant to be kept as h or removed? The transliterations are currently inconsistent: Ἥλιος → Hēlios, but Εἵλως → Eilōs (helot). — Eru·tuon 06:50, 10 April 2019 (UTC)

Never mind, I read the documentation and figured out that the rough breathing is supposed to be kept. — Eru·tuon 07:02, 10 April 2019 (UTC)

Okay, Module:Ancient Greek (ALA-LC) is done. The next task is to figure out how to merge it with Module:Ancient Greek. — Eru·tuon 07:09, 10 April 2019 (UTC)

I think rough breathing is kept where there is a ῾. So it would be kept for Ἥλιος (Hēlios) but not for Εἵλως (Eilōs). M.Clay1 (talk) 11:44, 10 April 2019 (UTC)

The document doesn't seem to make a distinction based on whether the rough breathing is placed to the left or on top: "The rough breathing ( ̔ ) is romanized h. When it appears with a vowel or a diphthong, the h precedes the romanized vowel or diphthong; when it appears with rho (Ῥ, ῥ), the h follows the romanized rho (Rh, rh)." — Eru·tuon 22:08, 13 April 2019 (UTC)

Module:TimeAgo's calculations sometimes off by a week

As you can see from the testcases, the module TimeAgo does not accurately calculate the number of years that have passed. Its current calculations are 7 days behind, it claims that 2018-04-04 (1 year and 6 days ago) was 11 months ago. This seems to result from TimeAgo not calculating based on dates, but based on seconds. Could this problem be fixed by calling Module:Age in Module:TimeAgo?

Possible solution

Pseudo-fix, to be placed on line 92:

-- Fix year calculations
if magnitude_num == 63115200 then
   result_num = {{age in years|args[1]}} -- (incorrect way to call a module, but you get what I mean)

-- Fix month calculations
elseif magnitude_num == 5356800 then
  result_num = {{age in months|args[1]}} -- (again, incorrect)
end

Regards, – Þjarkur (talk) 13:34, 10 April 2019 (UTC)

Are you referring to the following wikitext?

{{#invoke:TimeAgo|main|4 April 2018}} → Script error: No such module "TimeAgo".
{{#invoke:TimeAgo|main|2018-04-04}} → Script error: No such module "TimeAgo".

That is currently showing 12 months ago. If you saw 11 months, it was probably a caching issue where the displayed text was generated at a time when 11 months was correct. I'm not familiar with what TimeAgo is supposed to do but it looks like it decides what time units to use and 12 months is probably what it intends. It is using a unit (month) that gives a good indication of the period (± half a month), whereas saying 1 year might mean anything from perhaps 7 to 17 months. Johnuniq (talk) 07:38, 11 April 2019 (UTC)

Þjarkur's post was yesterday 10 April 2019 where {{#invoke:TimeAgo|main|4 April 2018}} produced "11 months ago". Today 11 April 2019 it produces "12 months ago" but {{#invoke:TimeAgo|main|5 April 2018}} produces "11 months ago". An example which may continue showing the issue:

{{#invoke:TimeAgo|main|{{#time: j F Y | -1 years -6 days}}}} → Script error: No such module "TimeAgo".

where {{#time: j F Y | -1 years -6 days}} → 10 September 2025

PrimeHunter (talk) 09:47, 11 April 2019 (UTC)

Thanks, that didn't occur to me. Module:TimeAgo has table timeText with a value for months of 2,678,400. That is supposed to be the number of seconds in a month. It has been calculated from the number of seconds in 31 days. I have no idea what side effects might result from changing that, but a better average value would be

365.25 * 24 * 60 * 60 / 12 = 2,629,800

Using that value gives the desired result of 11 months. The module calculates the number of months by dividing the number of seconds by 2678400. That gives 11.98 for the period in question, whereas dividing by 2629800 gives 12.2. Rounding to the nearest month would also work.

Module:Age uses a more esoteric method to calculate a difference in months because it's quite tricky: going from Feb 1 to Mar 1 is 1 month but (in non-leap years) is only 28 days. I'm not sure what the best fix would be. Mr. Stradivarius is busy but might like to comment. Johnuniq (talk) 11:04, 11 April 2019 (UTC)

I think Module:Age's esoteric calculations are desirable here, since TimeAgo seems to mainly (?) be called from {{start date and age}} used for showing how long ago events happened. For older events, TimeAgo is only off by a day or so, but it was odd to see RMS Titanic's "Maiden voyage" value refuse to update after purging yesterday (is correct today). – Þjarkur (talk) 12:16, 11 April 2019 (UTC)

There was a similar discussion to this on VPT a week or two ago at VPT. --Izno (talk) 14:25, 11 April 2019 (UTC)

@Þjarkur: I refactored Module:TimeAgo/sandbox and fixed the testcases, results at Module talk:TimeAgo/testcases. The module has a basic problem in that it calculates inputTime from the date/time in the input, and the time now, then takes the difference, then estimates how many time units (years/months etc.) that is. However, for most cases, the input will be something like '1 Feb 2012' (no time) and that makes inputTime assume 12 noon as the time. On the other hand, the time now is the precise date/time now (to the nearest second). That is why some obvious cases such as a date exactly 12 months ago sometimes showed 11 months. I added in a rounding kludge which seems to work. The testcases were probably correct when entered, but now, some years later, many expected calculations were wrong so I replaced them with calls to Module:Date. Please give {{time ago/sandbox}} a test. If it's ok, I'll update the main module. Johnuniq (talk) 08:01, 13 April 2019 (UTC)

Marvellous! Your solution seems to work great. – Þjarkur (talk) 12:17, 13 April 2019 (UTC)

I have done more checking. First, my above comment about the input defaulting to time noon is not correct (it defaults to 00:00:00; I was confused by running standard Lua on a local computer). Second, there are still a bunch of irritating errors found with systematic checking. For example, today (2019-04-14) gave these results (using fixed wikitext so it won't change):

{{time ago/sandbox|2019-09-13}} → 5 months' time (should be 4)
{{time ago/sandbox|2019-07-14}} → 2 months' time (should be 3)
{{time ago/sandbox|2016-04-14}} → 2 years ago (should be 3)
{{time ago/sandbox|2018-03-15}} → 13 months ago (should be 12)

It's mostly correct and the above are arguable. I'll think about what to do. Johnuniq (talk) 05:07, 14 April 2019 (UTC)

For anyone watching this, I changed the sandbox module to use Module:Date for weeks/months/years. That was the only way I could see to get results that people would expect. I did some tests which show that using Module:Date has a very low overhead. I'll let things mature for a day or two and will then update Module:TimeAgo. Johnuniq (talk) 07:42, 15 April 2019 (UTC)

I updated Module:TimeAgo so the change is live. Johnuniq (talk) 07:24, 18 April 2019 (UTC)

Help for Wikidata module

Hi! A while ago i requested a module, thanksfully, helpful users helped to create. That's now used in almost all articles on Azerbaijani Wikipedia.

On Azerbaijani Wikipedia, infoboxes are filled by Wikidata properties by default to speed up creating articles. Everything is working correctly. What i want is to teach the module these:

On Wikidata:
1) If there's no Azerbaijani label/article for the Q-element, skip that and don't show in infoboxes.→
2) If there's no Azerbaijani article but there's Azerbaijani label, show that in plain text.→
3) If there's article on Azerbaijani wikipedia, then show the element with link to the article.

The module is located here. The part that i mentioned starts from 984th line.

An example is Corc Herbert Uoker Buş article. On infobox you can see that Doğum yeri (birth place) has parameters that are different. For example, Milton has Azerbaijani label on Wikidata but no article on Azerbaijani. That will be shown on infobox, but in plain text (category 2). Norfolk County has no Az label on Wikidata and no article in Azerbaijani Wikipedia and has to be skipped (category 1). The rest have article they will be shown (category 3).

I hope, i made myself clear. Thanks!--Toghrul Rahimli (talk) 08:43, 5 April 2019 (UTC)

@Toghrul Rahimli: I'm afraid that the Wikidata module on az-wiki is rather more complex than that. It deals with places by calling a routine that returns a string of locations. Using your example, for George H. W. Bush (Q23505), place of birth (P19), we would expect 'Milton' as that is the value in the Wikidata entry. Instead, we get Milton^[d], Norfolk County^[d], Massaçusets, ABŞ^[1] as you can see if you preview {{#invoke:Wikidata|formatProperty|property=P19}} anywhere in the az:Corc Herbert Uoker Buş article.

I've been able to cut out some of that and simplify the code in az:Module:Wikidata/sandbox but I can't get it to skip 'Norfolk County' as you want. You can see what happens if you preview {{#invoke:Wikidata/sandbox|formatProperty|property=P19}} in the az:Corc Herbert Uoker Buş article. Unfortunately, the module has no documentation and I'm unable to find my way round the az-wiki well enough to figure out what is being passed into the call that adds 'Norfolk County'. The sandbox code at lines 986-992 ought to skip it, but somehow the labelLanguageCode is being set to 'az' while supplying the English label. That may be a function of the way language fallback works for the mw.wikibase.entity:getLabelWithLang method, but of course that has atrociously poor documentation as well. Sorry I can't be more help. --RexxS (talk) 15:37, 22 April 2019 (UTC)

@RexxS:, thanks for sparing your time and for the help! We don't have any programmer on our wiki so that's why we encounter such problems and cannot solve them within the community.

I applied your edited module. It works partially. But crashes. Please take a look at the same article, you'll see "Dəfn yeri" (Place of Burial) has crashed. Those crashed parts doesn't have any label in Azeri. Place parameters can be skipped, as you mentioned, they are interconnected and very tough to solve. It can stay, we shall add the labels manually. The module was set to find English label if there's no Azeri one.

So basically, if there's no label in Azeri on Wikidata = skip, label but no article = plain text. For example on az:Məxfurə Yermakova teatr aktrisası leads to wikidata. It can be plain. There's no importance of p19 and p20.

Please feel free to edit the module on az-wiki if you want, Cheers!--Toghrul Rahimli (talk) 16:14, 22 April 2019 (UTC)

Lua help

Moved from User talk:Pppery

– * Pppery * _{has returned} 12:16, 21 April 2019 (UTC)

How do I print the contents of a table? I'm trying to understand the protectionLevels for a title, but Module:Sandbox/DannyS712/gen isn't printing any protection, despite the pages I test being protected. Can you help? Thanks, --DannyS712 (talk) 04:57, 21 April 2019 (UTC)

@DannyS712: Use mw.dumpObject. * Pppery * _{has returned} 12:16, 21 April 2019 (UTC)

@DannyS712: If you want to retain full control over the formatting of what is returned, then you can use a for loop as you were attempting to, along with Pppery's advice to use the pairs() iterator function to traverse the table. However, the value in the key-value pair table of title.protectionLevels is itself a table, so you can use an inner loop to extract its values, or you can use table.concat() as a more convenient alternative when the table is a simple sequence (as it is in this case). Something like this adaptation of your earlier code should work:

local p = {}

function p.main( frame )
	local title = mw.title.makeTitle( 'Wikipedia', 'Arbitration' )
	local protection_table = title.protectionLevels
	local text = 'Start:<br>'
	for k, v in pairs( protection_table ) do
		text = text .. k .. ' = ' .. table.concat(v, ", ") .. '<br>'
	end
	return text
end

return p

Using mw.dumpObject is always a good first step as it recursively expands tables within tables, if they exist. Once you've seen the structure of the object, it becomes easier to customise how you process it. HTH. --RexxS (talk) 15:41, 21 April 2019 (UTC)

I wrote Module:Dump for this kind of thing. mw.logObject/dumpObject are very convenient but dump produces a cleaner result that I can follow more easily. Last time I tried, I saw a weird bug when dumping mw.title.getCurrentTitle() (dump gets confused and expands what it thinks are nested tables forever). I edited Module:Sandbox/DannyS712/gen as a demo with the result shown at User:DannyS712/module. Johnuniq (talk) 00:32, 22 April 2019 (UTC)

I added a demo at Module talk:Sandbox/Johnuniq/debug using mw.dumpObject to display a complex table. I don't know why it is truncated but I'll forget it for now. Johnuniq (talk) 04:03, 22 April 2019 (UTC)

Module:College color and Module:College color/data

This module is used in nearly 100k articles and uses a flat data file about 250k in size. Is there a way to check for performance problems with this large data file, and possible suggestions on how the data file might be split. -- GreenC 00:33, 22 April 2019 (UTC)

I had a look at the code and it is very efficient. Since it uses mw.loadData rather than require to access the data, the enormous table is only loaded once per page and Lua is stunningly fast although it has to do a lot of work parsing the large data table. Module:Convert/data is even more over-sized yet {{convert}} can handle 1,100 converts with less than 1 second of Lua time and 4 MB of Lua memory. The only way I know to check for performance problems is to find a page where the module is called a large number of times then inspect the NewPP report in the HTML source of the page. Johnuniq (talk) 03:07, 22 April 2019 (UTC)

Johnuniq, I created two testcase pages, one using the template the other a control without. User:GreenC/testcases/moduleCollegeColor/test with and User:GreenC/testcases/moduleCollegeColor/test without. Feel free to edit. -- GreenC 14:17, 22 April 2019 (UTC)

it looks like "check_data" uses require, but I don't think that function is used in articles (only in this thread). it could be split like Module:Portal/images, but that would in some cases split the aliases from the full team names. Frietjes (talk) 16:24, 22 April 2019 (UTC)

I added 806 {{college color boxes}} to your test. The HTML source has a NewPP report showing total Lua time 1.3 seconds and memory 3.5 MB. That time hit only happens once per page, each time the page is purged. There may be an article using hundreds of these templates and hundreds of others such that the total time is a problem. Unless there is an example where that is the case, the time used is not significant. Before I added the 806 templates, the Lua time was trivial (less than 20 milliseconds). Johnuniq (talk) 01:33, 23 April 2019 (UTC)

Retrieving a country adjective from country name

Is there any template or module available that produces a country adjective from a country name? So for example "France" -> "French", "Brazil" -> "Brazilian". --Gonnym (talk) 08:30, 23 April 2019 (UTC)

Module:FooBarHumMigNav/adjectives, but I don't know how complete it is (236 countries/regions) nor do I know its provenance. For the sake of comparison, Module:Language/data/iana regions lists the 289 countries/regions by ISO 3166 and UN M.49 codes that are listed in the IANA language subtag registry. I can imagine expanding ~/iana regions to include both noun and adjective forms so that IETF language tags like pt-BR might be used to render 'Brazilian Portuguese', for example.

I did find this linked to from CLDR. You might troll through CLDR to see if there is an easy place to get a summary like that europa.eu page.

If you find a better source of adjectival country names (preferably something standardized – we should not be making up adjectives) let me know.

—Trappist the monk (talk) 13:21, 23 April 2019 (UTC)

Thanks for those links, I'll go look them over. The only other link I know of, is the one used in the WP:NCTV and WP:NCFILM guidelines - List of adjectival and demonymic forms for countries and nations. --Gonnym (talk) 19:49, 23 April 2019 (UTC)

Newline above table

Why wikitext table "{|\n|cell\n|}" from module → template (invoke) → page shows two lines above the table when in the page wikitext is only one line between the text and the template? If I replace wikitext with "<table><tr><td>cell</td></tr></table>" then only one empty line will be displayed as usual. --Sunpriat (talk) 01:15, 15 May 2019 (UTC)

See Template talk:Weather box#Spacing and particularly search for the comment by Jts1882 near the end. Johnuniq (talk) 04:05, 15 May 2019 (UTC)

Module:Lok sabha constituency

The following articles use wikitext

{{Infobox lok sabha constituency1|{{#invoke:Wikidata|pageId}}}}

For the first article, that is equivalent to

{{Infobox lok sabha constituency1|Q3595503}}

Articles

I think that due to some recent Wikidata changes, the articles are displaying "Lua error in Module:Lok_sabha_constituency at line 270: bad argument #2 to 'format' (string expected, got nil)."

Template:Infobox lok sabha constituency1 calls Module:Lok sabha constituency and looking at that shows I fixed a similar problem in January 2018. Any thoughts on how to proceed? I looked at the module again but it really needs to be rewritten. I am inclined to simply comment-out the call to the infobox in the articles. Any thoughts? Johnuniq (talk) 03:59, 21 May 2019 (UTC)

@Johnuniq: The proximate cause of the problem is that S102 is left as global variable and undefined if the qualifier doesn't exist. I've fixed that part. That then throws up invalid entity ID errors for a couple of those articles:

I'll try to track that down. The module uses the old, expensive getEntity calls and needs updating. It also fails the requirement that local values should be able to override auto-generated ones. On the other hand, it's a niche use and perhaps a relevant WikiProject can work on it. I'd be loathe to disable the box if we can get it working. --RexxS (talk) 15:05, 21 May 2019 (UTC)

Nah, I give up. There are just too many places where the assumption is made that when a table of property values exists, it has a datavalue, which isn't always true (e.g. for some value and no value). That makes it really hard to track down the problem where an entity ID is constructed from 'Q' .. foo.datavalue[numeric-id] which I'm guessing is the source of the errors. --RexxS (talk) 15:39, 21 May 2019 (UTC)

@RexxS: Thanks for looking. I agree with your conclusion and will comment-out the infobox in due course. Even after your fix there are 29 unintended globals in the module (some of which are simply omission of "local") but it really needs to rewritten from scratch. Doing that is unappealing, particularly given the strong pushback against infoboxes replying on Wikidata (although your idea of only using Wikidata if no local value is given is good). Johnuniq (talk) 04:04, 22 May 2019 (UTC)

Module request

Hello, I am looking to streamline the {{citation}} template, by auto-generating the unique backlink as a suffix to the listing. (Full conversation.) If there is any member who is capable of training, I would like to learn.

Example

References

AllMusic Staff (2011), "Tyler Pursel Credits", AllMusic, retrieved 27 January 2014 {{citation}}: |author= has generic name (help), ^{^}
Apar, Corey (5 September 2007), "Ladybirds", Spin, retrieved 22 January 2014, ^{^ a b c d}
Apple, Meiyee (16 July 2007), "Regional Community Theater", The Fader, retrieved 23 January 2014, ^{^ a b c d}
Aubin, Paul (19 July 2007), "Videos: Ladybirds: "The Brown and Red Divide"", Punknews, retrieved 26 January 2014, ^{^}
Bunch, Adam (22 August 2007), "Ladybirds: Regional Community Theatre", PopMatters, retrieved 24 January 2014, ^{^ a b}
DeAndrea, Joe (2007), "Ladybirds - Regional Community Theater", AbsolutePunk, retrieved 24 January 2014, ^{^ a b c}
Greene, Jo Anne (2007), "Regional Community Theatre", AllMusic, retrieved 24 January 2014, ^{^ a b c}
Hasty, Katie (17 September 2007), "Ladybirds Take Flight", Billboard, retrieved 26 January 2014, ^{^}
Olund, Paul (6 July 2007), "Candy-coated goodness to make you smile", Today, NBC, retrieved 22 January 2014, ^{^ a b c d}

With help from Trappist the monk, Erutuon, and Headbomb, they've explained that a data module that searches for {{sfn}}, scanning the page for matching {{sfn|last|date}} and {{citation|last|first|date|title|work|url|accessdate}}, and tallies, would be loaded with mw.loadData, and then adds a backlink, after the relevant citation. - NorthPark1417 (talk) 03:43, 16 April 2019 (UTC)

Parsing wikitext is far too complex for a module. Sure, it could be done, but should it? I don't think that modifying the way references work is something that a module should attempt. If worthwhile, it should be done as a modification to MediaWiki, the underlying software. Johnuniq (talk) 04:53, 16 April 2019 (UTC)

Disambiguation check

In Module:Infobox television disambiguation check I currently check if the article has correct disambiguation (per WP:NCTV) by checking if it uses one of the valid formats. The format can be prefixed by a country (country TV series) or year (yyyy TV series), or both (yyyy country TV series) and I'd like to add another validation that checks if the country uses the correct adjective from the list at Module:Country adjective (based on List of adjectival and demonymic forms for countries and nations, which is what NCTV says to use). Any suggestions on how to correctly do this? --Gonnym (talk) 15:00, 19 May 2019 (UTC)

Give the current table a name:

local adj_from_country = {

then add a function to Module:Country adjective that builds a transposed table.

local country_from_adj = {};

	for k, v in pairs (adj_from_country) do
		country_from_adj[v] = k;
	end
	
return {
	adj_from_country = adj_from_country,
	country_from_adj = country_from_adj
	}

the above ~~not~~ tested but not saved. Try it; tell us if it works.

—Trappist the monk (talk) ~~15:42, 19 May 2019 (UTC)~~ 15:55, 19 May 2019 (UTC)

Update the code, but I'm not quite sure I understand how to invoke it as I'm getting attempt to call field 'adjFromCountryList' (a table value). Also, I just realized that I do not need the country names at all. What I pass is a single string and it just needs to match one of the adjectives. Should I modify the table or can it work with the current list? (if it can work with the current list, then I'd like to keep it so if any future need arises, for a conversion from one to the other, it will already be available). --Gonnym (talk) 17:08, 19 May 2019 (UTC)

It isn't obvious that you are doing anything with this module; the string adjFromCountryList only appears in Module:Country adjective (so says cirrus search of the module namespace). You do have to

local data = mw.loadData ('Module:Country adjective')

then to get some country's adjective, index into the adjective-from-name table with:

local country = -- some code here that gets the country name for which you want an adjective ...

if not data.adjective_from_country_list [country] then	-- returns the adjective associated with country or nil
	-- code here to do something with a bad country
	return	-- failure message or whatever
else		-- maybe not necessary
	-- code here to do something with a country name that has an adjective
end

or flipped around to look in the table of adjectives for a matching country name:

local adjective = -- some code here that gets the adjective for which you want a country name ...

if not data.country_from_adjective_list [adjective] then	-- returns the countru associated with adjective or nil
	-- code here to do something with a bad adjective
	return	-- failure message or whatever
else		-- maybe not necessary
	-- code here to do something with a adjective that has a country name
end

This kind of testing is an exact-match testing so you may want to normalize somehow before testing because dabs can be peculiar.

—Trappist the monk (talk) 18:51, 19 May 2019 (UTC)

Stupid mistake of mine, I used require instead of loadData. Ok this code now works, but like I said, this isn't really my use-case, as instead of converting from country to adj or the other way, I'm actually doing a 1:1 match: "Does 'x' appear in text?". This can work if I use the second option you gave (any failure meaning the country name couldn't be found) - would this be correct usage or should I do this someway else? --Gonnym (talk) 19:10, 19 May 2019 (UTC)

Then I guess you haven't clearly explained the problem or I have completely missed what you are saying – not the first time for that between us. I undertood you to say that you are parsing apart the dab string and then validating the various portions of that to make sure that the whole dab is valid. If that is not what you are doing, show and / or explain what it is that you doing / want. As I write this, Module:Infobox television disambiguation check/sandbox does nothing with this code.

Why wouldn't this proposed method be a correct usage? You could, I suppose, change the function in Module:Country adjective to do this:

country_from_adj[v] = true;

but that seems rather silly to me when getting a country name from an adjective might be more useful to someone else in some other application.

—Trappist the monk (talk) 19:29, 19 May 2019 (UTC)

Ok, I'll try explaining with an example so you see what I mean. The Changeling (TV drama) is a TV-related article that uses an incorrect disambiguation (one that isn't supported by WP:NCTV) "TV drama". My current code catches articles like this as it checks against a valid list, and "TV drama" isn't on it. Mira quién baila (Spain TV series) or Frontline (U.S. TV program) (after the recent RfC that replaced the usage of U.S. for American) are not caught as "TV series" and "TV program" are valid. What I want to do is after I validate the format (TV series/TV program), to see if the title has extended disambiguation and see if it is one of the valid country adjectives from the list. The title can also be Heartland (2007 U.S. TV series) or The Flash (1990 TV series) so would need to separate the year from the country text. So the complete process should be:

Check if the title has disambiguation. - currently does this.
Check if the title uses a valid format. - currently does this.
Check if the title has extended disambiguation.
Separate the year (yyyy) from the other part of the text.
Check if there is any other text
Check if the text is a valid country adjective. - what I'm trying to work on now.

Regarding the sandbox code not doing anything atm, I know, I'm testing it in the console so I didn't need to connect it to anything, but like I said, it seems that it does work, in that if it returns a country then the text is valid, and if it doesn't return a country then the text is not valid. I just wanted to make sure that I'm not doing any wasted processing (as I don't care what the country is so maybe the code isn't efficient). --Gonnym (talk) 21:15, 19 May 2019 (UTC)

Does this work?

I think that what you describe needs to validate this pattern:

[[year] [country adjective]] TV series | TV programme | TV program | TV film | film | miniseries | serial | game show | talk show | web series

I modified the order of the type specifiers from your original because 'TV program' and 'TV programm' (without the 'e') can be found in 'TV programme' but have since change how the code works so that reordering may not matter now.

—Trappist the monk (talk) 22:54, 19 May 2019 (UTC)

This looks good. One issue I ran into was that I haven't been able to reach the "type specifier only" case. When I try to reach it with a type, lets say "TV series" only, I get "error: no type specifier". Not sure why the count is 0 in this case. --Gonnym (talk) 16:02, 21 May 2019 (UTC)

fixed, i think.

—Trappist the monk (talk) 16:14, 21 May 2019 (UTC)

Thanks again Trappist for your help! So far it looks like everything it should do, it does and it passes all of the testcases. --Gonnym (talk) 19:20, 21 May 2019 (UTC)

Part 2

I'm working on doing disambiguation checking for a sister infobox (Template:Infobox television season) at Module:Sandbox/Gonnym/Infobox television season disambiguation check and wanted to re-use the code. For that I've split the code to Module:Sandbox/Gonnym/Infobox disambiguation check and modified the code at the previous module (Module:Infobox television disambiguation check/sandbox) which works; I now pass as parameters the unique variables (title, validDisambiguationTypeList, exceptionList and otherInfoboxList). My problem is now, the extended disambiguation checks at the base module are different. The validation process here is:

series <#>
season <#>
<country> series <#>
<country> season <#>
<country> season
<year> season
<year> TV series, series <#>
<year> TV series, season <#>

Any idea how best to approach this? --Gonnym (talk) 13:58, 25 May 2019 (UTC)

Replaced '<' with '<' to keep my syntax highlighter happy (no closing </country> for example).

All of the elements in each enumeration above are required? What is the difference between 'series' and '<series>'? between 'season' and '<season>'? between 'series' and 'season'? between '<series>' and '<season>'?

—Trappist the monk (talk) 14:20, 25 May 2019 (UTC)

Those are incorrect mistakes in the above list. Thanks for pointing that out, fixed now. And yes, in each version, all elements are required, with the ones in the brackets having different values. --Gonnym (talk) 14:38, 25 May 2019 (UTC)

Sort of off-topic, but why is this iterative mechanism:

local function getDisambiguation(title)
	local match = require("Module:String")._match
	return match(title, "%s%((.-)%)", 1, -1, false, "")
end

preferable to this:

local function getDisambiguation(title)
	return title:match ('%s*%b()$');
end

If the purpose of getDisambiguation() is to get the parenthetical disambiguator (always the last parenthetical text in a title, isn't it?), isn't the above native use of string.match() a simpler and better choice? Test in debug console:

=mw.ustring.match ('title (title part) (dab)', '%s*%b()$')

—Trappist the monk (talk) 14:56, 25 May 2019 (UTC)

Only reason I used one over the other, is that I was familiar with the first. I have no issue with switching to your suggested code, but it does require a small fix, as it returns the "()" brackets. So I'm getting "(dab)" instead of "dab", which the previous function returned. --Gonnym (talk) 15:02, 25 May 2019 (UTC)

=mw.ustring.match ('title (title part) (dab)', '%s*%b()$'):gsub('[%(%)]', '')

—Trappist the monk (talk) 15:52, 25 May 2019 (UTC)

This causes an error when the title does not have disambiguation. Is there a reason why this method is better than calling another function which has code already verified to work? --Gonnym (talk) 19:50, 25 May 2019 (UTC)

Point.

=(string.match ('title (title part) (dab)', '%s*%b()$') or ''):gsub('[%(%)]', '')

Doesn't need mw.ustring.match() because we're not looking for unicode characters.

Yeah, Module:String works but you have to require() it. Then, to find what you want it to find, it iterates across the string and adds each individual capture to a table (whether you need these captures or not). When it's done doing that, it calculates an index into the table and returns the content of that index or an error message or whatever is assigned to |nomatch=. Because you want whatever is inside the right-most patentheses pair, string.match (title, '%s*%b()$') goes right to the end and if the last stuff in the string is something that looks like a parenthetical dab, returns that or nil. The or '' bit changes nil to empty string and the :gsub('[%(%)]', '') bit strips the off parentheses (basically same way as is done by mw.text.trim (dab, '()')). This latter is, to my mind, a more straightforward solution that doesn't take much time to think about how it works (which is also why I missed the nil return but, as you can see the solution to that was also simple).

—Trappist the monk (talk) 21:13, 25 May 2019 (UTC)

=(string.match ('title (title part) (dab)', '%s*%b()$') or ''):gsub('[%(%)]', '') didn't work at all, but =(string.match ('title (title part) (dab)', '%s*%b()$' or ''):gsub('[%(%)]', '') did (without the closing bracket before "or"), but I still get the same error. Any non-disambiguated title ("Title") will throw an error. --Gonnym (talk) 22:01, 25 May 2019 (UTC)

My original:

1. =(string.match ('title (title part) (dab)', '%s*%b()$') or ''):gsub('[%(%)]', '')

the one you say doesn't work at all:

2. =(string.match ('title (title part) (dab)', '%s*%b()$') or ''):gsub('[%(%)]', '')

the one you say does work:

3. =(string.match ('title (title part) (dab)', '%s*%b()$' or ''):gsub('[%(%)]', '')

Both 1 and 2 are the same and for me both find the dab; with 3 I get an error because unbalanced parentheses.

In the versions of this that work (for me) the parentheses ahead of :gsub(...) hold the OR of string.match() with ''. When string.match() does not match (no dab) it returns nil. nil or '' returns empty string. string.gsub() the operates on the match or the empty string; if the match then it removes the parentheses; if no-match, returns empty string.

Rewriting #1 so that there is no dab:

4. =(string.match ('title', '%s*%b()$') or ''):gsub('[%(%)]', '')

returns an empty string because there is no match. As it should.

Where are you seeing the error and what does the error say?

—Trappist the monk (talk) 22:31, 25 May 2019 (UTC)

Ugh, I must have copied it incorrectly somehow. Copied it again and it now works. Thanks for that. Now I can move forward and test the actual new code :) --Gonnym (talk) 23:32, 25 May 2019 (UTC)

The simple, and probably perfectly adequate, way for doing this dab parsing is an if-then-elseif-then-...-end structure; there are only eight correct forms and relatively few infoboxen per article. For that, make a table of patterns (with captures) could be k/v pairs or simply a sequence:

local year;
local country;
local num;
local patterns = {
	'(%d%d%d%d) TV series, season (%d+)',	-- <year> TV series, season <#>
	'(%d%d%d%d) TV series, series (%d+)',	-- <year> TV series, series <#>
	'(%d%d%d%d) season',					-- <year> season
	'([%D]+) season (%d+)',					-- <country> season <#>
	'([%D]+) series (%d+)',					-- <country> series <#>
	'([%a ]+) season',						-- <country> season
	'season (%d+)',							-- season <#>
	'series (%d+)',							-- series <#>
}

if dab:match (patterns[1]) then
	year, num = dab:match (patterns[1])
elseif dab:match (patterns[2]) then
	year, num = dab:match (patterns[2])
elseif dab:match (patterns[3]) then
	year= dab:match (patterns[3])
elseif dab:match (patterns[4]) then
	country, num = dab:match (patterns[4])
elseif dab:match (patterns[5]) then
	country, num = dab:match (patterns[5])
elseif dab:match (patterns[6]) then
	country = dab:match (patterns[6])
elseif dab:match (patterns[7]) then
	num = dab:match (patterns[7])
elseif dab:match (patterns[8]) then
	num = dab:match (patterns[8])
end

if not (year and country and num) then
	return false;
end

if year then
	...
end

if country then
	...
end

if num then
	...
end

—Trappist the monk (talk) 15:52, 25 May 2019 (UTC)

@Trappist the monk:, I've encountered a small issue which I don't know how to handle. Even-though I use ipairs to iterate over the table (line 84) and have ^(%d+) TV series, season (%d+) as the first entry (line 8-9) of the pattern list, values of "1999 TV series, season 1" are being handled by ([%D]+) season (%d+) instead (meant for "British season 1"), as can be seen on the testcasts. I've tried removing the other patterns and leaving only this one and its .type value is never "4" like I've set it to. The same system I've used with Module:Infobox television disambiguation check/sandbox, which works. Any idea why? --Gonnym (talk) 18:20, 27 May 2019 (UTC)

At Module:Sandbox/Gonnym/Infobox disambiguation check line 210 the dab includes a leading space. The pattern ^(%d+) TV series, season (%d+) requires the first character to be a digit (white space is not a digit so the test moves on to ([%D]+) season (%d+) where any non-digit character preceding <'season'><space><digits> is a match so 'TV series, season n' is a match. Removing %s from (string.match (title, '%s*%b()$') gives different results. I don't know if that space character is important. In Module:Sandbox/Gonnym/Infobox television season disambiguation check at validDisambiguationPatternList, you might also want to anchor the patterns to the beginning and end of the string '^...$'.

—Trappist the monk (talk) 19:45, 27 May 2019 (UTC)

I think I'll just go back to calling the code from Module:String, which I've tested after where you said the issue was, and the code now works. There is no reason to re-invent the wheel in this case, that code is tested and works, while me trying to get the same results resulted in hours wasted and non-working code. So far, all works. Thank you for solving this issue, it drove me nuts! --Gonnym (talk) 20:12, 27 May 2019 (UTC)

Emoji module

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 💬 ^they_them 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 💬 ^they_them 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}} →
{{emoji | {{emocode|smiley}} | size=24 | theme=noto}} →
{{emoji | {{emocode|smiley}} | size=24 | theme=noto 8.0}} →

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}} →

But not File:Noto Emoji Pie 1f9b8 1f3ff 200d 2640.svg →

{{emoji | 1f9b8 1f3ff 200d 2640 |theme=noto | size=24}} → 🦸 1f3ff 200d 2640;

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}} }} →
{{emoji | {{emocode | 8ball}} }} →

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 💬 ^they_them 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 💬 ^they_them 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

n

emoji and

k

invocations of emoname, pre-generating the reverse table reduces the time complexity from

O(nk)

to

O(n+k)

. Qzekrom 💬 ^they_them 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 💬 ^they_them 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}} → Lua error in Module:Data at line 17: Tried to read index "smiley" of mw.loadData("Module:Emoji/data").emotbl, which is a nil.
{{#invoke:Data|Module:Emoji/data|emorevtbl|1f603}} → Lua error in Module:Data at line 17: Tried to read index "1f603" of mw.loadData("Module:Emoji/data").emorevtbl, which is a nil.

This is because it's returning p.emotbl.smiley and p.emorevtbl.1f603. Qzekrom 💬 ^they_them 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}} →
{{#invoke:Data|Module:Emoji/data|emorevtbl}} →
{{#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)

you may be right regarding "template-syntax vs. lua syntax" (or rather, "template-syntax literacy vs. lua litercy"), though i doubt it. at least on hewiki, i'm pretty sure many of the people who are willing to edit templates, will refuse to edit lua code. it may be superstitious, and i may be simply wrong, but i believe this is so. regarding the "reverse lookup" - methinks this is a straw argument. this is something added to the lua module "because we can", but it has no real value. maybe you can think of a real world use-case for converting 1f62b to "tired_face" - i can't.

arguments aside, i have some constructive comments for your code:

it would be nice to be more lenient with the parameter: specifically, allow different case (i.e., convert param to lowercase in the function), white-space (convert any number of consecutive whitespaces to a single underscore)
allow multiple emojies in one call (i don't use emojis all that much, but i noticed that people who do, often times use more than one), so the module will be willing to take not only {{template name|sad_face}} but also {{template name| Sad Face}} or even {{template name| WINK | wink | Wink | nudge| NUDGE | Nudge }} to return 3 winks and 3 nudges. just a thought.
as to performance: it should be easy enough to create a 2nd "loadData module", say, "Module:Emoji/revdata", which will consume the "data" module and return the reverse, and only require it inside function emoname(). this way, the reversing only executes if emoname() is invoked (i.e., practically never, unless there's some usecase i can't think of), without losing any functionality. may be petty...

peace - קיפודנחש (aka kipod) (talk) 23:09, 26 March 2019 (UTC)

@kipod: (Aside: please check MOS:LISTGAP - it's good to be kind to the users of assistive technology.)

I wish I could help you increase the number of Hebrew editors willing to work in Lua. If you wanted to use the "course" I made for use when mentoring Google Code-in at the 9 pages from User:RexxS/GCI-Task01 to User:RexxS/GCI-Task09, you'd be most welcome.

I think that having the reverse lookup would be useful for anybody seeing a hex code (as is used in Template:Emoji) and wondering what the emoji's name was. I agree it wasn't part of the original request, but I was trying to encourage User:Qzekrom to see the possibilities of, and perhaps experiment with, the Lua code. I think I was successful in that. I've found throughout my life that increasing the technological investment in a given process rarely makes it any quicker or cheaper, but it does open up the possibilities to do more things.

Thanks for those constructive suggestions. I'm always happy to hear your critiques – they keep me on the ball.

I agree that it would be nice to allow a greater flexibility in what the code accepts as parameters. But I always intended this to be Qzekrom's code, not mine, so I'm hoping they'll read this and try to implement your suggestions. There's no better way to learn how to use string.lower(), string.gsub() and Lua patterns (documented at mw:Extension:Scribunto/Lua reference manual) than by trying them.

I'm not so sure that translating multiple emojies in one call would be as useful, unless we also upgrade Template:Emoji to accept multiple codes as inputs. Perhaps converting that template to Lua in order to simply the process of accepting multiple codes could be the next project for Qzekrom?

The problem of having a second loadData module is the old problem of having duplicate data sources. It's easy enough to generate a second data module from the first, but keeping them synchronised thereafter when updates on one or the other can occur is the nightmare for maintainers. No amount of bot runs and re-generating data is a good solution, and that's recognised in the industry. The solution is always to have one authoritative data source and create derivatives on the fly. That's the technique I was demonstrating for Qzekrom, and I strongly advise against worrying about the difference in performance between generating the reverse table dynamically once per page and reading a static second data source. I assure you that the difference is not only negligible when using Lua, but also completely insignificant compared to the issues of data integrity that attempting to synchronise two freely-editable static data sources will create. Cheers --RexxS (talk) 00:31, 27 March 2019 (UTC)

@RexxS: maybe i did not fully understand what you are saying (happened before, you may remember), but if i did, i think you did not understand me...

i took the liberty to modify your code a bit to demonstrate what i meant. there should be zero "maintenance" of the 2nd module - all the actual data still stays with the one table, the whole point of exiling the reversing piece into a 2nd "loadData" module is so it can be invoked only when reverse lookup is actually desired (i.e., very rarely). as a piece that meant to demonstrate an idea rahter than be "production", the new module (Module:Emoji/data/revtable) is more terse than is good for it. if you like it, you can remove the 2nd (reversed) table and the reversing loop from Module:Emoji/data, and everything still works. again, this is super petty - i totally agree with you that the reversing code and space is negligible. as to "multiple emojis in a single call" - i guess you are right, it would only make sense if the template that invokes it will change to make use of it (which i believe it has to anyway, to make use of the module...) as to the parameter "sanitation" comment - take it as directed not at yourself, but at the person who's supposed to take this demo and make it production code. peace - קיפודנחש (aka kipod) (talk) 02:23, 27 March 2019 (UTC)

My apologies, kipod I didn't properly parse the bit about 'consume the "data" module and return the reverse'. I can see exactly what you meant now. Indeed, that's a neat example of separating out the rarely used code, and I'll remember the technique for future use. Thank you. --RexxS (talk) 13:37, 27 March 2019 (UTC)

Wikipedia talk:Lua/Archive 8

Requested move 16 December 2018

List of parameters as one parameter

Requested move 27 December 2018

Lua pattern issue with en dash

Patterns: cannot use literal pipe character %|

Template:Gcd

Requested move 28 January 2019

Module request

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

Move request

upload / file determination

Help at Template:Article history

Location of test cases

Module to rationalise image scales

Convenience editing heading

Show a sequence

Module help request: Ancient Greek transliteration

Module:TimeAgo's calculations sometimes off by a week

Help for Wikidata module

Lua help

Module:College color and Module:College color/data

Retrieving a country adjective from country name

Newline above table

Module:Lok sabha constituency

Module request

References

Disambiguation check

Part 2

Emoji module