NSIS: Refactor translations to use higher level functionality

[sledgehammer999]

Apparently only the low-level APIs are documented well in the official docs.
There is higher level abstraction available to achieve the same thing less painfully.
You need to read the comments in Include\LangFile.nsh and Contrib\Modern UI 2\Localization.nsh.

This new infrastructure allows for not translating all strings for a certain locale and having it fallback to English.
The comments from the linked files were the last pieces of the puzzle so I can understand how to integrate non-builtin languages to the installer. I have such an example commit with the Filipino language (this is a demo. I will first merge #18935 for attribution and then rebase this PR).

Now the question is if it is acceptable for the installer UI to be mostly in English (the various NSIS text strings) only our own strings translated?

NOTICE: This is an intermediately step. The last step is to convert our translations files into gettext .po files (similar to Qt's .ts files). The .po files can be integrated with Transifex. Then via a python script autogenerate the *Extra.nsh from the .po files and autogenerate the translations.nsh file.

NOTICE2: The diff is huge because the strings were moved around (via scripting), the actual changes are few.

Any comments?

[glassez]

Now the question is if it is acceptable for the installer UI to be mostly in English (the various NSIS text strings) only our own strings translated?

Are you saying that by adding an additional language, it is possible to provide translations only for our own strings, and the strings of NSIS itself cannot be translated?

[sledgehammer999]

Are you saying that by adding an additional language, it is possible to provide translations only for our own strings, and the strings of NSIS itself cannot be translated?

Technically, they can be. Look at the commit Example of integrating a non-builtin language. Notice the .nlf file? That file is copied from NSIS\Contrib\Language files\English.nlf. with the language ID in the file adjusted to Filipino. The English.nlf contains all the English strings and technically forms the base upon which the other languages do their translations. The same goes for the .nsh file. It contains the strings for the "Modern UI 2" (or MUI2) of NSIS. However, you can have it as stub file for your language because the loading API for the .nsh explicitly allows for setting a fallback language.

It isn't clear to me what the format of the .nlf file is. I am sure that through trial and error we can "reverse engineer" it. The question is: Should we even try to make it available to translators on Transifex? Are we ok getting community translations for NSIS itself?

[glassez]

The question is: Should we even try to make it available to translators on Transifex? Are we ok getting community translations for NSIS itself?

I think the NSIS translations should be contributed to NSIS itself. After they are merged there, we will also be able to merge translations for the respective languages. Or even merge them independently of NSIS itself, if users are satisfied with seeing a partially translated interface.

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.