> From: Marnen Laibow-Koser <mar...@marnen.org>
>
> I mean that it’s clearer who wrote what if you don’t delete the line
> that says “Werner LEMBERG <w...@gnu.org> wrote:” :)
Ah, my mailer doesn't generate 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.
Yes, and this choice was set a longer time ago already. The search
algorithm is actually documented in `usage.pdf`, 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.
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.
>> 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. 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) before the English translation
files are eventually set up. Not everyone is fluent in English, and
especially error messages tend to be cryptic in general.
Werner
