I'm confused; why do we need to add this? (Also, even if we do this doesn't satisfy the "translate to croatian" issue it would close, so I think that may be misguided.)

OK I understand this is how we add languages now. Does the file need all the keeps and English phrases? It would be clearer to me that it was a template if it were empty, for example, and I assume the contents doesn't really matter as the keys and phrases to translate should come from the English source?

We currently have the option on Weblate set to not allow anyone to add arbitrary languages. Instead the admins get notified and this is how we heed the request.

You're right, we should probably reword the issue or just close it because the language is not guaranteed to actually end up in the next release. I just thought it might be nice to mention in the release notes if it does manage to get in.

I just thought it might be nice to mention in the release notes if it does manage to get in.

I agree; just not sure how to manage that except remembering to do it manually somehow.

If we added it with empty translations, Weblate would fill them in automatically anyway. And I think it is required for the fallback to English to work, no? Would the JS translation framework actually use a different language if the chosen one does not satisfy the requested term? Or does it fall back because we actually do have all untranslated strings in there with the English phrase?

So apparently it does fall back to English when the chosen language has no entry for the string. That actually allows us to use the JSON files more sensibly. To stay compatible with the way Transifex did things, I set it up to insert the English string for untranslated stuff. But actually not having the keys for untranslated strings in a language file at all makes more sense, as then the information what parts are translated and which strings just happen to be identical (like "LAN") can be deduced from looking at the JSON files alone. Right now this state is only available within Weblate's internal database.

I guess we can try what happens when adding this file simply as an empty JSON object. But we'll need to disable the auto-fill behavior on Weblate first. If that works, I guess we can remove untranslated entries from other language files as well in a follow-up. What do you think @calmh?

Honestly I think the exported files from Weblate should contain the English values for untranslated strings. It may be that we currently show the key if there is no matching entry for a given language, and that happens to be English, but ideally we'd have more machine readable keys and then that approach is bad.

It's just that in this manuever we're adding something where it looks like the keys/values might be relevant: "this is what should be translated", while adding an empty file (or empty json object) would better illustrate to me what's going on -- creating a placeholder for translation to be imported into...

I think you misunderstood. The GUI falls back to the "en" locale for keys not contained in the chosen language's JSON file. It does not show the key itself. Tested with the theme-name-dark key for example, when removing that from a language file, it will fall back to "Dark", the English translation.

This is probably the effect of:

As for the handling in Weblate, it is definitely cleaner to keep out untranslated strings. As it is right now, they will be added, but set to "needs-editing" state instead of what it should be, the "empty" state. It effectively pre-occupies the needs-editing state that otherwise would be available to mark "fuzzy" or "unsure" translations. Using that as intended would help when people want to search and filter stuff. E.g. to get the current set of strings without the English dummies, you'd use this filter:

state:>=translated OR (state:needs-editing AND NOT check:same)

where it should be only:

state:>empty

@calmh I didn't see your approval emoji on the last comment until now. Does that mean you're OK to go ahead and remove the untranslated strings from JSON files? I have a PR almost ready for it, would finish that if you approve.

Yes, sure