I18n with custom language code - max 8-character limit for language name

support
1

I am using a multi-lingual setup to create variants of a Hugo site.

After much debugging, it appears that there is an 8-character limit on the code/name that can be used for a language.

As an example:

baseURL = "http://example.org/"
defaultContentLanguage = "abcdefg"
title = "My New Hugo Site"

[languages]
  [languages.abcdefg]
    languageName = "abcdefg"
    title = "abcdefg"
    weight = 1
  [languages.abcdefgh]
    languageName = "abcdefgh"
    title = "abcdefgh"
    weight = 1
  [languages.abcdefghi]
    languageName = "abcdefghi"
    title = "abcdefghi"
    weight = 1

and the following files in the i18n directory: abcdefg.toml, abcdefgh.toml, abcdefghi.toml, running hugo -v produces the following info message:

INFO 2021/06/18 09:35:17 Translation func for language abcdefghi not found, use default.

Is this a known issue? Perhaps a note on the Hugo multi-lingual help page underneath the text that reads " From Hugo 0.31 you no longer need to use a valid language code. It can be anything." would be useful - it can’t be anything, it can be anything up to 8 characters

2

most sites use the short names for languages
see List of ISO 639-2 codes - Wikipedia
or the shorter ISO 639-1 - Wikipedia

if you use it - will never need 8 characters :wink:

1 Like
3

If you think that will help in the documentation then go to github and create a PR in the documentation site.

I for one wouldn’t define this as bug until I know that it is one which I don’t without knowing the content of your i18n directory. If there is no file about that language then that message is normal. If that file is not parseable then that message is normal. If your language setup has issues then that might also be a result.

The way I understand that message, that the “Language Code” can be anything, while still being in alignment with the ISO standard (which I don’t find right now, but it’s a nice number :wink: ). A language code is expected to be two characters at least, with maybe a dash and two or more characters. So abcdefg wouldn’t be a proper language code either. MY-abc would be probably…

Anyway. Prove that the language-slug (I guess we are talking about [languages.THISISTHELANGUAGECODE]) is limited to 8 characters, before you call it a bug, then add an issue if you think it should be allowed to be longer :wink:

Edit: ISO 639-1 is what I meant :slight_smile: Thanks @ju52

4

Understood, but this is specifically around custom language support

Screen Shot 2021-06-18 at 11.17.57 AM
Screen Shot 2021-06-18 at 11.17.57 AM701Ă—457 43.6 KB

5

I believe that’s what I was showing above - am I missing something? I’m not saying it’s a bug, it was just surprising behavior to me. The entire point of Custom language codes not support in multilingual setup · Issue #3564 · gohugoio/hugo · GitHub was to support “custom” language codes, so I was not aware of any limitation on those - length-based or otherwise.

Maybe I misinterpreted this statement “It can be anything.” - can it be anything that complies with RFC 5646?

6

best practices works best :wink:

https://www.rfc-editor.org/info/rfc5646