New NLS design discussion

[lakshayrohila]

This discussion is opened for brainstorming on the issue #3841. Your ideas about the same are welcome!

NOTE: If anyone has started working on the issue, then please ignore this discussion (or take suggestions from it 👍) and let us know about the same. Otherwise I will start working on the issue, once I get approvals/suggestions.

It will be great to do update MoManager as described by @dimkr here. So, here are the core features (on top of previous features, modified if necessary) what I think the new script should atleast have:

1. translations should be done automatically (and later on reviewed by a human)
2. translations should made for pre-built woof-CE (even pre-merge2out), i.e. making it a part of build

On top of that, we can have complete GUI method for translation and review, instead of opening default-text-editor with a .po file.

This is how I think I should do it :

• Leave momanager as-is and start working on another script, utilizing code from momanager as well (we can later on announce it as deprecated, or even remove it completely).
• Create new directory under woof-code, maybe named as rootfs-nls, which will contain all the code and/or data for nls support.
• Create a script which provides features (1) and (2), which can be run later on by user
• Put reviewed .po files for a language at woof-code/rootfs-nls/[ISO 639-1 code]/*.po (ISO 639-1 code)
• Also put a cache file at woof-code/rootfs-nls/[ISO 639-1 code]/remaining_updates, which will contain information on .pos which need to be updated
• Once review is complete for a language, the user could create a new PR
• Create, if possible, a github workflow which runs on every PR and gains information whether after this PR, nls for any language will be needed to be updated (and update the remaining_updates as required).
• Update build process to allow it to keep all the related NLS files in final build's nls.sfs (maybe somewhere else, as you say).

That is just the design for the script I have in mind. If you think that the design is okay, then please approve. Otherwise, please suggest what could be the better way of doing the same 👍.

Regards
@lakshayrohila

[gyrog]

Are you aware of this forum topic, https://forum.puppylinux.com/viewtopic.php?t=8693?

I'm currently working on transforming FrugalPup to support i18n, and found it's a deeper rabit-hole than I first thought.

Unfortunately I can't comment on the current MoManager as with a $LANG=en_AU.UTF-8, it says it's not for me, and exits.
But I do appreciate that automated translation should be utilised.
I did manage to use some online translation services to produce a French frugalpup.mo as a test.
My main pain is that the automaticly generated French translation is much longer that the English original.
This sometimes plays havoc with the look of dialogs.

I guess I'm saying that automatic translation is a convenient start, while a lot more useful than no translation, it really needs to be reviewed by a human.
And of course the new script will work outside the woof-ce environment for applications that are still being developed.

[lakshayrohila]

BTW, I tried creating this thing earlier, but I couldn't finish it due to lack of time. I'm also cleaning up the documentation stuff that had remained with me earlier and am opening the pull request soon. I'll see in the future what plans I have to continue developing for Puppy, as currently, I have left programming itself due to time limitations (yes, I am no professional programmer).

[gyrog]

I hope you find the time.

I do have one suggestion:
As well as supporting the gettext type translations, it would be handy if it could also translate files like the following,
init.txt
This is the translation technique used by the 'init' script, and maybe some others.
The translated version of the file is simply included into the script, thus redefining the mentioned variables.