-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSIS: Refactor translations to use higher level functionality #20501
Conversation
25026d0
to
51b6c15
Compare
Apparently only the low-level APIs is 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`.
51b6c15
to
30cc8d9
Compare
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 It isn't clear to me what the format of the |
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. |
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. |
This PR was closed because it has been stalled for some time with no activity. |
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 thetranslations.nsh
file.NOTICE2: The diff is huge because the strings were moved around (via scripting), the actual changes are few.
Any comments?