[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Ticket 4337 di

Ok, for what it is worth, here is my take on it (and more or less what I ended up with at the end of the discussion): I think the advantages of a language-agnostic tagline outweigh the advantages of a translated promotional opportunity.

Writing just "LilyPond" (which does have a logofied spelling) is likely not making LilyPond's role overly clear, but "LilyPond 2.19.48" looks like a version number (unless you consider it a publisher's catalogue number). It also helps actual users to keep track of just when some score might be worth retypesetting with a current version. This will incentivize people to keep the tagline in even if they are distributing paper scores to people not working with LilyPond. And of course, we can make a clickable link in the PDF. It would be nice if we had a more logoesque readable logo than just "LilyPond" but being suitably small and readable and graphical at the same time is probably too much to expect.

So I'd vote for "LilyPond x.xx.xx" with an underlying link to http://lilypond.org and that's about it. It has a good chance to stay in, it's international, it's both pretty decent and informative (and the version number might help against the "I've seen LilyPond scores and they did not look good" effect for scores compiled 15 years ago).

Yes, there were a variety of opinions. This is not really a consensus solution but I think one a lot of people will be able to live with.

That leaves the question of a general document language support infrastructure open. Maybe we won't really need it, maybe it will be desirable. But for the tagline, I think overall we are better off without requiring it at all.

[issues:#4337] Enhancement: automatically translate tagline

Status: Accepted
Created: Fri Apr 03, 2015 04:29 AM UTC by Anonymous
Last Updated: Wed Sep 07, 2016 03:07 PM UTC
Owner: nobody

Originally created by: *anonymous

Originally created by: address@hidden

Simon Albrecht wrote :

please open a tracker issue for this thread. I’m going to make another essay at coding something sensible.

Yours,
Simon

Am 16.03.2015 um 12:13 schrieb Simon Albrecht:
Am 16.03.2015 um 10:22 schrieb David Kastrup:
Simon Albrecht <address@hidden> writes:

Thanks for elaborating, Harm. That’s some elegant coding with which I
couldn’t have come up :-)

Am 15.03.2015 um 19:22 schrieb Thomas Morley:

[snip]
\version "2.19.16"

%% Please note, \language has to be declared before 'used-language'
%% is done or included, (if stored elsewhere)
\language "deutsch"
%\language "english"
%% if no tagline for a language is defined, default-english will be
printed
%\language "catalan"

%% TODO: find better method to detect which language is actually used
#(define used-language
   (car
     (find
       (lambda (e) (eq? (cdr e) (ly:parser-lookup parser 'pitchnames)))
       language-pitch-names)))
I imagine that a generic solution worth being included in the code
base would require this definition to be made through the \language
command itself.
I don't think it is a tenable solution to equate notename language with
document language.

Definitely. Or would a survey be useful on the relationship of “input and output language” in current use?
After all, I have no idea on how many users actually change the defaults for both (i.e. use \language and define their own tagline and tocHeaderMarkup &c.).
Alternative user syntax drafts:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

document-languages =
#'((input-language . dutch)
(output-language . english))
%% that would be the default
%% output-language might be used for other things also, e.g. table of contents.

% Scenario 1: (my favourite)
\language "deutsch"
% sets both values to 'deutsch
\language output "italiano"
% sets only output-language and leaves input-language as default
% two language commands would be used
% in order to have different non-default settings for both

% Scenario 2:
\inputLanguage "catalan"
\outputLanguage "english"
% perhaps with \language still setting both –
% or only input-language for backwards compatibility?
% Shouldn’t be too difficult for convert-ly though.

% mix both scenarios

\language "deutsch"
% sets only input-language for backward compatibility reasons
\language output "espanol"
% provide no command for setting both – may be easier understood then

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On naming: perhaps input-language is too wide, because all the commands and identifiers are in English anyway. Then it would better be called notename-language.

I hope you agree that it’s worthwhile to make all these thoughts and that it would be good to have such functionality in an easy-to-use way.

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

From:	Auto mailings of changes to Lily Issues
Subject:	[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Ticket 4337 discussion
Date:	Wed, 07 Sep 2016 16:01:17 +0000