Thread

Commits

  1. Fix wording in amvalidate error messages

  1. translatable string fixes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-05-21T18:52:38Z

    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
    
  2. Re: [HACKERS] translatable string fixes

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-05-23T00:15:57Z

    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
    
    
    
  3. Re: [HACKERS] translatable string fixes

    Daniele Varrazzo <daniele.varrazzo@gmail.com> — 2017-05-24T13:26:42Z

    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
    
    
    
  4. Re: [HACKERS] translatable string fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-05-24T18:13:52Z

    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