Make LLM translation of new UI strings a PR requirement, make Crowdin dependency - verification only

[dnch13]

What problem would this solve?

• New UI strings routinely ship untranslated across most of the 27 locales; Crowdin sync + human translation lag behind releases.
• Contributors can't complete translations inside their PR and rarely bother with Crowdin.

(if used in-IDE LLM, translation process would be times faster, if used chat with web-version, again times faster then waiting for crowdin, no missing translations would ever exist if proposal is accepted)

What do you propose?

Make in-PR, LLM-generated translations the optional pipeline instead of Crowdin (chat with good LLM is now available for anyone):

• Add the section below to AGENTS.md, so AI agents (Copilot, Claude, etc.) generate all translations whenever a PR adds/changes translatable strings, update CONTRIBUTE.md guide.
• Add a CI check that every locale file has the same keys as en-US — fail the PR otherwise.
• Crowdin, if kept at all, becomes optional post-hoc review, not a blocker.

---

My previous Issue was closed before several other important points had been stated (I would even say in an arrogant and barbaric manner), so I will just create a new issue, again, as I have stated before, because this particular PR can save A LOT of time for people, drastically simplifying the process of translating Gitea - the necessary tooling is available to anyone (the core idea here is to save time for the both developers and end-user, making translations more straightforward, concentrating on an attempt to save time for people, dropping personal judgment, solving problems, boosting karma - not ego).

Well, OK... My previous proposal was to drop Crowdin entirely (since frontier models like Mythos, Fable, GPT-5, GLM-5.3 generate translations with exceptional quality, the problem you stated is totally outdated; use available information, focus on a modern context). Next proposal: "Use Crowdin as a verification tool, keeping translation delivery synced with PRs".

Before you respond - I would additionally state that your reply should not necessarily be binary; think about the positive and negative consequences of each of your words (try to imagine different paths, weighed on scales, and think about which emotion leads you where; drop everything except a will to help people).

@techknowlogick @silverwind @KN4CK3R

[silverwind]

I agree that we off-board Crowdin and ship full AI-generated translations in the repo, which are more valuable than falling back to English. Those translation must be generated with enough context to be semantically correct, e.g. not throw only the JSON file towards the LLM without any context on how the text is used. Every text must be investigated in the places it is used.

I see no benefit of keeping Crowdin around, translation corrections should be done under review like all code changes which would probably slightly raise the review workload but I think acceptably.

[silverwind]

Also once we have all translations entirely in the repo, some more warts in the current translation system become easily fixable, for example:

• Semantic tags, e.g. replace <b>@%[1]s</b> pushed %[3]d commit to %[2]s with {user} pushed {num} commits to {branch}.
• Removal of HTML tags from translation strings.

The removal of the crowdin interaction frees us to basically adopt any translation system we like, ideally something popular that supports semantic tags.

[lunny]

Another solution is when a PR merged, an agent could read the commit merged and invoke crowdin API to provide a translation and translation approver just need to confirm or modify. Since the agent know more context than the crowdin internel ai, it should have a better translation result than before. If most the machine translation are right for some months, we could switch to the proposal process.

[dnch13]

@silverwind @lunny
Sounds good - i would suggest following approach: CI checks translations when they exist (filling - if not), while the agent may or may not act before. Keeping the fill-up step separate and optional means forks like Forgejo can still do it their own way. Not really familiar with gitea's CI-CD, but could help with part related to agent or add a makefile command to sort translations alphabetically, to keep sorted state in both repo and CI.