New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
martybr opened this Issue Oct 18, 2016 · 11 comments

Comments

Projects
None yet
4 participants
@martybr

martybr commented Oct 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 18, 2016

Member

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.

Member

bep commented Oct 18, 2016

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.

@bep bep added the Enhancement label Oct 18, 2016

@martybr

This comment has been minimized.

Show comment
Hide comment
@martybr

martybr Oct 18, 2016

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 }}

martybr commented Oct 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 18, 2016

Member

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.

Member

bep commented Oct 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@martybr

martybr Oct 18, 2016

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.

martybr commented Oct 18, 2016

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 bep added the Stale label Feb 28, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Feb 28, 2017

Member

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.

Member

bep commented Feb 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 1, 2017

Member

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.

Member

bep commented Mar 1, 2017

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.

@bep bep closed this Apr 9, 2017

@drupol

This comment has been minimized.

Show comment
Hide comment
@drupol

drupol May 2, 2017

I just lost a couple of days on this :(

drupol commented May 2, 2017

I just lost a couple of days on this :(

@bogem

This comment has been minimized.

Show comment
Hide comment
@bogem

bogem May 2, 2017

Contributor

So this issue should be actually reopened

Contributor

bogem commented May 2, 2017

So this issue should be actually reopened

@bogem bogem reopened this May 2, 2017

@bogem

This comment has been minimized.

Show comment
Hide comment
@bogem

bogem May 2, 2017

Contributor

I also lost whole day to find it.

Contributor

bogem commented May 2, 2017

I also lost whole day to find it.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep May 2, 2017

Member

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.

Member

bep commented May 2, 2017

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.

@bogem

This comment has been minimized.

Show comment
Hide comment
@bogem

bogem May 2, 2017

Contributor

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.

Contributor

bogem commented May 2, 2017

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.

bogem added a commit to bogem/hugo that referenced this issue May 2, 2017

@bogem bogem added Bug and removed Stale Enhancement labels May 2, 2017

@bep bep closed this in #3427 May 2, 2017

bep added a commit that referenced this issue May 2, 2017

@ghost ghost referenced this issue May 22, 2017

Open

spf13/hugo v0.21 released #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment