Template talk:Lorem ipsum

Purpose

For use where "nonsense" text needs to be inserted. Urhixidur 21:20, 3 March 2006 (UTC)

Other variations of template

A longer (and different) version is found in Template:Lorem ipsum dolor. Urhixidur 21:35, 3 March 2006 (UTC)

An even longer (and different) version, with a parameter to control the number of paragraphs, can be found in Template:Lorem Ipsum. Lambiam^Talk 18:27, 18 March 2006 (UTC)

(note: now, they all redirect to this page) Ajlee2006 (talk) 11:16, 28 June 2020 (UTC)

Category

Please can someone remove this template from Category:Templates and place it in Category:Wikipedia templates instead. I can't work out how. --RobertG ♬ talk 15:57, 10 November 2006 (UTC)

Done. I wasn't sure what category to put it in. A lot of new templates use the the template doc page pattern, which means documentation and categories are on a subpage that's transcluded in the main template... in this case, Template:Lorem ipsum/doc. – flamurai (t) 20:02, 10 November 2006 (UTC)

Question

Exactly, how many words do the whole "Loren Ipsum" thing has? I found on the website provided and got "Generated 150 paragraphs, 14360 words, 96947 bytes of Lorem Ipsum" by generating "1000000" words. --202.71.240.18

Lorem ipsum text

I would rather use an "original" Lorem ipsum:

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum., where no additive characters are used, only those, who appear already in the latin text (but of course not the whole latin text). E.g. instead of "adipiscing" use "adipisci" etc. If we leave it like it is, the "wrong" Lorem ipsum will be spread everywhere, not only in wikipedia. On the german Lorem ipsum site the original text is already used, it is the same as you can see on History and discovery. --Saippuakauppias 11:21, 1 June 2007 (UTC)

is this really the "original"? because now the adipisicing version has taken over the internet. Ajlee2006 (talk) 11:16, 28 June 2020 (UTC)

indexing by search engines

This ranks in google searches, which irks me for commercial reasons. However, shouldn't WP templates be excluded from search engines, as their content appears on article pages anyway, where indexing is pertinent? -Charlene — 88.72.12.159 (talk) 23:47, 15 March 2008 (UTC)

Newline bug from protect-tag

{{editprotected}} 26-June-09: Stop the newline-bug caused by the protect-tag. The top line of the template should be changed to join with the 2nd line (and stop the newline) by adding an HTML comment "<!--...-->" as follows:

<noinclude>{{pp-template|small=yes}}</noinclude><!--
--><includeonly>...

In templates like this one, that generate text-only (with no infoboxes, or tables or images), the top protect-tag will generate a newline (after the 1st line), unless it is followed by an HTML comment of the form "<!--...-->" to join the top 2 lines.

This is a systemic problem in Wikipedia, which only affects templates that generate inline-text, because other templates are not affected when they generate most infoboxes, tables or images.

The problem is based on another systemic problem in the MediaWiki markup language: consecutive <xxx> tag-groups sometimes leave newline-breaks when coded on multiple lines, although true HTML coding would suppress newlines between 2 lines of tag groups such as "<table><tr>" followed by line "<td>xxx</td></tr></table>". In true HTML, the newline would be suppressed after coding a "<tr>". The problem could be automatically fixed, for everyone long-term, by fixing MediaWiki to suppress a newline after "</noinclude>" or similar tags. It is a trivial issue, but difficult for some to comprehend.

Anyway, the problem can be expected to re-occur, with other protected templates that generate inline-text. -Wikid77 (talk) 11:36, 26 June 2009 (UTC)

The template was only semi-protected, but I fixed it anyway. — Martin (MSGJ · talk) 13:00, 26 June 2009 (UTC)

Retrofit talk-page year headers

26-June-09: I have added subheaders above as "Topics from 2006" (etc.) to emphasize the dates of topics in the talk-page. Older topics might still apply, but using the year headers helps to focus on more current issues as well. Afterward, I dated/named unsigned comments and topics (including "Purpose" & "Other variations of template") in date order for 2006. -Wikid77 (talk) 19:20, 26 June 2009 (UTC)

Category, again

Resolved

Should this template have a category?—Markles 20:50, 19 October 2009 (UTC)

It's in Category:Placeholder templates.  — SMcCandlish ☏ ¢ 😼  06:20, 29 July 2018 (UTC)

Semi-protected edit request on 19 October 2015

184.147.183.18 (talk) 01:40, 19 October 2015 (UTC)

 Not done as you have not requested a change, but I suspect you are in the wrong place, as this page is only to discuss improvements to Template:Lorem ipsum. - Arjayay (talk) 07:43, 19 October 2015 (UTC)

Needs safesubst

This needs safesubst markup, since if you substitute this to get lorem text with which to work further, you get the entire template markup instead of just the lorem text. I've made a few attempts at it, but keep getting gibberish output, no matter where I put the safesubst stuff, so I'm evidently lacking sufficient coffee and focus or something. Someone who does a lot of complex safesubst'ing will need to have a go at this.  — SMcCandlish ☏ ¢ 😼  06:19, 29 July 2018 (UTC)

PS: The category insertion code also needs a namespace test, as it should not apply that category unless it's used in mainspace.  — SMcCandlish ☏ ¢ 😼  06:23, 29 July 2018 (UTC)

SMcCandlish, is this still a legitimate item of interest? Recent changes for other purposes have simplified the code considerably, so that adding safesubt markup should be a trivial global substitution. However, it will make the code a lot uglier (doesn't it always?) so if it's not needed, let's not. Don't know if you still recall your use case, but would the simpler {{lorem ipsum span}} work for you? Substing that would be easier, and not particularly ugly. Mathglot (talk) 10:44, 7 August 2021 (UTC)

@Mathglot: It would be nice if both of them would cleanly subst, and not apply cleanup/tracking categorization when not used in mainspace.  — SMcCandlish ☏ ¢ 😼  04:41, 11 August 2021 (UTC)

Semi-protected edit request on 1 September 2020

{{subst:trimtytyrgytt|1=

}} 49.207.217.60 (talk) 10:53, 1 September 2020 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Seagull123 Φ 13:17, 1 September 2020 (UTC)

Possible bug in Template:testcase table code

A possible bug in {{testcase table}} code is causing some sandbox test cases to appear to fail, where invoking the sandbox directly does not fail. In particular: revision 1037022234‎ of testcases, shows rev 1037021742‎ of the sandbox *failing* with missing newlines between paragraphs. However, this appears to be an artefact of the {{testcase table}} template, because invoking the sandbox directly in ExpandTemplates or from a separate page works fine. This is one more reason to remove {{testcase table}} code and replace it with template {{test case}}. Mathglot (talk) 02:56, 4 August 2021 (UTC)

Linter error related to recent changes?

There are new Linter errors at Template:Fix-span/testcases and at Template:Update after/testcases, and probably other places, that appear to have been caused by changes here. In the former case, a span tag is being asked to wrap multiple lines from the template that include two line breaks, something that span tags are not allowed to do. – Jonesey95 (talk) 05:32, 4 August 2021 (UTC)

A simple case that shows the error (put in Special:ExpandTemplates):

{{fix-span/sandbox |text=er |pre-text=qw |post-text=ty |class=foo |title=This is a tooltip |date={{CURRENTMONTHNAME}} {{CURRENTYEAR}} |content={{lorem ipsum}} |span-class=bar}} – Jonesey95 (talk) 05:36, 4 August 2021 (UTC)

A different flavor of error has cropped up at Template:Edit fully-protected/testcases, also probably related to the recent changes here. – Jonesey95 (talk) 05:38, 4 August 2021 (UTC)

Is the zwsp entity doing this? The parser function is eating my needed line-breaks between lorem paragraphs, when args 2 and 3 are both empty. Another way to do this, if you're running into a wall, is to change all the */P1../P20 subtemplates and add the terminating line breaks at the end of the template. I'm just not sure if they would get trimmed upon transclusion or not. Another way, is to add html p-tags into the main template but the zwsp seemed simpler. However, if the p-tag works and zwsp causes problems, please let me know and I'll change it. Sorry for introducing linter errors; I'm unaware of these while working on templates, and if the test cases all look good, I usually think that I'm done. But, maybe not quite? Please advise. Thanks, Mathglot (talk) 06:01, 4 August 2021 (UTC)

How can I help? How about if I create a version based on sandbox rev. 1037041745‎ with all the {{zwsp}}'s replaced by <p></p>; would that help? Mathglot (talk) 06:29, 4 August 2021 (UTC)

See sandbox rev 1037047619‎; does that help? If that doesn't work, my next attempt would be to drop the zwsp and move the opening p-tag before each paragraph begin, if 2 and 3 are empty. If unterminated p-tags are not a problem, then that's the end of it; and if they are, then terminate the paragraph with p-end. Lmk, Mathglot (talk)

I have fixed the lint error now. The problem is the line breaks, they do so that the parser encloses the Lorem Ipsum inside a p-element. When someone then has enclosed a inline element around {{Lorem ipsum}} you get a lint error. You will still get a lint error if you are using more than one paragraph, but this is ok because then the error is correct (You should not enlose an inline element around block elements). I use User:PerfektesChaos/js/lintHint which makes it easy to see any lint errors on a page. Please test and do not hesitate to revert if I broke it again, but I think it this time should be ok. Tholme (talk) 18:45, 4 August 2021 (UTC)

@Tholme:, sorry, this breaks (almost all) test cases. For example:

{{Lorem ipsum|2}} should generate two paragraphs, but only generates one in rev. 1037135997

Note: The following is a result of doing {{subst:lorem ipsum|2}} at 20:37, 4 August 2021 (UTC) (i.e., when template rev. 1037135997‎) was live: {{#ifexpr:2>0|{{Lorem ipsum/P1|link=no}}{{#ifexpr:2>1| {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>1|{{Lorem ipsum/P2}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>2|{{Lorem ipsum/P3}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>3|{{Lorem ipsum/P4}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>4|{{Lorem ipsum/P5}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>5|{{Lorem ipsum/P6}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>6|{{Lorem ipsum/P7}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>7|{{Lorem ipsum/P8}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>8|{{Lorem ipsum/P9}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>9|{{Lorem ipsum/P10}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>10|{{Lorem ipsum/P11}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>11|{{Lorem ipsum/P12}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>12|{{Lorem ipsum/P13}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>13|{{Lorem ipsum/P14}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>14|{{Lorem ipsum/P15}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>15|{{Lorem ipsum/P16}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>16|{{Lorem ipsum/P17}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>17|{{Lorem ipsum/P18}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>18|{{Lorem ipsum/P19}} {{#if: || {{#if: || {{zwsp}}}}}}|}}{{#ifexpr:2>19|{{Lorem ipsum/P20}}}}}}{{#ifeq:|no||{{Template:Main other|[[Category:Wikipedia articles containing placeholders]]}}}} Note that the second paragraph content *is* present above; it starts "Curabitur pretiam...". The live template currently generates this for {{Lorem ipsum|2}}: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.

The previous content of the testcases page was admittedly hard to follow; I've kept the test cases (and added a few) and converted it to use template {{test case}} which color-signals the failing tests (i.e., when sandbox and template results disagree). This should help going forward, as failing tests will flip from collapsed and green, to expanded and yellow. (There is one failing test with {{lorem|0}} which has nothing to do with your changes; it is collapsed/green because it's in both sandbox and live.)

I understand that the problem is with line breaks. I plan to make changes to the sandbox to implement the p-tag solution I mentioned before, and which I hope will fix this. However, I don't have a way to examine linter errors directly, and I'll give you first refusal at the sandbox if you want to try again before I do that; please let me know if you prefer that I go first. Mathglot (talk) 20:37, 4 August 2021 (UTC)

@Mathglot: Sorry again, please try your fix and please ping me and I will check the linter error if needed. Tholme (talk) 20:56, 4 August 2021 (UTC)

@Tholme: no worries. Will need some time, as this fix exists only in my head. Will ping you when done. If there's some kind of "Linter 101" page you could point me to, so I can do my own checks, that might help. I have only the foggiest notion of what the actual problem is here. (I am aware that <span>...</span> cannot contain line breaks, and that that is somehow connected to the linter problem. But I don't know why we are talking about span tag in the first place; is someone trying to enclose {{Lorem}} output inside a span tag? If so, why can't they just stop doing that? It's the nature of Lorem to generate paragraph breaks, and enclosing it within a span makes no sense to me. Can they just change their spans to divs, and the problem goes away?) Thanks, Mathglot (talk) 21:13, 4 August 2021 (UTC)

Mathglot, I am working on the sandbox and I think I am close to a workaround. Let me know when you are done. – Jonesey95 (talk) 21:22, 4 August 2021 (UTC)

@Mathglot: You are right, and yes they should. The problem is that since they have already done it, and it was working without error before the changes to this template, someone else has to do the fixing. You can see some of the errors on this page: Special:LintErrors/multiple-unclosed-formatting-tags (atm i think all these errors are because of this template), it usually updates quite quickly, but there is some delay. You can ususally do a nulledit on one of the pages with errors and see if is removed from the error list to check if the error is fixed. See for example User:Hersfold/Adopt/Wikimarkup where you have this code: <small>{{Lorem ipsum}}</small>. It seems like this has been in a template or har been copied over to a lot of pages. Tholme (talk) 21:31, 4 August 2021 (UTC)

(edit conflict) @Jonesey95: Haven't even started; was trying to get the Testcases page in shape to make it easier for Tholme. (Testcases are all green at the moment; also, turns out the broken {{lorem|0}} was introduced by Tholme's last change, so is working again after the revert.) I'll hold off on my changes; you go ahead and go first, I'll wait for you. And no hurry at all; I've got plenty to do, take your time (days/weeks, really; no hurry). Mathglot (talk) 21:35, 4 August 2021 (UTC)

@Tholme:, thanks for that explanation; this is finally starting to make more sense to me. I'll see what I can dig up (outside this template) to maybe help things along. I'm hands-off right now, until J95 is done, and anyway I have things to do (wait, editors get to eat? sleep? That's not in my contract...) Mathglot (talk) 21:42, 4 August 2021 (UTC)

Small + Lorem fixup worksheet

@Tholme:, based on your last comment, I'm going to start fixing the problems I find. My first cut, is this list of 66 pages containing "<small>{{Lorem</small>". The vast majority of them are on User pages or subpages. Needless to say, there are no doubt many more, as that is an exact-match search, but it's a start. Mathglot (talk) 22:05, 4 August 2021 (UTC)

Tholme and Jonesey95, as part of my effort to assist in resolving the linter error issue, please note that I have created {{Lorem ipsum span}} and I intend to use this to alter occurrences of <small>{{lorem ipsum}}</small> (almost all in User space) to use the new span template. The new template emits a single string which is enclosable in tags in an inline context. I've seen no occurrence so far where a user has used a value higher than '2' in an inline context, so the new template either emits string 1 (Lorem ipsum dolor sit amet... or string 2 Curabitur pretium tincidunt.... I'll add new strings if anybody uses a higher value. See fixed up example here: User:Captain-tucker/Adoption Center/Wikimarkup. Mathglot (talk) 22:42, 4 August 2021 (UTC)

@Tholme: and Jonesey95, I may have fixed the problem by fixing all the uses of this template in inline context. Tholme, please rerun your link; for me, it shows no linter errors now. This doesn't mean the template can't be improved, and I'm not a fan of the {{zwsp}} solution, but I wanted to attack the linter problems first. Can we declare that problem fixed now? If not, please send me another link showing errors, so I can find more occurrences and fix them. Mathglot (talk) 23:27, 4 August 2021 (UTC)

That's not really a fix, unfortunately. ''{{lorem ipsum}}'' is still broken, for example. I've been playing around in the sandbox, and I can fix one problem, but then something else breaks. I'm going to keep trying a few more things. – Jonesey95 (talk) 23:56, 4 August 2021 (UTC)

In what way is your example broken? It's not broken for the main template, you can try it in Special:ExpandTemplates. The two ticks generate an i-tag, and it's true that you can't embed the block elements from the template directly inside the i-tag (which is inline context) because that's illegal, but the mw software creates a div tag, then a p-tag, and only then the i-tag (which is legal); and if you generate two paragraphs, such as for ''{{lorem ipsum|2}}'', mw creates one div, p-tags for the first paragraph, and i-tags (in the right place, inside the p-tags), but no i-tags for the second paragraph. (And also a stray pair of i-tags with nothing between it.) So the first paragraph is italicized, and the second one isn't. Which seems like a bug, not a feature, to me. The output from ExpandTemplates is:

<div class="mw-parser-output"><p><i>CONTENT OF PARAGRAPH ONE</i>
</p><p>​CONTENT OF PARAGRAPH TWO
</p><p>​<i></i>
</p></div>

If the mediawiki software allows the markup ''{{SOME TEMPLATE}}'', then theoretically it would need to distribute the i-tags to every p-tag pair within the div, but that's not what it's doing. In any case, this isn't anything we can fix I don't think, and would have to be bumped up to WMF. Pinging xaosflux for an opinion.

Back to our template issue: if breaking ''{{lorem ipsum}}'' is the only problem left, then there is no problem imho, or at least, it's not our problem. Are there other issues you've found? Afaic, the live template (rev. 1037154209‎) is working (except for the legit error you found with the scramble-it-all-together-no-line-breaks feature), and I don't think we have to change it (except for that). That said, I think the zwsp solution is a bit ugly, p-tags are probably cleaner; but if it works, it works.

Apart from the ''{{lorem ipsum}}'', are there any other linter errors? I've fixed all the ones I could find, and the link that Tholme included above which had dozens of linter errors, now has none after my fixes. Do you know of others? If not, let's declare victory and go home. Thanks, Mathglot (talk) 01:15, 5 August 2021 (UTC)

@Mathglot: Markup around a transclusion isn't expected to behave, if a template needs such an option it should be a parameter call to the template which can then switch or invoke the parameter to apply the styling within. — xaosflux ^Talk 01:35, 5 August 2021 (UTC)

@Xaosflux: thanks, not surprised. I don't know that we need that styling (if we do, as you pointed out, it's an easy fix), but your first statement was news to me. Do you think that someone sort of went halfway in trying to allow that case? Because clearly, the ticks start out on the outside, and then in paragraph one, they get turned into an i-tag and properly embedded within a p-tag, which in turn sits inside the div. So paragraph one is valid html and generates the proper italic style. If you look at the second paragraph code, however, there is no i-tag inside the p-tag pair, but then there's that empty <i></i> right after it—looks to me like someone was attempting to have it work for the second paragraph as well, and just messed up. What do you think? Is this worth filing a Phab ticket at WMF to fix their code generator? I can't see any possible reason for that empty i-tag pair sitting there, other than some bug or other. Something got popped in the wrong order. Mathglot (talk) 01:44, 5 August 2021 (UTC)

The parser/renderer is converting two errors, two unmatched italic tags, into valid markup by inserting matches for those tags. It flags those two errors as Linter errors. There is no guarantee that Linter errors will continue to be rendered in the old way in the future, so they are slowly being fixed by gnomes. We gnomes look at the error reports, especially in Template space where essentially all errors caused by transclusions have been eliminated; that is how this problem came to our attention. If you use ExpandTemplates and have LintHint turned on, it will highlight the errors for you. We need to go back to the old version and continue experimenting in the sandbox. – Jonesey95 (talk) 05:34, 5 August 2021 (UTC)

I tried to find them but I don't see them. If you can generate mismatched i-tags with a particular set of arguments for the current version, can you please tell me what they are so I can duplicate it? If I run something like {{lorem ipsum|3}} in a clean sandbox and examine the generated html, there are no i-tags, only p-tags, and they are all matched. If you are talking about your example above with italic wikimarkup outside the template, like this: ''{{lorem ipsum}}'', that's not a valid combination and we don't have to test for it. (See Template:Lorem ipsum#Notes about font styling, a new section of the doc page I just wrote, which summarizes this topic based on xaosflux's tip and everything else I've learned here, and suggests how to deal with bold, italic, or small text for lorem output.)

I've removed all such combinations I could find in favor of a working version, and the table of Linter errors that Tholme sent me with dozens of linter errors is now completely empty, except for one case on the Testcases page. I have linthint turned on, but if I click the little yellow box it doesn't show any errors and just turns green. Maybe that's because it's the first time I've used it, and I may be doing something wrong. Please tell me what error you are seeing.

There's a legit bug with the run-together-text issue, but I'm not sure how important this is. If you think about it, arg3 is documented as the "postfix" param, for adding ending text, like end-paren, or end-quote, and so on. The fact that placing a blank there causes a completely different behavior, namely what amounts to a string-join function, suggests to me rather strongly that someone made a virtue out of necessity; that is, they were encountering a bug in development of the postfix feature causing an unwanted join, and they couldn't get the aberrant string-join behavior to go away in their test case when they didn't provide a value and it was blank; so instead of backing it out, they simply declared it a new "feature", and voila--a cheap way to quit working on a bug. If you think about it, suppose that the template had no join feature currently, just the prefix and postfix params, and a user comes to Talk with a Requested template edit: "I want to reuse param 3, so that if it's blank (instead of null or absent) we join the content of all paragraphs together." What would be your response? I'd say, "Sorry, that's overloading an existing param with a completely different function in a very confusing way. If you want a join-everything feature, then request a new param |join=, and if |join=yes, then do the join, otherwise don't. We shouldn't overload an already existing param designed for something else." I'm sure you'd reject it, too,along the same lines, wouldn't you? So, my intended fix for the legitimately existing bug, is to add a new named param 'join' more or less as specified, document it properly, then recognize the legacy version of "param 3 = blank" as an alternate trigger for the join function, add the "join" param to the /doc page, and quit documenting the param 3=blank part of it, so it falls completely out of use and people use |join=yes instead. If there's even any use of the 3=blank trigger now, which is doubtful outside the testcases page. I'll do a search tomorrow, to see if there are actually any cases of anybody using that "feature".

One other thing: Tholme: thanks for the link to the Linthint gadget, I have it installed and I see the yellow box turning to green, but I've not seen an error table that it's supposed to generate in some cases. Can you give me some text I can place in Special:ExpandTemplates that will cause linthint to create a table of errors, so I can see what it looks like? I'm not getting an error table, just a green button, for the tests I try with the live version of {{Lorem ipsum}}. (Your example can be anything; doesn't have to be lorem; any string, any template, anything at all; I just want to ensure I've installed it correctly so it creates the table of errors when it's supposed to.) Thanks, Mathglot (talk) 08:23, 5 August 2021 (UTC)

Tholme, I finally found one that generates the table, so my installation of Linthint is working after all. The string that generated the lint errors is this one:

''{{bold div|{{Lorem ipsum|3|link=yes}}}}''

That creates a lint table with two entries, both "missing i end tag" (although I don't see any missing ones, just weirdly placed ones, discussed previously above with xaosflux). This was identified as an invalid wiki markup construction, so there is nothing to fix here as far as the template is concerned. The user shouldn't write code like that, and if they do, they're going to get uncertain behavior. One way to get what they're looking for, is here. Mathglot (talk) 09:00, 5 August 2021 (UTC)

Now that the new version is out, where does that leave us with linter errors? I don't see anything in the linthint gadget while running some of the examples from ExpandTemplates, but I haven't tried that many combinations yet, and also, I'm still new to the gadget. Mathglot (talk) 06:29, 6 August 2021 (UTC) @Tholme:, do you still see linter errors connected with this? If so, can you quantify it, compared to the number that were there before--is it about the same, worse, better, much better? Mathglot (talk) 08:21, 6 August 2021 (UTC)

Text doesn't run together anymore

I added test case 7 after seeing on the documentation page that the template is no longer running text together as it should. I think at this point, with at least three different kinds of bugs in production, we need to return the template to its overly nested, pre-zwsp state, and then continue to experiment in the sandbox. – Jonesey95 (talk) 00:04, 5 August 2021 (UTC)

@Jonesey95:, that's a legit bug, but I'll fix that. It's caused by the zwsp's; the solution is don't emit the zwsp's when they invoke run-together, and that's an easy fix. That's the only bug I'm aware of, and I'm not sure anyone is using that feature. Please don't roll back the template just yet. See comments above. Mathglot (talk) 01:16, 5 August 2021 (UTC)

By the way, the reason that one slipped through when I made my original changes, is that there was never any test case for the run-together-text feature, so when I made my changes and went to the testcases page, when I saw that all cases were working, I assumed that version was good. As you discovered, that's not the case, due to the missing test case. (And there may be other test cases that are missing as well.) Mathglot (talk) 01:24, 5 August 2021 (UTC)

I detailed it more in the subsection above, but I'm planning on adding param |join= as an explicit named param to trigger the "join-everything" function, with param 3 = blank as a second, (and kinda weird) alternate trigger. More on this later. Mathglot (talk) 08:28, 5 August 2021 (UTC)

That sounds like a better, more deliberate suggestion. I don't like it when blank parameters change a template's behavior. – Jonesey95 (talk) 14:19, 5 August 2021 (UTC)

The bigger part of the "join" bug which we haven't explicitly mentioned (so I will now) is that any value for param 2 or 3 triggers the join (or maybe just 3). This is because of the "ifnot (2) and ifnot (3) then (zwsp)" code; so even a quote mark or a parenthesis is non-empty, and blocks the needed newline and it shouldn't. That's a part of the "join" bug as well and if it's serious enough we can roll back (although I'd prefer to see if anyone is squawking, so far crickets?). Adding the explicit join is next; glad you approve. To some extent, I question if anyone really needs "join" functionality, but I think it has to be there now, if only to provide backward-compatibility for a functionality that has already been documented for a long time, and thus is "out of the bag" so to speak. (I've never seen any outside implementation that supported such a join functionality for lorem, so it's a weirdo, but whatever.) Mathglot (talk) 19:01, 5 August 2021 (UTC)

As noted elsewhere, this is working now. Mathglot (talk) 06:17, 6 August 2021 (UTC)

New section on font styling added to /doc page

One of the rabbit holes we tried to run down, was attempting to fix the template for invalid cases like ''{{lorem ipsum}}'' (ditto for bold or <small> text). I've added a new section on font styling to the /doc page to explain that these produce unpredictable results, and providing alternatives.

The new section is #Notes about font styling. Hopefully, this will help users using this template to find the results they are seeking without running into the same problems. Please review/adjust as you find necessary/helpful. Thanks, Mathglot (talk) 03:59, 5 August 2021 (UTC)

Looks good. I have added some testcases. It looks like a bit of tweaking is still needed to display multiple wrapped paragraphs (they currently display all in one big paragraph), but I think this is the right approach. – Jonesey95 (talk) 14:19, 5 August 2021 (UTC)

New version with |join= is live; wrapping still t.b.d. Mathglot (talk) 06:15, 6 August 2021 (UTC)

Wrapping now works, with the latest version. Mathglot (talk) 10:36, 7 August 2021 (UTC)

Join functionality

@Jonesey95:, Just wanted to check in with you before implementing this, because thinking about the design does raise a few questions we maybe hadn't thought of before. In particular, it's not completely clear whether join plays nice with prefix and suffix, or even what it would do exactly if both were allowed at the same time. Right now, you can't have both at once; or at least, not join+suffix, because 3 is overloaded for both. Theoretically you could have join+prefix, but what would that even mean? Possibly parens or double quotes, but all joined together? Numbering or bullets, in the middle of a line? Dunno about that, might need a discussion and wider consensus.

So, really there's kind of an implication already, that if you have join now (i.e, 3=space), then you don't have suffix anymore, and since prefix makes little sense without suffix, I'm comfortable with saying that for the new param, "If we have param |join=yes then we suppress prefix and suffix". If we decide we want to allow both at once, that's kind of new functionality, and we can open it up to see how everyone wants to define that. But really, I think that's overkill for something like lorem ipsum, which is really kind of simple in concept. Anyway, unless you have an objection, I plan to implement join this way, at least at first.

Btw, this makes the implementation nice and clean: start off at the top checking #if |join=yes, then a simple join of /P1../P(n), else proceed to current code section. Sweet! Lmk, Mathglot (talk) 21:27, 5 August 2021 (UTC)

I think we should boldly get rid of this functionality. I think that this is a search of all namespaces for this functionality in use, and there aren't any. My insource search may be wrong, though. What do you think? – Jonesey95 (talk) 22:49, 5 August 2021 (UTC)

@Jonesey95: I'm fine with it, but we should maybe get buy-in from a few regulars here, as well as maybe a few trusted templates folks that aren't involved. I'll get back to that in a minute; what I actually came here for was to give you a progress report.

So, I'm doing a phased approach, with phase 1 completed now, namely, adding new param |join= to support that functionality. That's now in the sandbox and working: test cases 7b-7f are all working exactly as desired. (7a is the legacy case for the blank arg3.) Phase 2 is next, and would be adding in the blank-arg3 trigger to the condition at the top; but if we get rid of the functionality completely, then we don't need it, or phase 1 either for that matter. Alternatively, we could keep the |join= param because it's functionally clean for the user, and for the template coding, and just junk the wacky blank-arg3-trigger, which would keep the join functionality, but shift it from blank-arg3 to the new param, which wouldn't be a terrible solution. I started in on phase 2, you can see the effects of it in new subtemplate {{lorem ipsum/joinreq}}, but we won't need it, if we drop the wacky trigger. Even with it, keeping that trigger is pretty ugly, and I'd love to junk it.

I can either hold off on phase 2 (adding the arg3 join trigger condition to the sandbox) until we get consensus to keep or drop it, or I can just go ahead and put it in anyway (I know how to do it now, it's no big deal) and remove it later if we get consensus for removal. Maybe the next step is to create a new top-level discussion for a separate proposal to junk the blank-arg3 trigger for join, or to junk join functionality completely, so editors don't have to wade through this long thread. Top editors of this template are here, and we should also loop in WOSlinker, Tholme, and folks like Trialpears, Primefac, maybe xaosflux since he was briefly involved – I'm probably forgetting a few usual suspects, – and we should add a neutral message to WP:WikiProject Templates. Want to write the proposal, or should I? Obviously, I'm an immediate support vote if you write it; I'd probably vote to keep the new param since we already have it (in the sandbox), so why not; but I'm not married to it, and am fine with ditching it if consensus prefers that approach. Lmk, Mathglot (talk) 01:25, 6 August 2021 (UTC)

If you can make |join= work easily, then go for it. Let's definitely get rid of the "blank parameter different from no parameter" approach, though. Also, please see the section above for a bug report in which wrapping the template in a div appears to trigger unrequested paragraph joining. I think that is a more important, though probably less fun, issue to work on. – Jonesey95 (talk) 02:04, 6 August 2021 (UTC)

Cool; will do. I'm with you: i hate the "blank param different than no param" (and on top of that, "non-blank param, does something completely different"; happy to get rid of that. I guess we can see if anybody squawks and put it back if we have to. Can't imagine too many in favor of such squirrely functionality, other than possibly for backwards compatibility, but as you pointed out, doesn't seem like anybody's even using it. Wouldn't be surprised if the "div-wrapping" issue is related to the "blank param" issue, and as soon as I remove that, I bet it will just go away. We'll soon see. Mathglot (talk) 02:50, 6 August 2021 (UTC)

 Done. Param |join= is now live, and a space in arg3 no longer means anything special. The div wrapping issue remains, but that's relatively minor since until our doc page update, I doubt anyone ever used it. I I'm done for today, thanks for everything! Please check it over, see if I missed anything, and more test cases are always good. Doc page updates still t.b.d. Ttyl, Mathglot (talk) 04:09, 6 August 2021 (UTC)

Non-list prefix bug

Jonesey, there's still a bug that was there before that I noted off-wiki for fixing along with this update, and then forgot about with all the 'join' stuff, so it's still there now. Namely, when "prefix" starts with a list or indent-style element (hash, asterisk, colon) then skipping insertion of the zwsp is the right thing to do, because any of those metacharacters causes a line break. However, the current code skips insertion of zwsp for any prefix, so, even for a parenthesis, or a double-quote, or an 'X', and then the paragraphs get joined, where there should be an introduced zwsp. The fix is to only skip it for those three. (Or use p-tag instead of zwsp, which I still prefer.) I'll add test cases for these tomorrow (unless you get there first). To see the bug, compare output of {{lorem|2|:}} with {{lorem|2|X}}. Thanks, Mathglot (talk) 07:01, 6 August 2021 (UTC)

@Jonesey95:, fixed everything with a simplifying rewrite, which is actually just an upgrade from earlier revision 1037020305, dropping zwsp, and adding p-tags. (Also integrated the join logic in the main body, instead of separately at the top.) The p-tag logic is farmed out to subtemplates to make the main-line code transparent and easier to follow. Having the p-tags properly allocated in the output also resolved all the outstanding "wrapping" issues. The testcases page could stand some more "prefix" and "join" cases.

This is the baseline I was going for, because the old, super-nested version was essentially unmaintainable and unalterable, and had hidden bugs not exposed by the rump testcases page at the time, along with that screwy, overloaded, prefix param. The code is solid and looks clean, now. Not saying there isn't some niggling little bug I missed, but if there is, it must be something fairly minor since all current test cases look good; and if there is one, at least it will be easier now for anybody to approach the code. WOSlinker, thanks for your contributions fixing up some of the intermediate versions; Tholme and Jonesey, thanks for the help and education on linter. Nice collaboration, everyone. Mathglot (talk) 01:54, 7 August 2021 (UTC)

By the way, just a design note: all of the paragraph separation (or, not-separation) between lorem paragraphs is now handled by the three sub-templates; the main code is agnostic to how this is achieved. Currently, it's via Html p-tags (or absence of them), but if that's undesirable for some reason, it could be changed to newlines by adjusting the sub-templates only, letting the mw software change newlines to paragraphs. Mathglot (talk) 04:06, 7 August 2021 (UTC)

Missing /p tag for limited character count

Nice work, Mathglot! The only minor bug remaining is in the documentation page (and now in testcases), where {{str left}} is recommended for limiting the character count. The template outputs an opening p tag but does not close it with /p. I'm guessing that the easiest way to fix this error is to add |limit= or |characters= within the template itself instead of using str left as a hack to show less than a whole paragraph. – Jonesey95 (talk) 20:57, 7 August 2021 (UTC)

@Jonesey95:, thanks. I think we can handle that with a doc page-only change. Either of these work, and could be the basis for a doc page change:

• {{str left|{{Lorem ipsum|join=yes}}|123}}
• {{str left|{{Lorem ipsum span}}|123}}

In the top one, the "join" version generates an inline-level Html element, and in the second, the "span" version always generates inline-level elements. Since the latter was designed for that, and that example is simpler (why explain why they have to use "join" with a single paragraph?) I've opted for the second one and tweaked the /doc accordingly. See what you think: Template:Lorem ipsum#Limiting character count to less than one paragraph. Once we settle on the wording, I'll copy the same text to Template:Lorem ipsum span/doc as well. Test case fix coming up. Mathglot (talk) 21:42, 7 August 2021 (UTC)

That works great. Much better than my proposal. – Jonesey95 (talk) 23:04, 7 August 2021 (UTC)

Testcases and both doc pages updated. Mathglot (talk) 02:36, 8 August 2021 (UTC)