Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure

Поиск
Список
Период
Сортировка
От Khushboo Vashi
Тема Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure
Дата
Msg-id CAFOhELcNZXUOKfTOtbpdudMGi1Nyx+jNjD16YjQ=-5KgypMWAg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure  (Dave Page <dpage@pgadmin.org>)
Ответы Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure  (Rahul Shirsat <rahul.shirsat@enterprisedb.com>)
Список pgadmin-hackers


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

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 failing on Linux only? Why does the following from node.js (which follows the same pattern) work fine?

var type_label = 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ów"

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.

+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 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?

--

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure
Следующее
От: Dave Page
Дата:
Сообщение: pgAdmin 4 commit: Remove leading whitespace and replace it with '[...]