On Sun, 12 Apr 2026 at 06:42, Tom Lane <[email protected]> wrote: > > David Rowley <[email protected]> writes: > > append_tuple_value_detail() contains some pretty weird translation > > strings. The code currently does: > > > /* translator: This is the terminator of a conflict message */ > > appendStringInfoString(buf, _(".")); > > > I'm not a translator, but isn't that going to be pretty hard to know > > what to do with, given that the same string could be used for anything > > else in the code and need something completely different done? That > > same function also contains a _(": ") and _(", ") which seem equally > > hard to deal with. > > Yeah, this seems to me to fly in the face of our style guide's > rule about "don't construct messages out of parts". And the > reason for the rule is precisely that stuff like this poses > insoluble problems for translators. > > I think it'd be reasonable to make this helper function build > a string like > (value, value, value) > with the punctuation being untranslated on the grounds that this > is standard SQL notation. Then that could be plugged into a > translatable message that might hopefully represent a full sentence > with a %s for the tuple data.
I've updated the code to avoid constructing messages from translated fragments. append_tuple_value_detail() now only builds a SQL-style tuple string like (v1, v2, v3) without any translation or punctuation. All punctuation and sentence construction are moved to the callers, which now use a single translatable string with a %s placeholder for the tuple data. Attached patch has the changes for the same. Regards, Vignesh
0001-replication-fix-translation-issues-in-tuple-value-de.patch
Description: Binary data
