Add optional default value to language lang.Translate

[jmooring]

This is a common, or at least useful, construct:

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

Meaning, lookup the translation for "word", and if there isn't one, use "default" instead.This works great, but when you run hugo --printI18nWarnings you get:

WARN  i18n|MISSING_TRANSLATION|en|word
WARN  i18n|MISSING_TRANSLATION|de|word

In the construct above, we don't care that a translation does not exist... we've already handled that with a default value.

The current signature is:

lang.Translate KEY [CONTEXT]

Wondering about something like...

lang.Translate KEY [CONTEXT] [DEFAULT]

That's a bit wonky, because (theoretically) someone might want to pass a string as CONTEXT, though usually CONTEXT will be float, integer, or map. We could take the risk:

• If there are three args the last is the default.
• If there are two args, and the second is a string, it's the default. Although unlikely, this could break some sites, but I have no data to backup the risk estimate.

We can get the desired behavior by (a) mounting i18n to data and (b) creating a partial that uses site.Data to check for key existence before calling lang.Translate. But the translation call isn't nearly as elegant as {{ T "word" "default" }} or {{ T "word" 42 "default" }}.

If we do this, both of the following should ignore cases where a default value is specified:

1. --printI18nWarnings (must have)
2. enableMissingTranslationPlaceholders = true (nice to have)

---

Related:

• Add lang.HasTranslation #10538

[McShelby]

As already mentioned in the discourse:

That feature would be great!

I recently removed those warnings from my theme by a not very elegant workaround adding 6 lines of code for each occurance 😦

I can not say anything about the impact to other users but it would at least solve my hassle.

[bep]

In the construct above, we don't care that a translation does not exist...

That's a little bit of a bold statement. I think I would still care.

--printI18nWarnings (must have)

If we the new "default" thing suppressed these warnings, there's no way for me as a Norwegian theme user using a theme created by a Japanes theme author to know that there's untranslated "default" Japanese text in my UI.

If your theme has 20 translation IDs, how hard is it to put these into YAML/TOML compared to putting them directly into the template?

As an added foot note here, there maybe improvement potential here in the way we handle fallback translations (e.g. pick Swedish if Norwegian translation is missing).

[jmooring]

The use case that triggered this proposal is quite narrow: translating the text that appears when rendering a menu entry. There are several valid ways to translate this depending on how the menu entry is defined (automatically, in front matter, or in site config):

1. The name property
2. The page's linkTitle
3. The page's title
4. Using the i18n function with the menu entry's name, identifier, or keyName as the lookup key

I simply wanted a way to say: if there's a translation in the i18n table, use that instead. And do it without falling back to the default content language, and without triggering a warning.

Closing this in favor of lang.HasTranslation as proposed in #10538 and implemented in #10539.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.