Previously: https://bugs.kde.org/show_bug.cgi?id=422381

I suppose the KDE translation workflow prefers using PO files, so I will aim to provide a POT file via Messages.sh and then make use of the PO files (or the built MO files) in the installer generation process.

At this moment, the translations for the custom strings are hacked in using NSIS header files. I have a rough idea of putting the strings into a Python script instead and make use of Python's gettext support to just output the translated header files, which I believe would be easy enough to be implemented. This way, the Messages.sh can invoke xgettext to extract the strings from the Python script and generate a krita-installer.pot file.

Some points that need to be noted or discussed:

• Is it OK to leave the NSIS built-in strings translations up to NSIS?
  • NSIS comes with translations for the other built-in strings (https://sourceforge.net/p/nsis/code/HEAD/tree/NSIS/trunk/Contrib/Language%20files/) but their quality may vary and availability may not match the available KDE translations (I haven't compared the lists). Obviously we can't include a translation with only our custom strings but not the NSIS built-in strings.
  • It will not be easy to integrate the NSIS built-in strings with KDE's translation, so I would rather not attempt it.
  • Is it reasonable to (or would we even want to) ask KDE translators to also help fix up NSIS's built-in translations? (Tyson already did so to the Simplified Chinese translation but I guess it is an exceptional case.)
• I would have the script scan through NSIS's built-in language files to see what translations are available. NSIS uses Windows LCID (Locale ID) so it would map them according to the table.
• Should the installer include incomplete translations (i.e. when translations to the NSIS built-in strings are available but custom strings are not translated)?
  • How can I actually detect incomplete translations via Python's gettext?
    • I guess I can just compare the "translated string" with the untranslated string for equality, but this would fail for short untranslatable strings (which we don't actually have any) and for en_GB (but NSIS doesn't have en_GB translations anyway).
  • What would be the threshold for inclusion (e.g. 80% of all strings translated)?