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

From: Rahul Shirsat <rahul(dot)shirsat(at)enterprisedb(dot)com>
To: Khushboo Vashi <khushboo(dot)vashi(at)enterprisedb(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, 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-07-02 19:40:57
Message-ID: CAKtn9dOuKoL+ynwULN_8KLtaF+cXPypMUtBcC6Umoi-p+TE=Cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

+1 for --no-fuzzy-matching for updating translations.

On Thu, Jul 1, 2021 at 11:18 AM Khushboo Vashi <
khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:

>
>
> On Wed, Jun 30, 2021 at 6:55 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> 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.
>>
>> +1 for pybabel update with -N option
>
>> - 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
>>
>>

--
*Rahul Shirsat*
Senior Software Engineer | EnterpriseDB Corporation.

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Akshay Joshi 2021-07-05 06:18:21 Re: [pgAdmin][RM-6569]: [Housekeeping][React] Port catalog objects to react
Previous Message Rahul Shirsat 2021-07-02 19:38:15 [patch][pgAdmin] RM6550 5.4 running on kubernetes fails to log in even with the right environment variables defined