WIP: Plugins v3

[phw]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences:

Problem

• JIRA ticket (optional): PICARD-1861

This is the work in progress of a proposed rework of the plugin system.

The main part here is an initial specification of the plugin API in PLUGINS.md. The document builds upon the extended discussion of requirements for a new plugin system on the wiki. But currently the focus is on the plugin API and loading inside Picard, not so much on the distributions side. But @zas had some good ideas here of using git, and parts of this are documented in the spec

Beside the document there is only very rough prototyping to evaluate the ideas a bit. The very last commit does do some initial plugin loading, but this was committed as current state very much in the middle of the work.

This is IMHO not yet ready for review, but as I had little time the recent weeks let's have this up here to build upon. So far it was mostly @zas and myself discussing some ideas. I think the general direction is solid, but we should put this up for a wider discussion.

Solution

Action

Additional actions required:

• Update Picard documentation (please include a reference to this PR)
• Other (please specify below)

[zas]

How would that work?

1. Plugins have their own domain, but cannot access picard domains, this may be a problem for constants/attributes from database
2. Plugins have their own domain, a set of methods from plugin API to use it ((), N() are those from Picard, P_() and PN_() for plugins)
3. We append plugin domain to the main one (chaining fallbacks https://docs.python.org/3/library/gettext.html#gettext.NullTranslations.add_fallback), basically Picard main domain is used, but plugin "extends" it, standard picard/i18n are used
4. ?

We need to test each approach to find the best.
Loading plugin translations can be either automatic (we expect .mo files to be somewhere identical for all plugins), or by a specific call from the plugin to the API to indicate where to find translations (decided by plugin author). I tend to prefer the first approach, as it is simple, safer, and "normalize" plugins.

[phw]

My preference would also be 1. I think plugins should have their own translation generally. For thing like attribute translations we have separate domains anyway. If this becomes a requirement we could consider exposing this via the API as well.

Opiton 3. sounds interesting though, we should probably try how well this works.

[zas]

Actually using fallbacks isn't a good idea, as it may leads to conflicts between strings (if we search main domain first and plugin has a different translation for the same string, it will not appear, and the reverse searching plugin domain first and falling back on main, would let plugin translations to override main translations).

Also .mo aren't supposed to be portable between systems.
Though GNU gettext is able to take care of endianess at runtime it seems, it is usually preferable to compile .po to .mo on target system.
An interesting thread about that: https://stackoverflow.com/questions/53285634/is-there-a-portable-way-to-provide-localization-of-a-package-distributed-on-pypi