How to deal with internalization in this multiple plugins context ?

• Sep 23, 2022 - 09:00

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"


In reply to by jeetee

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





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.

In reply to by parkingb

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

In reply to by Jojo-Schmitz

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


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).

In reply to by Jojo-Schmitz

> That would overwrite the
> 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.

In reply to by parkingb

batch_convert in the plugin repository does download directly from GitHub (in this case from (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

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


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.

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