One file per line seems best. We already did this in some cases. This adopts the same format everywhere (except in some cases where the list reasonably fits on one line).
This reverts commit 617d69141220f277170927e03a19d2f1b77aed77. While I still think the basic idea is attractive, we need to sort out what happens with built .c files, and there also seem to be VPATH issues.
The backend already used a mechanically-generated list of *.c files, but everywhere else we had a manually-written-out list of files in which to seek translatable messages. Commit b0a55e432 contains the latest in a long line of failures to update those lists. Rather than manually fix its oversight, let's change to using "$(wildcard *.c)" in all these nls.mk files. Many of these files also have manual references to some *.c files in other directories, most often src/common/. Perhaps we should try to improve that situation too; but it's a bit less clear how, so for now just fix the local file references. Kyotaro Horiguchi and Tom Lane Discussion: https://postgr.es/m/20220713.160853.453362706160476128.horikyota.ntt@gmail.com
This moves the list of available languages from nls.mk into a separate file called po/LINGUAS. Advantages: - It keeps the parts notionally managed by programmers (nls.mk) separate from the parts notionally managed by translators (LINGUAS). - It's the standard practice recommended by the Gettext manual nowadays. - The Meson build system also supports this layout (and of course doesn't know anything about our custom nls.mk), so this would enable sharing the list of languages between the two build systems. (The MSVC build system currently finds all po files by globbing, so it is not affected by this change.) Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/557a9f5c-e871-edc7-2f58-a4140fb65b7b@enterprisedb.com
Get rid of the separate "FATAL" log level, as it was applied so inconsistently as to be meaningless. This mostly involves s/pg_log_fatal/pg_log_error/g. Create a macro pg_fatal() to handle the common use-case of pg_log_error() immediately followed by exit(1). Various modules had already invented either this or equivalent macros; standardize on pg_fatal() and apply it where possible. Invent the ability to add "detail" and "hint" messages to a frontend message, much as we have long had in the backend. Except where rewording was needed to convert existing coding to detail/hint style, I have (mostly) resisted the temptation to change existing message wording. Patch by me. Design and patch reviewed at various stages by Robert Haas, Kyotaro Horiguchi, Peter Eisentraut and Daniel Gustafsson. Discussion: https://postgr.es/m/1363732.1636496441@sss.pgh.pa.us
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1c361d3ac016b61715d99f2055dee050397e3f13
In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of warn_or_exit_horribly() were changed but this was not updated.