Workaround for permalink: false bug

[adamduncan]

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]

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]

@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]

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]

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