Editor generated json

[Yelinz]

Reference file en.json

{
  "navigation": {
    "profile": "Profile",
  }
}

Generated by editor for de.json

{
    "navigation.profile": "Profil"
}

Is it intentional that the generated structure is flat?

[samuelstroschein]

Is it intentional that the generated structure is flat?

Not per se, but it can happen. Can you send your current config file?

cc @inlang/plugins

[Yelinz]

/**
* @type { import("@inlang/core/config").DefineConfig }
*/
export async function defineConfig(env) {
  const { default: sdkPlugin } = await env.$import('https://cdn.jsdelivr.net/npm/@inlang/[email protected]/dist/index.js');

  const { default: jsonPlugin } = await env.$import(
    "https://cdn.jsdelivr.net/npm/@inlang/plugin-json@3/dist/index.js",
  )

  const { default: standardLintRules } = await env.$import('https://cdn.jsdelivr.net/npm/@inlang/plugin-standard-lint-rules@3/dist/index.js');

  return {
    referenceLanguage: 'en',
    plugins: [
      jsonPlugin({
        pathPattern: "./languages/{language}.json",
      }),
      sdkPlugin({
        languageNegotiation: {
          strategies: [{ type: "url" }],
        },
      }),
      standardLintRules(),
    ],
  };
}

[Yelinz]

Interestingly enough, the vscode extension also extracts messages without nesting in json.
If we use the structure from above and extract an text from the code with navigation.login as the id, the key is just the string, without adding to the existing object.

{
  "navigation": {
    "profile": "Profile",
  },
  "navigation.login": "Login"
}

This seems more intended but still kind of weird behavior if you started a nesting manually.

[Yelinz]

#874 looks like the problem I encounted

[samuelstroschein]

Commented on the issue to bump priority. The plugins are heavily refactored at the moment, including other parts of inlang's core. Hopefully the bug resolves itself after the refactor is complete in a week or so.

[vytenisstaugaitis]

Also noticed this, thought that it was intentional.

[NiklasBuchfink]

This is also related: #1199

I see what's the problem. inlang detects either nested or flattened keys for the whole file.
In the past, we have recognized the nesting per message and stored the metadata for it, but as soon as a new message is to be added, we do not know which formatting to apply.

@NilsJacobsen Is this correct and should we change the current behavior?

[NiklasBuchfink]

@vytenisstaugaitis FYI: #874 (comment)

Please feel free to upvote or downvote the proposed behavior and let me know your concerns :)

[NiklasBuchfink]

This is now implemented. All files are formatted according to the formatting of the source language.