locale can be longer than just 2 letter code

[Crystal-RainSlide]

For this assertion:

mkdocs-git-revision-date-localized-plugin/mkdocs_git_revision_date_localized_plugin/plugin.py

Line 117 in 708128b

assert len(locale_set) == 2, "locale must be a 2 letter code, see https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes"

...and the way locale is used:

mkdocs-git-revision-date-localized-plugin/mkdocs_git_revision_date_localized_plugin/util.py

Line 9 in 708128b

from babel.dates import format_date, get_timezone

mkdocs-git-revision-date-localized-plugin/mkdocs_git_revision_date_localized_plugin/util.py

Line 72 in 708128b

"date": format_date(loc_revision_date, format="long", locale=locale),

mkdocs-git-revision-date-localized-plugin/mkdocs_git_revision_date_localized_plugin/js/timeago_mkdocs_material.js

Line 9 in 9747e59

timeago.render(nodes, locale);

...and the document of Babel and timeago:

• for Babel
• for timeago/timeago.js

Instead of just 2 letter code, locale also support longer format like en_US, or even:

• RFC3066 for Babel (date, datetime...),
• en_short .etc for timeago.

This assertion should be lifted, and document of this plugin may be changed accordingly, from ISO 639-1 to the document of Babel and timeago.

---

Change locale to locale: { default: en, babel: en_US, timeago: en_short } or:

locale: en
locale_babel: en_US
locale_timeago: en_short

... may also be considered.

[timvink]

Thanks for reporting this. I agree we should support this, using a 2-letter locale is an unnecessary simplification.

I'm thinking of writing a kind of validation function, that depending on the type validates the locale input. I would like to throw a helpful error message when a user has invalid input.

Separate locale input is also something to be considered. Great for developers that want to use multiple time formats in a theme, but also additional cognitive overhead for regular users.

Will give it some thought next time I work on this plugin. In the meantime I could remove the assertion if that helps your use-case?

[Crystal-RainSlide]

For me, I can just use JavaScript to change the strings afterwards, and I don't need to specify the sub-language tag right now, thus I'm not in a hurry.

The need is focused on pt_BR, zh_Hant / zh_HK / zh_TW and so on, as pt defaults to pt_PT, and zh defaults to zh_Hans / zh_CN.

[EDIflyer]

Agree would be good to change - I was trying using en-gb at first to get non-US date format but then realised only en was allowed 😉

[tooilxui]

It is recommended to remove this restriction first. This will be very helpful for Chinese-speaking countries. For us, it is the same as zh but there are more than three differences.

[jonaharagon]

Will give it some thought next time I work on this plugin. In the meantime I could remove the assertion if that helps your use-case?

@timvink This would help my use-case, my zh-Hant mkdocs-material site builds are now broken after #143 was fixed.

[tooilxui]

Will give it some thought next time I work on this plugin. In the meantime I could remove the assertion if that helps your use-case?

@timvink This would help my use-case, my zh-Hant mkdocs-material site builds are now broken after #143 was fixed.

@jonaharagon agree with you

/cc @timvink

[LorhanSohaky]

Any update? I'm trying to use pt-br