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 1lypYc-0001Xa-Sx for pgadmin-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 05:48:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lypYb-000332-Kl for pgadmin-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 05:48:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lypYb-00032t-Du for pgadmin-hackers@lists.postgresql.org; Thu, 01 Jul 2021 05:48:13 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lypYX-0003dD-05 for pgadmin-hackers@postgresql.org; Thu, 01 Jul 2021 05:48:12 +0000 Received: by mail-lf1-x12f.google.com with SMTP id d16so9632493lfn.3 for ; Wed, 30 Jun 2021 22:48:08 -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=vMWW6g9L0Apmhh1+KG0DuoBqTq7pEFD/dHV0u+mrtCE=; b=KGUQUZETJMP/vx0X4aiUOf2PHK6MIwMAT2KUXQNtcn+Xl3Blwz1UETu65zZWeLjPiL pZq7s5p2vSrBosZFQAlfLmP/3o/Wr5w8+b3t7R+G/6LgfO2aCq7IVIriwHd+jEO+mfAS 3/QfoAhQFXRmVXcwNaEFJj8WolRSmzzBtuJIDgD6TJM38Xn9o4441TPaPL49xQ6W+M46 wzf0G/QfbHQt8j6XItMTiHjxiH02zwTTv9TRBtuQaEWIlTDFcQkg72nTnNWj+ij/vxyW Q0100tTcMQUIVLbWsoyeJstxmNkUpvaMZlk9uSnAMFvuSM0KZN+Rm0JGrkqld+cadq2r wf1w== 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=vMWW6g9L0Apmhh1+KG0DuoBqTq7pEFD/dHV0u+mrtCE=; b=mk0az+W8y2vzHNN2Wf59+89R3xCSlWfK5cS0FwPTs1EX1uLRERCw157mt4ZxSolKiV IQnKsfYA5OBwUHbimCHU8DvQIjnHxthXRqHYst/PUVivtpyowPsVGx8AARPWDvqticBY W6DjOofX/aV04VfV4qe5I+qO/T9ZXmkwcInuCJMZGLRmXrqry0sXEao6mfQH78iHP1gT I208TjVuL/xQflzU630o/FAJecpHt90LMzDJaOV1ZgC40YfRHGvyr2t+HB2X4hOBoESF o9pLfZ1cYYoDFqnyacTpbxWkj2DnZgcym9RlQIZbv0H2NReJQr6btQENZ0CGWY+GzhVF qAng== X-Gm-Message-State: AOAM532xyat1pgIuh+ycKAOqZwzpb8CQLqjo0i/NyS9YGkmh94lB97BJ PX6wk7b4ZU+CeHeQe8N1Gr+6OKFEZIIRQnF5tNK5P0QwghIq/7XK7WCTaxFWFi3NmFyWunCPQxO gjkbk2DSdSUhbrhkB/j6i3esjPhQjxnPRE32nOOtaAOu/a2Hda1eEXCmjWwTmsxrX5cfrIlvm+r A+QLMENo9ATF3BU82G+3xyVgJfJVqnPUjksaxySYzcIgtrtcLd1NVqmoWyNg== X-Google-Smtp-Source: ABdhPJxE+DwhuwATi09JqXvN6h7gHgExbA6bnaOmPthQAzPdFsaDG+muUzVX1FZrcf1AgKz07jtGopbGg9rqkIa3glA= X-Received: by 2002:a19:4355:: with SMTP id m21mr30236741lfj.618.1625118486993; Wed, 30 Jun 2021 22:48:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Khushboo Vashi Date: Thu, 1 Jul 2021 11:17:56 +0530 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Dave Page Cc: Rahul Shirsat , Aditya Toshniwal , pgadmin-hackers , Akshay Joshi Content-Type: multipart/alternative; boundary="00000000000022b69105c60962bf" 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 --00000000000022b69105c60962bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. > > +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 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? > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > --00000000000022b69105c60962bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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.

+1 for=C2=A0pybabel 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=C2=A0https://www.pgad= min.org/development/translations/ for current stats.

Thoughts?

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

ED= B: https://www.e= nterprisedb.com

--00000000000022b69105c60962bf--