Horton

Thread

Commits

  1. Fix set of NLS translation issues

  1. NLS handling fixes.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-08-10T06:21:31Z

    Hello. I found that backend's .po file has lines for GUC
descriptions but we won't see them anywhere.

The cause is GetConfigOptionByNum is fogetting 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)

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)


plperl/plpgsql/tcl have another kind of problem in NLS. It
installs some GUC parameters and their descriptions actually have
a translation but in *its own* po file. So GetConfigOptionByNum
cannot get them. I don't have an idea to fix this for now.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  2. Re: NLS handling fixes.

    Michael Paquier <michael@paquier.xyz> — 2018-08-10T17:15:08Z

    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

  3. Re: NLS handling fixes.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-08-10T17:30:51Z

    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

  4. Re: NLS handling fixes.

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-08-10T20:50:55Z

    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

  5. Re: NLS handling fixes.

    Michael Paquier <michael@paquier.xyz> — 2018-08-20T04:23:38Z

    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

  6. Re: NLS handling fixes.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-08-21T02:49:05Z

    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

  7. Re: NLS handling fixes.

    Michael Paquier <michael@paquier.xyz> — 2018-08-21T06:22:50Z

    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