feat(plugins/i18next): Use path to decide default namespace

[MrTwixxy]

Disclaimer: I haven't tested it yet, since Im unable to build myself

This fixes the default behavior of using the first namespace when there's none defined.
Useful when you have a monorepo and only want 1 sherlock project

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7ec9773

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[felixhaeberle]

@MrTwixxy can you sign the CLA?

1. do you have a link where on the i18next page this behavior is described as we need to make sure not to break existing setups?
2. have you added a test to the test file which should mimic this behavior? this is needed to make sure everything is working smoothly with further updates.

thank you for the PR:)

[MrTwixxy]

I have read the CLA Document and I hereby sign the CLA

[felixhaeberle]

@MrTwixxy I've approved the pipeline so we can check if the changes leads to errors.

[MrTwixxy]

I've fixed the tests and added a new one.
The behavior isn't 'defined' somewhere, but the default behavior isn't either.
I don't expect things to break for the following reasons:

• Nothing changed if namespaces are used how they normally are
• If you aren't using them how they normally are, it's just using always using the default, which still happens if the path doesnt match any namespace

[felixhaeberle]

hey, we have to discuss this change internally as this would mean that every plugin now needs some kind of strategy on how to do documentPath's, see https://github.com/MrTwixxy/inlang-monorepo-fork/blob/7ec9773714d9875bab0b3778a7567b4b103f1aed/inlang/source-code/versioned-interfaces/plugin/src/customApis/app.inlang.ideExtension.ts#L43

[MrTwixxy]

Having the argument passed into the function doesn't necessarily mean that it has to be used right?

[samuelstroschein]

@felixhaeberle i tend to agree with @MrTwixxy. just because the argument exists, doesn't mean that a plugin needs to use documentPath.

[samuelstroschein]

i propose to close this pr given that we will re-implement the custom API opral/inlang-sdk#125