Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Rahul Shirsat <rahul(dot)shirsat(at)enterprisedb(dot)com>
Cc: Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure
Date: 2021-06-30 13:25:12
Message-ID: CA+OCxoyWueM+uo3z1xMnCVD3rw59wrWBPaRLqT8A15ezNxGV8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi

On Wed, Jun 30, 2021 at 9:22 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Wed, Jun 30, 2021 at 8:28 AM Rahul Shirsat <
> rahul(dot)shirsat(at)enterprisedb(dot)com> wrote:
>
>> Hi All,
>>
>> Please find the attached patch for resolving this issue wrt above
>> suggestion.
>>
>
> Well that may fix the problem (and is a reasonable change), however, I
> think it's important that we understand the root cause. Why is this failing
> on Linux only? Why does the following from node.js (which follows the same
> pattern) work fine?
>
> var type_label = gettext('%s Script',stype.toUpperCase());
>

Rahul and I figured out the root cause. The issue is occuring because the
previous string had no parameters (i.e. no %s's). Because fuzzy matching is
used for the translations, when updating the catalogs it was matching with
the old translation, which at runtime would likely have caused a crash
because the catalogs would have contained something like:

#: pgadmin/browser/static/js/node.js:209
#, fuzzy, python-format
msgid "Search %s Objects"
msgstr "Typy obiektów"

There are a few of ways around this:

- Manually fix the translations in each catalog. This is not a good idea
because we don't speak all those languages and will probably mess the
translations up.

- Run something like 'make msg-extract && pybabel update
--no-fuzzy-matching -i web/pgadmin/messages.pot -d web/pgadmin/translations
&& make msg-compile', then commit the results. This will remove all fuzzy
matches from the catalogs, which means more work for the translators on the
next release, but will likely also result in them becoming much cleaner.

- Change the code to use the conditional fix.

I'm leaning towards the second option. In the worst case, it'll lose about
58 fuzzy translations (meaning 58 messages to re-translate), but at least
we'll know they are clean. See
https://www.pgadmin.org/development/translations/ for current stats.

Thoughts?

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Aditya Toshniwal 2021-06-30 13:42:02 Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure
Previous Message Dave Page 2021-06-30 12:11:17 Re: RM 6427 - Newlines in text columns of resultset show an allegedly "empty" field