Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyaUG-00030h-KI for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:42:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyaUF-0000vY-CS for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:42:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyaUE-0000vL-Uq for pgadmin-hackers@lists.postgresql.org; Wed, 30 Jun 2021 13:42:43 +0000 Received: from mail-ua1-x934.google.com ([2607:f8b0:4864:20::934]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lyaUB-0000Si-I9 for pgadmin-hackers@postgresql.org; Wed, 30 Jun 2021 13:42:41 +0000 Received: by mail-ua1-x934.google.com with SMTP id c20so1025789uar.12 for ; Wed, 30 Jun 2021 06:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SKIAZMDr6ChKO3wZdESb1v0/NfQu4oHaOh6vJsjb+no=; b=t0Z0BtE7bYdnL7A1mu4Sk8fLW9jecM22qOt0L2IkbrYA2xmC71Wahhu1b7CMJMIHUP 2Ne4+LwObk0/RSIm5IIaqgC0wZLbjk381u0fcVW6kWJJbNEwu6n2Ey8tHObTgb+C//mT wNao5rHPA+NXRQ3JyZxOGqgKPg5cSPKrfJ/z6DpSIIEF3ULSLT9gGOCdU8bFV1u9c3Jj tEmGmIla//NDKtNAGUEUUrQ2pm/6bzMov1nIdJj2nPqIDDY/CTzNhpZAMi2QOLVp2PJq hUd2W2MP2z70l9Zm6WCw7eevTX0mLAvv/7ezZHcI3cmnsaM9IjkpxDYLpWQgbbpdpGUi XW0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SKIAZMDr6ChKO3wZdESb1v0/NfQu4oHaOh6vJsjb+no=; b=ecmMQPkEEzgWiEbgJ305vF9KqR3LhE01JM235JpDk8KOshC1Hd9SVGxP7NFwUbvCQq PBDZp4ezFD5YxOyiL6RLqPoZgwPZaZ0MTMQfK3/qCPKldje9jgjsNN3NKG80HJl2s+ME xCWZfGlSDakNfEgdFJmlcp+OMVe0WNM+y/vh8pvPkOLUdOjQkmMvCtvzy+ArVSrJINXF tFaGCQ6g3tZLfY2qTCuzso87l4cTMnJ54C9onpPyvuSwV6wSrLcCmqUpf/J4vKCm671M rxNewMOEZfyx7LfWgqZkiGM7K+Wp5ThuKp7UCGV0RseV2zrWQ8uCVRrL8PyYdYMV51eo aNQA== X-Gm-Message-State: AOAM533mv0cKwrR98YPzhGkj4k9ps2cVBUon6j48yS3CjSnq1u1hzLYt xkTxFZ+7NYyuRKxcCeXbZu59j6JGgz1A7ZgMmoGtJs18+56eXappvyTgod49PiBab+7piqamWhl gOzGvtmS6uictVTdhUiKeoPRVEVEwOPcWzYTcmdF5BR/m+iU1QZ7/lepc8nzoEEDIihQmw1bk93 yGHP6Nf/LTovqwwAZeNpJeqRukZNx0A/NvLHRKa5tLJ7PgqShFP1cM3iF+W0o0sl8= X-Google-Smtp-Source: ABdhPJyW1WJfcrIpOGgGdiPqeAQgdmEoRLPUEmQVPEtXUieu3f7TGA51mAN0GlezRx9HwQVsl7bvv/i3GcVK938lxA4= X-Received: by 2002:ab0:6392:: with SMTP id y18mr33332059uao.139.1625060558365; Wed, 30 Jun 2021 06:42:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Wed, 30 Jun 2021 19:12:02 +0530 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Dave Page Cc: Rahul Shirsat , pgadmin-hackers , Akshay Joshi Content-Type: multipart/alternative; boundary="00000000000051fbe605c5fbe58d" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000051fbe605c5fbe58d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 30, 2021 at 6:55 PM Dave Page wrote: > Hi > > On Wed, Jun 30, 2021 at 9:22 AM Dave Page wrote: > >> Hi >> >> On Wed, Jun 30, 2021 at 8:28 AM Rahul Shirsat < >> rahul.shirsat@enterprisedb.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 fail= ing >> on Linux only? Why does the following from node.js (which follows the sa= me >> pattern) work fine? >> >> var type_label =3D 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 wit= h > 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=C3=B3w" > > 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/translatio= ns > && make msg-compile', then commit the results. This will remove all fuzzy > matches from the catalogs, which means more work for the translators on t= he > 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 abou= t > 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? > Right. I'm in favor of removing the incorrect translations. For which, the right way is the second option. Shouldn't we add the no fuzzy flag in the makefile ? This problem can occur again. > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > --=20 Thanks, Aditya Toshniwal pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com* "Don't Complain about Heat, Plant a TREE" --00000000000051fbe605c5fbe58d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=
On Wed, Jun 30, 2021 at 6:55 PM Dave = Page <dpage@pgadmin.org> wro= te:
Hi

On Wed, Jun 30, 2021 at 9:22 AM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Wed, Jun 30, 2021 at 8:28 AM Rahul Shirsat <rahul.shirsat@= enterprisedb.com> wrote:
Hi All,

Please fi= nd the attached patch for resolving=C2=A0this issue wrt above suggestion.

Well that may fix the problem (and is = a reasonable change), however, I think it's important that we understan= d 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 =3D gettext('%s Script',stype.toUpperCase())= ;

Rahul and I figur= ed out the root cause. The issue is occuring because the previous string ha= d no parameters=C2=A0(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=C3=B3w"

There are a few of ways = around this:

- Manually fix the translations in ea= ch catalog. This is not a good idea because we don't speak all those la= nguages and will probably mess the translations up.

- Run something like 'make msg-extract && pybabel update --no= -fuzzy-matching=C2=A0-i web/pgadmin/messages.pot -d web/pgadmin/translation= s && make msg-compile', then commit the results. This will remo= ve all fuzzy matches from the catalogs, which means more work for the trans= lators on the next release, but will likely also result in them becoming mu= ch cleaner.

- Change the code to use the condition= al 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= =C2=A0https://www.pgadmin.org/development/translations/ for curre= nt stats.

Thoughts?
<= /div>
Right. I'm in favor of removing the incorrect = translations. For which, the right way is the second option.
S= houldn't we add the no fuzzy flag in the makefile ? This problem can oc= cur again.

--
Dave Page<= br>Blog: https:/= /pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com=



--
Thanks,
Aditya Toshniwal
pgAdmin hacker=C2=A0| Sr. Softwa= re Engineer | edbpostgres.com<= /font>
"Don't Complain about Heat, Plant a TREE&qu= ot;
--00000000000051fbe605c5fbe58d--