Samuel Stroschein

Great haha. This is an SDK issue (the position we are hiring)

We should probably drop support for yarn below v3. - sveltekit and other libs are dropping support - yarn

@ZerdoX-x Thanks again for the elaborate messages. I am in the moving to NYC process. Excuse my longer-than-usual reply times. It is key to understand that a) inlang is an...

I updated the inlang message format (v2) to by human editable, hopefully resolving this issue because the need for the json and i18next plugin does not exist anymore. See https://inlang.com/m/reootnfj/plugin-inlang-messageFormat

@ZerdoX-x namespace should still be supported. We are waiting for #1585 to be completed before we close this issue

cc @martin-lysk ids seem necessary. merge conflicts can not be automatically resolved without ids and neither can lint rules that report duplicates work reliably.

@herr-ahman what you describe can be implemented by importer/exporter plugins with #1585. But, we won't recommend it, and likely won't implement in plugins maintained by us. Naming keys is too...

> @martin-lysk I propose to make your example of duplicate variants a parse time error Clarification is sought on how users should fix duplicate variants in inlang apps when the...

@martin-lysk don't mix types and performance optimization for queries/storage ⚠️ We had a nesting of objects under language tags but refactored it. The code ergonomics were bad, and a potential...

I take that we agree. Another (killer) argument for the linting system is the possibility of adopting inlang for existing projects. We do not have a guarantee that existing projects...