Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Wed, Mar 4, 2020 at 10:05 AM Werner LEMBERG <address@hidden> wrote:

>
> > From: Marnen Laibow-Koser <address@hidden>
> >
> > I mean that it’s clearer who wrote what if you don’t delete the line
> > that says “Werner LEMBERG <address@hidden> wrote:” :)
>
> Ah, my mailer doesn't generate that.


Maybe it’s worth seeing if you can set it to generate it.  This has been a
standard part of quoting at least since I first encountered it on Usenet in
the early 1990s.


>
> >> 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.
>
> Yes, and this choice was set a longer time ago already.  The search
> algorithm is actually documented in `usage.pdf`,


I’ve never seen that file.  Where would I find it?

section 'Relocation
> algorithm':
>
>   1. Compute the directory where the currently executed lilypond
>      binary is located.  Let’s call this `bindir`.  Set (internal)
>      environment variable `INSTALLER_PREFIX` to `bindir/..` (i.e., the
>      parent directory of `bindir`).
>
>   2. Check environment variable `LILYPOND_DATADIR`.  If it is set, use
>      its value for LilyPond’s data directory, `datadir`.  Otherwise
>      use either `$INSTALLER_PREFIX/share/lilypond/version` (with
>      `version` being the current LilyPond version) or
>      `$INSTALLER_PREFIX/share/lilypond/current`.
>
>   3. Check environment variable `LILYPOND_LOCALEDIR`.  If it is set,
>      use its value for LilyPond’s locale data directory, `localedir`.
>      Otherwise use `$INSTALLER_PREFIX/share/locale`.
>
>   4. Check environment variable `LILYPOND_RELOCDIR`.  If it is set,
>      use its value for the directory of LilyPond’s relocation files,
>      `relocdir`.  Otherwise use `$INSTALLER_PREFIX/etc/relocate`.
>
>   5. If `datadir` doesn’t exist, use a compile-time value instead.
>      Ditto for `localedir` (but not for `relocdir`, since it doesn’t
>      make sense to have that).
>
>   6. If `relocdir` exists, process all files in this directory as
>      described in [Relocation files], page 11.


OMG this is documented?  I wish I’d known all this weeks ago when I was
writing the Mac Makefile!  I wound up trying to make sense of relocate.cc
instead (and I’m not all that great at C++, though relocate.cc is one of
the more readable examples of it that I’ve seen).


>
> My patch would extend this with
>
>   7. Repeat step 3 since step 6 might set or overwrite
>      `LILYPOND_LOCALEDIR`.  (Changes to `LILYPOND_DATADIR` and
>      `LILYPOND_RELOCDIR` in relocation files are ignored, however.)


>
> It's a bit clumsy, I know, so if you have better ideas please please
> tell us.


My first idea would be to move step 3 after step 7.  But I don’t know if
that would actually work. :)


>
> >> 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?
>
> The idea of localized error messages is to use them as early as
> possible IMHO.


Sure, that makes sense.

Just imagine that the program's master language is
> Chinese, and you get illegible stuff (or even hollow boxes if you
> don't have a Chinese font installed)


(Does any general-purpose OS distribution these days *not* have at least
one Chinese font installed?)

before the English translation
> files are eventually set up.


Not really disputing your point, but this is a poor analogy: Lily’s master
language *isn’t* Chinese; it’s English, and pretty much every computer
system in the world that can run Lily can display ASCII.  (Yeah, I know, I
did some programming on an EBCDIC system in the 1990s, but...)

Not everyone is fluent in English, and
> especially error messages tend to be cryptic in general.


Sure, and I’d obviously *rather* that we have the localized strings as
early as possible.  But to me, the most obvious way of doing that
*correctly* would be to determine the *actual* locale path as early as
possible, and to call bindtextdomain (once) as soon as possible after
that.  After all, if LOCALEDIR has been changed, then it’s very likely that
the early call to bindtextdomain (with the obsolete path) won’t *actually*
load any usable strings, so what’s the point of having it?

    Werner


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