Re: [HACKERS] translatable string fixes
Alvaro Herrera writes: > It took me a very long time to figure out how to translate these 9.6-new > strings in the AM validate routines: > msgid "gin operator family \"%s\" contains support procedure %s with > cross-type registration" > ... > Maybe we can use this phrasing: > "gin operator family %s contains support procedure %s registered with > different left and right types" OK with me, or maybe better "support procedure %s with different left and right input types". I doubt "registered" adds much. > The other complaint I have about this one and also other amvalidate > functions is the hardcoded AM name, so it's actually one string per AM, > which is annoying (a total of twenty-something messages which are > actually only four or five different ones). Ignoring the second part of > the phrase now, we could use this: > "operator family %s of access method %s contains support procedure %s with > cross-type registration" If that seems better to the actual translators, it's OK with me. It's not real clear where is the boundary between combining near-duplicate messages and assembling messages at runtime. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [pgsql-translators] [HACKERS] translatable string fixes
On Tue, May 23, 2017 at 1:15 AM, Alvaro Herrera wrote: > It took me a very long time to figure out how to translate these 9.6-new > strings in the AM validate routines: > > msgid "gin operator family \"%s\" contains support procedure %s with > cross-type registration" > > The problem I had was that the term "cross-type registration" is not > used anywhere else, it's not clear what it means, and (worst from my > POV) I couldn't think of any decent phrasing in Spanish for it. After > staring at the code for a while, I translated them roughly as: > > "gin operator family %s contains support procedure %s registered with > differing types" > > which I think is a tad clearer ... but as a user confronted with such a > message, I would be at a complete loss on what to do about it. I did something similar, translating the equivalent of "across different types". Had to look at the source code to understand the meaning of the sentence. Maybe cross-type registration is a bit too cryptic. > Maybe we can use this phrasing: > "gin operator family %s contains support procedure %s registered with > different left and right types" > > > The other complaint I have about this one and also other amvalidate > functions is the hardcoded AM name, so it's actually one string per AM, > which is annoying (a total of twenty-something messages which are > actually only four or five different ones). Ignoring the second part of > the phrase now, we could use this: > "operator family %s of access method %s contains support procedure %s with > cross-type registration" Yup, that was boring and error-prone :\ -- Daniele -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] translatable string fixes
It took me a very long time to figure out how to translate these 9.6-new strings in the AM validate routines: msgid "gin operator family \"%s\" contains support procedure %s with cross-type registration" The problem I had was that the term "cross-type registration" is not used anywhere else, it's not clear what it means, and (worst from my POV) I couldn't think of any decent phrasing in Spanish for it. After staring at the code for a while, I translated them roughly as: "gin operator family %s contains support procedure %s registered with differing types" which I think is a tad clearer ... but as a user confronted with such a message, I would be at a complete loss on what to do about it. Maybe we can use this phrasing: "gin operator family %s contains support procedure %s registered with different left and right types" The other complaint I have about this one and also other amvalidate functions is the hardcoded AM name, so it's actually one string per AM, which is annoying (a total of twenty-something messages which are actually only four or five different ones). Ignoring the second part of the phrase now, we could use this: "operator family %s of access method %s contains support procedure %s with cross-type registration" Thoughts? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] translatable string fixes
I noticed this entry while updating the translation for 9.6:
#: catalog/index.c:3456 commands/vacuumlazy.c:1345 commands/vacuumlazy.c:1421
#: commands/vacuumlazy.c:1610 commands/vacuumlazy.c:1820
#, c-format
msgid "%s."
msgstr "%s."
All of these correspond to errdetail printing pg_rusage_show() output.
I think these are all bogus and should be changed to
errdetail_internal() instead. Surely if we want pg_rusage_show() output
to be translated, we should apply _() to the snprintf() call inside that
function.
At the same time, trying to append a period in the callers seems
pointless; if we really feel a strong need for that period I suggest we
add a flag to pg_rusage_show() to indicate whether to add it or not,
though my inclination is not to bother.
I also attach style fixes for other issues I found.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 96641d740437c5a002b852189754ca0a30f803fc Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sun, 21 May 2017 10:10:52 -0400
Subject: [PATCH 1/6] Make messages identical
---
src/backend/storage/page/bufpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/storage/page/bufpage.c
b/src/backend/storage/page/bufpage.c
index f2a07f2111..11607827d8 100644
--- a/src/backend/storage/page/bufpage.c
+++ b/src/backend/storage/page/bufpage.c
@@ -889,7 +889,7 @@ PageIndexMultiDelete(Page page, OffsetNumber *itemnos, int
nitems)
offset != MAXALIGN(offset))
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
-errmsg("corrupted item pointer: offset
= %u, size = %u",
+errmsg("corrupted item pointer: offset
= %u, length = %u",
offset, (unsigned int)
size)));
if (nextitm < nitems && offnum == itemnos[nextitm])
--
2.11.0
>From 81b220ba12027a85efb84690e9bce643bc2c93d1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sun, 21 May 2017 10:30:12 -0400
Subject: [PATCH 2/6] Make strings identical
---
src/backend/utils/adt/json.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/adt/json.c b/src/backend/utils/adt/json.c
index f704418603..192f9abae1 100644
--- a/src/backend/utils/adt/json.c
+++ b/src/backend/utils/adt/json.c
@@ -2003,7 +2003,7 @@ json_object_agg_transfn(PG_FUNCTION_ARGS)
if (arg_type == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-errmsg("could not determine data type
for argument 1")));
+errmsg("could not determine data type
for argument %d", 1)));
json_categorize_type(arg_type, &state->key_category,
&state->key_output_func);
@@ -2013,7 +2013,7 @@ json_object_agg_transfn(PG_FUNCTION_ARGS)
if (arg_type == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-errmsg("could not determine data type
for argument 2")));
+errmsg("could not determine data type
for argument %d", 2)));
json_categorize_type(arg_type, &state->val_category,
&state->val_output_func);
--
2.11.0
>From 8dbe584d39b4f19aab97f790652a827ecb943bbd Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sun, 21 May 2017 12:48:15 -0400
Subject: [PATCH 3/6] correctly do not quote type name
---
src/backend/catalog/pg_aggregate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/catalog/pg_aggregate.c
b/src/backend/catalog/pg_aggregate.c
index 959d3845df..ada6e6171b 100644
--- a/src/backend/catalog/pg_aggregate.c
+++ b/src/backend/catalog/pg_aggregate.c
@@ -433,7 +433,7 @@ AggregateCreate(const char *aggName,
if (aggTransType == INTERNALOID && func_strict(combinefn))
ereport(ERROR,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
-errmsg("combine function with \"%s\"
transition type must not be declared STRICT",
+errmsg("combine function with
transition type %s must not be declared STRICT",
format_type_be(aggTransType;
}
--
2.11.0
>From d0a06f1012e461f67ae4b24ca91f629a514d7138 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sun, 21 May 2017 13:44:20 -0400
Subject: [PATCH 4/6] Fix translation for pg_rusage_show()
---
src/bac
