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 1lyahy-0003MD-77 for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:56:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyahw-0007qX-Dy for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 13:56:52 +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 1lyahw-0007qO-4C for pgadmin-hackers@lists.postgresql.org; Wed, 30 Jun 2021 13:56:52 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lyaht-0000aQ-2m for pgadmin-hackers@postgresql.org; Wed, 30 Jun 2021 13:56:50 +0000 Received: by mail-ej1-x635.google.com with SMTP id bu12so4458401ejb.0 for ; Wed, 30 Jun 2021 06:56:48 -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=7x2tJ/soYJ4sbB7DPq3VmTLk+ErwTVmcbnyItekYeXE=; b=TrSxuTVMtSKB0qpyeJQSTUe3ZrXjwbHgcAn4YwzUJ0A9WJSW7TZGewdPgKBoF4vhH+ V3uFXhlpT+raAvIsZ5ttIO3wCToF8w8fX87wc73q8ueFwGpLil5l8QT4hTU9LhmAnfyB JfmvjSQf1rMuyYqWQRfuq5GAWh4d25X4fyrGfogD2BpoS6Bi2OxLOkDU6VdTisWgu3BD sywQO/ykOmGFXDlMnF3P3OJmuORc7ElT3MkWbEpkeqt1OMUWh47OTh3Be9Cgy4PAB4Nc 0VkU2cok8hYIjK4TK7c/ty/LMgfHxp2Mmqqniq25bEGpCuIHoRyHqX+GZ2bFy/mpxGpp 62ww== 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=7x2tJ/soYJ4sbB7DPq3VmTLk+ErwTVmcbnyItekYeXE=; b=GuyjSjpu6IiK4XXHNlDfTfBCPCwdZOrBFG6Q92Ls+gZ/JiWjIJtI75Eyw/atiUCSUV f2RciHjKFl4LSkfS36EAbTd3+CkQidaJFIh5frGrL3MWXgA+8bB9LHlS6L+b63uCPuRb raeN/UtX3VdptRbFItNp5jIU1Kl5zVlRpYrB0AfFTNHLrIpgrtm1Tc6u0pNgYLZnA+1K WeiQcYX0BvK/p2OVmnS87fYBND5hcJefuHULijybApOKUdIcgbTBxBAz7JNrecWaDUtx FWuHvNyWTYHqMPIeRb+aaZnPU/aAPmWOEvwXd5icBtazJoTeDImpjW7CiAfyQ5Fn/Jmu QLfg== X-Gm-Message-State: AOAM531hMnyeO/7vDm1bW1ex7OLbn5Q4vzqp0iE1veR5Q9OLnSBwQdlb +2KcSQ3euOgCjAxGByaS1+3ny2Xi/rKhVQEY5Sc8fg== X-Google-Smtp-Source: ABdhPJy83+GQ4V5AU7T+Z2e8QJC/ke8gUN/PCzK1qId/zth5TbEkS+0ChEDqZwBPG86yzrfA6AlMtKYRsJVEos+KlI8= X-Received: by 2002:a17:907:3e0b:: with SMTP id hp11mr35408485ejc.89.1625061406524; Wed, 30 Jun 2021 06:56:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 30 Jun 2021 14:56:35 +0100 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Aditya Toshniwal Cc: Rahul Shirsat , pgadmin-hackers , Akshay Joshi Content-Type: multipart/alternative; boundary="000000000000dfdf7d05c5fc176e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000dfdf7d05c5fc176e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 30, 2021 at 2:42 PM Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > 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 fai= ling >>> 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 is occuring because th= e >> 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 wi= th >> 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/translati= ons >> && make msg-compile', then commit the results. This will remove all fuzz= y >> 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 a= t >> 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, th= e > right way is the second option. > Shouldn't we add the no fuzzy flag in the makefile ? This problem can > occur again. > Maybe :-). That's the point of this email - to gather such opinions. --=20 Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --000000000000dfdf7d05c5fc176e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 30, 2021 at 2:42 PM Adity= a Toshniwal <aditya= .toshniwal@enterprisedb.com> wrote:
H= i,

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 Pag= e <dpage@pgadmin.= org> wrote:
Hi

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

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

W= ell 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(= 9;%s Script',stype.toUpperCase());
=

Rahul and I figured out the root cause. The issue is oc= curing 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 c= atalogs it was matching with the old translation, which at runtime would li= kely have caused a crash because the catalogs would have contained somethin= g like:

#: pgadmin/browser/static/js/node.js:= 209
#, fuzzy, python-format
msgid "Search %s Objec= ts"
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 be= cause we don't speak all those languages and will probably mess the tra= nslations up.

- Run something like 'make msg-e= xtract && pybabel update --no-fuzzy-matching=C2=A0-i web/pgadmin/me= ssages.pot -d web/pgadmin/translations && make msg-compile', th= en 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 l= ikely 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 abo= ut 58 fuzzy translations (meaning 58 messages to re-translate), but at leas= t we'll know they are clean. See=C2=A0https://www.pgadmin.org/deve= lopment/translations/ for current stats.

Thoug= hts?
Right. I'm = in favor of removing the incorrect translations. For which, the right way i= s the second option.
Shouldn't we add the no fuzzy flag = in the makefile ? This problem can occur again.

Maybe :-). That's the point of this email= - to gather such opinions.=C2=A0

--
--000000000000dfdf7d05c5fc176e--