Side-bar editor and popup editor does not work as expected

[VldMrgnn]

Hello,

I also have this issue ( as in refereced #469 ), but more, as the translations are not present in the workspace, only in explorer-bar... The only way to make the translation is to edit directly the json files. It actually worked prior to latest update to 2.5.7. After update it does not even if I try to downgrade to prior versions. I tryied my best to make it work but I am stucked here.

Please see attached:

I provide the settings: settings.json (some tweeks after the update to 2.5.7 in order to make it work...) :

{ ...,
  "i18n-ally.enabledFrameworks": [
        "vscode", "react", "i18n-tag","custom"
    ],
    "i18n-ally.localesPaths": ["./public/locales", "public/locales"],
    "i18n-ally.pathMatcher": "{locale}/{namespace}.json"
 }

i18n.js (this worked for two years without any change)

import i18n from 'i18next';
import Backend from 'i18next-xhr-backend';
import LanguageDetector from 'i18next-browser-languagedetector';
import { initReactI18next } from 'react-i18next';

i18n
r-backend
  .use(Backend)
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    fallbackLng: ['en','ro'],
    whitelist: ['ro', 'en'],
    nonExplicitWhitelist: true,
    load: 'languageOnly',
    keySeparator: '.',
    debug: false,
    interpolation: {
      escapeValue: false, 
    },
    ns: ['translation'],
    defaultNS: 'translation',
    react: { 
      useSuspense: false
    },
    backend: {
      loadPath: '../locales/{{lng}}/{{ns}}.json',
      allowMultiLoading: true,
      crossDomain: true
    }
  });

export default i18n;

The output from terminal :

🈶 Activated, v2.5.7

――――――

💼 Workspace root changed to "/var/lib/sws/engine/om0React"
🌞 Enabled
🧩 Enabled frameworks: VS Code, React, i18n Tag, Custom
🧬 Enabled parsers: json

🚀 Initializing loader "/var/lib/sws/engine/om0React"
📂 Directory structure: file
🗃 Custom Path Matcher: {locale}/{namespace}.json
🗃 Path Matcher Regex: /^(?<locale>[\w-_]+)\/(?<namespace>[^/\\]+)\.json$/

📂 Loading locales under /var/lib/sws/engine/om0React/public/locales
    📑 Loading (en) en/translation.json [1619791355123.0857]
    📑 Loading (ro) ro/translation.json [1619791379245.6006]
    📑 Loading (se) se/translation.json [1619791399579.2483]

👀 Watching change on /var/lib/sws/engine/om0React/public/locales
✅ Loading finished

Please advise. Thank you.

Originally posted by @VldMrgnn in https://github.com/lokalise/i18n-ally/issues/469#issuecomment-830568941

[VldMrgnn]

And another example:

[antfu]

@VldMrgnn Can you share a minimal reproduction so we can look into it? Thanks

[VldMrgnn]

@antfu Thank you for the reply. Please tell me what should I share more for the reproduction

[VldMrgnn]

Hello, I found out that if the key is defined with a dot, e.g "validsum.gosave" then the translation is not shown in editor nor in the right-pane. If the key is one word( no dot), it displays ok.

for example, in the picture, both keys exist and are defined. In the edittor only the one without the dot is displayed correctly.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[terales]

Can you share a small repo with reproduction, please? It's not excetly clear with just screenshots at the moment

[4O4]

This problem occurs when there's a failure of vscode's file watcher. The extension is not being notified about changes done to translation files and the translations are not properly reloaded.

The interesting part is that everything could work fine even in case of the file watcher failure, but it doesn't because there are two places in the extension code which are responsible for translations reloading and their logic is slightly out of sync:

• Reloading that happens during write, when changes in the translation editor are being saved: https://github.com/lokalise/i18n-ally/blob/370eac4a6aa87fc735d237247e2a4944352c4f35/src/core/loaders/LocaleLoader.ts#L322
• Reloading that happens in other situations, including file change detection: https://github.com/lokalise/i18n-ally/blob/370eac4a6aa87fc735d237247e2a4944352c4f35/src/core/loaders/LocaleLoader.ts#L451-L453

Notice lack of unflatten() call in the first one.

The problem was probably never noticed because the first (faulty) code is being executed when changes made in the translation editor are saved and then it is always immediately followed by the proper reloading which occurs on file change detection.

So when these log messages appear in the output:

💾 Writing /i18n-ally/examples/by-frameworks/next-translate/locales/en/common.json
✅ Loading finished

the translations are not actually properly reloaded, the cache is populated with wrong object structure. However if the file watcher works properly, we immediately get the additional output:

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

and everything works fine. But we won't see this additional output when the watcher doesn't work, so we're stuck in the broken state.

What really blew my mind is that the failure of the watcher can be caused by misconfiguration of the workspace's files.watcherExclude and this misconfiguration might not be so obvious at first glance. At least it was not in my case. I had some exclude paths with special characters [ and ] in them, like that: "**/[logs]/**": true, and it silently breaks the whole watcher and every single feature of vscode that depends on it, including file explorer which stops refreshing automatically on external changes in filesystem. It seems that special characters must be escaped, so when you change it to "**/\\[logs\\]/**": true, then everything goes back to normal, vscode works properly and the extension works properly despite having a little bug or logic desync.

[VldMrgnn]

@4O4 Thanks for looking on to this issue. It seems that you deeply investigated the situation. I don't see anything strange here:

Even knowing that is a watcher issue I really don't know to fix the issue here, so the simplest way is to create translation keys without the dot.

example.hello -- does not work as expected example_hello -- is ok

[4O4]

@4O4 Thanks for looking on to this issue. It seems that you deeply investigated the situation. I don't see anything strange here:

Even knowing that is a watcher issue I really don't know to fix the issue here, so the simplest way is to create translation keys without the dot.

example.hello -- does not work as expected example_hello -- is ok

This was just one example of possible causes of file watcher failure. You might have hit some other case, might be configuration of the vscode or even the operating system which is ultimately responsible for delivering notifications from filesystem.

Anyway I have submitted a PR with a simple fix for that, so when it is approved and merged you should not have this problem anymore when using keys with dots.

The reason it works when there are no dots in keys is that the structure of the loaded translations is then always flat, so there is no difference between the translations object before and after unflatten()ing

[VldMrgnn]

It totally make sense. Great forensic job! Thanks a lot.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[4O4]

@terales Did you have a moment to check the MR that would fix this issue?

[VldMrgnn]

Thank you @4O4, I was waiting for the PR you made to solve the issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[4O4]

Does this bot even work correctly? It closed the MR even though I've written a comment there 🙂 Let's see if it works here

[VldMrgnn]

Nothing on this?