[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dlang] Internationalisation WIP
From: |
Akim Demaille |
Subject: |
Re: [Dlang] Internationalisation WIP |
Date: |
Thu, 3 Dec 2020 07:07:58 +0100 |
Hi Adela,
> Le 2 déc. 2020 à 01:33, Adela Vais <adela.vais99@gmail.com> a écrit :
>
> Hello!
>
> I never worked with gettext (as a bash command) before, and I have some
> trouble understanding how I automatically generate the .mo files and put
> them into /usr/local/share/locale (where the code from the
> examples/c/bisthromatic hints they should be found).
I would not bother with this. The Makefile machinery is there for us
not to have to think about that. You will find the po files in po/
and in runtime-po/.
Let "make install" do its job.
> My understanding is
> that from the .po files I have to generate .mo files, and these are used by
> the programs generated with Bison.
Yes. But you should not have to do that by hand. Just install Bison.
> If I try to run "sudo make install" in the po directory I get this error:
>
> [...]
> /usr/bin/install: cannot stat './bg.gmo': No such file or directory
> installing ./bg.gmo as /usr/local/share/locale/bg/LC_MESSAGES/bison.mo
> [...]
>
> and so on for each language file. After the command, no files exist in the
> LC_MESSAGES directories.
I need more details, your logs are too short. What do you have in po/?
and in runtime-po? Did you properly run "./bootstrap"?
> If I run make update-po or update-gmo, I also get errors for missing files.
I need logs.
> The second problem is that I expected dgettext to receive the argument
> "bison-runtime", like in C, not "bison", as it happens now in D. If I use
> "bison-runtime" the messages remain in English.
Did you check whether the PO files in bison-runtime do contain the
translations you depend upon?
I don't know what you mean here. The reason the C skeleton uses
bison-runtime is because it does so explicitly:
# if ENABLE_NLS
# include <libintl.h> /* INFRINGES ON USER NAME SPACE */
# define YY_(Msgid) dgettext ("bison-runtime", Msgid)
# endif
So all the messages generated by *bison* use YY_, i.e., translations
from the bison-runtime catalogue. While *user* messages are translated
as follows (from c/bistromathic):
#if defined ENABLE_NLS && ENABLE_NLS
# define _(Msgid) gettext (Msgid)
#else
# define _(Msgid) (Msgid)
#endif
static const char *
yysymbol_name (yysymbol_kind_t yysymbol)
{
static const char *const yy_sname[] =
{
N_("end of file"), N_("error"), N_("invalid token"), "+", "-", "*", "/",
"^", "(", ")", "=", "exit", N_("number"), N_("function"), N_("variable"),
"NEG", "$accept", "input", "exp", YY_NULLPTR
};
/* YYTRANSLATABLE[SYMBOL-NUM] -- Whether YY_SNAME[SYMBOL-NUM] is
internationalizable. */
static yytype_int8 yytranslatable[] =
{
1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
0, 0, 1, 1, 1, 0
};
return (yysymbol < YYNTOKENS && yytranslatable[yysymbol]
? _(yy_sname[yysymbol]) <========================
: yy_sname[yysymbol]);
}
That means, of course, that both catalogues must be loaded. In the
bistromathic you'll see
#if defined ENABLE_NLS && ENABLE_NLS
// Set up internationalization.
setlocale (LC_ALL, "");
// Use Bison's standard translation catalogue for error messages
// (the generated messages).
bindtextdomain ("bison-runtime", BISON_LOCALEDIR);
// The translation catalogue of bistromathic is actually included in
// Bison's. In your own project, use the name of your project.
bindtextdomain ("bison", LOCALEDIR);
textdomain ("bison");
#endif
But you know all this, since you did it properly in your branch.
> Here [1] (and also as attachments) is a work in progress for this task,
> with the mention that examples/d/c/calc/calc.y is modified just for testing
> reasons, it will not be changed in the official commit.
Let's address your issues one at a time. First, let's see why
make install fails for you.
Cheers!