[ENH] Multilingual distribution

[janezd]

Orange 3.38 might support switching between languages. This is a draft of how add-ons would support that.

We would upload original sources to PyPi and run translation during installation. Add-on is "translated" if (see here)

• setup is run as install (not develop),
• Orange version is at least 3.38,
• trubar is installed. I propose we'd make it a requirement although Orange doesn't depend on it -- only translation of add-ons does. (Note: the current release of Trubar supports only translation to a single language, not switching. This PR suppose a new version which is still in development.)

If add-on supports multiple languages but Orange doesn't, or vice-versa, everything should work.

pip install -e . or python setup.py develop should keep source intact. Hence developers wouldn't (have to) notice that add-ons become multilingual when installed. Orange itself would also only be translated when preparing the release, not earlier.

Note: this only works if add-on is installed via python setup.py install or pip install --no-build-isolation .. Without --no-build-isolation, pip creates some kind of temporary virtual environment that has nothing but built-in Python modules.

@markotoplak, thanks for bringing setup.py to my attention. What do you think about this?

To do:

• How does this interact with CI?
• Can we move InstallMultilingualCommand to another place (where?!?!) where it can be shared between add-ons?

[markotoplak]

On Friday we tested sloppily: contents of the first build bdist_wheel were not actually translated, because the source was translated after wheel files were copied into the build/ folder. The second wheel would be OK then.

I fixed setup.py to actually change the files that are installed. This even avoids problem with trubar editing files in the repository. The current state according to my tests:

• sdist contains the original code and translations, which are applied after installation
• the wheel contains translated files which are then just copied
• pip install -e . does not call trubar, which I prefer.
• the conda package contains translated files from the wheel and these are just copied at installation

I did not check whether anything works though - for now I just tried to ensure that files are translated.

[markotoplak]

TODO:

• Before making a release we need to get trubar into conda forge.

[janezd]

TODO:

• Before making a release we need to get trubar into conda forge.

I'm working on it.

[markotoplak]

Windows build fails with Can't open configuration file C:\Users\runneradmin\AppData\Local\Temp\pip-req-build-wujae7jl\i18n\trubar-config.yaml

[markotoplak]

Ok, fixed the previous problem. Now the problem is that, inside trubar, yaml wants to smartly open files with cp1252, and that does not work.

[markotoplak]

PyQt6 do not pass because we still haven't fixed them in any add-on.

Now Windows tests are still not working. Waiting for a proper Trubar release. If they then pass, we merge.