> 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