Wikipedia talk:WikiProject Classical music

LilyPond

Is there an official preference for LilyPond over images of scores in music articles?Trumpetrep (talk) 22:12, 21 February 2026 (UTC)

Not that I know, and I don't think there's a general preference. However, many user-supplied score snippet images are faulty and it's difficult to correct them. LilyPond allows for relatively easy corrections/improvements and, where meaningful, allows sound output. Horses for courses. -- Michael Bednarek (talk) 01:34, 22 February 2026 (UTC)

There certainly should be a preference for any scalable representation over a pixel image. Lilypond is a popular system, but it is a niche format; musicXML is editable by any number of music score programs, and would seem optimal. Imaginatorium (talk) 03:46, 22 February 2026 (UTC)

LilyPond is supported by the Mediawiki Score extension and thus available on enwiki; musicXML is not currently. Cheers, SunloungerFrog (talk) 08:08, 22 February 2026 (UTC)

If you would like to support the eventual deployment of my 3 year-old patch to the Score extension that makes it generate beautiful SVG graphics instead of the poor resolution PNG images it currently generates, please comment or vote on the 13 year-old Phabricator ticket T49578. Squeaky wheels get the oil. Currently held up by server upgrades, T385404 — Jonathanischoice (talk) 02:41, 23 April 2026 (UTC)

@Jonathanischoice: I am replying here, since I was considering on opening up a discussion on this, but this already exists. I think the work you have done with getting Lilypond up to speed is great, but I still don't see the advantage of it for simple, unchanging things such as range. Lilypond markup still falls short compared to SVG files in regards to copy-and-pasting, transparent backgrounds, and so forth. Hoping for some other editor input. Why? I Ask (talk) 09:30, 12 July 2026 (UTC)

LilyPond now generates SVG files on Wikipedia (https://upload.wikimedia.org/score/j/c/jcbhv59kvtvnr7xu01tfpeg7cillsu8/jcbhv59k.svg from Dies irae) which I can easily cut/paste/edit. -- Michael Bednarek (talk) 11:01, 12 July 2026 (UTC)

That's so good to know, Michael. How do we generate an SVG from the LilyPond code? Trumpetrep (talk) 15:45, 12 July 2026 (UTC)

Wikipedia:Tech news § Tech News: 2026-28 says:

The Score extension now supports rendering music scores as SVG images in addition to PNG, addressing a long-standing feature request and resolving historical image quality issues. Both formats are now provided to clients, with PNG in the src attribute and SVG in the srcset attribute.

So just use the Score extension, and the software will handle it for you. I don't pretend to understand the srcset attribute, but I believe that browsers will pick the most suitable image offered, and for most modern browsers that will be the SVG. Cheers, SunloungerFrog (talk) 16:01, 12 July 2026 (UTC)

So there's something general users need to download? Not exactly a strong case for using it. Why? I Ask (talk) 17:27, 12 July 2026 (UTC)

There's nothing that general users need to download. The extension is something that's already on the Mediawiki instance that runs enwiki. When I go to Dies irae § 13th-century Gregorian chant, the notation is presented to me as an SVG file. Cheers, SunloungerFrog (talk) 18:04, 12 July 2026 (UTC)

Here is your example in dark mode. Is there a way to fix the output to match the background like SVG files from Commons do? This is less about dark mode and more for users who use custom skins that do not have a white background.

Why? I Ask (talk) 18:08, 12 July 2026 (UTC)

Dark mode is working now, although I needed to poke the page to get it to update the image. Caching is something being worked on; storing and caching the LilyPond-generated images is handled differently from uploaded assets. — Jonathanischoice (talk) 17:31, 1 August 2026 (UTC)

When you click on it, do you expect it to expand, download, or play? You can always right-click to save it. Do you want transparent backgrounds, or non-transparent backgrounds? Either is easy to do with a div, but I think it would be good to add that to the Score extension as an option (or write a simple template that wraps the score code). Do you want it to auto-flip between white and black, like the text does, when switching to dark and light mode? That would also be an easy fix to add class=skin-invert to the SVG image. I'm not sure what you mean by easy copy and pasting. — Jonathanischoice (talk) 17:09, 12 July 2026 (UTC)

I expect it to expand. For me, when trying to copy-and-paste the image from an infobox, it does not seem to paste as an SVG when putting it into, say, Google Slides. It works if you type the Lilypond file URL in, but some software lack that option. You say that you can make a transparent background? Could you please demonstrate that? For the infoboxes that have a grey look, the general white background of the outputting SVG does not cut it. Not to mention, the dark and light modes as you said. Why? I Ask (talk) 18:05, 12 July 2026 (UTC)

The reason is the SVG file itself is transparent (it has no background colour assigned), for example —

Musical scores are temporarily disabled due to a security issue. See Help:Score.

— but the Score Extension applies a white background div to it, since the Score extension does not (currently) support dark mode markup, and black SVG music on black background is hard to read. If you save the above SVG file you'll find it doesn't have a background, even though it is currently displayed with a white background here. I think we should be able to easily tweak the Score extension to support light/dark mode, then we won't have to use the white fallback. — Jonathanischoice (talk) 18:23, 12 July 2026 (UTC)

But still, it is not easily copy-and-pasteable on my end. And how can you get it to render a transparent background when being placed into Wikipedia? Whenever I download a Lilypond SVG file, it has rendered a transparent background. How can we get the score extension to do the same on Wikipedia? Why? I Ask (talk) 18:27, 12 July 2026 (UTC)

Looks like there is already phab:T431148 on this topic. Cheers SunloungerFrog (talk) 19:59, 12 July 2026 (UTC)

It will be good to get the Score extension to handle this, but in the meantime it seems we can wrap the LilyPond in a <div class="skin-invert"> and it will display inverted in dark mode; with a transparent background in the Wikipedia mobile app, and with a black background in desktop browsers and Firefox mobile; I just did this on the tuba article Infobox. — Jonathanischoice (talk) 17:03, 15 July 2026 (UTC)

There is now a patch for SVG dark mode support on T431148 which renders it with a transparent background. — Jonathanischoice (talk) 15:32, 21 July 2026 (UTC)

Lilypond is great. A few months back I spotted a small typo in a score on Wikipedia and fixed it instantly. Paul Matthews (talk) 16:50, 31 July 2026 (UTC)

I do not want to re-bring up old things, but the recent disablement of scores has only reinforced my belief that SVG files should have a de facto preference over Lilypond. I don't think Lilypond or SVG files should be edit-warred over, but Lilypond still shows some downsides and limitations that SVG files do not have. Many musical instrument pages just straight up do not show the range, for example. Why? I Ask (talk) 20:09, 27 October 2026 (UTC)

@Why? I Ask I disagree. The current issue was unfortunately poorly timed with half the internet going down due to critical PHP flaws, including a bunch of Wikimedia infra. A fix is on the way, please be patient. Jonathanischoice (talk) 20:40, 27 October 2026 (UTC)

I also disagree. Though it is mind-boggling that rendered musical scores could not have been cached as-is before being indefinitely taken down again, which would accommodate a lot more patience. Hftf (talk) 20:54, 27 October 2026 (UTC)

Yes, if there was a way to cache the Lilypond SVG output, that would make a lot of things simpler. Why? I Ask (talk) 00:06, 28 October 2026 (UTC)

By way of an update, this Score issue is being tracked publicly on T441579, while the Score-specific security issue itself is being worked on by staff devs on a separate, private ticket. As you can see I have already copped a bit of flak for my impatience on the ticket; we are assured that a fix will be available soon. I worked hard to get the SVG functionality, which took three years from patch to deployment, and I don't want to see that go to waste. It would be really helpful actually if you could enumerate clearly for me what "downsides and limitations" means, so that I may endeavour to fix them in a future update. I already have a patch waiting for more testing that removes the need for Ghostscript and Imagemagick now that we have SVG and don't need PNG fallback in the 2026 browser landscape. — Jonathanischoice (talk) 23:01, 27 October 2026 (UTC)

@Jonathanischoice: Thank you for pushing for improving Lilypond. I think it's a great tool! I just think that in certain cases (not all), the benefits are outweighed by the drawbacks. But I also get that this is a very specific outage. Why? I Ask (talk) 00:08, 28 October 2026 (UTC)

COI edit request – Lucas Krupinski

Hello, I am connected to the subject of the article Lucas Krupinski and have disclosed my conflict of interest on the article talk page, so I am not editing the article directly. There is an outstanding COI edit request concerning additional independent sources for the article, which currently carries a single-source maintenance tag. The request has been awaiting review for approximately three months. As this is an article about a classical pianist, I wondered whether an uninvolved editor from WikiProject Classical music might be willing to review the request when convenient: Talk:Lucas Krupinski#Request to review additional sources for single-source tag Many thanks for your time. Pianofan642 (talk) 19:08, 8 August 2026 (UTC)

Request for independent review — Svetlana Smolina biography update

Hello. I am Svetlana Smolina, the subject of the Wikipedia article Svetlana Smolina, and I have disclosed my conflict of interest on the article's Talk page. The biography is substantially outdated, and I have submitted a detailed edit request with proposed neutral updates and supporting published sources, including People's Daily/Xinhua, CBA24N, Música Clásica, Artburst Miami, and other sources. I would be very grateful if an uninvolved editor with an interest in classical music could review the proposed updates and make any changes that satisfy Wikipedia's sourcing, neutrality, and biographical guidelines. The request is here: Talk:Svetlana Smolina#Proposed biography update — conflict-of-interest disclosure Thank you very much for your time. FantasticPiano (talk) 00:25, 13 August 2026 (UTC)

Request for review: Mark Weiser and David Fennessy

Started drafts for two composers who didn't have articles yet, both currently in AFC review. Mark Weiser (opera composer, reviews in San Francisco Classical Voice, SF Examiner, Metro Silicon Valley, ASCAP Nissim Prize winner): https://en.wikipedia.org/wiki/Draft:Mark_Weiser_(composer) and David Fennessy (Irish composer based in Glasgow, works performed by BBC Scottish Symphony Orchestra and RTÉ National Symphony Orchestra, reviewed in The Scotsman): https://en.wikipedia.org/wiki/Draft:David_Fennessy. Flagging in case anyone wants to take a look or help expand once they're live. Fancy45611 (talk) 00:12, 26 August 2026 (UTC)

Proposed deletion of Somogyi String Quartet

The article Somogyi String Quartet has been proposed for deletion because of the following concern:

Tagged for notability concerns for almost 9 years. No other language has a reliably sourced article from which to translate. Poorly sourced stub about a band. Created by a SPA with two (2) edits, probably an employee or member.

You may prevent the proposed deletion by removing the {{proposed deletion/dated}} notice, but please explain why in your edit summary or on the article's talk page.

Please consider improving the page to address the issues raised. Removing {{proposed deletion/dated}} will stop the proposed deletion process, but other deletion processes exist. In particular, articles for deletion allows discussion to reach consensus for deletion based on established criteria.

If the proposed deletion has already been carried out, you may request undeletion of the article at any time. Bearian (talk) 12:40, 26 August 2026 (UTC)

Move discussion at Talk:Andy Pape (composer)

There is a move discussion at this talk page. Input from others would be appreciated. All opinions are welcome.4meter4 (talk) 02:14, 28 August 2026 (UTC)

Stuart Dunkel

This musician and artist doesn't appear to be notable, and the sourcing is poor. Can somebody please add additional references? Otherwise, we can propose this for deletion. Bearian (talk) 04:44, 5 September 2026 (UTC)

Rameau

Short: please check the edit history of Rameau.

Longer: this is an open letter to Barbarbarty who reverted an infobox for the composer more than once today. I explained to them in edit summary and on their talk page. The talk page entry was removed with the request never to post there again, therefore here: I cited the standard procedure to suggest an infobox in contentious cases on the talk and add it to the article when there is no objection within 7 days. I looked it up and found that I was wrong: it was only three days (72 hours).

Background: this project changed the wording of its guidelines in 2026. Infoboxes can now be added to articles without establishing consensus for them before adding them. Hidden messages in articles requesting a previous consensus have been removed. To my observation, Rameau didn't even have such a message.

What do others think? Gerda Arendt (talk) 14:22, 20 September 2026 (UTC)

Imaginatorium and Michael Bednarek restored, thanks to both. Perhaps we need to keep a link to the changed guidelines on this page, because some users seem not to understand what the change means. --Gerda Arendt (talk) 16:13, 20 September 2026 (UTC)

If the only purpose for posting this notice on here was to get an edit you wanted restored I fail to see what the purpose of summoning me here was for.

I also object to “not knowing what the guidelines are.” That is not my problem and I take offense to the idea that my actions were merely due to ignorance. I especially do not think that the new guidelines simply mean “add infoboxes as you like and no one can object after it is added.” Barbarbarty (talk) 16:16, 20 September 2026 (UTC)

The purpose was to see what others think. I wouldn't not revert a revert of my edit, thinking that it means to invite edit warring. Here, I also invited you to explain your repeated action, and the only explanation I could think of is that you were not aware. The new guidelines mean "add infoboxes as you like, and when someone objects, they can revert, and you better begin a discussion". (It's much less waste of time, because reverts are rare.) Remember, you reverted an infobox I had added for Rameau, before, and I could have started a discussion but I tried to ignore it (to not waste time). Then came the new discussion (by others), with no objection, and then the next addition, based on it. --Gerda Arendt (talk) 16:36, 20 September 2026 (UTC)

Well your explanation of my behavior was incorrect. I still do not think that is what the new guidelines mean, and I clearly am not the only user who shares that view. But sure. I ask you to please respect that I am not interested in discussing this topic further. Barbarbarty (talk) 16:45, 20 September 2026 (UTC)

Well, as I said I could only guess. If I went around and pinged others I'd be accused of canvassing, so I came to this community spot. You decide what you want to contribute. --Gerda Arendt (talk) 16:50, 20 September 2026 (UTC)

To address the actual topic - infoboxes are beneficial. They are beneficial elsewhere on Wikipedia, and they are beneficial here. There was an ENDLESS conversation here that finally settled on the guidelines that @Gerda Arendt is referring to. And the result, while less than satisfying, means that infoboxes are explicitly allowed for Classical music articles, and that removing them without discussion consensus first is a bad idea. So yes - here's a voice in support of keeping the darn infobox. PianoDan (talk) 14:52, 21 September 2026 (UTC)

The discussion has been settled. Infoboxes have always been allowed for such articles. The guidelines still say any dispute over to add them is resolved through consensus first. I don’t see anyone disputing that, nor should they. This particular article has been decided on already, so what’s done is done. Barbarbarty (talk) 16:58, 21 September 2026 (UTC)

Updating our banner

I've long felt it odd that Template:WikiProject Classical music doesn't include assessment and an importance scale. I would support adding these components as most WikiProject banners include them. I note, that the vast majority of article have multiple banners, so the articles are being assessed anyway in most cases by other projects. Simply adding the parameters to out banner, would automatically superimpose the assessment made by other projects on our banner (due to the way banners are now bundled), which would give us valuable information. Lastly, knowing what articles are not assessed often gives us a quick pathway to identify articles nobody in the project has viewed. This is valuable in terms of improving issues that frequently crop up in newer articles by inexperienced editors such as adjusting formatting, adding categories, etc. It also helps identify stub class articles which need improvement/expansion. I can't see the downside of not including assessment in the banner because of the way it can aid in targeting article improvement. Thoughts?4meter4 (talk) 14:00, 26 September 2026 (UTC)

Sounds good. Trumpetrep (talk) 19:09, 26 September 2026 (UTC)

I started another thread at Template talk:WikiProject Classical music#Updating the banner to include assessment. Project members please take a moment to comment so we can get a WP:CONSENSUS opinion. Best.4meter4 (talk) 14:57, 13 October 2026 (UTC)

List of compositions by Henry Cowell

Please add entries and sources to this list. Thank you for helping! Bearian (talk) 01:56, 8 October 2026 (UTC)

Proposed deletion of Kentaro Sato

The article Kentaro Sato has been proposed for deletion because it appears to have no references. Under Wikipedia policy, this biography of a living person will be deleted after seven days unless it has at least one reference to a reliable source that directly supports material in the article. The nominator also raised the following concern:

only source is his own website.

If you created the article, please don't be offended. Instead, consider improving the article. For help on inserting references, see Referencing for beginners, or ask at the help desk. Once you have provided at least one reliable source, you may remove the {{prod blp/dated}} tag. Please do not remove the tag unless the article is sourced. If you cannot provide such a source within seven days, the article may be deleted, but you can request that it be undeleted when you are ready to add one. Bearian (talk) 23:26, 14 October 2026 (UTC)

I couldn't find any WP:SIGCOV. It may exist in Japanese.4meter4 (talk) 06:35, 15 October 2026 (UTC)

Hmm. He has a page on the publisher PanaMusica: Japanese. They list 33 published works, some of which they (PanaMusica, spelling variable, a large music publisher in Japan) publish themselves: English list. But most are self-published ("Wiseman Project"). The current page is promotional in tone (the "Musical style" section is unsourced and vapid to the point of exhaustion). The Japanese page ja:佐藤賢太郎 includes lots of items shown as （音楽提供） (i.e. "provided music for..."), and typically following them leads to other WP pages like da:Sommer i Sunny Beach, which do not mention him, and trying searches for other show names (like "Judge Judy") with his name go nowhere. Personally I am unable to conceive of a benefit to humanity from deleting this page, but it could well be reduced to a stub awaiting further investigation. I mean, for goodness' sake, he plainly exists, has written lots of music, which has been performed all over the place, and an WP reader might well want to know more about him. Imaginatorium (talk) 09:27, 15 October 2026 (UTC)

"A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject."

Without this standard, Wikipedia would abound with articles on everything under the sun. Anyone could create an article about anything. It would not take long for a Wikipedia without this standard to turn into Geocities, instead of an encyclopedia. Trumpetrep (talk) 18:39, 15 October 2026 (UTC)

Yes and this fails WP:BLP policy as well. Sourcing reliably for living people is essential for legal reasons for Wikipedia. We can’t publish things that are not verifiable about living people.4meter4 (talk) 19:53, 15 October 2026 (UTC)

Edit request awaiting review: Hirofumi Yoshida (COI disclosed)

Hello. I have a conflict of interest regarding the article Hirofumi Yoshida: I am a longtime friend of the subject and I am not paid; this is disclosed on my user page. I have posted a sourced edit request at Talk:Hirofumi Yoshida#Request: update career and awards (conflict of interest disclosed). The article has not been substantially updated since about 2016. Would a project member be willing to review whether the proposed additions are suitably sourced and neutral, and add what is appropriate? Several of the sources are official or independent (Japan's Ministry of Education (MEXT), Kanagawa Prefecture, il Resto del Carlino, the Teatro Comunale di Bologna biography, the label Tactus). Thank you for your time. Direttore1623 (talk) 02:57, 16 October 2026 (UTC)

@Cunard: Given your foreign language skills, would you mind taking a look at this.4meter4 (talk) 04:18, 16 October 2026 (UTC)

A lot of this article looks okay with independent reliable sources. The engagements section is mostly unsourced fluff that should be deleted. There's no harm in having a high quality short article as opposed to a low quality long article that looks like self-promotion. Trumpetrep (talk) 02:31, 17 October 2026 (UTC)

Thank you, Trumpetrep. I agree that a short, well-sourced article is better than a long promotional one. I have a conflict of interest, so I will not edit the article myself, but I would have no objection if an independent editor removed the unsourced engagements material. Direttore1623 (talk) 07:35, 17 October 2026 (UTC)

Move discussion

Alcina was recently moved to Alcina (opera) with no discussion. I have started one at Talk:Alcina (opera)#Requested move 17 October 2026. All opinions welcome.4meter4 (talk) 11:42, 17 October 2026 (UTC)

Another move discussion

Oreste was recently moved to Oreste (Handel) with no discussion. I have started one at Talk:Oreste (Handel)#Requested move 17 October 2026. All opinions welcome.4meter4 (talk) 15:10, 17 October 2026 (UTC)

Another Handel opera move discussion

Scipione was moved to Scipione (opera) with no discussion. I have started one at Talk:Scipione (opera)#Requested move 18 October 2026. All opinions welcome.4meter4 (talk) 02:14, 18 October 2026 (UTC)

Should Infobox classical composer accept all parameters of Infobox person?

Since 2022, {{Infobox classical composer}} has accepted all parameters that {{Infobox person}} has. However, the closing remarks to a 2010 RfC directs that {{Infobox classical composer}} should implement a minimal set of fields.

Given the length of time since the 2010 discussion, I wanted to check the latest consensus: should the template continue to implement all parameters of {{Infobox person}} or should it implement a restricted subset (as defined in the documentation)? What do editors think? — hike395 (talk) 01:15, 19 October 2026 (UTC)

• A restricted subset. Many of the extended parameters will not be appropriate or relevant. Nikkimaria (talk) 01:20, 19 October 2026 (UTC)
• I have no preference. Trumpetrep (talk) 01:59, 19 October 2026 (UTC)
• Subject-specific guidance is what facilitates better composer infoboxes and makes them easier to review. While similar improvements might be achieved by modifying WikiProject advice, guidance alone would be less effective without a dedicated template.

The essence of a template is to provide a concrete, ready-made, fillable example of how information about composers can be presented, rather than merely describing the desired approach in the abstract. Its purpose is to serve as a model, not to enforce a rigid standard or prevent adaptation to individual cases in an automatic or mechanical manner.

For that reason, I do not think the template needs to be restricted either to serve this purpose or to avoid deletion. However, if restricting its use is necessary to justify its retention, then I would support doing so, since the template would still provide valuable subject-specific guidance. MONTENSEM (talk) 05:32, 19 October 2026 (UTC)

• The template should continue to implement all the parameters of {{Infobox person}}. There should not be a blanket ban on certain parameters. Parameters should be chosen on a case-by-case basis at each individual article per MOS:INFOBOXUSE, which states: Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article. Khiikiat (talk) 12:45, 19 October 2026 (UTC)

  Just as, from the similarities between the subject-specific composer infobox and the more general person infobox, it does not follow that the former should be deleted, from a separate or restrictive subject-specific composer infobox, it does not follow that there is "blanket ban" on other infoboxes with others parameters, only that there is editorial guidance (there are "no rules", after all, in principle, and what are templates but suggested forms for content, here at the community or subject-specific level). MONTENSEM (talk) 17:47, 19 October 2026 (UTC)

• merge it to Infobox person There is nothing about classical composers that is so unique as to warrant their own custom Infobox, which uses the same parameters as Infobox person but restricts them to a small subset. The idea that none of the additional parameters available at {{Infobox person}} will EVER be appropriate or relevant to composers is just absurd. If {{Infobox person}} can work for Journalist ({{Infobox journalist}}), Photographers ({{Infobox photographer}}) and Actors ({{Infobox actor}}) all of which are just redirects, there is no reason that classical composers cannot also use this same template. Not a single page will be harmed in any way by including a parameter of Infobox actor. If a user chooses to include information that is fictitious or improperly sourced, that should be addressed on the page in question, not by banning the use of that parameter on all Infoboxes for composers. Zackmann (^{Talk to me}/_{What I been doing}) 04:40, 21 October 2026 (UTC)

  Even a restricted subset within infobox composer isn't tantamount to a ban, since the more general infobox can be used per MOS. A restricted subset isn't strictly necessary for the more subject-specific template to be retained. The subset of more subject-relevant parameters, some of which are distinct, makes the composer infobox easier to use. Its template documentation provides more subject-specific guidance about those parameters. This editorial guidance reduces infobox content disputes, saves editors time, and generally produces better articles. It does not have to be binding or final in order to serve such a general purpose across composer articles (and ONUS and DUE WEIGHT still burden the person adding information to the article, even in an infobox). These are advantages that infobox person lacks. MONTENSEM (talk) 11:50, 21 October 2026 (UTC)

• Composers are persons. I believe that infobox person is well-maintained and works fine for composers, and I use it for them. Hardly any composer is or was only a composer, - they earned money rather with playing an instrument, conducting, teaching, you name it. Verdi ran a farm. I explained in the deletion discussion for {{Infobox classical composer}} the history that led to it as a restricting template. (I wasn't aware that as of 2022, it wasn't even restricting any more.) We could place guidance for which parameters of infobox person to use in the project guidelines, and merge the template. --Gerda Arendt (talk) 09:07, 22 October 2026 (UTC)

  I thought about this too, but wouldn't it be easier to have template guidance where it is most useful, rather than having to compare two pages, subject-specific guidance and to have to apply it to a general template with over fifty parameters? To me, nothing is worse than seeing a demanding, overwrought template like that, whether it's for a citation or what have you, when I am just trying to write an article. It seems to me like the merge is based on things that aren't properly editorial, like the fact that there is a code-level identical wrapper or that composers are people. No one is disputing these things, it's just that they're not really at issue here. A template isn't about code-level or ontological identity. It's for editors! But I agree with this, if it is deleted. I just don't see why these things necessitate, in my view, the removal of a functional, useful, purposeful template. MONTENSEM (talk) 16:22, 22 October 2026 (UTC)

  I use infobox person, but I don't go to the complete large template. Instead, I copy from a working similar case, such as Schumann, Mozart, Beethoven, Verdi, Max Reger, Stravinsky. --Gerda Arendt (talk) 21:24, 22 October 2026 (UTC)

  I recently asked for an Essay infobox, because so many articles on essays shoehorned information into the Book infobox where the parameters just did not apply. A few editors howled that it was overcategorization. I agreed with them, but I still felt the Essay infobox was a helpful new tool.

  Wikipedia rarely has one clear solution for problems. If we just allow Person infoboxes for composers, an editor will inevitably be unaware of the policy and ask aloud why there isn't a Composer infobox, and vice versa.

  In my limited experience on this issue, the kinds of simple infoboxes Gerda just linked to are the most acceptable to the widest range of editors.

  Those who dislike infoboxes find these streamlined ones the least objectionable.

  Editors who are pro-infobox are satisfied enough with these simple iterations to no longer feel the urge to argue over the issue.

  It's a classic compromise: no one is completely happy but forward progress is achieved. Trumpetrep (talk) 22:54, 23 October 2026 (UTC)

  You both make good points. The overcategorization frame is useful.

  I like the guidance for a minimalist approach at MOS:INFOBOX: it preserves the essence of the composer infobox compromises and RFCs.

  I don't like infobox person precisely because, in a sense, it doesn't (the full version is so long). (I think this makes it a bad template for composers' infoboxes in a way that shouldn't just be implicit. But I can wiggle here.)

  On the three big differences mentioned at the outset of the deletion discussion:

  1) The family/relatives guidance harmonizes well, I think.

  2) The list-of-works approach doesn't match. Deleting infobox composer may mean having to preserve/reconsider/migrate this guidance to community guidelines, probably with the proviso that MOS:INFOBOX and ONUS/DUE WEIGHT ultimately govern disputes. Perhaps list of works could be added to infobox person.

  3) Flourished vs. years active: the former is narrower in a way that is subtle but important. Perhaps flourished could be introduced to infobox person. MONTENSEM (talk) 07:46, 24 October 2026 (UTC)

  Just replying to 2): infobox person has already |works= (which the other also has), which can be filled with a list of works in the many cases of prolific composers who have a separate article for their complete works, examples Verdi and Reger (linked above). --Gerda Arendt (talk) 08:28, 24 October 2026 (UTC)

  That's what's been done, and it's documented in the composer infobox categorically. "List of works" is arguably shoehorned into "works" in the redundancy of this formulation and could be simply added to infobox person as a cleaner piped link labeled "List of works", going to the composer's list of works, if we read this as a merge and not just as a delete.

  But the person infobox offers other approaches, and the last RFC asks us to consider them not only case-by-case, but categorically (to smoke the whole pack, as it were).

  Say I come to edit/talk with several RS supporting Bach's "[[most] notable] works" as the B-minor mass, St Matthew Passion, Goldberg Variations, Well-Tempered Clavier, and Brandenburg Concertos. In my view, votes via ONUS burden the addition, which is somewhat reassuring in terms of compromise, but are we then editorializing against RS? This is probably the most thorny question raised. Practically, we wouldn't raise it, but eventually, I think, someone probably would (and arguably has, in that most recent RFC close). MONTENSEM (talk) 18:08, 24 October 2026 (UTC)

Edit request for Pierre Bleuse

Hello, I have posted an edit request at Talk:Pierre Bleuse#Edit request: article update to update the article, which stops in 2021 (current positions, discography, independent sources). I have a paid conflict of interest, disclosed on my user page, so I am not editing the article myself. A review by an editor familiar with classical music biographies would be much appreciated. JeanMartinBercel (talk) 11:09, 27 October 2026 (UTC)

I took a brief look, only at your sandbox so far. It would be easier for us if we could see the difference to the existing article. What I see is an article with a "laundry list" of orchestras and essential things not linked (Casals Festival), so I would not like to just overwrite the article. Could you perhaps point out the changes, JeanMartinBercel? --Gerda Arendt (talk) 11:30, 27 October 2026 (UTC)

Thanks Gerda Arendt, fair point, overwriting the whole article wasn't a good idea. I've redone the sandbox starting from the current article, so the changes are easier to see: diff.

Thank you, that looks helpful. I'll move the details to the article talk page, and will hopefully start updating today. --Gerda Arendt (talk) 07:08, 28 October 2026 (UTC)

The update is basically done. --Gerda Arendt (talk) 13:13, 28 October 2026 (UTC)

"Warrack, 48"

Does anyone know which of the two cited sources did Jonyungk cite with "Warrack, 48" in this edit – Special:Diff/122372345? I can't ask the author, as they are inactive. Gikü (talk) 18:43, 29 October 2026 (UTC)

Tchaikovsky symphonies and concertos.

Boy, that's aggravating when people don't cite things fully. Trumpetrep (talk) 19:48, 29 October 2026 (UTC)

Request for comment on user-generated audio files

There is a Request for comment on user generated audio files at the "No original research" page. Trumpetrep (talk) 23:56, 2 November 2026 (UTC)

Sol Gabetta

The article of Sol Gabetta needs attention. An IP user marked many facts as missing citations, and marked the sections, and marked the article, which looks horrible, but the reason are of course the missing citations. I tried to talk to them on their talk, but have no idea if IP users get notifications now. Anybody who has time today? Not me, that is, or I'd do more myself. I found one encyclopedia that helped. Probably checking if existing refs support other facts also might help. -- Gerda Arendt (talk) 13:17, 5 November 2026 (UTC)