plugin api needs to account for multiple definitions

[samuelstroschein]

Context

The implementation of loadMessages and saveMessages only allows one plugin to define the API.

The upcoming MESDK-66 will change the API to allow multiple plugins to define importers and exporters. Apps are responsible for selecting an importer or exporter/assign it to MESDK-98.

@felix.haeberle was unaware in MESDK-128 and INWEB-108 that the importers and exporters plugin API will be a 1-to-many solution.

I am opening this issue to drive alignment.

Proposal

Should every plugin api be (default) designed as 1-to-many and thereby avoid "how to merge plugin apis" logic (which will likely not satisfy future requirements anyways)?

The use cases of i18n are so vast that we seem to need the flexibility of people using different importers/exporters, matchers, machine translation plugins at the same time. It seems like we should default design the plugin API to just map to many.

importer/exporter

crucial to support multiple imports and exporters

machine translate

everything ai needs to move the plugin api because people want to use different providers e.g. deepl, google translate, chatgpt, inlang gai, ….

matchers

seems obvious that people should be able to mix and match different plugins for different matchers

https://www.loom.com/share/9a2ecd0affb846fc93c05ee531289a5b?sid=77f3b8a8-206b-4ea2-8c18-1fe367746147

[jldec]

@samuel.stroschein @felix.haeberle please confirm if my summary sounds right

• the current messages (load/save) plugin API will be deprecated
• one project should be able to host multiple plugins or modules of the same "type"
  • message lint rules (already true)
  • message importers (replace single loadMessages)
  • message exporters (replace single saveMessages)
  • message function matchers (replace single app.inlang.ideExtension custom api)

[samuelstroschein]

yep except custom api can still stay until we have "Where used in code" plugin API as a workaround.

insihgt being: most (all?) plugin apis shouldn't be merged or resolved. instead, the sdk (and apps) iterate over the provided apis and provide the user with a choice e.g. "do you want to use the deepl or google translate plugin to machine translate this message"

[felixhaeberle]

Also, it would be extremely convenient for developers to have all-in-one plugins for libraries like i18next which already define a importer/exporter & a matcher like we have it now to have a super quick getting started and don't have to communicate multiple concept.