Hey Stephen, Here is my proposed approach and some questions as I am working on the proposal for "Configurable Mail Footers".
The Implementation Approach I am planning on: 1. Update api_url to include $language as a placeholder and update get_template_data to accept it. With some preferred language -> English fallback inside Postorius, and 404 if English is also missing so Core continues up the list -> domain -> site chain. 2. Language will be optional so existing templates don't break. 3. A dedicated footer editor at list, domain, and site level with a language selector, plain textarea and reset-to-default. Live preview might be a stretch goal. 4. Tests for the fallback chain and permissions along with user documentation Here are a few questions I have: 1. Should the preferred language -> English fallback happen inside Postorius, or should core handle it? 2. Existing templates have an empty language field. Should empty mean English/default, or language-agnostic? This affects how we handle the unique constraint when new language-specific records are added alongside old ones. 3. A registered URL silently overrides any filesystem template the moment it is saved. Should the editor warn the admin when this is about to happen? 4. Should the new dedicated footer editor remove footers from the generic template dropdown to avoid confusion, or keep both working in parallel? Thank you Sambodhi _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
