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 Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Make-messages-identical.patchtext/plain; charset=us-asciiDownload
From 96641d740437c5a002b852189754ca0a30f803fc Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
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
0002-Make-strings-identical.patchtext/plain; charset=us-asciiDownload
From 81b220ba12027a85efb84690e9bce643bc2c93d1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
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
0003-correctly-do-not-quote-type-name.patchtext/plain; charset=us-asciiDownload
From 8dbe584d39b4f19aab97f790652a827ecb943bbd Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
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
0004-Fix-translation-for-pg_rusage_show.patchtext/plain; charset=us-asciiDownload
From d0a06f1012e461f67ae4b24ca91f629a514d7138 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun, 21 May 2017 13:44:20 -0400
Subject: [PATCH 4/6] Fix translation for pg_rusage_show()
---
src/backend/catalog/index.c | 2 +-
src/backend/commands/vacuumlazy.c | 10 ++++------
src/backend/utils/misc/pg_rusage.c | 2 +-
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index b0b43cf02d..6aae1ab6fd 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -3453,7 +3453,7 @@ reindex_index(Oid indexId, bool skip_constraint_checks, char persistence,
ereport(INFO,
(errmsg("index \"%s\" was reindexed",
get_rel_name(indexId)),
- errdetail("%s.",
+ errdetail_internal("%s",
pg_rusage_show(&ru0))));
/* Close rels, but keep locks */
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index e1e39dfb4e..0506a9340c 100644
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -1342,8 +1342,7 @@ lazy_scan_heap(Relation onerel, int options, LVRelStats *vacrelstats,
"%u pages are entirely empty.\n",
empty_pages),
empty_pages);
- appendStringInfo(&buf, _("%s."),
- pg_rusage_show(&ru0));
+ appendStringInfo(&buf, "%s.", pg_rusage_show(&ru0));
ereport(elevel,
(errmsg("\"%s\": found %.0f removable, %.0f nonremovable row versions in %u out of %u pages",
@@ -1418,8 +1417,7 @@ lazy_vacuum_heap(Relation onerel, LVRelStats *vacrelstats)
(errmsg("\"%s\": removed %d row versions in %d pages",
RelationGetRelationName(onerel),
tupindex, npages),
- errdetail("%s.",
- pg_rusage_show(&ru0))));
+ errdetail_internal("%s", pg_rusage_show(&ru0))));
}
/*
@@ -1607,7 +1605,7 @@ lazy_vacuum_index(Relation indrel,
(errmsg("scanned index \"%s\" to remove %d row versions",
RelationGetRelationName(indrel),
vacrelstats->num_dead_tuples),
- errdetail("%s.", pg_rusage_show(&ru0))));
+ errdetail_internal("%s", pg_rusage_show(&ru0))));
}
/*
@@ -1817,7 +1815,7 @@ lazy_truncate_heap(Relation onerel, LVRelStats *vacrelstats)
(errmsg("\"%s\": truncated %u to %u pages",
RelationGetRelationName(onerel),
old_rel_pages, new_rel_pages),
- errdetail("%s.",
+ errdetail_internal("%s",
pg_rusage_show(&ru0))));
old_rel_pages = new_rel_pages;
} while (new_rel_pages > vacrelstats->nonempty_pages &&
diff --git a/src/backend/utils/misc/pg_rusage.c b/src/backend/utils/misc/pg_rusage.c
index 8781a383c0..fa248ab081 100644
--- a/src/backend/utils/misc/pg_rusage.c
+++ b/src/backend/utils/misc/pg_rusage.c
@@ -61,7 +61,7 @@ pg_rusage_show(const PGRUsage *ru0)
}
snprintf(result, sizeof(result),
- "CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec",
+ _("CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec"),
(int) (ru1.ru.ru_stime.tv_sec - ru0->ru.ru_stime.tv_sec),
(int) (ru1.ru.ru_stime.tv_usec - ru0->ru.ru_stime.tv_usec) / 10000,
(int) (ru1.ru.ru_utime.tv_sec - ru0->ru.ru_utime.tv_sec),
--
2.11.0
0005-Make-new-message-identical-to-existing-ones.patchtext/plain; charset=us-asciiDownload
From 594efc25047ddae72cc285fb95b1689c11916a1b Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun, 21 May 2017 09:34:26 -0400
Subject: [PATCH 5/6] Make new message identical to existing ones
---
src/backend/access/brin/brin_pageops.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c
index 4878f8b776..987e6005cb 100644
--- a/src/backend/access/brin/brin_pageops.c
+++ b/src/backend/access/brin/brin_pageops.c
@@ -73,10 +73,8 @@ brin_doupdate(Relation idxrel, BlockNumber pagesPerRange,
{
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
- errmsg("index row size %lu exceeds maximum %lu for index \"%s\"",
- (unsigned long) newsz,
- (unsigned long) BrinMaxItemSize,
- RelationGetRelationName(idxrel))));
+ errmsg("index row size %zu exceeds maximum %zu for index \"%s\"",
+ newsz, BrinMaxItemSize, RelationGetRelationName(idxrel))));
return false; /* keep compiler quiet */
}
@@ -359,10 +357,8 @@ brin_doinsert(Relation idxrel, BlockNumber pagesPerRange,
{
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
- errmsg("index row size %lu exceeds maximum %lu for index \"%s\"",
- (unsigned long) itemsz,
- (unsigned long) BrinMaxItemSize,
- RelationGetRelationName(idxrel))));
+ errmsg("index row size %zu exceeds maximum %zu for index \"%s\"",
+ itemsz, BrinMaxItemSize, RelationGetRelationName(idxrel))));
return InvalidOffsetNumber; /* keep compiler quiet */
}
@@ -669,7 +665,7 @@ brin_getinsertbuffer(Relation irel, Buffer oldbuf, Size itemsz,
BlockNumber oldblk;
BlockNumber newblk;
Page page;
- int freespace;
+ Size freespace;
/* callers must have checked */
Assert(itemsz <= BrinMaxItemSize);
@@ -825,10 +821,8 @@ brin_getinsertbuffer(Relation irel, Buffer oldbuf, Size itemsz,
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
- errmsg("index row size %lu exceeds maximum %lu for index \"%s\"",
- (unsigned long) itemsz,
- (unsigned long) freespace,
- RelationGetRelationName(irel))));
+ errmsg("index row size %zu exceeds maximum %zu for index \"%s\"",
+ itemsz, freespace, RelationGetRelationName(irel))));
return InvalidBuffer; /* keep compiler quiet */
}
--
2.11.0
0006-Make-messages-consistent-with-others.patchtext/plain; charset=us-asciiDownload
From 1a5cf7144933169596741a0c0e1c6f5a22606cf8 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Sun, 21 May 2017 13:53:04 -0400
Subject: [PATCH 6/6] Make messages consistent with others
---
src/backend/catalog/namespace.c | 2 +-
src/backend/commands/variable.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
index 8fd4c3136b..8092381ae5 100644
--- a/src/backend/catalog/namespace.c
+++ b/src/backend/catalog/namespace.c
@@ -3685,7 +3685,7 @@ InitTempTableNamespace(void)
if (IsParallelWorker())
ereport(ERROR,
(errcode(ERRCODE_READ_ONLY_SQL_TRANSACTION),
- errmsg("cannot create temporary tables in parallel mode")));
+ errmsg("cannot create temporary tables during a parallel operation")));
snprintf(namespaceName, sizeof(namespaceName), "pg_temp_%d", MyBackendId);
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index defafa54b2..1f72d7bee9 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -776,7 +776,7 @@ assign_client_encoding(const char *newval, void *extra)
*/
ereport(ERROR,
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
- errmsg("cannot change client_encoding in a parallel worker")));
+ errmsg("cannot change client_encoding during a parallel operation")));
}
/* We do not expect an error if PrepareClientEncoding succeeded */
--
2.11.0
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 Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-translators mailing list (pgsql-translators@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-translators
On Tue, May 23, 2017 at 1:15 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> 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-translators mailing list (pgsql-translators@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-translators
Alvaro Herrera <alvherre@2ndquadrant.com> 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-translators mailing list (pgsql-translators@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-translators