Oh, you wanted me to judge this particular page, if it fits my claims? Sorry, I didn’t apprehend it that way. – Yes, why not? This entry seems to be ok.
You asked another question, if there was a need to include composers into track titles. Although I know that some hardware library players handle it this way, I personally didn’t propose it, and I can live without it.
My point regarding track titles would be that a consistent naming scheme (not only for track titles, but globally) within the database could be easily achieved by getting the user interface right, finally:
Look into the above mentioned document again:
Beethoven: Symphony No. 3 in E-Flat Major, Op. 55 “Eroica”
They divide it into “Composer”, “Type of work”, “Number”, “Key”, “Catalogue” and “Name”
But it isn’t a division into categories, the whole term is a composition of categories that together make the track title string. From a database point of view we have 6 entires, not one. And these 6 entries are applicable to most of classical music (which is all I am familiar with). Let one or two be empty for some works, like “Name”, and have a few others in reserve for special needs, like with Opera, where “Act” and / or “Scene” may be needed. But make everything that is its own category an entry in the database and make an input mask for each of them! All the hassle with English, German, Italian etc. keys (C minor or c-moll or do mineur?) are instantly gone! All you (not you personally, of course) as the database programmer have to do, is to provide translations for the 24 keys in all supported languages ONCE – in a drop-down-menu. With another drop-down-menu (or a toggle in Picard’s preferences), the contributor and the user can chose their language and the order, in which they want to compose the string – and automagically they get what they want without scripting or guidelines – every time and for all their music, consistently. Contributors can only chose from dropdown-menus, no typos, no alternatives, just the set of possibilities they have chosen with their language. The output for someone else might vary, as everything is pre-translated in advance internally. For example: German and English require a “in” in front of the key, like “in C minor” or “in c-moll”. Others not. So the “in” isn’t optional, but is inserted if the language is set to English or German. Other languages don’t insert (or even show) the “in” at all in the input mask. I hope you understand what I mean. This way all the trouble with guidelines and inconsistent data and discussion forum questions would instantly disappear. Don’t give the user of a database any chance to decide something by themselves! Everything can and must be standardized and the input mask must have crystal clear fields to fill in. In MusicBrainz there already IS a lot of stuff just like I propose, like in “Year” one can only type in digits and there must be four of them. Or the barcode is checked for plausibility. Or artist- composer- or orchestra names have to be chosen from pre-existing ones or have to be created elsewhere once and for all. This is the way a database should work! But as soon as one clicks to the next page with the tracks, the mess begins …