On Wed, Mar 4, 2020 at 1:15 PM Werner LEMBERG <w...@gnu.org> wrote: > > From: Marnen Laibow-Koser <mar...@marnen.org> > > Date: Wed, 4 Mar 2020 10:35:00 -0500 > > > >> The search algorithm is actually documented in `usage.pdf`, > > > > I’ve never seen that file. Where would I find it? > > Ouch. It should be at > > > http://lilypond.org/doc/v2.19/Documentation/usage-big-page.html#relocation > > but it's missing! The same for > > http://lilypond.org/doc/v2.19/Documentation/usage.pdf > > which misses the whole section on relocation. > > This means that the HTML files on lilypond.org are not reflecting > 2.19.84 — I've added the documentation for relocation with commit > 7200d7365be more than a year ago... > > This is a serious problem IMHO. >
Yikes. That would explain why I hadn't seen it. :P > > > OMG this is documented? I wish I’d known all this weeks ago when I > > was writing the Mac Makefile! > > Sorry for that. I only use my self-compiled PDF files and didn't > notice that it's missing on the web page. > > > 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? > > Again: Patches are highly welcomed :-) > Understood, and perhaps I'll come up with something. (I can probably at least write C++ on the level required for relocate.cc...) Or perhaps it will turn out that there really isn't a better way than what you already did, at least without doing more redesign than I care to right now. > > > Werner > Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
