This template falls within the scope of WikiProject Opera, a group writing and editing Wikipedia articles on operas, opera terminology, opera composers and librettists, singers, designers, directors and managers, companies and houses, publications and recordings. The project discussion page is a place to talk about issues and exchange ideas. New members are welcome!
I see this has been changed. However it looks too small to me. Was the Opera Project told? After all it is their project banner. Also I see the coding has been changed by Happy-melon. Why? Again, was the Opera Project not told? The previous coding was decided after a project discussion (see here). It should not have been changed without consulting the project.--Kleinzach 02:44, 4 November 2008 (UTC)
Wikipedia is not a bureaucracy, there is no 'red tape', no hoops that 'must' be jumped through to improve the encyclopedia. Are there issues with the new code? If so, they should be resolved. Obviously if there are insurmountable issues then resolving them may require reverting to a previous version; that's what we keep old versions for. But if we adopted an approach of "consulting group X" before making any changes to pages, we'd never get anywhere. In response to the actual issue raised, yes, the new image is a little small. I will correct that. Happy‑melon 12:07, 4 November 2008 (UTC)
Happy-melon your arguement frankly doesn't make any sense and is misapplication of WP:OWN. This article's purpose is to serve the opera wikiproject as its the banner for the opera wikiproject. I think common sense would have dictated talking to the opera project first about making changes to the opera project's banner. I personally have concerns about the massive changes to the template language. I am not a template expert so I'm not necessarily complaining about anything, but I would like some reassurances that none of our assessments/the former capabilities of the template have been lost. Common courtesy would be at least to have informed us about the changes and why they were necessary. The project depends upon the template as an essential tool so it's not beyond the bounds of what's reasonable for us to ask that you dialogue with us. Nrswanson (talk) 12:43, 4 November 2008 (UTC)
It does and I definitely appriciate where you are coming from. If you wouldn't mind, without too much techno babble, just briefly highlighting the benefits of your changes for us at the project so we understand that would be great. And I'm not asking you to justify the changes, just to inform us so we're all on the same page. :-)Nrswanson (talk) 13:38, 4 November 2008 (UTC)
I have no problem if they want to change the logo but, at least, please tell us why it has to be changed. Secondly, why didnt the changes been informed or at least discuss about it in Project opera discussion page? And also, who is User:Javitomad and why User:Happy-melon is so happy to obey to his/her request for change? If you asked me, the old logo is much better, besides, we in Project Opera voted for it to become our logo in the first place! - Jay (talk) 14:14, 4 November 2008 (UTC)
Addition: We also use the logo as our member tag and our portal. Does that mean we have to change them all to fit your so called "non-bureaucracy"? What is it like when one project has many different shape of logo? It doesnt work that way in the real life and I believe Wikipedia is not exempted. - Jay (talk) 14:35, 4 November 2008 (UTC)
To answer Whjayg's question first, SVG images have numerous advantages over lossy PNG images, most notably being that .svg images can be losslessly scaled to any size required by the page or the browser it is rendered on. For a situation like this, where the same image is presented at a different size depending on whether the |small=yes parameter is passed, this is a notable advantage. SVG images are also more easily editable without losing quality, and have various other advantages; see Commons:Transition to SVG. Seeing a request to replace a .png with a similar .svg, I considered the request to be essentially trivial. The logo issue should be considered separately to the meta-template issue; my comments about bureaucracy refer to the latter and should not be confused. Whether you update your other images is entirely up to the project, although I would strongly recommend that you do so because of the advantages listed above. And on the contrary, one of the things that makes wikipedia such a wonderful place is the way in which it is different to real life: nowhere in the real world is "ignore all rules" enshrined in law! Happy‑melon 14:49, 4 November 2008 (UTC)
@Nrswanson: yes I'd be happy to summarise the changes. They essentially fall into two categories: specific problems with the old code, and superior features available from the new code. Examples of the former included:
Use of 'messagebox' CSS classes, which are deprecated
Use of |nested= parameter to trigger nesting inside banner shells, now deprecated (although only very recently so)
Intermitent support for 'extended' |class= values: some parts of the code expected values like "cat" and "disambig", other areas failed gracefully with these values (output "unassessed", etc), other areas produced bizzarre output, saying "has been rated as category-class" but actually rating it as something else.
Inconsistent support for upper/lowercase |class= values (some areas treated "FA" as "fa", others didn't)
Duplication of a large chunk of peer review code just because it was activated by a different parameter rather than using an 'if A or B' construct
NavFrames render oddly inside bannershells in the cologneblue skin in some instances; also extremely bulky code
There are other issues but they are minor in comparison. The benefit of a meta-template is that its code structure receives much more attention and so these issues are generally resolved and prevented. Specific advantages other than "not being broken" include:
Incorporates |listas= as standard, allowing, for instance, biographies to be category-sorted by surname rather than forename.
Supports |category=no to disable all category inclusion in examples and demonstrations
Fully case-insensitive and consistent handling of |class= and |importance= values
Uses the latest CSS and JS-based nesting and rendering, which prevents box-overlapping.
Tremendous scope for expansion or contraction to add or remove features as desired by the project. See the documentation for a description of what's possible.
Jay, Happy-melon didn't change our logo. User:Javitomad did. Now that we have the logo, I suggest we talk about it at the project to ask which one we like better. Happy-melon, if we decide we like the old logo better, would you be willing to reintegrate it into the new template for us? Also, if we do decide to go with the old logo, would it be possible to convert it into svg (which I gather is better)? Nrswanson (talk) 15:00, 4 November 2008 (UTC)
(edit conflict)Comment I can see the reasons for changing the coding on the banner template, and that is of course, entirely separate from the logo. Javitomad is the one who designed the original logo. I really wish he had asked about changing it before he did it. He didn't just change it from .png to .svg. He actually changed the design, which I'm not sure I like particularly. I've left him a note at his talk page asking him to explain at the OP Talk Page why he felt the design (shape and colour of background) had to be changed in the process. There may be good technical reasons for it, although I can't imagine what they'd be. Voceditenore (talk) 15:05, 4 November 2008 (UTC)
That's ok. Naturally the choice of image is ultimately the project's decision, although SVG images are preferable to PNGs for the reasons I gave above, among others. So if you prefer to use the existing design, recreating it as an .svg would be a good idea; I don't have the facility to do that, but a lot of editors do. Once a decision has been made, updating the banner is trivial; I or any other admin can make that change by editing the sixth line to read, for instance, |IMAGE_LEFT=NameOfImage.svg to use Image:NameOfImage.svg. Happy‑melon 23:33, 4 November 2008 (UTC)
Template-protected edit request on 19 June 2015
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
We'd like to add the Draft class to the template, analogous to the List class which the template already supports. The WikiProject Opera discussion supporting this change is at Wikipedia talk:WikiProject Opera#Input needed re Template:WikiProject Opera. I can't give a more "complete and specific description" of the requested edit because I haven't got a clue how to do it, but it should be a straightforward task for an template editor experienced with WikiProject banners.
Voceditenore (talk) 15:44, 19 June 2015 (UTC)
@Voceditenore:Question: At the moment, this template is using the "standard" quality scale (FA, A, GA, B, C, Start, Stub, FL, List, NA). Draft-class is part of the "extended" bundle (the "standard" ten plus Category, Disambig, Draft, File, Portal, Project, Template). Do I take it that you do not wish to have the other six as well? If so, that's not a problem, I can create the appropriate subpage so that you can have a custom scale. --Redrose64 (talk) 16:12, 19 June 2015 (UTC)