Extracting text into i18n message into a namespace mistakenly create a property with the namespace name

[andrejoaquim-dc]

Describe the bug
Extracting text into i18n messages has a bug that creates an additional property to the JSON file equal to the namespace's name.
This bug is not present in version 2.8.1.

Extension Version
i18n-ally 2.9.0 for Visual Studio Code

Framework/i18n package you are using
react-i18next

To Reproduce
Steps to reproduce the behavior:

1. Create a two translation files e.g. locales/en/indexPage.json and locales/en/aboutUsPage.json
2. Extract some test in a component using "Extract text into i18n messages" into aboutUsPage namespace
3. Check that the file contains "aboutPage" key.

I've the following configuration:

{
    "i18n-ally.defaultNamespace": "global",
    "i18n-ally.enabledFrameworks": ["react-i18next"],
    "i18n-ally.keystyle": "nested",
    "i18n-ally.localesPaths": "public/locales",
    "i18n-ally.pathMatcher": "{locale}/{namespaces}.json",
    "i18n-ally.namespace": true
}

Device Infomation

• OS: macOS 13.0.1 (22A400) (Ventura)
• Version: 2.9.0
• VS Code Version: Version: 1.77.3 (Universal)

Extension Log
Go to View -> Output -> i18n Ally, and paste the content below. You should mask any sensitive information

Output > `i18n Ally`

🈶 Activated, v2.9.0

――――――

💼 Workspace root changed to "/Users/andre.joaquim/Documents/GitHub/next-marketing-app"
🌞 Enabled
🧩 Enabled frameworks: React I18next
🧬 Enabled parsers: json, yaml, json5

📈 Telemetry id: 3418a043-a095-4271-9017-483653ad3c18
🚀 Initializing loader "/Users/andre.joaquim/Documents/GitHub/next-marketing-app"
📂 Directory structure: dir
🗃 Custom Path Matcher: {locale}/{namespaces}.json
🗃 Path Matcher Regex: /^(?<locale>[\w-_]+)\/(?<namespace>.+)\.json$/

📂 Loading locales under /Users/andre.joaquim/Documents/GitHub/next-marketing-app/public/locales
	📑 Loading (en) en/aboutUsPage.json [1683043450818.9702]
	📑 Loading (en) en/indexPage.json [1683042949933.0496]

👀 Watching change on /Users/andre.joaquim/Documents/GitHub/next-marketing-app/public/locales
✅ Loading finished


――――――

💾 Writing /Users/andre.joaquim/Documents/GitHub/next-marketing-app/public/locales/en/aboutUsPage.json
✅ Loading finished

🔄 File changed (change) en/aboutUsPage.json
	📑 Loading (en) en/aboutUsPage.json [1683043493383.912]
✅ Loading finished

Screenshots

v2.9.0

Screen.Recording.2023-05-02.at.16.57.30.mov

v2.8.1 (where the issue's not happening)

Screen.Recording.2023-05-02.at.16.58.35.mov

[kibertoad]

@andrejoaquim-dc Thank you for the report! Would you be open to send a fix pull request for this?

[ocadoret]

I think that this issue comes from the changes made in the getPathWithoutNamespace method

It used to check only on the presence of the namespace as a prefix, but now checks on namespace + delimiter (which is : with i18next framework) on a rewritten key (with all delimiters are normalized to .).

I'm not familiar enough with this project, so I might be wrong on that :)

[andrejoaquim-dc]

@kibertoad Yes, I can try taking a look at it. @ocadoret thanks for flagging, I'll check if that's the case. Is there any test suite for this behaviour that I could check?

[andrejoaquim-dc]

Hey @Swiftwork! Would you mind helping me out a bit in understanding where this bug might come from? Thanks in advance!

[Swiftwork]

@andrejoaquim-dc unfortunately I don't have a deep insight into the project and it's been a while since I contributed that PR. I assume that it's probably just a statement somewhere that should have another check but I couldn't tell you where. Probably easiest is to add debug breakpoints and see why the namespace isn't removed. Might be that the extract text and inline resolve (the translation replacement) use the same function but need two different outputs. @ocadoret might be right in checking that. Unfortunately I don't have time to assist. Good luck hunting!

[jeansantodb1]

Yes, I'm facing the same issue right now. There is someone current working on this? Maybe with the right instructions i could try open a PR.

[andrejoaquim-dc]

Hey @jeansantodb1, I still haven't find time to work on this, unfortunately :(

[terales]

A fix for the issue is released in v2.9.1

@andrejoaquim-dc @jeansantodb1 can you check whether it was fully solved?

[ocadoret]

v2.9.1 is working for me, thanks a lot !

[andrejoaquim-dc]

Yes! Thanks a lot! 💪

[Swiftwork]

@terales I assume there was a reason I added those additional delimiters but if the code works without them and no other issues arise, great! Glad to see that some more work on this great plugin is being done.