search

adamduncan / eleventy-plugin-i18n

Eleventy plugin to assist with internationalization and dictionary translations
MIT License
103 stars 10 forks source link

Workaround for permalink: false bug #11

Open adamduncan opened 3 years ago

adamduncan commented 3 years ago

Flagged by @unconfident in #4.

Existing implementation makes use of page.url to deduce locale. It was already a bit of a flimsy premise, but will throw an error if authors decide to permalink: false any pages (which is totally fair game in 11ty).

This doesn't solve #4 entirely, but will prevent the error in the meantime.

adamduncan commented 3 years ago

This got me thinking: If a user is going to permalink their article (in theory could be permalinked anywhere), then would one expect the contextLocale be the destination of that page (i.e. the page.url) as opposed to the source (page.fileStemPath)? Or does it make sense that the source file retains its intended locale in spite of where it ends up? What is your expected behavior?

adamduncan commented 3 years ago

@gremo suggested providing a function to determine the locale in the API (with a smart default). That might point us in a better direction, but not 100% on the API specifics just yet 🤔

gremo commented 3 years ago

I was not aware of the issue about permalink: false on pages.

I have used a lot of partials/includes, which doesn't generate pages, like the permalink: false option. For what I've seen, the page object is undefined or null (can't remember) here when you use the i18n filter.

I could be naive, but I can't see any problems. Like my PR, just try to guess the locale using the default strategy, eventually providing more strategies the user can choose. If page is undefined, fallback to some value.

adamduncan commented 3 years ago

0.1.2 has sailed with a more pressing fix. This whole using page data to sneakily get locale from url is a little iffy (as demonstrated by #12). I think it needs a rethink in the context of 11ty v1. Let's hold...