extract `parsePattern` & `addVariantToMessage` into `@inlang/sdk`

[felixhaeberle]

https://github.com/opral/monorepo/blob/e29b3361db6994a489beaac3acd116c9ce609877/inlang/source-code/plugins/next-intl/src/plugin.ts#L154-L234

Hey @jldec ,

I stumbled over this code, which seems to belong in the SDK; what do you think? Similar implementations are likely to be found in the JSON & i18next plugins.

How do we treat message parsing/variant creation in the new SDK v2 implementations?

In my understanding, multiple libraries may have different syntaxes to support, so the plugin should be used only as a bridge to execute functions with some library-specific arguments. Still, the functions should be within the SDK – I guess.

This raises the question: How does importer/exporter change the plugin landscape and functions?

Sorry for raising that many questions, but hopefully, you can clarify a bit🙏

[felixhaeberle]

cc @samuelstroschein @martin-lysk who maybe also have an idea how this can involve.

[samuelstroschein]

Are you asking if parsing third party message syntaxes belongs to the inlang SDK?

If so, the answer is no. Plugins are responsible for parsing and serializing third party message syntaxes. The SDK concerns itself with our own format. The plugin API exists to keep third party stuff out of the SDK and thereby increase the flexibility of the inlang system as a whole.

[felixhaeberle]

No, the discussion is around utility functions and where they should live. This one, for example, should clearly live in the inlang SDK, as it creates a variant in the Message format

https://github.com/opral/monorepo/blob/e29b3361db6994a489beaac3acd116c9ce609877/inlang/source-code/plugins/next-intl/src/plugin.ts#L159

---

Overall, the communication and responsibility of plugins is a mess.

1. Some do only provide message loading/saving.
2. Some do only provide matching functionality for Sherlock.
3. Some do both.

3 is the coolest of them, BUT at the cost of flexibility (can only import from one format), code duplication (same JSON parsing code in every package).

[samuelstroschein]

ah. utlity functions like createMessage etc don't exist atm because we did not reach a consensus how those functions should work (cc @loris.sigrist). the discussion was concluded with "let everyone hand roll for now and then see what's next".

---

Overall, the communication and responsibility of plugins is a mess.

This seems to be an unrelated issue? Discuss somewhere else?

1. Some do only provide message loading/saving.
2. Some do only provide matching functionality for Sherlock.

The website (cc @nils.jacobsen) just misses a "this plugin defines xyz" section and explainer what x,y, or z do on the product page. I did a sketch a while ago but can't find it anymore.

[felixhaeberle]

utlity functions like createMessage etc don't exist atm because we did not reach a consensus how those functions should work (cc @loris.sigrist)

why did we not reach consensus?

"let everyone hand roll for now and then see what's next"

This results in a lot of code duplication in plugins / libraries and is also very likely to get out of sync on updates. We can't even track this if we do not have a hard dependency on a variant/message creation function.

The only part that saves us here is TypeScript checking for the correct Message format when the type is being used where the message is created.

[jldec]

relevant discussion (decision not to introduce a new pattern parser for now) in https://github.com/opral/monorepo/pull/2795#issuecomment-2116397305

fyi - I also asked @nils.jacobsen to hold off on extracting sdk helpers for the new v2 MessageBundle format, until we're further along with the v2 sdk api.

NOTE: There are already 2 very basic helpers to create v2 MessageBundle and Message types which we can use for testing. They assume simple strings without variants like v1.

[felixhaeberle]

@opral/inlang-plugins Can you create a follow-up task to #2795 updating the plugins when ready?

[samuelstroschein]

@felix.haeberle please don't use github. people don't get notifications on linear.

[felixhaeberle]

@samuelstroschein We do not have a plugin team in Linear AFAIK.

[NilsJacobsen]

There is also nobody responsible for plugins right now. I would propose that you (@felix.haeberle) do it because you will add more plugins in the next days.

[felixhaeberle]

@nils.jacobsen Alright, lets do it that way 👍