translation: Provide more context to Transifex translators #21465

The Problem

Using native Qt translation files (TS, *.ts) for exchanging with Transifex platform limits means to provide context to translators to the only category:

| C++ source code | TS XML element | Transifex metadata |-----------------------------------------------|------------------------------------------------|:------------------: | Class Name | <name>ClassName</name> | Context | disambiguation parameter of tr() function | <comment>Short comment</comment> | N/A | Translator Comments //: ... | <extracomment>Nice comment.</extracomment> | N/A

More details:

• https://docs.transifex.com/formats/introduction
• https://docs.transifex.com/formats/qt-ts
• https://doc.qt.io/qt-5/linguist-ts-file-format.html

The Solution

XLIFF file format is supported by Transifex much better.

And Qt provides us with a stand-alone conversion tool lconvert.

$ lconvert -o bitcoin_es.xlf -i bitcoin_en.ts

Now more context options are available:

| TS XML element | XLIFF XML element | Transifex metadata |------------------------------------------------|-------------------------------------------------|:------------------: | <name>ClassName</name> | <group resname="ClassName">...</group> | yes | <comment>Short comment</comment> | <context>Short comment</context> | yes | <extracomment>Nice comment.</extracomment> | <note from="developer">Nice comment.</note> | yes

More details:

• https://docs.transifex.com/formats/xliff
• https://code.qt.io/cgit/qt/qttools.git/tree/src/linguist/lconvert/lconvert.pro?h=5.12.10

Looking for Concept (N)ACKs.

Concept ACK

So our disambiguation strings don't end up on transifex to provide context? Why do we have them? If they don't show up on transifex then they serve no purpose for the Translators.

Following from your chart it seems that the development flow wouldn't involve too much overhead/change from what we have now. It seems that migrating to the XLIFF files, the C++ disambiguation strings will show up as <comment> in the TS XML Element which would then show up on Transifex. This is a huge benefit to translators.

So our disambiguation strings don't end up on transifex to provide context?

Yes, for now.

Why do we have them? If they don't show up on transifex then they serve no purpose for the Translators.

I did not check the whole code base, but it seems https://github.com/bitcoin-core/gui/pull/220 was the first usage of them. Translation file (*.ts) could be downloaded from Transifex by a translator to work on it locally using Qt Linguist tool. Then the translated file could be uploaded to Transifex back.

Concept ACK if it helps translators.

I think the only code change necessary here to use the new format would be to add lconvert step to make translate, and check in the resulting bitcoin_en.xlf file for Transifex to pick up. That only affects the English (base) translation.

This assumes that we still get back .ts files when pulling translations with the transifex-migrate-resource.py script. If not, that script too will need to be adapted (to convert back to .ts for Qt usage).

Translation file (*.ts) could be downloaded from Transifex by a translator to work on it locally using Qt Linguist tool. Then the translated file could be uploaded to Transifex back.

It's possible, though this might lose the metadata (who translated what), as well as prevents people from collaborative editing of the same language. I do not think it would be good to recommend it.

Translation file (*.ts) could be downloaded from Transifex by a translator to work on it locally using Qt Linguist tool. Then the translated file could be uploaded to Transifex back.

It's possible, though this might lose the metadata (who translated what), as well as prevents people from collaborative editing of the same language. I do not think it would be good to recommend it.

I agree with your latter statement. I mentioned that option only for a reason to show how the additional context means could be used right now.

@laanwj

Concept ACK if it helps translators.

My concerns are about how to test this approach without breaking anything.

My concerns are about how to test this approach without breaking anything.

We could create 22.0 translations early and test with that. If it breaks now, not too bad, still a lot of time to start over.

@laanwj

We could create 22.0 translations early and test with that.

See #21694.