locale can be longer than just 2 letter code

[Crystal-RainSlide]

For this assertion:

https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/708128b1358d45da4aaa4629f4e1ca7df76a3236/mkdocs_git_revision_date_localized_plugin/plugin.py#L117

...and the way locale is used:

https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/708128b1358d45da4aaa4629f4e1ca7df76a3236/mkdocs_git_revision_date_localized_plugin/util.py#L9 https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/708128b1358d45da4aaa4629f4e1ca7df76a3236/mkdocs_git_revision_date_localized_plugin/util.py#L72 https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/9747e59c37d5969c5a99631677effe73f9c779c3/mkdocs_git_revision_date_localized_plugin/js/timeago_mkdocs_material.js#L9

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