Re: From the random thoughts file: automatic translation of add-ons


Rui Fontes
 

Hello!


It will be good only if it was possible to use the "Translation memory", a kind of repository of translations made by humans...

Using only automatic translation from Google, or even from DeepL, a better translation system, it will be very risky to use...


Best regards,

Rui Fontes
NVDA portuguese team




Às 10:47 de 08/05/2022, Sukil Etxenike via groups.io escreveu:

Hi,

Interesting. There are two problems here, though. The first one is automatic translation, which you already mentioned. This is aggravated by the lack of context in some strings, which could worsen it.

The second one would be placeholders (format strings and such). We would have to ensure that at least the placeholders are returned as is, and that exactly the ones requested are returned.

Thanks,

Sukil




El 08/05/2022 a las 6:15, Luke Davis escribió:
Hi all

Something I have been pondering for the last couple weeks.

In NVDA add-ons, at least those using the template, .pot files can be generated. In fact, my add-on Appveyor builds generate them all the time, although I don't generally use them.

Headers aside, these include message identifiers, file names/paths, and line numbers for each translatable string. Actually, the message itself is included as msgid, and the message string (msgstr) is empty, but that is how "scons pot" does it, so I assume it has to be that way.

Now let me say that I read and write about a dozen languages. These include: English, C, C++, Python, PERL, PHP, JAVA, Bash, YAML, HTML, CSS, and others.

Of course I jest. The only human language I speak is English, which is why I am asking about this here: my translation experience is absolutely none.

After the .pot files, the translation team goes to work, and we end up with per-language .po files, that have lines looking like these, taken from an older version of Add-on Updater:

msgid "Check for &add-on updates..."
msgstr "Buscar &actualizaciones de complementos..."
msgid "Check for NVDA add-on updates"
msgstr "Buscar actualizaciones de complementos de NVDA"
#. Translators: This is the label for the Add-on Updater settings panel.
#. Add-on summary, usually the user visible name of the addon.
#. Translators: Summary for this add-on
#. to be shown on installation and add-on information.
msgid "Add-on Updater"
msgstr "Actualizador de complementos"
#. Translators: This is the label for a checkbox in the
#. Add-on Updater settings panel.
msgid "Automatically check for add-on &updates"
msgstr "Buscar automicamente &actualizaciones de complementos"

So here was my idea.

Since we have the Instant Translate add-on, and we have Google Translate, and other translation services that are API driven:
What is stopping us from, during an add-on build, calling out to a translation service with the message IDs from a pot file, and using the result to construct multiple language po file results?

Wouldn't that give us immediate localization for any add-on?

Now, obviously those translations, being machine generated, would be significantly inferior to human derived translations, but not all of us can get translation teams dedicated to translating our add-ons.

I would expect some kind of translation, to be better than no translation at all.

But I only speak English, and as such have deficient knowledge. So am I wrong?

I suspect that I am missing a major factor in this, or it would have been done by someone, long before now.

Luke






Join nvda-addons@nvda-addons.groups.io to automatically receive all group messages.