Add lang.HasTranslation

[bep]

Fixes #10538

[bep]

A quick note for the documentation:

While lang.Translate (and its aliases i18n and T), depending a little on the configuration, will often return something even if lang.HasTranslation returns false. For lang.HasTranslationto returntrue`, there needs to be an exact match for the given translation key/language.

And I think this PR should do the above.

/cc @regisphilibert @jmooring

[jmooring]

I am looking at this for the first time, so please be gentle...

It seems like the intent of this is to avoid falling back to the default language (currently always English due to #9216) when translating a string.

So you would do something like:

{{ if lang.HasTranslation "apple" }}
  {{ lang.Translate "apple" }}
{{ else }}
  {{ "apple (default)" }}
{{ end }}

Would it be easier to do this?

{{ or (lang.TranslateNoFallback "apple") "apple (default)" }}

Or disable falling back to the default language via site configuration? Then you could just do:

{{ or (T "apple") "apple (default)" }}

One of the drawbacks with the lang.HasTranslation approach is that hugo --printI18nWarnings will return nothing, so you would have to search through the code to find the missing translations. Additionally, the enableMissingTranslationPlaceholders in site configuration has no effect.

[bep]

Or disable falling back to the default language via site configuration?

I think you get a "best effort" language? My memory is ... hazy.

Oh, well ... I didn't read the original issue very well, I just had some urge to ... implement something.

{{ or (T "apple") "apple (default)" }}

I like that use of or.

But the thing is, if Hugo did a great job of finding a default, then this shouldn't be needed. I would think that in a 100 language Hugo site, I would prefer not having to manage this. And, as a Norwegian, I would be happy to get the Danish word for apple in the above example (which happens to be the same as in Norwegian: eple).

[regisphilibert]

Hi I agree lang.HasTranslation will not be broadly used. But it will be on projects with many languages which can neither afford to wait for a new key to be translated in every single languages before releasing, neither leave untranslated or placeholder strings laying around in production.

[jmooring]

@regisphilibert I am not suggesting that we don't do it. I am, however, suggesting a couple of alternative implementations that, to me, seem easier to use.

[regisphilibert]

Oh I see @jmooring sorry for misinterpreting that. So your suggestion is adding a no fallback alternative so we can test if empty? It seems a good approach indeed. lang.TranslateNoFallback