How can developments in one plugin positively influence other plugins?

[felixhaeberle]

Problem

When one plugin undergoes heavy development (like our json plugin), it often introduces new features and enhancements that other plugins may miss out on. This situation can lead to a disparity between plugins, where some benefit from the latest advancements while others lag behind. We need to find effective ways to ensure that developments in one plugin positively influence and benefit other plugins within the ecosystem to support each feature in the inlang ecosystem from a plugin perspective in like the same quality and quantity.

Short: @inlang/team We need a solid "backport strategy" when the number of plugins is rising and some plugins are on the cutting edge where other plugins may not have those features. From a user perspective, I want every inlang plugin to have the same quality as any other. Best, I will not use two at the same time – but if one lacks extremely behind another one, inlangs potential is not being used (like placeholders / folder detection missing in yaml plugin).

Proposal

To address this issue, we can explore various strategies and approaches that encourage collaboration, code sharing, and knowledge exchange among plugin developers & plugins. By implementing these strategies, we can foster a more inclusive and progressive environment for the entire plugin ecosystem. Here are some proposed strategies:

1. Standardization

• Identify common functionalities and practices introduced in heavily developed plugins.
• Promote discussions among plugin developers to establish plugin standards or best practices based on the successful features.
• Encourage plugin developers to align their plugins with the established standards to ensure interoperability and ease of integration into the inlang ecosystem.

2. Documentation and Examples

• Encourage plugin developers to create comprehensive documentation for their plugins, focusing on the new features and enhancements. (check if a plugin has the required amount of minimum documentation)
• Share examples and tutorials demonstrating how to leverage the new features effectively.
• Establish a collaborative platform where plugin developers can collectively improve and maintain documentation. (our open source inlang repository -> docs folder -> where we guide people to put in their docs)

4. Collaboration and Knowledge Exchange

• Provide a dedicated forum or platform (e.g., GitHub Discussions / Discord) for plugin developers to connect, share insights, and exchange ideas.
• Foster a culture of collaboration by encouraging developers to actively participate in discussions and contribute to each other's projects.

5. Community Feedback

• Encourage plugin developers to listen to their respective communities and understand their needs with talking to them in GitHub issues
• Share success stories and positive feedback from heavily developed plugins to inspire other developers. (Discord wins/progress Channel & potential newsletter)

By implementing these proposed strategies, we can bridge the gap between heavily developed plugins and other plugins, ensuring that advancements positively influence the entire ecosystem.

Please feel free to provide your feedback and suggestions on these proposed strategies. Let's discuss how we can make developments in one plugin have a positive impact on other plugins.

[NiklasBuchfink]

3. was my favorite 😉

I very much support the proposal. Feature support, migrating, sharing concepts and code, documentation, communication with plugin developers and users are all very big topics that need to be addressed in that context.

In this context, we will also see different types of plugins:

• Plugin only for own private repo, not to become maintainer.
• Plugin is developed and used once, then unmaintained
• Plugin is updated, but its users do not use the latest version

@felixhaeberle Do you think it is possible to separate functions from the syntax of different formats (json, yaml, po, md, etc) so that supporting new features feels more like adding a function import. For example, support for placeholders, different folder structures, and other features could be integrated into createPlugin or imported from @inlang/core/plugin. This way we can always update the plugin template and improvements from the template can be synced into the fork.

[felixhaeberle]

Everything which can be code shared should be. Placeholders need a bit more work but for example the folder as language detection which you pointed out is totally standalone from the file content & could be easily shared.

Currently, we do not have a code sharing concept for such functionality because the plugins are living at remote places what makes it hard to code share. Importing it from @inlang/core/plugin is an interesting proposal which should be checked.

@NiklasBuchfink Overall, I would also think about adding the plugins to the monorepo because why not and it eases code-sharing and communication (docs) for the respective plugins.

[samuelstroschein]

@felixhaeberle Thanks for opening this discussion.

The question of rising quality among plugins is valid. The proposals all lean towards "build a community around plugins". I do not believe that we have the capacity to "force foster" a community for plugins. Eventually, developers will build that community themselves if they see the need.

What we can do, and probably should do, is move plugins maintained by us into our monorepo and thereby ensure quality and code sharing among "by inlang" plugins.

When one plugin undergoes heavy development (like our json plugin), it often introduces new features and enhancements that other plugins may miss out on.

FYI this seems like a minor issue. The JSON plugin is a zombie that needs to support a variety of use cases. In most cases, a plugin has a finite scope and doesn't need a lot of features.

---

@felixhaeberle you proposed moving maintained by inlang plugins into the monorepo too. Seems like we both agree on that one. Feel free to open an issue "move plugins maintained by inlang to monorepo to increase quality and iteration speed".

[NilsJacobsen]

So for now it is only the i18next-plugin that should be moved into the monorepo right?

[NilsJacobsen]

@felixhaeberle @samuelstroschein

[samuelstroschein]

Opened an issue #884.

Closing this discussion as "we decided to improve plugin quality by moving maintained by inlang plugins into the monorepo".