Support {key:value} structured json files

[WebFreak001]

Such as

// data.nls.json
{
    "msg.hello": "Hello World"
}

Having keys and messages quickly gets messy when there are a lot of keys

[dbaeumer]

@WebFreak001 sorry for the late response but we by design tried to avoid this. The reason why there is no hash map support is to avoid the runtime and memory overhead involved with this. Instead we have vscode-nls-dev tools that should help with created compact array based nls files. Could you outline why this approach is not working for you?

[WebFreak001]

this key value approach is simply the easiest and most compatible to work with, it isn't as error-prone as the other ways because every key has exactly one value in a very easy to read way (copy-paste friendly). Sure for a final release in a node.js-only project that might seem like a good idea, but in my case I'm also using the same translation files in a (non-js) language server. There is also the issue with having different arrays for keys & values. This is especially a problem when adding new translations somewhere at the top and forgetting to add a key (if you have someone contributing to the project that might happen easily and confuse them). That will shift all translations so they don't make any sense.

But the most important part is when having the value only arrays and then extending or reducing one language file everything else will shift if you don't update them accordingly.

The values and keys array approach is a bit better there but still less readable and copy-paste friendly than these maps.

[dbaeumer]

The concerns you raised got addressed by our approach as well. During dev time there is no need to have any external translation files. You simply put the default / English strings into the source code. Then during build time vscode-nls-dev takes these strings out of the JS source code, rewrites the JS code and generates the json files.

I do see the point of already having translation files which forces to write another converter.

In general there is no enforcement to use vscode-nls for an extension. You can use our own nls mechanism as well if you want. All you need to honor is the VSCODE_NLS_CONFIG:"{"locale":"en-us","availableLanguages":{}}" env variable which describes the language picked by the VS Code editor for the user interface.