How to deal with internalization in this multiple plugins context ?

• Sep 23, 2022 - 09:00

Hi,
I was looking at the finalisation the internalization of my batch_convert's extension.
And i realized that in the plugins/translations folder I add not only the translations files for the batch_convert plugin but also from other plugin.
And the last plugin being installed just erases the translation from previously installed plugins.

Any idea how to deal with that overriding issue ?

I couldn't find a way to tell qsTr to look for translation files with a specific prefix such as "batchconvert_locale_en.ts" or in a specific folder such as "translations\batchconvert\locale_en.ts" or "batchconvert\locale_en.ts"

Comments

• Sep 23, 2022 - 09:43

I see no differences between how the TempoChanges and the BatchConvert organise their translations:

TempoChanges

trTempoChange.png

BatchConvert

trBatchExport.png

Unless the user installs each plugin in a separated and specific folder (which is neither required for the plugin to work nor documented) both plugin translations filles would end up in ~/Documents/MuseScore3/plugins/translations/*.qm.

Actually, I discovered the conflict with translations files with the TempoChanges plugin.
When I worked on the BatchConvert translations I had a remaining "locale_zh_TW.qm" file I couldn't where it came from. Until I realized it came from the TempoChanges plugin and that all the other TempoChanges plugin were erased by the ones of the BatchConvert plugin.

Reply

• Sep 23, 2022 - 09:58

For the translations to work, indeed each such internationalized Plugin needs its own directory.

Maybe we should document that.
In theory it should be possible to concatenate the .ts files and (re)build the .qm files, but in praxis the hurdles are too high, as the necessary tools won't be available on most computers

Reply

• Sep 23, 2022 - 10:35

What about packaging the plugin directly in a specific folder.
So BatchConvert (same for TempoChanges, ...) would become

./README.md
/batch_convert/batch_convert.qml
/batch_convert/translations/*.ts

and to instruct people to install it as such ?

I would prefer that to unzipping a GitHub release zip file which has indeed a folder structure, but with a version specific name (e.g. MuseScore_TempoChanges-3.4.1) which could lead to conflict between plugin versions if the user forget to remove the folder with the previous version (e.g. MuseScore_TempoChanges-3.4.0).

Reply

• Sep 23, 2022 - 13:05

> That would overwrite the Readme.md
Agree
> batch_convert does come with it's own subdirectory
True for people downloading from the MuseScore plugins repository. Untrue for people downloading from GitHub. And same remark as for TempoChanges, the subdirectory name does not sound like something the user must keep during the installation ("batch_export-master") but more like technical name.

Reply

• Sep 23, 2022 - 14:51

batch_convert in the plugin repository does download directly from GitHub (in this case from https://github.com/Jojo-Schmitz/batch_export/archive/master.zip (a file that gets generated on the fly on GitHGub, as far as I can tell, it sure always contains the latest version of that branch)
You can rename the directory to your linkings, but on an update of that plugin would need to take care of the location, not so if you just keep the name.

But indeed if you download individual files from GitHub, this is different

Reply

• Nov 21, 2022 - 10:29

This how I've solved this in my batch_export version:

\batch_convert\batch_convert.qml
\batch_convert\translations\*.*
\Readme.md
\demo\batch_convert.png

And I exclude from the package anything which is not in \batch_convert\ (with a .gitattributes file).
So the the user can simply unzip the package zip file into its plugin folder. And the translations for the plugin remain separated from the other ones.

Reply

Do you still have an unanswered question? Please log in first to post your question.