Template:Notice is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should be proposed here first. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use ((edit protected)) to notify an administrator to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

Archives

Archive 1 Archive 2

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

All of these are coded up and well-tested, in Template:Notice/sandbox2.

Accessibility fix

Per the Manual of Style at WP:ALT and per WP:ACCESS guidelines:

When this has a custom image, this has to support an |alt= parameter and should default to an empty but present parameter. This will all match the behavior of ((Ombox)) without a custom image. I.e., introducing the custom image parameter without accounting for "alt" was a bug, because some images can contain text and stand in for text, in a meaningful way (i.e., require alt text), while most are simply visual candy and should be hidden from text-to-speech browsers and text-only browsers.

Basic English fix

Per WP:COMMON, WP:UPE:

The "header" parameter needs to be changed to "heading", with "header" retained as an undocumented alternative so that existing instances do not break, and the docs updated to use "heading" not "header". A "heading" is stand-out text that identifies (and usually precedes, and often summarizes) a section, chapter, etc. Examples include the <h#> heading tags in [X]HTML, or the short phrases that appear above the prose at the beginning of a book chapter. A "header" is metadata, usually invisible to the user, that provides information (usually technical) about a follow-on document or other content. Examples include HTTP headers and the <head> sections of [X]HTML documents. This "header-for-heading" confusion is a very common mistake, but it is is an error, and we shouldn't intentionally perpetuate it. Encyclopedias are supposed to be precise, and all that. :-) — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:59, 28 January 2010 (UTC)Reply[reply]

Usability fix

Per WP:COMMON, WP:USE:

<div style="text-align:center;"> should be<div>. All that is needed is for the heading to be a div and bold. The centering is unlike any other such messagebox on the entire system as far as I can tell, and is actually a major usability problem, since English speakers read left-to-right, and this heading could be important, but will never even be noticed by many users, especially in cases where the main text message of the template is short.

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:38, 28 January 2010 (UTC) Updated — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:50, 28 January 2010 (UTC)Reply[reply]

Not done - Since I am not a native English speaker and this is tricky stuff it takes me at least half an hour to write up the explanation. So hang on while I write it.

--David Göthberg (talk) 17:07, 28 January 2010 (UTC)Reply[reply]

Nevermind; I got your user talk note. Will fix the image issues. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:28, 28 January 2010 (UTC)Reply[reply]

Now fixed. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:46, 28 January 2010 (UTC)Reply[reply]

1: Oops, I read wrong. I mixed up "alt=" text and "link=" links. Okay, adding the "alt=" parameter is okay. (As you know I had just reverted another edit of yours involving "link=" links.)

2: My Oxford dictionary says:

Header = A line or block of text that is automatically added to the top of every page that is printed from a computer. (Compare footer.)

Heading = A title printed at the top of a page or at the beginning of a section of a book.

So you are right that "heading" is slightly more correct here, but "header" is not always invisible meta-data, it is only in computer communications and similar that "header" is something the users don't see. And in HTML tables we put the heading in the "header cells". So the difference is only subtle. If you do a search in template space you get almost four times as many hits on "header" as "heading", and "header" is shorter and easier to spell. Templates like ((editnotice)), ((navbox)) and the documentation of ((navbox)) use "header". And this template is widely deployed since a long time. So I object to bloating the template code for this.

3: Personally I slightly prefer the current centred heading. But more importantly, that heading has been that way for a long time and this template is widely deployed. So if you want to change that, then you should first achieve a new consensus.

So to sum it up: I only "agree" with the addition of the "alt=" parameter. But I won't do that edit for you since I keep well away from anything that has to do with the accessibility people. So I suggest you do a new editprotected request involving only the "alt=" parameter.

--David Göthberg (talk) 17:58, 28 January 2010 (UTC)Reply[reply]

[I'm going to fork this into separate replies so they can be dealt with individually.— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:06, 28 January 2010 (UTC)]Reply[reply]

1.alt= fix:

No issue to resolve, then. So, yes, install the alt= code that is triggered when |image= is used.

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Compliance with basic requirements of policies and guidelines does not require discussion, per WP:POLICY (nor does fixing stuff without having a big talk about it first, per WP:BOLD).

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:06, 28 January 2010 (UTC)Reply[reply]

No, compliance with "guidelines" do have to be discussed and resisted when the guidelines are broken. Several of the usability guidelines have been written by a small number of editors without any regard for what is good for Wikipedia as a whole and without a broader consensus. (Especially the "link=" stuff has been written by a single editor without any regard for what copyright law says, and totally without consensus.) I have time after time pointed out better technical solutions that would make things better for our blind readers, but the usability people don't want those solutions. Those methods would make the usage of "link=" and "alt=" unnecessary. So I won't do any edits in support of the current usability crusade, I leave that to others.

--David Göthberg (talk) 21:30, 28 January 2010 (UTC)Reply[reply]

The link= stuff no longer has anything to do with this conversation. And I didn't ask you to fix it. You said yourself that you didn't have a problem with it and recommended putting back up an editprotected about it. Why the argument? I realize that I put you on edge earlier today with edits relating to | in a different template, but that's nothing to do with this template and the code changes sought here. You've made it clear that you don't want to have anything to do with accessibility/usability stuff. That's what all of this is about, so maybe just don't object if you don't want to be involved? — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 23:10, 28 January 2010 (UTC)Reply[reply]

Oops, I didn't mean to object to adding the alt parameter. My above message was a response to your sentence "Compliance with basic requirements of policies and guidelines does not require discussion". It was not really meant as an objection to adding the alt parameter. Although when re-reading my comment I realise it sounds like I object to adding the alt parameter. But I leave it to someone else to add the alt parameter. (For a number of reasons that are not very relevant to discuss here, sorry that I hinted at those reasons.) So whoever else reads this: Go ahead and add the alt parameter.

--David Göthberg (talk) 09:59, 29 January 2010 (UTC)Reply[reply]

SMC: could you clarify what you want doing exactly? Template:Notice/sandbox2 seems to contain the code for all these changes, some of which do not have consensus yet. I imagine you are asking for this edit? — Martin (MSGJ · talk) 10:44, 29 January 2010 (UTC)Reply[reply]

It's even simpler. The | code in particular shouldn't be added, for reasons David went into elsewhere. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:51, 29 January 2010 (UTC)Reply[reply]

2. heading option

Both will work, so who cares? NB: The reason that WP templates frequently use "header" is, well, because WP templates frequently use "header". That is, once the error becomes effectively permanent by appearing in some widely-used templates, it starts spreading to other templates as template code is copied from one template to another. The only way to mitigate this is to correct the already-extant errors and stop propagating them. There is no reason not to start with this template and move on from there.

I'm a bit at a loss what to do about your objection, since it amounts to WP:IDONTLIKEIT without having any basis in usability, technical restrictions, policy/guidelines or other objective concerns. Adding a tiny bit of code is hardly "bloat". For bloat, see the source of Template:WPBannerMeta.

Another way of putting it: If I created a template that used a |rationalle= parameter [sic], and no one really noticed or cared for a while, would you object to someone suggesting that the correct word |rationale= actually be supported as an option, and call the correction "bloat" and suggest that it shouldn't be implemented simply because time has passed and deployment has been wide, even though nothing at all has to be done about already-deployed cases? It certainly doesn't require any bots or AWB sessions to correct usage of |header= to |heading=.

Basically, it's just wrong (in the sense of functionality, not morality) to force editors like me who know the difference between a heading and header to try to somehow remember to use an incorrect term (!!!) for this template just because some other people are used to it and don't care.

(NB: I did not say that headers are always invisible. I also did not include every possible definition of the word; the one for paged media isn't relevant here, since this isn't a paged medium).

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:06, 28 January 2010 (UTC)Reply[reply]

You are requesting that we add a second name for the "header" parameter. That means we have to support both names forever, and it means the code will be harder to edit forever. Unless someone does the huge effort to edit all pages that use this template. I don't see you offering to do that work. Experience has shown us that it is a bad idea to have several names for the same parameter. And "header" is a good enough name for that parameter, so no need to change it.

--David Göthberg (talk) 21:30, 28 January 2010 (UTC)Reply[reply]

I know what I'm requesting, me being me and the request being mine. The objection raised is trivial. There is no "bloat" or "difficulty" at play since these templates are utterly simplistic. I've already explained why there's a need to change it: "header" is incorrect (even you admitted that!) and it's nonsensical to expect normal editors to memorize someone else's errors and use them on purpose in order to get around a bug in a template. Just fix the template to no longer require (not "no longer support") the error. There is no need to do hundreds or thousands of edits, since there's no proposal to no longer support the wrong but already-used version (cf. red herring). "Header" is not a "good enough" name, since it is incorrect. I've already explained this 3 times now. Your objecting on this one is starting to sound like WP:FILIBUSTER to me, by way of WP:IDIDNTHEARTHAT. I'm not going to keep repeating myself. If you find the code too complex and "bloated" to manage, there are many others for whom this won't be a problem. Also, there is no consensus at all that having multiple names for a parameter here and there is a big deal, and in fact it is quite common, in templates that are both simple (various inline cleanup templates) and very complex (most if not all of the citation formatting templates like ((Cite news))). I'm sorry that you don't like the idea, but that's not a valid reason to prevent it moving forward. Don't like it, don't use it. You can use |header= all you like.

Honestly, I've never encountered this much resistance to such a simple change (I've even already provided the code!) that has no negative impact on anyone, anywhere. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 23:10, 28 January 2010 (UTC)Reply[reply]

PS: A concern you ought to be more aware of than most is that not all en.wiki editors are native English speakers, and cannot be expected to know that some English speakers treat "header" and "heading" as interchangeable. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 00:42, 29 January 2010 (UTC)Reply[reply]

As a non-native English speaker I don't assume any parameter names. Instead I check the documentation of the templates before I use them.

I have programmed templates at Wikipedia for some years now. Sadly I have spent some work months of that on cleaning up problems caused by templates using multiple names for the same parameters. That's time I could have spent on more productive things. So don't tell me that having several names for the same parameter is not a bad thing. So I object to adding more names to a parameter when it isn't necessary.

--David Göthberg (talk) 10:21, 29 January 2010 (UTC)Reply[reply]

3. Left-justification

That's fine; I don't have any issue with discussion. So, what objective reason for keeping it centered does anyone have, that trumps the two objective reasons I've already given for left-justifying it? "It's been that way for a while" doesn't really qualify (all progress on everything, world-wide, would stop if that were a good reason to resist change). Heh. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:06, 28 January 2010 (UTC)Reply[reply]

You happen to first look at the left of the boxes, while others first look at the middle of the boxes. Your arguments for left justifying the heading is just your personal preference, it is not objective reasons. Having it left justified or centred is just a matter of personal preference. So since we are two editors with different preferences here, the normal thing is to leave it as it has been for a long time now.

By the way, things you say seems to hint at that you are using some very high screen resolution. What resolution do you use?

--David Göthberg (talk) 21:30, 28 January 2010 (UTC)Reply[reply]

Sorry, but this is supported by decades of eye-tracking studies and other controlled usability research. You actually have to pay real money for the materials I'm talking about, particularly the web-focused work of the Nielsen Norman Group (which strikes me as the most relevant and which I've had a lot of experience with through my work), so I'm not sure what to cite to you; Nielsen's own separate usability site at UseIt.com probably has material on this. Yep: Here's a couple: [1](top-left start, to right then down then to right again; this "news" is almost 14 years old now). Basically, pretty much no one looks first at the middle. This is why (in L-to-R languages) around 99% of Web pages have branding top left and basic navigation starting top-left; Microsoft Word and probably every other word processor defaults to putting headings, at all levels, flush-left; [XHTML headings default to flush-left positioning, as do all other elements; the style guides of academic publishers almost universally call for flush-left headings on submitted papers; newspapers and magazines vastly prefer flush-left (newspapers tend to reserve centered headings for teaser captions above images, like my local papers's "State of the Union: 'I Don't Quit'" front page Obama picture caption this morning; everything else is left-justified); and Wikipedia itself left-justifies everything, including headings of all sorts, table and image captions, etc., etc. So, no, it's not just my personal preference. It's an entirely objective assessment that centered placement is unusual. Aside from above-picture captions in newspapers, huge-font titles on book and DVD covers and greeting cards (where position isn't an issue - the text can't be missed) and above-window window captions in MacOS and some GUI interfaces for *n*x, I'm having a hard time actually finding centered headings and heading-like text in any professionally-produced media around me, online or offline. Like, I'm literally looking on my desk and shelves and coffeetable. Even most magazine titles seem to be left-justified (why not books? I dunno...) If you want to make the text in the heading be 50 point, I can see a rationale for centered justification, but I think everyone would object to the font size. :-)]

[2] [3]

[null ]

[null ]

[null I'm not sure what else to tell you. I don't need a lecture on consensus, and I can count: I know you are one editor and I am one editor and I know that we do not have consensus for a change. That is why I have not put an editprotected back on this section yet. Believe it or not, I can tie my own shoes too.  :-/ Sorry this got off on the wrong foot (no shoe pun intended), but it clearly has. I didn't come here to argue. I came here to fix three glaring problems that have real reasons behind the proposed fixes. If you want me to continue wasting my time (this has taken over an hour of pointless research), I can do so, but I'm not going to be happy about it. Do you really care that much if a heading is centered and an correct word is rejected because it adds one line of template code? — ]SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 23:10, 28 January 2010 (UTC)Reply[reply]

PS: I used various resolutions. I have a widescreen (19whatever x 1200) laptop in front of me, an 1024x768 (sometimes 800x600, for testing) laptop next to it, and a 1280x1024 desktop on a side desk. I do not browse in full-screen mode, but always in a window around 65-80% screen width, so I'm not sure my monitor rez has much to do with anything. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 23:54, 28 January 2010 (UTC)Reply[reply]

If usability were our only concern, then Wikipedia would have a very boring look. We do some things because they look good. And some of us thinks that headings inside boxes look better when centred.

--David Göthberg (talk) 10:29, 29 January 2010 (UTC)Reply[reply]

4. "Crusade"?

Resolved

 – Just a misunderstanding.

I have to ask: Why argue about usability and accessibility if you don't care for the topic and characterize those who do as being on a "crusade" (see your comments under point 1, above)? All three of these are usability or accessibility issues (two strongly so). So why do you care? What's the point of a discussion if you've already decided I'm a "crusader", a term that would seem to only be wiki-definable in terms of WP:SOAPBOX, WP:GREATWRONGS and/or WP:POINT? I doubt that WP:WPACCESS think of themselves as "crusaders" nor as being as irrational as you paint them. What technical solutions are you proposing that are being ignored? I'd like to see what the objections are; if some of them are boneheaded, I'll say so. Just because some of the accessibility-focused editors have in mind this solution or that doesn't mean it's the only one that should be considered, and yours should be among them. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 23:24, 28 January 2010 (UTC)Reply[reply]

That's not what I meant. I care for usability way more than you think. I have had friends that were deaf or blind. And I have worked as a computer teacher at the main hospital in my city, teaching disabled people to use computers and fixing adaptations so they can use computers. (And the reason I have time to edit Wikipedia is that I now am retired due to my disabilities. Although my disabilities only partly affects what computer interfaces I can use.)

By the way, back in the early 90's we used to say: "As long as you have one muscle in your body you can control, then we can get you online." But since the end of the 90's we have thought controlled input interfaces. I am not kidding, it works, but it is very slow. The device is a headband with some EEG sensors in it, then you use two different feelings to select 0 or 1, thus enabling you to select characters and commands. For starters it is good to use two strong feelings, like sex and anger. But after some training most users switch to some lighter feelings since using sex and anger all the time is tiring. :))

A funny thing is that most normal people expect the 100% paralysed patients to write something profound when they are first connected to the thought controlled computer. But usually they instead type something like: "Please, no more tomato soup, I hate it." or "I want an extra pillow." (But usually in much shorter words.) They spend the first day or two informing of such things. Then they start writing messages to their relatives etc.

But I am getting off topic. The usability people here at Wikipedia often use bad technical solutions, so I won't do such edits for them. And I will continue to resist anything that I think is detrimental to Wikipedia.

--David Göthberg (talk) 11:21, 29 January 2010 (UTC)Reply[reply]

I think I'd be tired of tomato soup too. Ha. Okay, sorry I misunderstood you. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:28, 29 January 2010 (UTC)Reply[reply]

5. Misuse of caption

The |Notice caption should be removed from both lines of image code, as this is dead code, basically. Inline images does not have captions, and the code will (per #1 above) already have an |alt=. I've looked at other templates like this (((Copyedit)), ((Notable Wikipedian)), ((POV)), etc.) and none had captions like this, regardless of their intended namespace(s). — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:59, 29 January 2010 (UTC)Reply[reply]

Any support for the notion of using a non-vomit aesthetic for talkpage notices? Just throwing it out there. Skomorokh 19:19, 4 August 2010 (UTC)Reply[reply]

That's ((mbox))'s doing; probably worth bringing up centrally there. Chris Cunningham (user:thumperward: not at work) - talk 11:42, 16 October 2010 (UTC)Reply[reply]

... should be prohibited. The current ~50 transclusions show all sorts of misuse: human spaceflight uses it as an amateurish disclaimer, Saint Helena uses it as a sort of hand-hacked ((cleanup-tense)), Henry Bessemer as a collaboration banner, disability as a badge of shame / dispute tag, and Guanajuato as a hand-hacked ((update-section)) - and that's just the first five! If there are no objections I'll plug in some code which errors this out if used on mainspace with a note to the effect that it's not intended to be used for hand-hacked cleanup or dispute tags, and that social banners belong on the talk page. Chris Cunningham (user:thumperward: not at work) - talk 11:48, 16 October 2010 (UTC)Reply[reply]

Should we have a warning come up if it is tried to be used in article namespace? -- Alan Liefting (talk - contribs) 00:54, 11 May 2012 (UTC)Reply[reply]

When used as in the small mode the line spacing varies. It is wider when opposite the icon. See User talk:Alan Liefting. -- Alan Liefting (talk - contribs) 00:52, 11 May 2012 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can I get class and style to be passed to ((mbox))? I placed my suggestion for doing this into the sandbox. Thank you. 50.53.15.51 (talk) 15:24, 21 June 2012 (UTC)Reply[reply]

The change described above seems uncontroversial, but there is some other stuff going on in the sandbox as well. Can you detail all the changes you are proposing? — Martin (MSGJ · talk) 15:56, 21 June 2012 (UTC)Reply[reply]

I am only proposing passing the class and style as evidenced by this edit. I did notice there were other changes in the sandbox but they were not mine. 50.53.15.51 (talk) 11:59, 23 June 2012 (UTC)Reply[reply]

Okay, fine. So my only other comment is about the use of the style parameter.

| style = (({bodystyle|))}
| textstyle = (({style|))}

It's probably not a good idea to interchange the use of that parameter. Why not do the following? — Martin (MSGJ · talk) 16:35, 24 June 2012 (UTC)Reply[reply]

| style = (({style|))}
| textstyle = (({textstyle|))}

Well, since ((notice)) uses ((mbox))'s (({text))} but does not use that name, I thought it did not make much sense to introduce a parameter (({textstyle))} to ((notice)). Since it instead uses (({1))}, I thought it made the most sense to name it simply (({style))}. In order to pass (({style))} though that requires it to be renamed. I proposed (({bodyclass))} and (({bodystyle))} since it is common practice based on several other navigational templates. 50.53.15.51 (talk) 15:03, 26 June 2012 (UTC)Reply[reply]

I would oppose the naming schemes you are suggesting because it will cause unnecessary confusion. It may not be called text but it is text, so I don't see a good reason not to call it textstyle. — Martin (MSGJ · talk) 18:11, 27 June 2012 (UTC)Reply[reply]

Well, I believe it is more important to pass the values than what they are named but I would counter your argument that it is no more text than any other value (since it can contain non-textual content such as images, etc. and most fields are text-based to begin with so text is a very poor choice of naming). A much better name would be content or some such as it is the main content, textual or otherwise (and other media besides text can be included). Thus my idea was to just remove the text label but regardless of what it is named the field should be passed (as should the others also requested earlier). I personally find it more confusing to introduce a parameter textstyle when there is no corollary parameter named text within the template. You could name it 1style (of course it also applies to header) but that seems icky and thus my request to name it simply style. Thank you. 50.53.15.51 (talk) 19:39, 13 July 2012 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could this line please be added to the template to allow the option for shortcuts to be placed in this template?:

| imageright = ((#if:(({shortcut|(({shortcut1|))))))|((Shortcut|(({shortcut|(({shortcut1|))))))|(({shortcut2|))}|(({shortcut3|))}|(({shortcut4|))}|(({shortcut5|))))))}

The line has been added to the current version of Template:Notice/sandbox. I have tested the sandbox, and the edit works as it should. If this edit is accepted, please ping me so that I can update Template:Notice/doc. Thanks. Steel1943 (talk) 05:32, 29 March 2014 (UTC)Reply[reply]

I have created and example on Template:Notice/testcases using the shortcut parameter. Steel1943 (talk) 05:39, 29 March 2014 (UTC)Reply[reply]

• Why not just pass imageright through directly and save a bunch of bits? Something like:

| imageright = (({imageright|))}

and then the shortcuts could just be passed through as:

|imageright =((Shortcut|thisShortcut|thatShortcut|theOtherShortcut)) — ((U|Technical 13)) ^{(t • e • c)} 13:04, 29 March 2014 (UTC)Reply[reply]

@Technical 13: I'm more or less trying to keep the parameters consistently named to the ones that were recently set up in Template:Nutshell. However, if the rest of your proposed syntax works the same as the function of the parameters on Template:Nutshell, I'm not opposed. (I'm just opposed to your proposed parameter names.) Steel1943 (talk) 14:32, 29 March 2014 (UTC)Reply[reply]

• Not my parameter name. It is just passing the parameter through directly to the meta template Template:Mbox (which is actually Module:Message box). This would also allow an editor to actually use imageright for an image like it was intended and not restrict them to only using it for shortcuts. — ((U|Technical 13)) ^{(t • e • c)} 14:50, 29 March 2014 (UTC)Reply[reply]

• Oh, I see now; that's what I get for not looking at Template:Shortcut before I responded. Yeah, as long as the coding can handle at least 5 shortcuts without breaking any syntax, sure. Steel1943 (talk) 15:32, 29 March 2014 (UTC)Reply[reply]

 Done Since the cascading protection has been lifted, and I'm a template editor, I will carry out this edit myself. Technical 13, if you desire to implement your changes on top of my edit, by all means please do so. Steel1943 (talk) 16:00, 29 March 2014 (UTC)Reply[reply]

Done This has been done, Steel1943. Please feel free to update the documentation. — ((U|Technical 13)) ^{(t • e • c)} 16:02, 29 March 2014 (UTC)Reply[reply]

@Technical 13: wow, you beat me to it! Steel1943 (talk) 16:04, 29 March 2014 (UTC)Reply[reply]

• Of course I did Steel1943... :p As much work as I invested finding the transclusion that put it on CASC... I was watching... — ((U|Technical 13)) ^{(t • e • c)} 16:06, 29 March 2014 (UTC)Reply[reply]

• Technical 13 ... Steel1943 (talk) 16:08, 29 March 2014 (UTC)Reply[reply]

This edit request to Template:Info has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

A protected redirect, Template:Info, needs redirect category (rcat) templates added. Please modify it as follows:

• from this...

#REDIRECT [[Template:Notice]]

• to this...

#REDIRECT [[Template:Notice]]

((Redr|from alternative name|from template shortcut|fully protected))

• WHEN YOU COPY & PASTE, PLEASE LEAVE THE MIDDLE LINE BLANK FOR READABILITY.

Template Redr is an alias for the ((This is a redirect)) template, which is used to sort redirects into one or more categories.

• Alternative administrative option: Since the target of this redirect, ((Notice)), was modified from "fully protected" to "template protected" recently on March 29th, if it moves you to do same with this redirect, I'll be happy to do the rest! Thank you in advance! – Paine Ellsworth ^CLIMAX! 04:39, 6 June 2014 (UTC)Reply[reply]

  Done I've made the edit and lowered the protection to template protection as well. — Mr. Stradivarius ^{♪ talk ♪} 05:35, 6 June 2014 (UTC)Reply[reply]

And again, thank you very much, Mr. Stradivarius! – Paine  06:33, 6 June 2014 (UTC)Reply[reply]

I have reverted some recent changes to this template which caused the default alignment to be centred rather than left. I would oppose this change to the default, but feel free to add a |align=center or |center=yes option. — Martin (MSGJ · talk) 09:36, 4 April 2016 (UTC)Reply[reply]

Pinging @SMcCandlish: — Martin (MSGJ · talk) 09:37, 4 April 2016 (UTC)Reply[reply]

@MSGJ: Honestly, I to prefer it to be left by default myself, because it is much more readable especially on large monitors. I just added the |center=y option, and also made the text and heading independently styleable.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:45, 4 April 2016 (UTC)Reply[reply]

i note that you were trying to make ((warning)) consistent with this template? Would it be an idea to make that template a wrapper for this one? — Martin (MSGJ · talk) 10:29, 4 April 2016 (UTC)Reply[reply]

No objections, especially since it's virtually undocumented. I'm in the process now of genericizing the documentation to work with both.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:45, 4 April 2016 (UTC)Reply[reply]

Done with the doc ((#switch:...)) stuff. There's another template or two like this that can also be mostly merged and kept as wrappers. PS: |align= is presently aliased to |textstyle=, but can be made to accept |align=center if people really want that. Just needs some ((#if:...)) stuff so it does not collide with |center=y. It could then support |align=right so it can be ported to RTL wikis.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:14, 4 April 2016 (UTC)Reply[reply]
Implemented that, too (didn't even need the #if after all).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:36, 4 April 2016 (UTC)Reply[reply]

Please could you double-check my code at Template:Notice/sandbox and Template:Warning/sandbox. (The latter will become a wrapper for the former.) A few other points:

• I dislike very much that (({image))} will take just the raw filename, but (({imageright))} needs to be properly formatted. These two should really be consistent.
• Could we get away with |align=center rather than using an additional parameter |center=yes?
• Not too long ago, the template accepted fewer variants, i.e. (({header))} and not (({title))} or (({heading))}, and (({text))} or (({1))} but not (({reason))} or (({content))}. It would be best not to introduce new variants in my opinion. (Simpler is better.) I'm not sure if it's worth tracking these down and removing them or not.

— Martin (MSGJ · talk) 10:52, 5 April 2016 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

There’s a spare } in the template’s output that I can’t track down: it’s a <td> where the style attribute is “text-align: left;}” instead of “text-align: left;”. Help, please?

Thank you. —LLarson (said & done) 18:51, 8 August 2016 (UTC)Reply[reply]

@LLarson: The template has a extra curly bracket on the line:

| textstyle = (({textstyle|text-align: ((#if:(({center|))}|center|(({align|left))))};))))

it should be

| textstyle = (({textstyle|text-align: ((#if:(({center|))}|center|(({align|left))))};))}

I don't have edit permissions, so someone else will have to make the edit. Offnfopt^(talk) 22:25, 7 October 2016 (UTC)Reply[reply]

Done Thanks for the fix! — Mr. Stradivarius ^{♪ talk ♪} 03:25, 8 October 2016 (UTC)Reply[reply]

Perhaps the Latin example used in the template page could be changed to an example in English because it's a bit irritating to read? KingAndGod 06:25, 19 April 2018 (UTC)Reply[reply]

That is lorem ipsum which is widely used in examples. PorkchopGMX (Sign your posts with four tildes!) 18:31, 18 December 2018 (UTC)Reply[reply]

An editor has asked for a discussion to address the redirect Template:Info. Please participate in the redirect discussion if you wish to do so. Steel1943 (talk) 18:57, 18 November 2019 (UTC)Reply[reply]

Example.

Why does the background appear yellow here but white on article pages? --79.249.159.86 (talk) 08:35, 26 August 2020 (UTC)Reply[reply]

Banners based on Template:Mbox, like this one, by design, appear differently depending on the Wikipedia:Namespace in which they appear. --Bsherr (talk) 14:14, 26 August 2020 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please replace all instances of "|Notice" with "|link=|alt=" because by default no text appears when hovering over the image. Also, add another space after "textstyle" so the "=" line up. Thank you. JsfasdF252 (talk) 02:46, 5 November 2020 (UTC)Reply[reply]

 Partly done arbitrary images can be inserted here, which do not preclude them from needing attribution. (I did insert the whitespace requested.) — xaosflux ^Talk 18:55, 5 November 2020 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add |alt= to the end of each file invocation in this template. It can be empty or use (({imagealt|))}, as shown in the sandbox.

Per Wikipedia:Manual of Style/Accessibility/Alternative text for images, An image that is purely decorative (provides no information and serves only an aesthetic purpose) requires no alternative text. The lack of an empty alt for these icons is putting pages into a new MediaWiki tracking page at Special:LintErrors/inline-media-caption. Thanks. – Jonesey95 (talk) 17:20, 14 January 2022 (UTC) – Jonesey95 (talk) 17:20, 14 January 2022 (UTC)Reply[reply]

 Done — Martin (MSGJ · talk) 18:48, 18 January 2022 (UTC)Reply[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please replace:

| style      = ((#if:(({style|))} |((#if:(({small|))}||width:80%;)) (({style))} ))

With:

| style      = (({style|))}

The inline styles when |style= parameter is used are unnecessary – mbox already has styles setting it to 80% width. I've just made a similar change to Template:Caution and Template:Information page. Matma Rex talk 10:07, 20 January 2023 (UTC)Reply[reply]

 Done but I suspect that width is there for the same reason it's in talk header et al. Izno (talk) 22:32, 25 January 2023 (UTC)Reply[reply]

Someone please help. 2603:6080:D23E:7BD:4936:BC99:49CD:6A60 (talk) 12:23, 22 July 2023 (UTC)Reply[reply]