Move hardcoded links from translation to templates

[delvh]

trafficstars

Now, we can more easily change links as changing a link no longer invalidates all translations in other languages.

[silverwind]

The only issue with whole links is that the translator looses context and just sees %s, but I guess it's a minor one.

[delvh]

Yeah, I've thought about that as well. My best idea to combat this was not to introduce any spaces there, so that everyone knows wait, why is the text directly surrounded by these parameters?

[silverwind]

I think the last change with full links should be reverted. A translator wouldn't know what to do with Gitea runs anywhere %s can compile for and not even the translation key gives any hint.

[wolfogre]

One more question, what if we need different links for different languages?

I mean https://docs.gitea.com/installation/install-from-binary for locale_en-US.ini while https://docs.gitea.com/zh-cn/installation/install-from-binary for locale_zh-CN.ini.

I know we never did that, and most docs missed localization. But when we want to use a different link for a specific language, it is easy to apply or revert it: just update the translations on Crowdin instead of submitting a PR to update golang or template codes.

[wxiaoguang]

Sorry but I do not think it could do so directly at the moment.

All existing non-English translations would break, lead to incorrect template sentences.

The reason is the same: these keys/values would never be updated at crowdin side. Unless this could be done first: https://github.com/go-gitea/gitea/issues/27700#issuecomment-1771892952 , or use a new key for them.

[delvh]

I think the last change with full links should be reverted. A translator wouldn't know what to do with Gitea runs anywhere %s can compile for and not even the translation key gives any hint.

@lunny I'll let you discuss this with @silverwind. Tell me once you've reached an agreement

[delvh]

But when we want to use a different link for a specific language, it is easy to apply or revert it: just update the translations on Crowdin instead of submitting a PR to update golang or template codes.

I know we never did that, and most docs missed localization.

Hmm… Do we want to support hypotheticals? After all, if it was actually done, I'd agree. However, I'd say we have the opposite case: No one dares to change translations containing an outdated link as they know it will trigger the process of invalidating all these other translations. And so far, the link has changed a lot more often than it was translated into another URL. And as such, I'm more in favor of the proposed approach.

[delvh]

All existing non-English translations would break, lead to incorrect template sentences.

I don't understand, aren't outdated translations automatically invalidated and removed from the active pool of "having a translation"?

https://github.com/go-gitea/gitea/pull/29500#issuecomment-1972373997

I don't see how this blocks this PR? I didn't change any key itself, only the number of parameters within them.

[wxiaoguang]

All existing non-English translations would break, lead to incorrect template sentences.

I don't understand, aren't outdated translations automatically invalidated and removed from the active pool of "having a translation"?

IIRC no. So that's the real problem. See https://github.com/go-gitea/gitea/issues/27700#issuecomment-1771892952, at that time, the "outdated" didn't get "invalidated" or "removed"

[wxiaoguang]

Now the Crowdin sync works correctly, it could invalidate (remove) the outdated strings.

[wxiaoguang]

Stale for long time, and the new approach seems less maintainable:

{{ctx.Locale.Tr "startpage.license_desc"
  (SafeHTML `<a target="_blank" rel="noopener noreferrer" href="https://code.gitea.io/gitea">`) (SafeHTML `</a>`)
  (SafeHTML `<a target="_blank" rel="noopener noreferrer" href="https://github.com/go-gitea/gitea">`) (SafeHTML `</a>`)
}}