multilingual: Tagalog (tl) parsed to Filipino (fil)

[kpietron]

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.123.8-5fed9c591b694f314e5939548e11cc3dcb79a79c+extended linux/amd64 BuildDate=2024-03-07T13:14:42Z VendorInfo=snap:0.123.8

Does this issue reproduce with the latest release?

Yes

Description:

Despite meticulously following the recommended configuration steps provided in the documentation, I have encountered unexpected behavior with Hugo's handling of the Tagalog language. Specifically, Hugo fails to recognize the Tagalog language when configured with the provided settings:

[languages.tl]
languageCode = "tl"
languageName = "Tagalog"
weight = 18

[[module.mounts]]
source = 'content'
target = 'content'
lang = 'tl'

Reproduction Steps:

1. Configure Hugo with the provided Tagalog language settings.
2. Attempt to utilize Tagalog content on the website.

Expected Outcome:

I expected Hugo to seamlessly recognize and render content in the Tagalog language according to the configured settings.

Current Outcome:

However, despite rigorous troubleshooting, Hugo consistently fails to recognize the Tagalog language (tl). Instead, it loads default English translations. Intriguingly, changing the language identifier to an alternative value, such as xxx, resolves the issue, indicating that the problem may be specific to the tl language identifier.

[jmooring]

Confirmed. This isn't anything new; tested as far back as v0.76.0. Minimal reproducible example:

git clone --single-branch -b hugo-github-issue-12252 https://github.com/jmooring/hugo-testing hugo-github-issue-12252
cd hugo-github-issue-12252
hugo server

When running hugo --logLevel info...

INFO Translation func for language tl not found, use default.

Go's language package resolves tl to fil (see https://go.dev/play/p/tw0ydFlH09E).

[jmooring]

@kpietron Given that (a) Go resolves resolves tl to fil, and (b) there is localization support (dates, currencies, numbers, percentages, collation) for fil but not for tl, I recommend the following:

config

[languages.en]
contentDir = 'content/en'
languageCode = 'en-US'
languageDirection = 'ltr'
languageName = 'English'
weight = 1

[languages.fil]
contentDir = 'content/fil'
languageCode = 'fil-PH'
languageDirection = 'ltr'
languageName = 'Filipino'
weight = 2

content

content/
├── en/
│   └── _index.md
└── fil/
    └── _index.md

translation tables

i18n/
├── en.toml
└── fil.toml

The alternative, which would allow translations but not localization, is to name the translation using an artificial language tag:

i18n/
├── art-x-tl.toml
└── en.toml

I would not do this.

[kpietron]

The problem is that "Filipino" doesn't have an ISO 639-1 code. But when it comes to official standards, you have to use ISO 639-1 for the language code. So we can't use ISO 639-2 (FIL) because it's wrong. The only language code in ISO 639-1 is "TL," which is called Tagalog. I used an alternative solution and renamed the file to art-x-tl.toml, the translations now work, but I would like to have full support for this language.

[jmooring]

But when it comes to official standards, you have to use ISO 639-1 for the language code.

That may be true in your particular circumstance, but BCP 47 (and by extension RFC 5646) supports ISO 639-1, ISO 639-2, ISO 639-3, and ISO 639-5.

Regardless, this is an upstream issue with Go's language package... I will raise a question there.

See https://github.com/golang/go/issues/66335

[jmooring]

Won't fix. See https://github.com/golang/go/issues/66335#issuecomment-2001974760. Behavior is ultimately governed by the Unicode Consortium, which aliases tl to fil with a given reason of "legacy".

[github-actions[bot]]

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.