i18n translation not working if "id" and "translation" are equal

[martybr]

Example en.yaml:
Working:

- id: "recent_blogs"
  translation: "Recent Blogs"
- id: "month_january"
  translation: "January"

Not working (translations are not found anymore, checked with --i18n-warnings):

- id: "Recent Blogs"
  translation: "Recent Blogs"
- id: "January"
  translation: "January"

Using: Hugo Static Site Generator v0.17

[bep]

It is by design, but I have also been bitten by this. The trick is to use some kind of name pattern for the ids that doesn't make sense as a text.

Not sure we're gonna fix this (or how), but I will keep it open.

[martybr]

If it is fixed it makes things like translating months a bit easier by just doing this (since we don't have i10n yet):
{{ i18n .Date.Month.String }}

[bep]

The problem is that the library in use returns the id on missing translation, and we use that to detect missing translations.

{{ i18n (printf "m%d" .Date.Month) }}

Isn't much harder.

[martybr]

The library follows the "GNU gettext" implementation. When a translation is not found it returns the original text. I.e. it assumes the untranslated text is the default language used.

Perhaps it is possible let the DefaultContentLanguage variable state if the text needs to be translated or not. I.e. if the DefaultContentLanguage is English and the content is also in English then it is OK to just return the text. If the DefaultContentLanguage differs from the current content language then use it to detect missing translations. However this is not fully foolproof, for example the Dutch word "bank" also translates to "bank" in English, creating the same problem again :(

I see 3 possibilities:

• Only use id's which are always different from the translated text and let Hugo check for missing translations on the fly (current solution)
• Let it be the responsibility of the user to correctly provide translation files (least difficult to implement but does not help users searching for untranslated text)
• Let Hugo check the i18n files for missing translations and report those, simular to a gettext a PO-editor which performs such a check (perhaps a bit difficult to implement)

For now I stick with using unique ID's. Thanks for the heads up using the months variable.

[bep]

This issue has been automatically marked as stale because it has not been commented on for at least four months.

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

This issue will automatically be closed in four months if no further activity occurs. Thank you for all your contributions.

[bep]

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

[drupol]

I just lost a couple of days on this :(

[n10v]

So this issue should be actually reopened

[n10v]

I also lost whole day to find it.

[bep]

I just lost a couple of days on this :(

Please don't take that tone in here as it is demotivating for the people who spend ... more than a couple of days to work on this project. This behaviour is by design; yes, it could be improved, but it should be fairly easy to understand what happens if you experience it.

[n10v]

Here was the discussion: https://discuss.gohugo.io/t/language-selector-using-language-names-translated/6401/10
I just found a fix. I will post a PR in one sec.

[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.