Multilingual management for alerts

[ChipsVII]

As offer feeds can declare their own attributes and they don't have multilingual support, we could safely say that each feed is limited to one language. But we don't explicitely define it.

Offers are displayed thanks to a OffersList module, contained in a page itself in a root with specific language.

When executing the CRON to send alerts, we have no idea what language to use. An alert is linked to a single feed (for now), but it can be linked to multiple OfferList module, themselves can be linked to multiple pages in multiple different website roots. Unless the feed is linked to a notification with only one language, it is not possible to display the newly published offers in the right language directly in the email. The same goes for the unsubscribe link that should appear at the end of the message : the target page is referenced in the OffersList module, but we don't know which one to use.

Possible solutions :

• store current language in the alert when subscribing, so we know which language file to use to build the offers' details in the mail
• store module's id in the alert when subscribing, so we know which module to look for and get the right "unsubscribe" page URL in the mail (but if the id get used for another module, "oh dear, we are in trouble")

[ChipsVII]

@LupusVII I'd like your thought on that. As the only project using this bundle (for now) is fully in French, it is not yet a problem, but it might soon be.

[LupusVII]

Both solutions should fix those issues. This bundle should support multilingual features, but if we can handle that by doing one feed per language, it is good enough. After all, Contao has the same logic with the root pages. The one point that could be interesting would be to move the attributes' system outside the bundle logic, so we could use that elsewhere but time-consuming blablabla.

For your second point, maybe we should not have an unsubscribe module per se, but using subscribe module as an unsubscribe module if we have a valid token as an argument? So we can use your logic and never encounter the issue where the id is used for another module.

[ChipsVII]

For your second point, maybe we should not have an unsubscribe module per se, but using subscribe module as an unsubscribe module if we have a valid token as an argument? So we can use your logic and never encounter the issue where the id is used for another module.

The "unsubscribe" part is already contained in the "subscribe" menu 👌 I was more afraid of a user mistake/misbehavior, editing the module entry in backend and deciding that our "Offers Alert" module is now a "News List"/whatever