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 1m0Jxa-0001NV-D4 for pgadmin-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 08:28:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0JxZ-0006ad-26 for pgadmin-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 08:28:09 +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 1m0JxY-0006aV-KN for pgadmin-hackers@lists.postgresql.org; Mon, 05 Jul 2021 08:28:08 +0000 Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m0JxQ-0003LY-UJ for pgadmin-hackers@postgresql.org; Mon, 05 Jul 2021 08:28:06 +0000 Received: by mail-io1-xd2e.google.com with SMTP id h6so3034788iok.6 for ; Mon, 05 Jul 2021 01:28:00 -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=FU+PRL6SBtOWUPhktDh/QIO0B1GTzd0LEEheMBOpmBI=; b=w7xmqaUIwpQ2HdUC8KeqVg4paQ1HfgY2XKx3igessRv4wKDvIPgL29nePEQsaHmWfp QtZ2dgVYr3H527AG/bG847DDjlfqPmkcQGUtB4Op4VbNkhRrfQ2HzTQ8+aQbdkjBYo6o X9u/3gLGIPSq3c59P+KIKDFhxjvK+K9a6F4wyF+pQMRM4YfnE4aVlXmlD64H5KzNnqjh oYc0HzHXGsPxMlU2HNcjIx+fkDP8jvq3PizNv5vG2X42KuvqZnyAkIFpC6S1b52BCbfz C4GLL0igousgxO9r9rwtAHzvgMfdacYKuUK3xi3rxt+KGxdjLn1Dh1+lE4Qfu4DHwN2J nqcA== 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=FU+PRL6SBtOWUPhktDh/QIO0B1GTzd0LEEheMBOpmBI=; b=GO1rWmL0hoi65RnyzkB9/n7QzxdGeX0SaY+hUxwyqRwBu7mwBlHQ9OD9ydNcT98gWd 9YTJoNDJsh6i6gNHUmfhYhDTzzcf9+wiT9Uy6s/gE24pQQpeJbdAuYJbM1EmQhR1Mwa2 KVIY3DhJZMJ+onbI6/AwCo/5/tAB4VG7RoqpG1YIDPz6yODZfWx1tYwGVVXDuv+zWf9n i6nWohv79Z0BrZ9su66bJ7T02YUBFlDdnKK6Pi5fZyka13dQ1CC9ywZK3FQ5BlphmXps YV5YfynGTUHgn0xJ7iteSXONBYeNLe5RgHW9vCuUU6GYc027aq8HUQQo128MtYCZhnTG jR9w== X-Gm-Message-State: AOAM533e1oKED5UquMbgkRvh3icMhg2p/aqob/qv/w0Pvj/iTjZgshoJ OE0PPQgVc1DB3L8QLEZsZiRoNWTeO8hFlkCyHxu49PnQO4ASGo1RMJkz1cLmwJYj3Px3yFK984t pkidzZciSSHIG+TCvkLl3I98EQ9805QuBf5i1UR5xJKzOF9c/hh6mV+VF1uWNQ168hrhwi8V5gR BaIA/ajCWLnYXnkWbQdEFvNoupJTOMRg7pF5luKAAptas03Ng6Ujl9lkUrot5F0NClHA== X-Google-Smtp-Source: ABdhPJyJE6wO/MT7/Xlc2nEw/NMjw3MwhXZCY6gFQ34bX6S4r1KzJeFiG8FwyJSA6vRy0btwHVYETK1SvcYYr0XeQaE= X-Received: by 2002:a05:6638:348c:: with SMTP id t12mr6842383jal.1.1625473361527; Mon, 05 Jul 2021 01:22:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akshay Joshi Date: Mon, 5 Jul 2021 13:52:30 +0530 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Dave Page Cc: Rahul Shirsat , Khushboo Vashi , Aditya Toshniwal , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000004e616e05c65c024d" 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 --0000000000004e616e05c65c024d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Mon, Jul 5, 2021 at 1:40 PM Dave Page wrote: > > > On Fri, Jul 2, 2021 at 8:41 PM Rahul Shirsat < > rahul.shirsat@enterprisedb.com> wrote: > >> +1 for --no-fuzzy-matching for updating translations. >> >> On Thu, Jul 1, 2021 at 11:18 AM Khushboo Vashi < >> khushboo.vashi@enterprisedb.com> wrote: >> >>> >>> >>> 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 f= ailing >>>>> 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 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 w= as >>>> matching with the old translation, which at runtime would likely have >>>> caused a crash because the catalogs would have contained something lik= e: >>>> >>>> #: 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/transla= tions >>>> && make msg-compile', then commit the results. This will remove all fu= zzy >>>> matches from the catalogs, which means more work for the translators o= n the >>>> next release, but will likely also result in them becoming much cleane= r. >>>> >>>> +1 for pybabel update with -N option >>> >>> > Akshay? > Yes, I'll also go with the second option "--no-fuzzy-matching". > > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > --=20 *Thanks & Regards* *Akshay Joshi* *pgAdmin Hacker | Principal Software Architect* *EDB Postgres * *Mobile: +91 976-788-8246* --0000000000004e616e05c65c024d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

On Mon, Jul 5, 2021 at 1:40 PM Da= ve Page <dpage@pgadmin.org> = wrote:


On Fri, Jul 2, 2021 at 8:41 PM Rahul Shirsat = <rah= ul.shirsat@enterprisedb.com> wrote:
+1 for --no-fuzzy-matching for = updating translations.

On Thu, Jul 1, 2021 at 11:18 AM Khushboo Vashi &l= t;khus= hboo.vashi@enterprisedb.com> wrote:


=
On Wed, Ju= n 30, 2021 at 6:55 PM Dave Page <dpage@pgadmin.org> wrote:
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:
<= div>Hi All,

Please find the attached patch for resolvin= g=C2=A0this issue wrt above suggestion.

Well that may fix the problem (and is a reasonable change), however, I t= hink 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 s= ame pattern) work fine?

var type_label =3D gettext= ('%s Script',stype.toUpperCase());

Rahul and I figured out the root cause. The issue i= s occuring because the previous string had no parameters=C2=A0(i.e. no %s&#= 39;s). Because fuzzy matching is used for the translations, when updating t= he catalogs it was matching with the old translation, which at runtime woul= d likely have caused a crash because the catalogs would have contained some= thing like:

#: pgadmin/browser/static/js/node= .js:209
#, fuzzy, python-format
msgid "Search %s O= bjects"
msgstr "Typy obiekt=C3=B3w"

There are a few of ways around this:

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

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

+1 for=C2=A0pybabel upd= ate with -N option


Akshay?=C2=A0

=C2=A0 =C2=A0 Yes, I'll also go with the second option= =C2=A0 "--no-fuzzy-matching".


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

EDB: https://www.enterprisedb.com



--
Thanks & Regards
Akshay Joshi
pgAdmi= n Hacker | Principal Software Architect
EDB Postgres
Mobile: +91 976-788-8246

--0000000000004e616e05c65c024d--