From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | make update-po@master stops at pg_upgrade |
Date: | 2022-07-13 07:08:53 |
Message-ID: | 20220713.160853.453362706160476128.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm not sure if it fits -hackers, but seems better than -translators.
I find it annoying that make update-po stops at pg_upgrade on master.
The cause is that a file is renamed from relfilenode.c to
relfilenumber.c so just fixing the name works. (attached first).
On the other hand, basically, every nls.mk contain all *.c files in the
tool's directory plus some in other directories with some exceptions:
a) nls.mk of pg_dump and psql contain some *.h files but they don't
contain a translatable string.
b) nls.mk of ecpglib is missing some files that contain translatable
strings. (adding theses files doesn't change the result of make
update-po, but I'll send another mail for this issue.)
c) nls.mk of pg_waldump, psql, libpq and preproc excludes some *.c
files which don't contain a translatable string.
At least for (a) above, removing them from nls.mk is rather good. For
(b), adding them is also good. For (c), I think few extra files
doesn't make difference.
I wonder if we can use $(wildcard *.c) instead of explicitly
enumerating every *.c file in the directory then maintaining the
list. Since backend does that way, I think we can do that the same way
also for the tools. Attached second does that except for tools that
have only one *.c. The patch doesn't make a difference in the result
of make update-po.
Either will do for me but at least I'd like (a) applied.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
pg_upgrade_nls_mk_relfilenumber.patch | text/x-patch | 668 bytes |
nls_mk_use_wildcard.patch | text/x-patch | 10.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-07-13 07:43:29 | Re: Refactor to make use of a common function for GetSubscriptionRelations and GetSubscriptionNotReadyRelations. |
Previous Message | Amit Langote | 2022-07-13 07:03:51 | Re: generic plans and "initial" pruning |