Re: lilypond.org has wrong HTML files for 2.19.84 (was: How do I change LOCALEDIR?)

[Marnen Laibow-Koser]

On Wed, Mar 4, 2020 at 1:15 PM Werner LEMBERG  wrote:

> > From: Marnen Laibow-Koser 
> > 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

lilypond.org has wrong HTML files for 2.19.84 (was: How do I change LOCALEDIR?)

[Werner LEMBERG]

> From: Marnen Laibow-Koser 
> 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.

> 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 :-)


Werner

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Wed, Mar 4, 2020 at 10:05 AM Werner LEMBERG  wrote:

>
> > From: Marnen Laibow-Koser 
> >
> > I mean that it’s clearer who wrote what if you don’t delete the line
> > that says “Werner LEMBERG  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 mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

> From: Marnen Laibow-Koser 
>
> I mean that it’s clearer who wrote what if you don’t delete the line
> that says “Werner LEMBERG  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

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Tue, Mar 3, 2020 at 6:25 PM Werner LEMBERG  wrote:

>
> > [A suggestion: you may want to keep attributions when trimming
> > quotes.]
>
> What exactly do you mean?


I mean that it’s clearer who wrote what if you don’t delete the line that
says “Werner LEMBERG  wrote:” :)


>
> >> Let's assume that a user sets the LILYPOND_LOCALEDIR environment
> >> variable manually for experimental purposes but not in the
> >> relocation files.  To get translated messages early it makes sense
> >> to set up the locale before parsing the relocation files.
> >
> > I could run that same logic in the other direction too: to get the
> > canonical translated messages, it makes sense to parse the
> > relocation files before taking custom env into account. :)
>
> I don't like 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.


>
> Let's assume the opposite and do as you suggest, i.e., that we first
> read relocation files.  If the user explicitly sets LILYPOND_RELOCDIR


I wasn’t aware that this environment variable was looked for.  Or did you
mean LILYPOND_LOCALEDIR?


> 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?

I think that this parsing is
> slower than what I do in my patch.
>
> In other words, I think we should first read the LILYPOND_RELOCDIR
> environment variable.  For consistency I also suggest to read *all*
> environment variables intended for the `lilypond` binary before the
> relocation stuff gets parsed – even at the cost that `bindtextdomain`
> must be called again.


I’ll take a look at the logic flow with that in mind, but I strongly
suspect (not know!) that it could be made less convoluted.


>
> >> Additionally, the code right now is simple.  Calling
> >> `bindtextdomain` multiple times is not expensive, AFAIK.
> >
> > I wouldn’t call searching for strings three times “simple” by my
> > definition of the word.  Maybe it’s necessary, but I would hope that
> > we could do fallback on the arguments as provided to the program,
> > and then just call bindtextdomain once.
>
> Improvements are very welcomed!  BTW, it is not clear to me why you
> insist so strongly on calling `bindtextdomain` only once.  Please
> elaborate.


“Insist so strongly” is really overstating my position, but in general,
since there’s only one text domain to bind (right?), I’d rather not make
redundant calls if it can be avoided.  To me, this principle is so obvious
that it’s actually hard to put the reasons into words, but you deserve an
explanation, so: multiple calls makes the program logic harder to follow
and is the sort of thing that often covers up lurking design problems.

In this case, I’m not yet certain that there *is* a problem lurking here;
I’d have to look at the code more to be sure, and I’m willing to defer this
discussion till I do that.  But I find it a suspicious pattern: in general,
I’d rather figure the right arguments and make one call if possible, rather
than make three calls with successive guesses.  In my experience, while
guessing in code is *occasionally* useful, more often it implies (but does
not prove) hacking and working on faith, rather than reasoning clearly
about what the code is supposed to do and how.

I don’t mean that to be insulting in the slightest, BTW.  I appreciate the
patch and the suggestions; I’m just thinking about ways to improve it
further.  (You know the principle: make it work, make it right, make it
fast, in that order.)

Werner
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

> [A suggestion: you may want to keep attributions when trimming
> quotes.]

What exactly do you mean?

>> Let's assume that a user sets the LILYPOND_LOCALEDIR environment
>> variable manually for experimental purposes but not in the
>> relocation files.  To get translated messages early it makes sense
>> to set up the locale before parsing the relocation files.
> 
> I could run that same logic in the other direction too: to get the
> canonical translated messages, it makes sense to parse the
> relocation files before taking custom env into account. :)

I don't like that.  IMHO, environment variables should be handled as
being 'stronger' than stuff in relocation files.

Let's assume the opposite and do as you suggest, i.e., that we first
read relocation files.  If the user explicitly sets LILYPOND_RELOCDIR
it is necessary to call the relocation code a second time to parse the
files in the new relocation directory.  I think that this parsing is
slower than what I do in my patch.

In other words, I think we should first read the LILYPOND_RELOCDIR
environment variable.  For consistency I also suggest to read *all*
environment variables intended for the `lilypond` binary before the
relocation stuff gets parsed – even at the cost that `bindtextdomain`
must be called again.

>> Additionally, the code right now is simple.  Calling
>> `bindtextdomain` multiple times is not expensive, AFAIK.
> 
> I wouldn’t call searching for strings three times “simple” by my
> definition of the word.  Maybe it’s necessary, but I would hope that
> we could do fallback on the arguments as provided to the program,
> and then just call bindtextdomain once.

Improvements are very welcomed!  BTW, it is not clear to me why you
insist so strongly on calling `bindtextdomain` only once.  Please
elaborate.


Werner

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

[A suggestion: you may want to keep attributions when trimming quotes.]


On Tue, Mar 3, 2020 at 2:42 PM Werner LEMBERG  wrote:

[...]

>
> >
> > Why does it need to check the LILYPOND_LOCALEDIR environment
> > variable at all if the relocated parameter is present?  It seems to
> > me that it should only ever need to look at one of those, but
> > perhaps I’m not understanding something.
>
> Let's assume that a user sets the LILYPOND_LOCALEDIR environment
> variable manually for experimental purposes but not in the relocation
> files.  To get translated messages early it makes sense to set up the
> locale before parsing the relocation files.


I could run that same logic in the other direction too: to get the
canonical translated messages, it makes sense to parse the relocation files
before taking custom env into account. :)

I don’t know which is the right decision in this case, but I don’t think
one or the other is necessarily obvious.


>
> Additionally, the code right now is simple.  Calling `bindtextdomain`
> multiple times is not expensive, AFAIK.


I wouldn’t call searching for strings three times “simple” by my definition
of the word.  Maybe it’s necessary, but I would hope that we could do
fallback on the arguments as provided to the program, and then just call
bindtextdomain once.


>
>
> Werner
>
Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

>> I don't think that the logic flow is wrong.  The idea is to have
>> translated error and warning messages as soon as possible.  At the
>> very beginning, lilypond only knows about the compile-time
>> LOCALEDIR location.  Later on it checks the LILYPOND_LOCALEDIR
>> environment variable, and finally the relocated version of
>> LILYPOND_LOCALEDIR.
> 
> Why does it need to check the LILYPOND_LOCALEDIR environment
> variable at all if the relocated parameter is present?  It seems to
> me that it should only ever need to look at one of those, but
> perhaps I’m not understanding something.

Let's assume that a user sets the LILYPOND_LOCALEDIR environment
variable manually for experimental purposes but not in the relocation
files.  To get translated messages early it makes sense to set up the
locale before parsing the relocation files.

Additionally, the code right now is simple.  Calling `bindtextdomain`
multiple times is not expensive, AFAIK.


Werner

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Tue, Mar 3, 2020 at 12:36 PM Werner LEMBERG  wrote:
[...]

> > I’d really rather not patch the code if I don’t have to, and three
> > attempts to do anything seems smelly to me (it suggests that the
> > logic flow is in the wrong order),
>
> I don't think that the logic flow is wrong.  The idea is to have
> translated error and warning messages as soon as possible.  At the
> very beginning, lilypond only knows about the compile-time LOCALEDIR
> location.  Later on it checks the LILYPOND_LOCALEDIR environment
> variable, and finally the relocated version of LILYPOND_LOCALEDIR.


Why does it need to check the LILYPOND_LOCALEDIR environment variable at
all if the relocated parameter is present?  It seems to me that it should
only ever need to look at one of those, but perhaps I’m not understanding
something.

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

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

>> Please try the attached patch.  It now calls `bindtextdomain` a
>> third time to take care of setting `LILYPOND_LOCALEDIR` in the
>> relocation files.
> 
> I’d really rather not patch the code if I don’t have to, and three
> attempts to do anything seems smelly to me (it suggests that the
> logic flow is in the wrong order),

I don't think that the logic flow is wrong.  The idea is to have
translated error and warning messages as soon as possible.  At the
very beginning, lilypond only knows about the compile-time LOCALEDIR
location.  Later on it checks the LILYPOND_LOCALEDIR environment
variable, and finally the relocated version of LILYPOND_LOCALEDIR.

If you know a better solution please make suggestions.

> but I’ll give the patch a try and see if it fixes the proximate
> issue.

Thanks.


Werner

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Tue, Mar 3, 2020 at 7:40 AM Werner LEMBERG  wrote:

> >> If I understand the code correctly (in file `relocate.cc`), the two
> >> calls to `bindtextdomain` happen before relocation files are
> >> read.[*] In other words, the `LILYPOND_LOCALEDIR` environment
> >> variable is honoured but a corresponding assignment in relocation
> >> files are ignored (for the lilypond binary itself – child programs
> >> do get the updated environment variable).
> >>
> >> Maybe this approach should be changed?
> >
> > Perhaps!  What is the point of overriding the environment setting
> > for LOCALEDIR?  Does LilyPond itself use that setting, or do only
> > the child programs use it?
>
> Please try the attached patch.  It now calls `bindtextdomain` a third
> time to take care of setting `LILYPOND_LOCALEDIR` in the relocation
> files.


I’d really rather not patch the code if I don’t have to, and three attempts
to do anything seems smelly to me (it suggests that the logic flow is in
the wrong order), but I’ll give the patch a try and see if it fixes the
proximate issue.  Thanks.

Werner


Best,

>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

>> If I understand the code correctly (in file `relocate.cc`), the two
>> calls to `bindtextdomain` happen before relocation files are
>> read.[*] In other words, the `LILYPOND_LOCALEDIR` environment
>> variable is honoured but a corresponding assignment in relocation
>> files are ignored (for the lilypond binary itself – child programs
>> do get the updated environment variable).
>>
>> Maybe this approach should be changed?
> 
> Perhaps!  What is the point of overriding the environment setting
> for LOCALEDIR?  Does LilyPond itself use that setting, or do only
> the child programs use it?

Please try the attached patch.  It now calls `bindtextdomain` a third
time to take care of setting `LILYPOND_LOCALEDIR` in the relocation
files.


Werner
>From fb1c6fea888450974eafc0b31add9a2d926d0106 Mon Sep 17 00:00:00 2001
From: Werner Lemberg 
Date: Tue, 3 Mar 2020 11:02:02 +0100
Subject: [PATCH] relocate.cc: Try harder to find directory for translations

This commit adds a third call to find translations; we now have the
following search algorithm.

  * Try the `LOCALEDIR` value as found with the `configure` script.
  * Try the `LILYPOND_LOCALEDIR` environment variable.
  * After relocation files are read, try the `LILYPOND_LOCALEDIR` variable
again.
---
 lily/relocate.cc | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/lily/relocate.cc b/lily/relocate.cc
index 63259e6913..6800c21ba3 100644
--- a/lily/relocate.cc
+++ b/lily/relocate.cc
@@ -211,6 +211,17 @@ setup_paths (char const *argv0_ptr)
   string bindir = File_name (dir_name (argv0_abs)).canonicalized ().to_string ();
   string prefix = File_name (bindir + "/..").canonicalized ().to_string ();
 
+#if HAVE_GETTEXT
+  // second try to get translations (using the LILYPOND_LOCALEDIR
+  // environment variable)
+  string localedir = set_up_directory ("LILYPOND_LOCALEDIR",
+   "localedir",
+   LOCALEDIR,
+   prefix + "/share/locale");
+  if (is_dir (localedir))
+bindtextdomain ("lilypond", localedir.c_str ());
+#endif
+
   // set INSTALLER_PREFIX environment variable
   sane_putenv ("INSTALLER_PREFIX", prefix.c_str (), true, true);
 
@@ -223,23 +234,24 @@ setup_paths (char const *argv0_ptr)
PACKAGE_DATADIR "/" TOPLEVEL_VERSION,
prefix + "/share/lilypond/" TOPLEVEL_VERSION,
prefix + "/share/lilypond/current");
-  string localedir = set_up_directory ("LILYPOND_LOCALEDIR",
-   "localedir",
-   LOCALEDIR,
-   prefix + "/share/locale");
   string relocdir = set_up_directory ("LILYPOND_RELOCDIR",
   "relocdir",
   "", // no compile-time default
   prefix + "/etc/relocate");
+  if (is_dir (relocdir))
+read_relocation_dir (relocdir);
 
 #if HAVE_GETTEXT
+  // the relocation files might have changed LILYPOND_LOCALEDIR again,
+  // so we try to get translations a third and final time
+  localedir = set_up_directory ("LILYPOND_LOCALEDIR",
+"localedir",
+LOCALEDIR,
+prefix + "/share/locale");
   if (is_dir (localedir))
 bindtextdomain ("lilypond", localedir.c_str ());
 #endif
 
-  if (is_dir (relocdir))
-read_relocation_dir (relocdir);
-
   prepend_env_path ("PATH", bindir);
   global_path.append ("");
 
-- 
2.16.4

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Mon, Mar 2, 2020 at 1:15 AM Werner LEMBERG  wrote:

>
> > how do I set LOCALEDIR (in this case, to match the packaged app
> > bundle rather than the build-time path)?  Unlike everything else of
> > this nature, neither the .reloc files nor environment variables work
> > (and I've tried setting both LOCALEDIR and LILYPOND_LOCALEDIR in
> > both places): when I use the .reloc file, it clearly finds the
> > setting in the file, but then later blithely prints out
> > LOCALEDIR="the/old/value/I/didn't/want".
>
> What exactly do you want to achieve?


I want LOCALEDIR to point to where the locales will actually be in the .app
bundle (under $INSTALLER_PREFIX).


> If I understand the code
> correctly (in file `relocate.cc`), the two calls to `bindtextdomain`
> happen before relocation files are read.[*] In other words, the
> `LILYPOND_LOCALEDIR` environment variable is honoured but a
> corresponding assignment in relocation files are ignored (for the
> lilypond binary itself – child programs do get the updated environment
> variable).
>
> Maybe this approach should be changed?
>

Perhaps!  What is the point of overriding the environment setting for
LOCALEDIR?  Does LilyPond itself use that setting, or do only the child
programs use it?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: How do I change LOCALEDIR?

[Hans Åberg]

> On 2 Mar 2020, at 01:46, Marnen Laibow-Koser  wrote:
> 
> On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg  wrote:
> 
> > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser  wrote:
> > 
> > One question as I continue to work on 64-bit Mac packaging: how do I set
> > LOCALEDIR (in this case, to match the packaged app bundle rather than the
> > build-time path)?  Unlike everything else of this nature, neither the
> > .reloc files nor environment variables work (and I've tried setting both
> > LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
> > file, it clearly finds the setting in the file, but then later blithely
> > prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal with
> > this?
> 
> I use a script, see [1]. It may work in an app bundle, too.
> 
> 1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html
> 
> Your script appears to set the LC_* locale variables, but not LOCALEDIR, 
> which is what I was asking about.  Am I wrong?

Yes, but I see from Werner’s post it wouldn’t work in our case.

Re: How do I change LOCALEDIR?

[Werner LEMBERG]

> how do I set LOCALEDIR (in this case, to match the packaged app
> bundle rather than the build-time path)?  Unlike everything else of
> this nature, neither the .reloc files nor environment variables work
> (and I've tried setting both LOCALEDIR and LILYPOND_LOCALEDIR in
> both places): when I use the .reloc file, it clearly finds the
> setting in the file, but then later blithely prints out
> LOCALEDIR="the/old/value/I/didn't/want".

What exactly do you want to achieve?  If I understand the code
correctly (in file `relocate.cc`), the two calls to `bindtextdomain`
happen before relocation files are read.[*] In other words, the
`LILYPOND_LOCALEDIR` environment variable is honoured but a
corresponding assignment in relocation files are ignored (for the
lilypond binary itself – child programs do get the updated environment
variable).

Maybe this approach should be changed?


Werner


[*] The first call uses the compile-time value `LOCALEDIR`, the second
call shortly thereafter the `LILYPOND_LOCALDIR` environment
variable.

Re: How do I change LOCALEDIR?

[Marnen Laibow-Koser]

On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg  wrote:

>
> > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser  wrote:
> >
> > One question as I continue to work on 64-bit Mac packaging: how do I set
> > LOCALEDIR (in this case, to match the packaged app bundle rather than the
> > build-time path)?  Unlike everything else of this nature, neither the
> > .reloc files nor environment variables work (and I've tried setting both
> > LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
> > file, it clearly finds the setting in the file, but then later blithely
> > prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal
> with
> > this?
>
> I use a script, see [1]. It may work in an app bundle, too.
>
> 1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html


Your script appears to set the LC_* locale variables, but not LOCALEDIR,
which is what I was asking about.  Am I wrong?
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: How do I change LOCALEDIR?

[Hans Åberg]

> On 1 Mar 2020, at 23:45, Marnen Laibow-Koser  wrote:
> 
> One question as I continue to work on 64-bit Mac packaging: how do I set
> LOCALEDIR (in this case, to match the packaged app bundle rather than the
> build-time path)?  Unlike everything else of this nature, neither the
> .reloc files nor environment variables work (and I've tried setting both
> LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
> file, it clearly finds the setting in the file, but then later blithely
> prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal with
> this?

I use a script, see [1]. It may work in an app bundle, too.

1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html

How do I change LOCALEDIR?

[Marnen Laibow-Koser]

One question as I continue to work on 64-bit Mac packaging: how do I set
LOCALEDIR (in this case, to match the packaged app bundle rather than the
build-time path)?  Unlike everything else of this nature, neither the
.reloc files nor environment variables work (and I've tried setting both
LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
file, it clearly finds the setting in the file, but then later blithely
prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal with
this?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org