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.
- 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.
