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 1m0Jh8-0000oy-Nu for pgadmin-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 08:11:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0Jh6-00038C-PP for pgadmin-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 08:11:08 +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 1m0Jh5-000384-5o for pgadmin-hackers@lists.postgresql.org; Mon, 05 Jul 2021 08:11:08 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m0Jgy-0003F4-7O for pgadmin-hackers@postgresql.org; Mon, 05 Jul 2021 08:11:05 +0000 Received: by mail-ed1-x533.google.com with SMTP id k17so4874005edq.2 for ; Mon, 05 Jul 2021 01:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rxddwkVF0rZOp0pJsmUJ5T1y3xLp/tl4jhtC4w/6CS0=; b=QRcbn6uzla/RtbU1F3htmK8HXSIBFr29HxGxXjdEztBhMSHYxNcmDVoF4apdRTAU7H xBX2OJOclQZAJ92peGQw3EHHXG4HhT7pgHBbfU3TyfGMJKiPpoq36wGdPB8GUCmnNoVq Z66G4qoAZJneG1E0CgpgCx8SXQQ0paDLrBlmq6GIwZ99J9gHgpGkxVQyipzL6skDjOWz jaYt1B8bRatmkH0THc4vd8EVeN7N1NasZP3krPY/fN9Xs+Psb1T+RU5/wuZdWkfPUXvV xscJGuQx9H0PQe26YZU68T/LASOpdxMxFqIMwyeBRPspixYFRtUKCGI9Xb4CdYAe4zkk UngA== 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=rxddwkVF0rZOp0pJsmUJ5T1y3xLp/tl4jhtC4w/6CS0=; b=MJdPF/NaUGDKNChb/H96nlxNGYPhKBpZyB1BNKeNqRt1W/zLCEahgfsUhkOuvV6Hy8 stMT/SDLJ6TBYTjKETJBLAOcytZxtuZQ11TzP75KE5wWU5ThJRmqcx9E9V9O1koz0Ib2 ePKsKqeclmY4Ox7ogtOOP0X0Tr5iPFFFGGWXsmTI1eyPdRaftTjLWuYRpCD8+BFykhNQ 3mQIKtteKZkJvGZXMWit41tXYtjssThCa/6h/OKr/oPQwG6ragRdt1PCjDpE8wWgnJlV nD3bskmd5cYSY/2ArjJ+t3yzgtr6rq/x+L1C/2NB7aAlrrj19cQFiEB758vuMopJ10t0 0hOQ== X-Gm-Message-State: AOAM532vkKQDsviYv5Rsecqd2hYwbZ7j2IJYf7+5QaDI8Z/zC3f6AgmF +oaFJr9gDgxXZ87LyPC5eCk6w9MRs83EdRfS7irR9w== X-Google-Smtp-Source: ABdhPJx0KdbKOtawrOJXmjdAlnLkRCS0UJ6dKgWULJVnC3vf9pqUn2XZqAxxQbdHNIImeAcmXh0naq6iaXHdyaot7MU= X-Received: by 2002:a05:6402:848:: with SMTP id b8mr14715511edz.44.1625472657564; Mon, 05 Jul 2021 01:10:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Mon, 5 Jul 2021 09:10:46 +0100 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Rahul Shirsat Cc: Khushboo Vashi , Aditya Toshniwal , pgadmin-hackers , Akshay Joshi Content-Type: multipart/alternative; boundary="00000000000058bbb105c65bd840" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000058bbb105c65bd840 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 2, 2021 at 8:41 PM Rahul Shirsat 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 fa= iling >>>> 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 wa= s >>> 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 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 msg-extract && pybabel update >>> --no-fuzzy-matching -i web/pgadmin/messages.pot -d web/pgadmin/translat= ions >>> && make msg-compile', then commit the results. This will remove all fuz= zy >>> 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 >> >> Akshay? --=20 Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --00000000000058bbb105c65bd840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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, 20= 21 at 11:18 AM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:<= br>


<= div class=3D"gmail_quote">
On Wed, Jun= 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
<= br>
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=C2=A0this issue wrt ab= ove 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 d= oes the following from node.js (which follows the same pattern) work fine?<= /div>

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

= Rahul and I figured out the root cause. The issue is occuring because the p= revious string had no parameters=C2=A0(i.e. no %s's). Because fuzzy mat= ching is used for the translations, when updating the catalogs it was match= ing with the old translation, which at runtime would likely have caused a c= rash because the catalogs would have contained something like:
#: pgadmin/browser/static/js/node.js:209
#, fuz= zy, python-format
msgid "Search %s Objects"
m= sgstr "Typy obiekt=C3=B3w"

There a= re a few of ways around this:

- Manually fix the t= ranslations in each catalog. This is not a good idea because we don't s= peak all those languages and will probably mess the translations up.
<= div>
- Run something like 'make msg-extract && py= babel update --no-fuzzy-matching=C2=A0-i web/pgadmin/messages.pot -d web/pg= admin/translations && make msg-compile', then commit the result= s. This will remove all fuzzy matches from the catalogs, which means more w= ork for the translators on the next release, but will likely also result in= them becoming much cleaner.

+1 for=C2=A0pybabel update with -N option
=


<= div>Akshay?=C2=A0


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

EDB: https://www.enterprisedb.com

--00000000000058bbb105c65bd840--