Gitea fails to start because of non-translated string

[ArchangeGabriel]

Description

On gitea service startup (using systemd):
Unable to register cron task update_migration_poster_id Error: translation is missing for task "update_migration_poster_id", please add translation for "admin.dashboard.update_migration_poster_id"
This fails the service start.

I’ve setup gitea with:

[i18n]
LANGS = fr-FR
NAMES = Français

Adding english makes it work.

I don’t think it should hard fail for a missing translated string…

Gitea Version

1.17.2

Operating System

Arch Linux

How are you running Gitea?

Systemd package using provided systemd service.

Database

PostgreSQL

[techknowlogick]

Thanks for this report, and all of the details you did, it is very appreciated.

That's an interesting fail condition, as i haven't been in the translation part of the code recently, but I believe things fall back to English since it has all of the translations, but by having only French I guess it has nothing to fall back to.

I guess if the translation isn't available we could just have it print the translation key, although that might run into issues with when we printf into the variables.

[ArchangeGabriel]

Those were exactly my thoughts (i.e. it likely falls back to English if possible, and currently fails if not), but not knowing gitea code base nor Go, I could not say whether falling back to the translation key was desirable. I should have mentioned all this in my first post. ^^

[wxiaoguang]

Some backgrounds here:

• The "default language": at the moment, the first language in the setting is used as "fallback language" and "UI default language" at the same time. If a language is used as a fallback language, then it's expected that it must contain all translations.
• The "fatal error for missing keys": in history, there are not only one issue reporting that the locale key is missing (especially for the tasks), so the cron task module checks its locale keys when initializing and reports fatal error (because nobody cares error logs if the program can run ....)

When these two mechanisms come together, and you set an incomplete translation as default language, then this issue happens.

Some possible solutions:

• Use a customized fr-FR locale file, or merge the missing keys from en-US into it on your side (a workaround without code change)
• Separate the "fallback language" and "UI default language" setting, instead of just using one "default language" setting
• When initialize the locale keys, always fill en-US keys first and then fill the default language keys
• (maybe more other mechanisms)

[wxiaoguang]

This PR #21200 implements solution 3