[mb-users] name formatting (was re: Style query: exact format for volume numbers)

[Andy]

On Sun, 2004-08-01 at 06:23, Tarragon M. Allen wrote:
> I would tend to feel that "Volume x" should be considered a Sub-Title as this 
> tends to simplify a lot of things, but I'm unsure that people consider the 
> additional colon as part of the title appropriate. (Note that the colon 
> seperater would presumably become optional as the database and tagger expand 
> in future).

Sorry for the long post -- this is kind of a complex idea.

It would be really cool if, eventually, different parts of the name
fields (which appear to be varchar(255) from the current documentation)
be broken out into parts like "title", "subtitle", "extra" (and perhaps
"years", "volumes", "featuring", but let's not go overboard), and then
there be a suggested "format string" to join these parts into a single,
usable string.  To continue your example:

title: My Friends
subtitle: The Collected Works
years: 1985,1986,1987,1988,1989,1990,1991,1992
featuring: Friend Foo, DJ Bar, Xyzzy
Volume: 2

suggested-format-string:
  "%title: %subtitle %range(%years) (%volume?Volume %volume) \(featuring
%list(%featuring)\)"

I know I'm packing a lot of stuff into that, "function calls" and
"conditionals".  

Just to toss out the idea, %range(%years) would convert a number series
into a range, that is:
  "%range(1980,1981,1982,1983)" would output "1980-1983"
(depending on how you wanted to store the number series information in
the database (just a text column or a normalized table) and how you want
to represent dis-contiguous ranges (1980-1985,1988) (if they show up at
all).  Would need some statistics on what kind of values you'd want to
put in a field named "Volume" to determine the best method.  If you just
allow a string there, you get rid of needing to determine that, but then
you have "style rules for the volume field", and the format can't be
customized.

%list would make a "readable list" (what I've seen called "English list"
elsewhere, but that's obviously English-centric).  The above would
become:
   Friend Foo, DJ Bar, and Xyzzy
(the use of punctuation and the word "and" would be localized)

You could also give each field a suggested format, which is only used if
the field is not null.  Format for the volume field could be "Volumes?
%volume" or something (where the s? is designating the proper way to
format the plural, (this needs some more thought)).  If you didn't give
each field a suggested format, the "conditionals" become more useful. 
Think of it as similar to the ternary operator (?:), only include the
portion of the format in parens if the field expands to a non-empty
string.

There could be a "global format" (that contains conditionals like the
above) that is used by default, and a suggested format for each album
and track (which would generate a string that is the format that
actually appears on the album cover).  Maybe the volume isn't a number,
but rather "The House-Techno Remix" or "Third". In these cases, the
album or track would have a customized suggested format that did not
necessarily include the word "Volume" or put it after the %volume string
rather than before.  

Also, the user could customize the format-string to use in the Tagger to
override the suggested format(s).  For example, maybe I want all my
volume numbers spelled out.  It may be better to force numbers into the
volume field, and then provide a function that expands numbers to
ordinal strings (1=>First, 2=>Second, 33=>Thirty-third).  So, then I
specify "%english_number(%volume)" (or a localized version) when tagging
my own files.

Migration could be relatively painless also.  Create the "extra" field,
and (maybe) initially populate it with information determined
programmaticly using regular expressions or whatnot (everything after a
colon, everything in parens, or something like that).  Make the default
suggested format string "%title %extra" -- this generates names exactly
like the old method.  Then add new fields, "subtitle", "volumes",
whatever, and then expand the suggested format string to include those
over time.  The tagger will have to be changed to dynamically list
fields you can edit (perhaps with a query to the server).  Once people
start seeing these "new" fields in the tagger, and that the information
is in the "wrong place" (in the extra field), they may be more inclined
to edit the data to put it into the correct fields.  ("Why is 'Volume 4'
in "extra" when there is a field for the Volume right there!? I better
put '4' in the Volume field and remove it from extra").

This gets rid of many of the style questions, including i18n.  The
format strings list localized words (Volumen or Volume or Vol., whatever
the user wants) and the %list and %range "functions" could have
localized versions also.

But this idea obviously needs more work.  I recently did something like
this for a retail sales product database and it worked pretty well (for
the small number of users who use that system, take from that what you
will); at least so far (they are still migrating some of the data to the
new fields).  Also, I hard coded the format strings in this case (comma
separated list), since I didn't have any i18n or style issues to deal
with.

-- 
Andy Bakun <musicbrainz at thwartedefforts.org>