Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Tue, Mar 3, 2020 at 6:25 PM Werner LEMBERG <address@hidden> wrote:

>
> > [A suggestion: you may want to keep attributions when trimming
> > quotes.]
>
> What exactly do you mean?


I mean that it’s clearer who wrote what if you don’t delete the line that
says “Werner LEMBERG <address@hidden> wrote:” :)


>
> >> Let's assume that a user sets the LILYPOND_LOCALEDIR environment
> >> variable manually for experimental purposes but not in the
> >> relocation files.  To get translated messages early it makes sense
> >> to set up the locale before parsing the relocation files.
> >
> > I could run that same logic in the other direction too: to get the
> > canonical translated messages, it makes sense to parse the
> > relocation files before taking custom env into account. :)
>
> I don't like that.  IMHO, environment variables should be handled as
> being 'stronger' than stuff in relocation files.


I think I tend to agree with you, actually, but my point is that it’s a
choice that has to be explicitly made one way or the other.


>
> Let's assume the opposite and do as you suggest, i.e., that we first
> read relocation files.  If the user explicitly sets LILYPOND_RELOCDIR


I wasn’t aware that this environment variable was looked for.  Or did you
mean LILYPOND_LOCALEDIR?


> it is necessary to call the relocation code a second time to parse the
> files in the new relocation directory.


Why?  Why not delay the parsing till *after* the relocation directory path
is established, so we can only do it once?  Do we need localized strings
for errors that happen before that?

I think that this parsing is
> slower than what I do in my patch.
>
> In other words, I think we should first read the LILYPOND_RELOCDIR
> environment variable.  For consistency I also suggest to read *all*
> environment variables intended for the `lilypond` binary before the
> relocation stuff gets parsed – even at the cost that `bindtextdomain`
> must be called again.


I’ll take a look at the logic flow with that in mind, but I strongly
suspect (not know!) that it could be made less convoluted.


>
> >> Additionally, the code right now is simple.  Calling
> >> `bindtextdomain` multiple times is not expensive, AFAIK.
> >
> > I wouldn’t call searching for strings three times “simple” by my
> > definition of the word.  Maybe it’s necessary, but I would hope that
> > we could do fallback on the arguments as provided to the program,
> > and then just call bindtextdomain once.
>
> Improvements are very welcomed!  BTW, it is not clear to me why you
> insist so strongly on calling `bindtextdomain` only once.  Please
> elaborate.


“Insist so strongly” is really overstating my position, but in general,
since there’s only one text domain to bind (right?), I’d rather not make
redundant calls if it can be avoided.  To me, this principle is so obvious
that it’s actually hard to put the reasons into words, but you deserve an
explanation, so: multiple calls makes the program logic harder to follow
and is the sort of thing that often covers up lurking design problems.

In this case, I’m not yet certain that there *is* a problem lurking here;
I’d have to look at the code more to be sure, and I’m willing to defer this
discussion till I do that.  But I find it a suspicious pattern: in general,
I’d rather figure the right arguments and make one call if possible, rather
than make three calls with successive guesses.  In my experience, while
guessing in code is *occasionally* useful, more often it implies (but does
not prove) hacking and working on faith, rather than reasoning clearly
about what the code is supposed to do and how.

I don’t mean that to be insulting in the slightest, BTW.  I appreciate the
patch and the suggestions; I’m just thinking about ways to improve it
further.  (You know the principle: make it work, make it right, make it
fast, in that order.)

    Werner
>
-- 
Marnen Laibow-Koser address@hidden http://www.marnen.org Sent from Gmail
Mobile