Re: Reorganize language files and add a new \language command. (issue2699041)

[Carl Sorensen]

On 10/24/10 8:17 PM, "Valentin Villenave" <address@hidden> wrote:

> On Mon, Oct 25, 2010 at 3:57 AM,  <address@hidden> wrote:
>> Update the \version string in all of these files!
> 
> Well, I was reluctant to put a minor version number. Do you think
> putting "2.14.0" would be okay?
> 
>> Then, the argument to your music function would not be a string, but
>> rather a symbol:
>> 
>> \language #'italiano
> 
> I did consider it. However, I have three reasons not to use symbols:
> - from a user perspective, typing "italiano" is slightly more
> straightforward than typing #'italiano. Remember, this function is
> intended for newcomers, who wouldn't even use music variables or
> \score blocks, let alone \overrides, boolean or symbols!

Well, although your intention is to make it easy for newcomers, that's not
(IMO) a good reason to move forward on this.  There are lots of other ways
to make it easy on newcomers (e.g. a template file that starts with the
language statement).  For me, the real reason is to get a language selection
method that can run in safe mode.

> - this also allows me to treat the given argument as case-insensitive.

I think this is a reason *not* to use the case-insensitive implementation.
LilyPond input *is* case sensitive (r1 is not the same as R1, c4 is not the
same as C4).  I think we should always be case-sensitive if we're ever
case-sensitive.  I would prefer to eliminate the case conversion part of the
patch.  I think that the best thing we can do to be easier is to be
consistent.

> - last but not least, if we ever do implement the \language command as
> a parser token, taking a simple-string argument, then almost no
> changes will be needed (if anything, the "foobar" syntax will still
> work, but plain \language foobar, without quotes, will also be
> possible).

This answer is much more compelling to me.  \language italiano (like \clef
treble) is very consistent.  So you've convinced me that a string argument
is OK.

> 
> That being said, I can indeed nest all the alists together, without
> necessarily using a (symbol?) argument: string->symbol is reliable
> enough A new patchset is on its way..

Perfect!

> 
>> That way we don't have to mess with strings and string comparisons, we
>> just use symbols.
> 
> Well, I hope I made my point about using strings. I'm pretty hopeful
> that string->symbol does a reliable enough of a job to not qualify as
> "messy" :-)

Yep, it's fine.

Thanks,

Carl