Template talk:Lorem ipsum
Page contents not supported in other languages.
For use where "nonsense" text needs to be inserted.Urhixidur 21:20, 3 March 2006 (UTC)[reply]
A longer (and different) version is found in Template:Lorem ipsum dolor.Urhixidur 21:35, 3 March 2006 (UTC)[reply]
An even longer (and different) version, with a parameter to control the number of paragraphs, can be found in Template:Lorem Ipsum.LambiamTalk 18:27, 18 March 2006 (UTC)[reply]
(note: now, they all redirect to this page) Ajlee2006 (talk) 11:16, 28 June 2020 (UTC)[reply]
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)[reply]
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
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)[reply]
is this really the "original"? because now the adipisicing version has taken over the internet. Ajlee2006 (talk) 11:16, 28 June 2020 (UTC)[reply]
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)[reply]
{{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)[reply]
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)[reply]
Should this template have a category?—Markles 20:50, 19 October 2009 (UTC)[reply]
184.147.183.18 (talk) 01:40, 19 October 2015 (UTC)[reply]
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)[reply]
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)[reply]
{{subst:trimtytyrgytt|1=
}} 49.207.217.60 (talk) 10:53, 1 September 2020 (UTC)[reply]
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)[reply]
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)[reply]
{{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)[reply]{{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)[reply]{{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
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. |
{{lorem|0}}
which has nothing to do with your changes; it is collapsed/green because it's in both sandbox and live.)<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)[reply]{{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)[reply]@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)[reply]
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)[reply]
@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)[reply]
''{{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)[reply]''{{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>
''{{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.''{{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.''{{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)[reply]{{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.)|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".''{{bold div|{{Lorem ipsum|3|link=yes}}}}''
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)[reply]
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)[reply]
|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)[reply]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)[reply]
@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)[reply]
|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.|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)[reply]|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)[reply]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)[reply]
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)[reply]
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)[reply]
{{str left|{{Lorem ipsum|join=yes}}|123}}
{{str left|{{Lorem ipsum span}}|123}}