It doesn't really matter which approach you choose. Both using a monorepo and separate repos are reasonably common approaches.
Keeping all variants in a single repository is definitely simpler to manage, and updating the data is straightforward. It is also straightforward to make cross-cutting changes, such as changing the data format and all dependent software in one go.
But there are some downsides with tooling, e.g. if language-specific tools expect some configuration to exist in the top-level directory of the repository. If you have an automated test suite or a CI server, you may be re-running tests for all languages even only code for one language changed. This might also complicate contributions for a single language's version. It may be unclear how version numbers for the packages relate to versions in your source control system. As a problem specific to GitHub, the releases page will also be a mess.
Having separate repositories for each language is definitely more complex, but also more flexible. Each package can be developed independently, and it's easy to version the packages separately.
Downsides are greater effort for updating the data. You can keep the data in a separate repository and integrate it as a git-submodule. However, a git-submodule references a specific commit – you'd have to update all dependent repositories to point to the updated version. This turns a single data update into an O(n) effort, though using a bot to automatically generate the necessary pull requests can reduce the human effort here. Alternatives like git-subtree that copy the data into each repository aren't any easier either.
Another downside is the difficulty of making cross-cutting concerns across all versions. It is possible that less popular packages lag behind and do not get new features.
While both approaches are good, they have distinct and largely opposite benefits/downsides. You can therefore decide by thinking about typical usage patterns:
- If data updates are frequent but code changes are rare, consider a single repository.
- If data updates are rare but code changes are frequent and independent, consider a separate repository per package.
This is not an either/or-solution. It is also possible to start with a single repository, and to spin out individual packages as they mature into an independent project.
