Auto-generated langpack PETs?

[BarryK]

I was wondering if anyone has thought about doing this, or knows of anyone who has done it and posted to this forum.
So much happens on this forum, it is possible something like this has been done and I missed it.

We have the MoManager tool for creating non-English translations and then a langpack PET.

Most of the existing langpack PETs for Puppy are very old and incomplete. Only a few people have maintained langpacks -- in particular there is esmourguit who has maintained the French translations, for both EasyOS and Puppy.

In theory, a CLI translation tool such as 'translate-shell' could be used to automate MoManager. It would probably create a langpack with some laughable translations, but would be a huge jump in getting more langpacks out there.
Translations could then be tweaked by a human.

translate-shell usage is described here:

https://ubunlog.com/en/translate-shell- ... -terminal/

If noone else has done it, I might have a go at automating MoManager.

[don570]

I believe I was the only one to try something creative with momanger.
I combined the variable 'LANG' , gettext , and the pinstall.sh script to create the right click menu items
in the language that the user had set in first run. I also added some mo files for some useful utilities.
It worked well.

Your idea seems entirely different.--->to create the mo files for the maintainer of langpack.
______________________________________________________

[step]

I understood differently: Barry's idea is to create pre-filled PO files in various languages by leveraging an automatic translation engine, such as google translate or any other engine that translate-shell can support.

[don570]

understood differently: Barry's idea is to create pre-filled PO files in various languages by leveraging an automatic translation engine, such as google translate or any other engine that translate-shell can support.

Maybe you are right . I thought that Barry had some way to use google translate so that a mo file could be be made.

Mo manager already has a list of scripts that can be translated.
___________________________________________

[step]

understood differently: Barry's idea is to create pre-filled PO files in various languages by leveraging an automatic translation engine, such as google translate or any other engine that translate-shell can support.

Maybe you are right . I thought that Barry had some way to use google translate so that a mo file could be be made.

Mo manager already has a list of scripts that can be translated.

Well, since MO files are generated from PO files we both should be correct I'm not too familiar with Mo Manager. I guess it performs the PO to MO conversion automatically.

[BarryK]

Yes, a CLI translator could fill in a po file.
In the case of scripts, MoManager will generate the po file.
And yes, MoManager creates mo files from po files.

It would probably have to be limited to simple strings, without formatting.
I don't know what the translator would do with "<b>bold text</b>" for example.
Variable names, like "${variable}" may also be a problem.

Then there are some names that you would not want to translate.
For example "Puppy Linux" in a text string.

I wonder if a CLI translator can be told to leave specific parts of a string as-is?
Even if it could, the resulting translation might be weird.

[step]

It would probably have to be limited to simple strings, without formatting.

Perhaps machine translation is more accurate when it has more context rather than less.

I don't know what the translator would do with "<b>bold text</b>" for example.

Google translate can translate and render HTML pages but I don't know if there's an API for that, and if translate-shell can use the API.

[don570]

I'm not too familiar with Mo Manager. I guess it performs the PO to MO conversion automatically.

For the sake of accuracy MoManager hands off the work of filling in the empty fields to a text editor such as Geany.
Then there is a simple one line command to convert to mo file.

It would probably have to be limited to simple strings, without formatting.
I don't know what the translator would do with "<b>bold text</b>" for example.
Variable names, like "${variable}" may also be a problem.

I would insert an unusual phrase such as TAN (Translator attention needed) into the computer translation file at places that are tricky
such as bold text and backslashes for new lines so that the human translator can spot the trouble translations and read the original carefully.

Good news! There doesn't appear to be a problem with dollar sign using google translate (see image)

Screenshot 2022-12-05 18.30.22.png (16.61 KiB) Viewed 603 times

___________________________________________

There are several people who have developed cli apps such as...
https://github.com/soimort/translate-shell#readme

Code: Select all

$ trans -brief 'Saluton, Mondo!'
Hello, World!

__________________________________

[TTT]

I've seen the Chinese users perusing perhaps the most sophisticated wrapper (they're truly in the need of): Emacs interface to Google Translate , but I'm such a poor thing in Emacs to grasp the breadth of its seemingly unbounded programmable auto-translation capabilities in all their glory. If only some adepts here could lead and guide…

Edit: Reading through the GitHub comments/issues, there is an async clone too: Go-Translate , supporting Google RPC API, Bing, DeepL, etc.

[don570]

When the variable name is a common noun there would be problems with $ sign
Example:

Screenshot 2022-12-07 15.51.14.png (15.93 KiB) Viewed 504 times

___________________________________________

Whereas if it isn't common the tranlation is okay...

Screenshot 2022-12-07 15.57.37.png (13.9 KiB) Viewed 504 times

It would be wise to check all the variable names in a script
and make sure that they aren't common dictionary entries.