Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create ParaglideJS Inlang plugin #140

Closed
felixhaeberle opened this issue Jun 4, 2024 · 6 comments
Closed

Create ParaglideJS Inlang plugin #140

felixhaeberle opened this issue Jun 4, 2024 · 6 comments

Comments

@felixhaeberle
Copy link

@LorisSigrist Do you see the value in bundling the inlang message format plugin & the m function matcher in a dedicated paraglidejs plugin to have a more convenient handling of modules?

see also https://discord.com/channels/897438559458430986/1084866749842870333/1247389185862533220 where user has issue identifying how to get Sherlock to work. This happens on a weekly basis, and probably much more silently.

Originally posted by @felixhaeberle in opral/inlang.com#85 (comment)

Copy link
Collaborator

I think we used to have the problem that a paraglide plugin was needed as a module and then you would have had two paraglide modules, which cased confusion.

The next reason was that we thought that it should be possible to use paraglide with more then one storage. Since we use different keys, that is not really a thing anymore, right?

Sry, this is not super accurate. Just trying to dig in the depths of my brain :D

Copy link
Collaborator

I'm not sure if that's a good idea, since we would be tie-ing the storage format to the API used in code.

Given that the init channels usually add both the m-function matcher & the inlang-message-format: Do we know how users end up with these half-setups?

Copy link
Collaborator

Paraglide doesn't need a storage plugin with persistency. So this is only about the matcher for paraglide.

@felixhaeberle
Copy link
Author

felixhaeberle commented Jun 4, 2024

I'm not sure if that's a good idea, since we would be tie-ing the storage format to the API used in code.

This was discussed yesterday with @samuelstroschein – I also had this misconception.

With importer/exporter saveMessage/loadMessage will become importMessage/exportMessage – with the main change that not last one wins anymore but multiple importer/exporter plugins are allowed then, making the import/export of the ParaglideJS plugin the default one + one of many.

Currently, it would mean the limitation you described.

Given that the init channels usually add both the m-function matcher & the inlang-message-format: Do we know how users end up with these half-setups?

🤷🏼 – manual setup? don't know, but happens often.

Copy link
Collaborator

I see. In that case doesn't it make more sense to wait for persistence to land before doing something like this?

Copy link
Member

Yes, let's wait for persistence.

@LorisSigrist LorisSigrist changed the title Create paraglidejs plugin Create ParaglideJS Inlang plugin Jun 4, 2024
@samuelstroschein samuelstroschein closed this as not planned Won't fix, can't repro, duplicate, stale Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants