NLS handling fixes.

On Fri, Aug 10, 2018 at 03:21:31PM +0900, Kyotaro HORIGUCHI wrote:

The cause is GetConfigOptionByNum is forgetting to retrieve
translations for texts that have been marked with gettext_noop.

Regarding GUCs, group names, short desc and long desc have
translations so the attached first patch (fix_GUC_nls.patch) let
the translations appear.

Besides GUCs, I found another misuse of gettext_noop in
pg_GSS_recvauth. (2nd fix_GSSerr_nls.patch)

view_query_is_auto_updatable() and most of its caller are making
the same mistake in a similar way. All caller sites require only
translated message but bringing translated message around doesn't
seem good so the attached third patch adds _() to all required
places. (3rd fix_view_updt_nls.patch, 5th fix_vacuumdb_nls.patch)

I have been looking at all the things you are proposing here, and it
seems to me that you are right for these. I lack a bit of knowledge
about the translation of items, but can such things be back-patched?

psql is making a bit different mistake. \gdesc seems intending
the output columns names in NLS string but they actually
aren't. DescribeQuery is using PrintQueryResults but it is
intended to be used only for SendQuery. Replacing it with
printQuery let \gdesc print NLS string but I'm not sure it is the
right thing to fix this. (4th, fix psql_nls.patch)

This one I am not sure though...
--
Michael

On 2018-Aug-10, Michael Paquier wrote:

On Fri, Aug 10, 2018 at 03:21:31PM +0900, Kyotaro HORIGUCHI wrote:

The cause is GetConfigOptionByNum is forgetting to retrieve
translations for texts that have been marked with gettext_noop.

Regarding GUCs, group names, short desc and long desc have
translations so the attached first patch (fix_GUC_nls.patch) let
the translations appear.

Besides GUCs, I found another misuse of gettext_noop in
pg_GSS_recvauth. (2nd fix_GSSerr_nls.patch)

view_query_is_auto_updatable() and most of its caller are making
the same mistake in a similar way. All caller sites require only
translated message but bringing translated message around doesn't
seem good so the attached third patch adds _() to all required
places. (3rd fix_view_updt_nls.patch, 5th fix_vacuumdb_nls.patch)

I have been looking at all the things you are proposing here, and it
seems to me that you are right for these. I lack a bit of knowledge
about the translation of items, but can such things be back-patched?

Well, if I understood correctly, the translations would have the
messages already translated -- the problem is that they are not used at
runtime. So, yes, this should be backpatched.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Michael Paquier <michael@paquier.xyz> writes:

I have been looking at all the things you are proposing here, and it
seems to me that you are right for these. I lack a bit of knowledge
about the translation of items, but can such things be back-patched?

I would certainly *not* back-patch the GetConfigOptionByNum change,
as that will be a user-visible behavioral change that people will
not be expecting. We might get away with back-patching the other changes,
but SHOW ALL output seems like something that people might be expecting
not to change drastically in a minor release.

Some general review notes:

* I believe our usual convention is to write _() not gettext().
This patch set is pretty schizophrenic about that.

* In the patch fixing view_query_is_auto_updatable misuse, nothing's
been done to remove the underlying cause of the errors, which IMO
is that the header comment for view_query_is_auto_updatable fails to
specify the return convention. I'd consider adding a comment along
the lines of

 * view_query_is_auto_updatable - test whether the specified view definition
 * represents an auto-updatable view. Returns NULL (if the view can be updated)
 * or a message string giving the reason that it cannot be.
+*
+* The returned string has not been translated; if it is shown as an error
+* message, the caller should apply _() to translate it.
 *

* Perhaps pg_GSS_error likewise could use a comment saying the error
string must be translated already. Or we could leave its callers alone
and put the _() into it, but either way the API contract ought to be
written down.

* The proposed patch for psql/common.c seems completely wrong, or at
least it has a lot of side-effects other than enabling header translation,
and I doubt they are desirable.

regards, tom lane

On Fri, Aug 10, 2018 at 04:50:55PM -0400, Tom Lane wrote:

I would certainly *not* back-patch the GetConfigOptionByNum change,
as that will be a user-visible behavioral change that people will
not be expecting. We might get away with back-patching the other changes,
but SHOW ALL output seems like something that people might be expecting
not to change drastically in a minor release.

Agreed, some folks may rely on that.

* In the patch fixing view_query_is_auto_updatable misuse, nothing's
been done to remove the underlying cause of the errors, which IMO
is that the header comment for view_query_is_auto_updatable fails to
specify the return convention. I'd consider adding a comment along
the lines of

* view_query_is_auto_updatable - test whether the specified view definition
* represents an auto-updatable view. Returns NULL (if the view can be updated)
* or a message string giving the reason that it cannot be.
+*
+* The returned string has not been translated; if it is shown as an error
+* message, the caller should apply _() to translate it.

That sounds right. A similar comment should be added for
view_cols_are_auto_updatable and view_col_is_auto_updatable.

* Perhaps pg_GSS_error likewise could use a comment saying the error
string must be translated already. Or we could leave its callers alone
and put the _() into it, but either way the API contract ought to be
written down.

Both things are indeed possible. As pg_SSPI_error applies translation
beforehand, I have taken the approach to let the caller just apply _().
For two messages that does not matter much one way or another.

* The proposed patch for psql/common.c seems completely wrong, or at
least it has a lot of side-effects other than enabling header translation,
and I doubt they are desirable.

I doubted about it, and at closer look I think that you are right, so +1
for discarding this one.

Attached is a patch which should address all the issues reported and all
the remarks done. What do you think?
--
Michael

At Mon, 20 Aug 2018 13:23:38 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180820042338.GH7403@paquier.xyz>

On Fri, Aug 10, 2018 at 04:50:55PM -0400, Tom Lane wrote:

I would certainly *not* back-patch the GetConfigOptionByNum change,
as that will be a user-visible behavioral change that people will
not be expecting. We might get away with back-patching the other changes,
but SHOW ALL output seems like something that people might be expecting
not to change drastically in a minor release.

Agreed, some folks may rely on that.

* In the patch fixing view_query_is_auto_updatable misuse, nothing's
been done to remove the underlying cause of the errors, which IMO
is that the header comment for view_query_is_auto_updatable fails to
specify the return convention. I'd consider adding a comment along
the lines of

* view_query_is_auto_updatable - test whether the specified view definition
* represents an auto-updatable view. Returns NULL (if the view can be updated)
* or a message string giving the reason that it cannot be.
+*
+* The returned string has not been translated; if it is shown as an error
+* message, the caller should apply _() to translate it.

That sounds right. A similar comment should be added for
view_cols_are_auto_updatable and view_col_is_auto_updatable.

* Perhaps pg_GSS_error likewise could use a comment saying the error
string must be translated already. Or we could leave its callers alone
and put the _() into it, but either way the API contract ought to be
written down.

Both things are indeed possible. As pg_SSPI_error applies translation
beforehand, I have taken the approach to let the caller just apply _().
For two messages that does not matter much one way or another.

* The proposed patch for psql/common.c seems completely wrong, or at
least it has a lot of side-effects other than enabling header translation,
and I doubt they are desirable.

I doubted about it, and at closer look I think that you are right, so +1
for discarding this one.

Attached is a patch which should address all the issues reported and all
the remarks done. What do you think?

Agreed on all of the above, but if we don't need translation in
the header line of \gdesc, gettext_noop for the strings is
useless.

A period is missing in the comment for
view_col_is_auto_updatable.

The attached is the fixed version.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Tue, Aug 21, 2018 at 11:49:05AM +0900, Kyotaro HORIGUCHI wrote:

Agreed on all of the above, but if we don't need translation in
the header line of \gdesc, gettext_noop for the strings is
useless.

I have let that one alone, as all columns showing up in psql have the
same, consistent way of handling things.

A period is missing in the comment for view_col_is_auto_updatable.

Fixed this one, and pushed. All things are back-patched where they
apply, except for the part of GetConfigOptionByNum getting only on HEAD
as it could be surprising after a minor upgrade as Tom has suggested.
--
Michael