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 1lyaDb-0002QB-Mc for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:25:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyaDZ-0002j9-Jn for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:25:29 +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 1lyaDZ-0002j1-9p for pgadmin-hackers@lists.postgresql.org; Wed, 30 Jun 2021 13:25:29 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lyaDV-0000Ju-Tz for pgadmin-hackers@postgresql.org; Wed, 30 Jun 2021 13:25:28 +0000 Received: by mail-ej1-x631.google.com with SMTP id bu12so4294035ejb.0 for ; Wed, 30 Jun 2021 06:25:25 -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=PEEDIEFupeOv52fgF+BR/EUDUDazpvoNMBNuUFSs9Ck=; b=gQJ9ARvPDrbxmPxgn2etNJqO0TumTUi6AGBk3f8z7gScvZXXHWgwTAfZ0P6NcNowKF YuNOKsA8W1MMDkwhb0fRZDf2PJrid+NajAqpAlAL04Kmdz4DP5kKbkKlzRsg1oAUZOvK RjSz+yyq6Cfdb08CU59qljNADtjPjNWal5Li4JXRLBUVUjxaIOWEZ3Si6vqkbXdRq9uz /0uT6mvsXqN3YdhWA9vEdBa7og8+DletBwF+ahlFdM2BWjLoSV7pmfuIzS2/YwTLG3cL q+e3AwdSCoOVWyfZr6dvHH9winFIhSJOe54qg85gCtA768zPxAaZ+mkk2Y0p2Jvc0e5e Io1w== 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=PEEDIEFupeOv52fgF+BR/EUDUDazpvoNMBNuUFSs9Ck=; b=XUwFvOpru/UsvOy8Z3MlvIdz+wvlqTIYhSGUrlYPkFYbWtW935TVYt3J9uHo0z+JKu +Hhc60BcxnWuc8vz3Bs6DLK9rtZU6Dz5h+yTys5WRT0WTameNoSZ7PLWK8z7LFoT2lsP xhHfKcSUH5qlNSF1xfz/uquPKgQUPYyVR4Woc0Vm3jCFPqmAEMMYBi8NcpRPSE09rcIn 0E8CkT/ELQH9a2SAyOn/BXXWgQGQLts/WCRwGKx4bZZW49JxEDTPBS4n5mGvKK/l/KZ/ 1AirjZXyPn6uooCTFK/Rrs/yIB9HTCkMOkjUzx4YQzRaQp+2K7ieWUZV7/c+/D0kdart rY5A== X-Gm-Message-State: AOAM530CbSwEQVduCMkTYevLbyp8PUueCNA0Z+0OPUgFGXLoUQ48xuw7 ObzadGRkkjHYrmxgGV/CpYkDVBIk48fQqmfOdC0TkMKSRagXNX7G X-Google-Smtp-Source: ABdhPJyVdHMxXgkjVf/ziBRrWfV03HoJtpZcmMjTC94hZPhl8EmU/epFpeq+tfzo2xPqZ3kX1aNRrwThnTQW6HhgUkM= X-Received: by 2002:a17:907:3e0b:: with SMTP id hp11mr35258715ejc.89.1625059524104; Wed, 30 Jun 2021 06:25:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 30 Jun 2021 14:25:12 +0100 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Rahul Shirsat Cc: Aditya Toshniwal , pgadmin-hackers , Akshay Joshi Content-Type: multipart/alternative; boundary="000000000000ac723b05c5fba762" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ac723b05c5fba762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 faili= ng > on Linux only? Why does the following from node.js (which follows the sam= e > 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 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 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. - 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? --=20 Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --000000000000ac723b05c5fba762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 fin= d 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 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 =3D gettext('%s Script',stype.toUpperCase());=

Rahul and I figure= d out the root cause. The issue is occuring because the previous string had= 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 t= ranslation, which at runtime would likely have caused a crash because the c= atalogs would have contained something like:

= #: pgadmin/browser/static/js/node.js:209
#, fuzzy, python-format<= /div>
msgid "Search %s Objects"
msgstr "Typy o= biekt=C3=B3w"

There are a few of ways a= round this:

- Manually fix the translations in eac= h catalog. This is not a good idea because we don't speak all those lan= guages 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/translations= && make msg-compile', then commit the results. This will remov= e all fuzzy matches from the catalogs, which means more work for the transl= ators on the next release, but will likely also result in them becoming muc= h cleaner.

- Change the code to use the conditiona= l fix.

I'm leaning towards the second option. = In the worst case, it'll lose about 58 fuzzy translations (meaning 58 m= essages to re-translate), but at least we'll know they are clean. See= =C2=A0https:/= /www.pgadmin.org/development/translations/ for current stats.

Thoughts?

--
<= /div>
--000000000000ac723b05c5fba762--