Re: ready for 2.21.80?

[Jonas Hahnfeld]

Am Sonntag, den 25.10.2020, 20:14 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 25.10.2020, 19:57 +0100 schrieb Jonas Hahnfeld:
> > Am Sonntag, den 25.10.2020, 19:29 +0100 schrieb Jean-Charles
> > Malahieude:
> > > Le 25/10/2020 à 19:13, Jonas Hahnfeld a écrit :
> > > > I can try to help if I understand the problem in detail. As you mention
> > > > the NR, you're probably referring to the Selected Snippets / Morceaux
> > > > choisis? The first example would be:
> > > > http://lilypond.org/doc/v2.21/Documentation/notation/writing-pitches.fr.html#accidentals
> > > > Are you saying that you're seeing the English text instead?
> > > 
> > > Exactly. And it's the same everywhere. I can't check snippets.html since 
> > > its revival came just this Summer (but it was in French except for the 
> > > menu).
> > > 
> > > > As a translator, you're probably building in-tree without a separate
> > > > build directory? I'll test that kind of setup in a second, maybe
> > > > there's a problem with that.
> > > 
> > > Thank you for any idea you might dig out!
> > 
> > So it's indeed this setup and I can reproduce the problem when
> > configuring and building directly in the source tree. Unfortunately, I
> > suspect this is fallout from
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/347 which would
> > be a pain to revert. I need to think if I can spot an error in the
> > include path order and if it's possible to correct without breaking a
> > bunch of other stuff...
> 
> Oh no, that's again the problem that lilypond-book prepends the current
> working directory to the list of include paths. So fully qualifying as
> snippets/<name>.ly makes the in-tree build first find the (unprocessed)
> file Documentation/snippets/<name>.ly and not the translated one in
> Documentation/out-www/snippets/<name>.ly

Changing directory before invoking lilypond-book might solve this
problem and help against similar issues in the future:
https://gitlab.com/lilypond/lilypond/-/merge_requests/479

This looks good in preliminary testing, both with separate build tree
and for in-tree compilation. To be sure, I'm currently doing a full
build with GUB. In the mean time, I'll investigate if it would be
feasible to revert !347 without too many conflicts...

signature.asc
Description: This is a digitally signed message part