cleanup: move old filtering and i18n documents

docs/filtering/Claude-TODO-V2.md

···
-# Next Steps for Complete i18n Integration
-
-**Status**: Template Rendering System Refactoring ✅ **COMPLETE**  
-**Next Phase**: Template Migration & Full i18n Implementation  
-**Project**: smokesignal (Event & RSVP Management)  
-**Date**: May 31, 2025
-
----
-
-Reference documentation:
-* https://github.com/XAMPPRocky/fluent-templates
-* https://docs.rs/fluent/latest/fluent/all.html
-* https://docs.rs/minijinja/latest/minijinja/all.html
-
-
-## Executive Summary
-
-The foundational i18n infrastructure is now complete with a unified `TemplateRenderer` system successfully implemented. All 16+ compilation errors have been resolved, and the application now has a modern, centralized template rendering architecture. The next phase focuses on migrating existing templates to fully utilize the i18n system and creating comprehensive language support.
-
-## Current State ✅ COMPLETED
-
-### ✅ Core Infrastructure 
-- **fluent-templates Integration**: Static loading with zero runtime overhead
-- **TemplateRenderer System**: Unified template rendering with automatic context enrichment
-- **I18n Template Functions**: `tr()`, `current_locale()`, `has_locale()` available in templates
-- **HTMX Integration**: Smart template selection (partial, bare, full)
-- **Gender Support**: Full French Canadian gender variant handling
-- **Error Handling**: Consistent error templates with context preservation
-- **Handler Modernization**: All HTTP handlers converted to TemplateRenderer API
-
-### ✅ Files Structure
-- **Templates**: 70+ English-only templates (`.en-us.html` variants)
-- **Fluent Files**: Complete English and French Canadian .ftl files
-- **Template Functions**: Ready for use (`tr()`, gender context, locale detection)
-- **Build System**: Compilation working, all tests passing
-
- # 🎯 i18n Migration Completion Summary
- ==================================
- 
- ✅ **PHASE 1 COMPLETED**: Template Migration
-    All hardcoded text converted to i18n functions
-    All templates using dynamic locale references
- 
- ✅ **PHASE 2 COMPLETED**: i18n System Fixes
-    📦 fluent-templates API compatibility fixed
-    🔧 i18n testing tool updated and working
-    🗂️  Duplicate translation keys removed systematically
- 
-    **Phase 3 COMPLETED : French Template Creation**
-
-
- **DUPLICATE KEYS RESOLVED:**
- 📝 Removed from English & French ui.ftl:
-    - view-event, status-*, mode-*, login-*, import-*
-    - location-cannot-edit, pagination-*, location
-    - tooltip duplicates (tooltip-planned, etc.)
- 
- 📝 Removed from English & French common.ftl:
-    - save, remove, view, clear, edit, close
-    - update-event, confirm
- 
- 📝 Removed from English & French ui.ftl:
-    - button-edit
- 
- **CLEAN FILE ORGANIZATION:**
- 🎯 actions.ftl → Action buttons and commands
- 🎯 common.ftl → Common UI elements and navigation
- 🎯 forms.ftl → Form-related translations
- 🎯 ui.ftl → Page-specific UI content
- 🎯 errors.ftl → Error messages and validation
- 
- **SYSTEM STATUS:**
- ✅ fluent-templates static loader working
- ✅ No duplicate key conflicts
- ✅ English and French Canadian locales functional
- ✅ i18n testing tool operational
- ✅ Template rendering with locale context
- 
- Summary of Completed Migration
-I have successfully completed the migration of all HTTP handlers to the new i18n renderer system. Here's what was accomplished:
-
-✅ Major Issues Fixed:
-Template Context Spread Operator Issues: Removed ..default_context spread syntax and replaced with explicit context variables in template_context! macros
-Contextual Error Macro Migration: Updated all contextual_error! calls from old syntax with StatusCode parameters to new simplified syntax
-Handle to String Conversion: Fixed all Handle to &str conversion issues by accessing the .handle field
-Return Type Mismatches: Converted tuple returns (StatusCode, Response) to direct Response returns
-Try Trait Issues: Removed ? operator from render_template calls since they return Response directly
-Missing Error Types:
-Replaced non-existent AdminError::SelfTermination with CommonError::NotAuthorized
-Replaced non-existent CommonError::AccessDenied with CommonError::NotAuthorized
-Borrow/Move Issues: Fixed by cloning context values before passing to renderers
-Language Type Conversions: Added proper .clone() calls for LanguageIdentifier types
-Template Renderer Migration: Replaced select_template! macro with create_renderer! macro
-✅ Files Successfully Migrated:
-handle_create_event.rs - Fixed template context spread and language cloning
-handle_edit_event.rs - Fixed return types, Handle conversions, and Try trait issues
-handle_oauth_login.rs - Fixed missing imports and error type variants
-handle_profile.rs - Fixed Handle to Option<&str> conversions and borrow issues
-handle_view_event.rs - Fixed return types and Handle conversions
-handle_admin_handles.rs - Fixed error types and template renderer migration
-handle_admin_denylist.rs - Fixed field access and borrow issues
-handle_admin_rsvp.rs - Fixed Language conversions and Handle to &str issues
-handle_admin_rsvps.rs - Fixed Handle conversions and Try trait issues
-handle_admin_event.rs - Fixed Handle conversions (from earlier sessions)
-handle_migrate_event.rs - Removed unused imports
-✅ Key Architectural Changes:
-Consistent Error Handling: All handlers now use the new contextual_error! macro syntax
-Unified Template Rendering: All handlers use the create_renderer! macro with proper i18n context
-Proper Type Safety: Fixed all type conversion issues between Handle types and string references
-Clean Response Types: All handlers return proper Response types instead of tuples
-Resource Management: Fixed all borrow/move issues with proper cloning strategies
-✅ Build Status:
-All compilation errors resolved: ✅
-Clean build with no warnings: ✅
-Ready for testing: ✅
-The entire codebase now uses the new i18n renderer system consistently, providing better internationalization support and cleaner error handling across all HTTP handlers.
-
-## Remaining Work 🚧 TODO
-
-
-
-
-### Phase 5: Testing & Quality Assurance
-**Priority**: HIGH | **Effort**: Medium | **Impact**: Critical
-
-#### 5.1 Ample logging to help debug 
-- fluent is fragile and expect perfect bundles without duplication or errors.
-- Add detailed logging at bundle loading time to help debug template or ftl dev. 
-
-#### 5.2 FTL test tool 
-- FTL Language files NEEDS TO not have duplicates between them for the same locale. 
-- It should give the option to keep one of the duplicate and detele the others
-- Compare FTL files between locales to find discrepancies.
-- https://docs.rs/fluent/latest/fluent/bundle/index.html
-
-#### 5.3 Comprehensive i18n Testing
-**Test Coverage Needed**:
-- Template rendering in both languages
-- Gender context switching (French)
-- Language preference detection
-- HTMX partial rendering with i18n
-- Error messages in correct language
-- Form validation in both languages
-
-#### 5.3 Language Switching Testing
-**Scenarios**:
-- Browser language detection
-- Cookie preference persistence
-- User profile language settings
-- HTMX header language passing
-- Fallback behavior (missing translations)
-
-#### 5.4 Form Validation Integration
-- Test locale propagation when making HTMX partial templates updates in forms results. 
-**Needed**: Ensure form errors display in correct language
-
-**Current State**: Basic error translation works  
-**Enhancement**: Context-aware validation messages and updates 
-
-### Phase 6: Performance & Optimization
-**Priority**: LOW | **Effort**: Low | **Impact**: Medium
-
-#### 6.1 Template Caching
-**Current**: Templates loaded on every request  
-**Optimization**: Implement template compilation caching
-
-#### 6.2 Translation Performance
-**Current**: fluent-templates static loading (already optimized)  
-**Monitoring**: Add performance metrics for translation lookups
-
----
-
-## Implementation Plan
-
-### Sprint 1 (Week 1-2): Core Template Migration
-1. **Day 1-3**: Audit all templates, create comprehensive translation key list
-2. **Day 4-7**: Update navigation and base templates with i18n functions
-3. **Day 8-10**: Migrate form templates (create_event, edit_event, etc.)
-4. **Day 11-14**: Complete remaining content templates
-
-### Sprint 2 (Week 3-4): Translation & French Templates  
-1. **Day 1-7**: Complete English fluent files with all extracted keys
-2. **Day 8-14**: Professional French Canadian translation of all keys
-3. **Day 8-14**: Create French template variants (parallel with translation)
-
-### Sprint 3 (Week 5): Testing & Integration
-1. **Day 1-3**: Comprehensive testing of both language variants
-2. **Day 4-5**: Handler integration verification and fixes
-3. **Day 6-7**: Performance testing and optimization
-
-### Sprint 4 (Week 6): Launch Preparation
-1. **Day 1-3**: Final testing and bug fixes
-2. **Day 4-5**: Documentation and deployment preparation
-3. **Day 6-7**: Production deployment and monitoring
-
----
-
-## Technical Specifications
-
-### Template Function Usage Patterns
-
-#### Basic Translation
-```html
-{{ tr("ui-welcome") }}
-{{ tr("form-submit") }}
-```
-
-#### Parametrized Translation
-```html
-{{ tr("event-count", count=events|length) }}
-{{ tr("welcome-user", username=current_handle.username) }}
-```
-
-#### Gender-Aware Translation (French)
-```html
-{{ tr("welcome-message", gender=user_gender) }}
-{{ tr("user-status", gender=user_gender, status=current_status) }}
-```
-
-#### Conditional Language Display
-```html
-{% if current_locale() == "fr-ca" %}
-  <!-- French-specific content -->
-{% endif %}
-```
-
-### File Naming Conventions
-
-#### Templates
-- English: `{template}.en-us.html`
-- French: `{template}.fr-ca.html`
-- Language-neutral: `{template}.html` (no language suffix)
-
-#### Fluent Files
-- `i18n/en-us/*.ftl` (English US)
-- `i18n/fr-ca/*.ftl` (French Canadian)
-
-### Translation Key Organization
-
-#### Prefixes
-- `ui-*`: User interface elements (buttons, labels, navigation)
-- `form-*`: Form labels, placeholders, validation messages  
-- `error-*`: Error messages and alerts
-- `action-*`: Action buttons and links
-- `page-*`: Page titles and headings
-- `admin-*`: Admin interface specific
-- `event-*`: Event-related content
-- `rsvp-*`: RSVP-related content
-
----
-
-## Success Criteria
-
-### Functional Requirements ✅
-- [ ] All templates use i18n functions instead of hardcoded text
-- [ ] Complete English and French Canadian translation coverage
-- [ ] Language switching works across all pages
-- [ ] Gender-aware translations work correctly in French
-- [ ] HTMX requests maintain language context
-- [ ] Error messages display in correct language
-- [ ] Form validation messages localized
-
-### Performance Requirements ✅
-- [ ] Page load time impact < 50ms
-- [ ] Translation lookup time < 1ms
-- [ ] Template rendering performance maintained
-- [ ] Memory usage increase < 10%
-
-### Quality Requirements ✅
-- [ ] Zero missing translation keys in production
-- [ ] All translations culturally appropriate
-- [ ] Gender agreement correct in French variants
-- [ ] Consistent terminology across all content
-- [ ] Accessibility maintained in both languages
-
----
-
-## Dependencies & Blockers
-
-### External Dependencies
-- **Translation Services**: Professional French Canadian translator
-- **Cultural Review**: French Canadian cultural/linguistic review
-- **Testing Resources**: Native French speakers for testing
-
-### Technical Dependencies
-- ✅ fluent-templates integration (COMPLETE)
-- ✅ TemplateRenderer system (COMPLETE)
-- ✅ HTMX i18n integration (COMPLETE)
-- ✅ Gender context system (COMPLETE)
-
-### Potential Blockers
-- **Translation Quality**: Professional translation availability
-- **Cultural Accuracy**: French Canadian cultural review
-- **Testing Coverage**: Comprehensive bilingual testing
-
----
-
-## Risk Assessment
-
-### High Risk 🔴
-- **Incomplete Translations**: Missing keys break user experience
-- **Cultural Issues**: Inappropriate French translations damage credibility
-
-### Medium Risk 🟡
-- **Performance Impact**: Extensive template changes affect load times
-- **HTMX Integration**: Language switching breaks dynamic functionality
-
-### Low Risk 🟢
-- **Template Syntax**: Minor template function usage issues
-- **Key Organization**: Suboptimal translation key structure
-
----
-
-## Conclusion
-
-The smokesignal application has successfully completed the foundational i18n infrastructure migration. The new `TemplateRenderer` system provides a robust, high-performance foundation for internationalization. The next phase focuses on content migration and comprehensive language support implementation.
-
-**Immediate Priority**: Begin template content migration (Phase 1) to convert hardcoded strings to i18n function calls.
-
-**Success Metrics**: 
-- 100% template i18n function usage
-- Complete English/French language coverage  
-- Maintained performance and user experience
-- Professional-quality translations
-
-**Timeline**: 6 weeks for complete implementation
-**Status**: Ready to begin implementation ✅
-
----
-
-*This document will be updated as implementation progresses through each phase.*

docs/filtering/FILTERING_PHASE1_GUIDE.md

···
-# Event Filtering System - Phase 1 Implementation Guide
-
-## Overview
-This document serves as a comprehensive guide for implementing Phase 1 of the event filtering system for the smokesignal-eTD application. It contains detailed architectural decisions, implementation strategies, and critical fixes that were identified during initial development attempts.
-
-## Phase 1 Objectives 🎯
-
-### 1. Core Architecture Implementation
-- **Complete filtering module structure** with proper separation of concerns
-- **Dynamic SQL query builder** with flexible parameter binding
-- **Faceted search capabilities** for data exploration
-- **Event hydration system** for enriching filter results
-- **Comprehensive error handling** throughout the filtering pipeline
-
-### 2. HTTP Integration
-- **Middleware layer** for extracting filter parameters from requests
-- **RESTful API endpoints** for both full page and HTMX partial responses
-- **Template-based rendering** with internationalization support
-- **Progressive enhancement** using HTMX for real-time filtering
-
-### 3. Database Optimization
-- **Performance-focused indexes** including spatial and full-text search
-- **Composite indexes** for multi-field filtering scenarios
-- **Automatic triggers** for maintaining derived data consistency
-- **PostGIS integration** for location-based filtering
-
-### 4. Code Quality
-- **Resolve all compilation errors** (excluding DATABASE_URL dependency)
-- **Clean up unused imports** to reduce warnings
-- **Type safety improvements** with proper lifetime management
-- **Documentation coverage** for all public interfaces
-
-## Recommended Technical Architecture
-
-### Core Filtering Architecture
-
-#### Module Structure
-```
-src/filtering/
-├── mod.rs              # Module exports and organization
-├── query_builder.rs    # Dynamic SQL construction
-├── service.rs          # Main filtering coordination
-├── facets.rs           # Facet calculation logic
-├── hydration.rs        # Event data enrichment
-├── errors.rs           # Error handling types
-└── criteria.rs         # Filter criteria definitions
-```
-
-#### Key Components Design
-
-**QueryBuilder** (`query_builder.rs`)
-- Dynamic SQL generation with parameter binding
-- Support for text search, date ranges, location filtering
-- Pagination and sorting capabilities
-- Lifetime-safe implementation preventing memory issues
-
-**FilteringService** (`service.rs`)
-- Coordinates between query builder, facet calculator, and hydrator
-- Manages database transactions and error handling
-- Provides clean async interface for HTTP layer
-
-**FacetCalculator** (`facets.rs`)
-- Generates count-based facets for filter refinement
-- Supports categorical and range-based facets
-- Efficient aggregation queries for large datasets
-
-**EventHydrator** (`hydration.rs`)
-- Enriches events with related data (locations, contacts, etc.)
-- Batch processing for performance optimization
-- Flexible hydration strategies based on use case
-
-### HTTP Layer Integration
-
-#### Middleware (`middleware_filter.rs`)
-- Extracts filter parameters from query strings and form data
-- Validates and normalizes input data
-- **Important**: Use concrete types instead of generics for Axum compatibility
-
-#### Handlers (`handle_filter_events.rs`)
-- Full page rendering for initial requests
-- HTMX partial responses for dynamic updates
-- **Important**: Ensure RenderHtml import is included
-
-### Database Schema
-
-#### Migration (`20250530104334_event_filtering_indexes.sql`)
-Recommended indexing strategy:
-- **GIN indexes** for JSON content search
-- **Spatial indexes** using PostGIS for location queries
-- **Composite indexes** for common filter combinations
-- **Automatic triggers** for maintaining location points
-
-### Template System
-
-#### Required UI Implementation
-- **Main filtering page** (`filter_events.en-us.html`)
-- **Reusable filter components** (`filter_events.en-us.common.html`)
-- **Results display** (`filter_events_results.en-us.incl.html`)
-- **Minimal layout** (`filter_events.en-us.bare.html`)
-
-#### Features to Include
-- Responsive design using Bulma CSS framework
-- Real-time filtering with HTMX
-- Internationalization support (English/French Canadian)
-- Progressive enhancement for accessibility
-
-## Critical Fixes to Apply
-
-### 1. Middleware Type Constraint
-**Problem**: Generic type `B` in middleware signature causes compilation errors
-```rust
-// Avoid (causes errors)
-pub async fn filter_config_middleware<B>(req: axum::http::Request<B>, ...)
-
-// Use instead
-pub async fn filter_config_middleware(req: axum::http::Request<axum::body::Body>, ...)
-```
-
-### 2. QueryBuilder Lifetime Issues
-**Problem**: `'static` lifetimes cause borrowing conflicts with dynamic parameters
-```rust
-// Avoid (causes errors)
-fn apply_where_clause(&self, query: &mut QueryBuilder<'static, sqlx::Postgres>, ...)
-
-// Use instead
-fn apply_where_clause<'a>(&self, query: &mut QueryBuilder<'a, sqlx::Postgres>, ...)
-```
-
-### 3. Missing Imports
-**Problem**: `RenderHtml` trait not imported in handler module
-```rust
-// Required import
-use axum_template::RenderHtml;
-```
-
-### 4. Unused Import Cleanup
-Common unused imports to remove:
-- `std::collections::HashMap` from filtering modules
-- Unused Redis and serialization imports
-- Redundant Axum imports in middleware
-
-## Performance Considerations
-
-### Database Optimization
-- **Index all filterable fields** to ensure sub-second query response
-- **Composite indexes** for common multi-field queries
-- **Spatial indexing** for efficient location-based searches
-- **JSON indexing** for flexible content search
-
-### Query Efficiency
-- **Parameterized queries** prevent SQL injection and improve caching
-- **Batch hydration** reduces N+1 query problems
-- **Selective field loading** based on hydration requirements
-- **Pagination** to handle large result sets
-
-### Caching Strategy (For Future Implementation)
-- **Redis integration** for facet and query result caching
-- **Cache invalidation** hooks for data consistency
-- **Configurable TTL** for different cache types
-
-## Testing Strategy
-
-### Unit Tests (Framework to Implement)
-- QueryBuilder SQL generation validation
-- Facet calculation accuracy
-- Hydration logic correctness
-- Error handling coverage
-
-### Integration Tests (Framework to Implement)
-- End-to-end filtering workflows
-- Database query performance
-- Template rendering accuracy
-- HTMX interaction validation
-
-## Internationalization
-
-### Localization Files to Extend
-- **English** (`i18n/en-us/ui.ftl`): Complete filtering terminology
-- **French Canadian** (`i18n/fr-ca/ui.ftl`): Full translation coverage
-- **Template integration** using Fluent localization system
-
-### Target Languages
-- `en-us`: English (United States)
-- `fr-ca`: French (Canada)
-- Framework ready for additional languages
-
-## Security Considerations
-
-### SQL Injection Prevention
-- All queries must use parameterized statements
-- User input validation at multiple layers
-- Type-safe parameter binding
-
-### Input Validation
-- Comprehensive validation of filter criteria
-- Sanitization of text search terms
-- Range validation for dates and numbers
-
-### Access Control (For Future Implementation)
-- Authentication hooks integration points
-- Authorization integration points
-- Rate limiting preparation
-
-## Implementation Roadmap
-
-### Phase 1A: Core Foundation
-1. **Set up filtering module structure**
-2. **Implement basic QueryBuilder with proper lifetimes**
-3. **Create FilteringService coordination layer**
-4. **Resolve compilation errors** with proper type constraints
-
-### Phase 1B: Database Integration
-1. **Configure DATABASE_URL** for sqlx macro compilation
-2. **Create and run filtering indexes migration**
-3. **Implement and test basic query functionality**
-4. **Add facet calculation capabilities**
-
-### Phase 1C: HTTP Layer
-1. **Implement middleware with concrete types**
-2. **Create handlers with proper imports**
-3. **Build template structure**
-4. **Add HTMX integration**
-
-### Phase 1D: Testing & Validation
-1. **Unit test implementation** for all filtering components
-2. **Integration test suite** for end-to-end workflows
-3. **Performance validation** with realistic datasets
-4. **UI/UX testing** for accessibility and usability
-
-## Next Steps (Phase 2 Preparation)
-
-### Production Readiness
-1. **Redis caching implementation** for performance optimization
-2. **Monitoring and observability** integration
-3. **Error tracking** and alerting setup
-4. **Performance profiling** and optimization
-
-### Feature Enhancements
-1. **Saved filters** for user convenience
-2. **Filter sharing** via URL parameters
-3. **Export capabilities** for filtered results
-4. **Advanced search operators** (AND/OR logic)
-
-## Architectural Benefits
-
-### Maintainability
-- **Clear separation of concerns** between layers
-- **Modular design** allowing independent component evolution
-- **Comprehensive documentation** for future developers
-- **Type safety** preventing runtime errors
-
-### Scalability
-- **Async/await throughout** for high concurrency
-- **Database connection pooling** ready
-- **Caching layer prepared** for performance scaling
-- **Horizontal scaling friendly** architecture
-
-### Extensibility
-- **Plugin-ready facet system** for new filter types
-- **Flexible hydration strategies** for different use cases
-- **Template inheritance** for UI customization
-- **Internationalization framework** for global deployment
-
-## Conclusion
-
-This guide provides the complete roadmap for implementing Phase 1 of the event filtering system. The architecture has been designed for:
-
-- 🎯 **Robust filtering capabilities** with comprehensive search features
-- 🔒 **Type-safe Rust implementation** with proper error handling
-- 🎨 **Modern web UI** with progressive enhancement
-- 🌍 **Internationalization support** for multiple locales
-- ⚡ **Performance optimization** through strategic indexing
-- 🛡️ **Security best practices** throughout the stack
-
-Follow this guide to build a production-ready filtering system that will integrate seamlessly with the smokesignal-eTD application.
-

docs/filtering/FILTERING_PHASE4_I18N_PLAN.md

···
-# Event Filtering System - Phase 4: I18n Integration Plan
-
-## Overview
-
-Phase 4 integrates the existing event filtering system with the i18n infrastructure, enabling locale-aware facet calculation, template rendering with dynamic translation functions, and HTMX-aware language propagation.
-
-**Status**: Ready for Implementation ✅  
-**Prerequisites**: Phase 1-3 Complete, I18n Infrastructure Complete  
-**Estimated Effort**: 2-3 days  
-
----
-
-## Current State Analysis
-
-### ✅ Infrastructure Ready
-
-#### I18n System
-- **fluent-templates static loader**: Fully implemented and working
-- **Template functions**: `t()`, `tg()`, `current_locale()`, `has_locale()` already available
-- **HTMX middleware**: Language detection with proper priority order implemented
-- **Gender support**: French Canadian gender variants working
-
-#### Filtering System
-- **Phase 1**: Core filtering, query builder, facets, hydration complete
-- **Phase 2**: Facet calculation and event hydration complete
-- **Phase 3**: Redis cache integration complete
-- **Templates**: Language-specific templates exist (`.en-us.html`, `.fr-ca.html`)
-
-#### Translation Keys
-- **Basic filter keys**: Most UI strings already translated in `i18n/*/ui.ftl`
-- **Missing**: Facet-specific translation keys for dynamic content
-
-### 🔧 Implementation Needed
-
-1. **Facet Translation Keys**: Add missing keys for category/date range facets
-2. **Locale-Aware Facet Calculation**: Pass locale context to facet calculators
-3. **Template Migration**: Update templates to use i18n functions instead of pre-rendered text
-4. **Service Integration**: Connect filtering service with locale from middleware
-5. **HTMX Language Headers**: Ensure facet updates propagate language correctly
-
----
-
-## Implementation Tasks
-
-### Task 1: Add Missing Translation Keys
-
-#### 1.2 Date Range Facet Keys
-Add date range translation keys:
-
-**File**: `/i18n/en-us/ui.ftl`
-```fluent
-# Date range facets
-date_range.today = Today
-date_range.this_week = This Week  
-date_range.this_month = This Month
-date_range.next_week = Next Week
-date_range.next_month = Next Month
-```
-
-**File**: `/i18n/fr-ca/ui.ftl`
-```fluent
-# Facettes de plage de dates
-date_range.today = Aujourd'hui
-date_range.this_week = Cette semaine
-date_range.this_month = Ce mois
-date_range.next_week = La semaine prochaine
-date_range.next_month = Le mois prochain
-```
-
-#### 1.3 Additional Facet UI Keys
-Extend existing filter keys for facet display:
-
-**File**: `/i18n/en-us/ui.ftl`
-```fluent
-# Facet labels and counts
-filter-categories-label = Categories
-filter-creators-label = Event Creators
-filter-date-ranges-label = Date Ranges
-filter-facet-count = { $count ->
-    [one] ({ $count } event)
-   *[other] ({ $count } events)
-}
-filter-clear-facet = Clear { $facet }
-filter-show-more-facets = Show more...
-filter-show-less-facets = Show less
-```
-
-**File**: `/i18n/fr-ca/ui.ftl`
-```fluent
-# Étiquettes et comptes de facettes
-filter-categories-label = Catégories
-filter-creators-label = Créateurs d'événements
-filter-date-ranges-label = Plages de dates
-filter-facet-count = { $count ->
-    [one] ({ $count } événement)
-   *[other] ({ $count } événements)
-}
-filter-clear-facet = Effacer { $facet }
-filter-show-more-facets = Voir plus...
-filter-show-less-facets = Voir moins
-```
-
-### Task 2: Update Facet Calculation Service
-
-#### 2.1 Add Locale Parameter to FacetCalculator
-**File**: `/src/filtering/facets.rs`
-
-```rust
-impl FacetCalculator {
-    /// Calculate all facets for the given filter criteria with locale support
-    #[instrument(skip(self, criteria))]
-    pub async fn calculate_facets_with_locale(
-        &self,
-        criteria: &EventFilterCriteria,
-        locale: &LanguageIdentifier,
-    ) -> Result<EventFacets, FilterError> {
-        let mut facets = EventFacets::default();
-        
-        // Calculate total count
-        facets.total_count = self.calculate_total_count(criteria).await?;
-        
-        // Calculate category facets with i18n support
-        facets.categories = self.calculate_category_facets_with_locale(criteria, locale).await?;
-        
-        // Calculate creator facets
-        facets.creators = self.calculate_creator_facets(criteria).await?;
-        
-        // Calculate date range facets with i18n support
-        facets.date_ranges = self.calculate_date_range_facets_with_locale(criteria, locale).await?;
-        
-        Ok(facets)
-    }
-
-    /// Calculate category facets with locale-aware translations
-    async fn calculate_category_facets_with_locale(
-        &self,
-        criteria: &EventFilterCriteria,
-        locale: &LanguageIdentifier,
-    ) -> Result<Vec<FacetValue>, FilterError> {
-        // ...existing query logic...
-        
-        let mut facets = Vec::new();
-        for row in rows {
-            let category: String = row.try_get("category")?;
-            let count: i64 = row.try_get("count")?;
-            
-            let i18n_key = Self::generate_category_i18n_key(&category);
-            
-            facets.push(FacetValue {
-                i18n_key: Some(i18n_key),
-                value: category,
-                count,
-                // Add locale-specific display name if translation exists
-                display_name: Some(self.get_translated_facet_name(&i18n_key, locale)),
-            });
-        }
-        
-        Ok(facets)
-    }
-
-    /// Get translated facet name with fallback to original value
-    fn get_translated_facet_name(&self, i18n_key: &str, locale: &LanguageIdentifier) -> String {
-        use crate::i18n::fluent_loader::LOCALES;
-        
-        let translated = LOCALES.lookup(locale, i18n_key);
-        
-        // If translation returns the key itself, it means no translation found
-        if translated == i18n_key {
-            // Extract readable name from key: "category.technology_and_innovation" -> "Technology And Innovation"
-            i18n_key
-                .split('.')
-                .last()
-                .unwrap_or(i18n_key)
-                .replace('_', " ")
-                .split_whitespace()
-                .map(|word| {
-                    let mut chars = word.chars();
-                    match chars.next() {
-                        None => String::new(),
-                        Some(first) => first.to_uppercase().collect::<String>() + chars.as_str(),
-                    }
-                })
-                .collect::<Vec<_>>()
-                .join(" ")
-        } else {
-            translated
-        }
-    }
-}
-```
-
-#### 2.2 Update FacetValue Structure
-**File**: `/src/filtering/mod.rs`
-
-```rust
-/// A single facet value with count and optional i18n support
-#[derive(Debug, Clone, Serialize, Deserialize)]
-pub struct FacetValue {
-    /// The actual filter value
-    pub value: String,
-    /// Number of events matching this facet
-    pub count: i64,
-    /// Optional i18n key for translation
-    pub i18n_key: Option<String>,
-    /// Pre-calculated display name (locale-specific)
-    pub display_name: Option<String>,
-}
-```
-
-### Task 3: Update FilteringService Integration
-
-#### 3.1 Pass Locale to Service
-**File**: `/src/filtering/service.rs`
-
-```rust
-impl FilteringService {
-    /// Filter events with locale-aware facets
-    #[instrument(skip(self, criteria))]
-    pub async fn filter_events_with_locale(
-        &self,
-        criteria: &EventFilterCriteria,
-        locale: &LanguageIdentifier,
-        options: FilterOptions,
-    ) -> Result<FilterResults, FilterError> {
-        // Generate cache key including locale
-        let cache_key = format!("filter:{}:{}", criteria.cache_hash(), locale.to_string());
-        
-        // Try cache first (if enabled)
-        if let Some(ref cache) = self.cache {
-            if let Ok(Some(cached_results)) = cache.get::<FilterResults>(&cache_key).await {
-                debug!("Cache hit for filter query with locale {}", locale);
-                return Ok(cached_results);
-            }
-        }
-        
-        // Execute query
-        let events = self.query_builder
-            .filter_events(criteria, &self.pool, &options)
-            .await?;
-        
-        // Calculate locale-aware facets
-        let facets = if options.include_facets {
-            Some(self.facet_calculator.calculate_facets_with_locale(criteria, locale).await?)
-        } else {
-            None
-        };
-        
-        // Hydrate events if requested
-        let hydrated_events = if options.include_hydration {
-            self.hydrator.hydrate_events(events, &options.hydration_options).await?
-        } else {
-            events.into_iter().map(EventView::from_event).collect()
-        };
-        
-        let results = FilterResults {
-            events: hydrated_events,
-            facets,
-            total_count: facets.as_ref().map(|f| f.total_count).unwrap_or(0),
-        };
-        
-        // Cache results (if enabled)
-        if let Some(ref cache) = self.cache {
-            let _ = cache.set(&cache_key, &results, self.config.cache_ttl).await;
-        }
-        
-        Ok(results)
-    }
-}
-```
-
-### Task 4: Update HTTP Handlers
-
-#### 4.1 Extract Locale from Middleware
-**File**: `/src/http/handle_filter_events.rs`
-
-```rust
-use crate::http::middleware_i18n::Language;
-
-/// Main filtering endpoint with i18n support
-#[instrument(skip(ctx, filtering_service))]
-pub async fn handle_filter_events(
-    Extension(ctx): Extension<WebContext>,
-    Extension(filtering_service): Extension<Arc<FilteringService>>,
-    language: Language,
-    filter_params: FilterQueryParams,
-    headers: HeaderMap,
-) -> Result<impl IntoResponse, WebError> {
-    let is_htmx = headers.contains_key("hx-request");
-    let criteria = EventFilterCriteria::from_query_params(&filter_params)?;
-    
-    // Include locale in filtering options
-    let options = FilterOptions {
-        include_facets: true,
-        include_hydration: true,
-        hydration_options: HydrationOptions::default(),
-    };
-    
-    // Use locale-aware filtering
-    let results = filtering_service
-        .filter_events_with_locale(&criteria, &language.0, options)
-        .await?;
-    
-    // Template selection with locale
-    let template_name = if is_htmx {
-        format!("filter_events_results.{}.incl.html", language.0)
-    } else {
-        format!("filter_events.{}.html", language.0)
-    };
-    
-    // Enhanced context for templates
-    let template_context = template_context! {
-        events => results.events,
-        facets => results.facets,
-        filter_criteria => criteria,
-        total_count => results.total_count,
-        current_locale => language.0.to_string(),
-    };
-    
-    Ok(RenderHtml(template_name, ctx.engine, template_context))
-}
-```
-
-### Task 5: Update Templates to Use I18n Functions
-
-#### 5.1 Update Filter Form Template
-**File**: `/templates/filter_events.en-us.common.html` → **Migrate to Single Template**
-
-Create new unified template: `/templates/filter_events.common.html`
-
-```html
-<div class="section">
-    <div class="container">
-        <div class="columns">
-            <!-- Filter Sidebar -->
-            <div class="column is-3">
-                <div class="box">
-                    <h2 class="title is-5">{{ t("filter-title") }}</h2>
-                    
-                    <!-- Search Form -->
-                    <form id="filter-form" 
-                          hx-get="/events" 
-                          hx-target="#events-results" 
-                          hx-trigger="submit, change from:input, keyup[keyCode==13] from:input"
-                          hx-push-url="true"
-                          hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-                        
-                        <!-- Text Search -->
-                        <div class="field">
-                            <label class="label">{{ t("filter-search-label") }}</label>
-                            <div class="control">
-                                <input class="input" 
-                                       type="text" 
-                                       name="q" 
-                                       value="{{ filter_criteria.text_search | default('') }}"
-                                       placeholder="{{ t('filter-search-placeholder') }}">
-                            </div>
-                        </div>
-                        
-                        <!-- Date Range -->
-                        <div class="field">
-                            <label class="label">{{ t("filter-date-range-label") }}</label>
-                            <div class="field-body">
-                                <div class="field">
-                                    <div class="control">
-                                        <input class="input" 
-                                               type="date" 
-                                               name="start_date" 
-                                               value="{{ filter_criteria.start_date | default('') }}">
-                                    </div>
-                                </div>
-                                <div class="field">
-                                    <div class="control">
-                                        <input class="input" 
-                                               type="date" 
-                                               name="end_date" 
-                                               value="{{ filter_criteria.end_date | default('') }}">
-                                    </div>
-                                </div>
-                            </div>
-                        </div>
-                        
-                        <!-- Sort Options -->
-                        <div class="field">
-                            <label class="label">{{ t("filter-sort-label") }}</label>
-                            <div class="control">
-                                <div class="select is-fullwidth">
-                                    <select name="sort">
-                                        <option value="date_asc" {% if filter_criteria.sort_by == "date_asc" %}selected{% endif %}>
-                                            {{ t("filter-sort-date-asc") }}
-                                        </option>
-                                        <option value="date_desc" {% if filter_criteria.sort_by == "date_desc" %}selected{% endif %}>
-                                            {{ t("filter-sort-date-desc") }}
-                                        </option>
-                                        <option value="created_asc" {% if filter_criteria.sort_by == "created_asc" %}selected{% endif %}>
-                                            {{ t("filter-sort-created-asc") }}
-                                        </option>
-                                        <option value="created_desc" {% if filter_criteria.sort_by == "created_desc" %}selected{% endif %}>
-                                            {{ t("filter-sort-created-desc") }}
-                                        </option>
-                                        <option value="relevance" {% if filter_criteria.sort_by == "relevance" %}selected{% endif %}>
-                                            {{ t("filter-sort-relevance") }}
-                                        </option>
-                                    </select>
-                                </div>
-                            </div>
-                        </div>
-                        
-                        <!-- Clear Button -->
-                        <div class="field">
-                            <div class="control">
-                                <a href="/events" class="button is-light is-fullwidth">
-                                    {{ t("filter-clear-all") }}
-                                </a>
-                            </div>
-                        </div>
-                    </form>
-                </div>
-                
-                <!-- Dynamic Facets -->
-                {% if facets %}
-                <div class="box">
-                    <h3 class="title is-6">{{ t("filter-facets-title") }}</h3>
-                    
-                    <!-- Category Facets -->
-                    {% if facets.categories %}
-                    <div class="field">
-                        <label class="label">{{ t("filter-categories-label") }}</label>
-                        {% for category in facets.categories %}
-                        <div class="control">
-                            <label class="checkbox">
-                                <input type="checkbox"
-                                       name="categories"
-                                       value="{{ category.value }}"
-                                       {% if category.value in filter_criteria.categories %}checked{% endif %}
-                                       hx-get="/events"
-                                       hx-target="#events-results"
-                                       hx-include="closest form"
-                                       hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-                                
-                                <!-- Use display_name if available, otherwise translate i18n_key -->
-                                {% if category.display_name %}
-                                    {{ category.display_name }}
-                                {% elif category.i18n_key %}
-                                    {{ t(category.i18n_key) }}
-                                {% else %}
-                                    {{ category.value }}
-                                {% endif %}
-                                
-                                {{ t("filter-facet-count", count=category.count) }}
-                            </label>
-                        </div>
-                        {% endfor %}
-                    </div>
-                    {% endif %}
-                    
-                    <!-- Date Range Facets -->
-                    {% if facets.date_ranges %}
-                    <div class="field">
-                        <label class="label">{{ t("filter-date-ranges-label") }}</label>
-                        {% for date_range in facets.date_ranges %}
-                        <div class="control">
-                            <label class="checkbox">
-                                <input type="checkbox"
-                                       name="date_ranges"
-                                       value="{{ date_range.value }}"
-                                       {% if date_range.value in filter_criteria.date_ranges %}checked{% endif %}
-                                       hx-get="/events"
-                                       hx-target="#events-results"
-                                       hx-include="closest form"
-                                       hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-                                
-                                {% if date_range.i18n_key %}
-                                    {{ t(date_range.i18n_key) }}
-                                {% else %}
-                                    {{ date_range.value }}
-                                {% endif %}
-                                
-                                {{ t("filter-facet-count", count=date_range.count) }}
-                            </label>
-                        </div>
-                        {% endfor %}
-                    </div>
-                    {% endif %}
-                    
-                    <!-- Creator Facets -->
-                    {% if facets.creators %}
-                    <div class="field">
-                        <label class="label">{{ t("filter-creators-label") }}</label>
-                        {% for creator in facets.creators %}
-                        <div class="control">
-                            <label class="checkbox">
-                                <input type="checkbox"
-                                       name="creators"
-                                       value="{{ creator.value }}"
-                                       {% if creator.value in filter_criteria.creators %}checked{% endif %}
-                                       hx-get="/events"
-                                       hx-target="#events-results"
-                                       hx-include="closest form"
-                                       hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-                                {{ creator.value }} {{ t("filter-facet-count", count=creator.count) }}
-                            </label>
-                        </div>
-                        {% endfor %}
-                    </div>
-                    {% endif %}
-                </div>
-                {% endif %}
-            </div>
-            
-            <!-- Events Results -->
-            <div class="column is-9">
-                <div id="events-results">
-                    {% include 'filter_events_results.incl.html' %}
-                </div>
-            </div>
-        </div>
-    </div>
-</div>
-```
-
-#### 5.2 Update Main Filter Pages
-Update both main filter pages to use the unified common template:
-
-**File**: `/templates/filter_events.en-us.html`
-```html
-{% extends "base." + current_locale() + ".html" %}
-{% block title %}{{ t("filter-events-title") }}{% endblock %}
-{% block head %}
-<meta name="description" content="{{ t("filter-events-description") }}">
-<meta property="og:title" content="{{ t("filter-events-title") }}">
-<meta property="og:description" content="{{ t("filter-events-description") }}">
-<meta property="og:site_name" content="{{ t("site-name") }}" />
-<meta property="og:type" content="website" />
-<meta property="og:url" content="{{ external_base }}/events" />
-<script src="https://unpkg.com/htmx.org@1.9.12"></script>
-{% endblock %}
-{% block content %}
-{% include 'filter_events.common.html' %}
-{% endblock %}
-```
-
-**File**: `/templates/filter_events.fr-ca.html`
-```html
-{% extends "base." + current_locale() + ".html" %}
-{% block title %}{{ t("filter-events-title") }}{% endblock %}
-{% block head %}
-<meta name="description" content="{{ t("filter-events-description") }}">
-<meta property="og:title" content="{{ t("filter-events-title") }}">
-<meta property="og:description" content="{{ t("filter-events-description") }}">
-<meta property="og:site_name" content="{{ t("site-name") }}" />
-<meta property="og:type" content="website" />
-<meta property="og:url" content="{{ external_base }}/events" />
-<script src="https://unpkg.com/htmx.org@1.9.12"></script>
-{% endblock %}
-{% block content %}
-{% include 'filter_events.common.html' %}
-{% endblock %}
-```
-
-#### 5.3 Update HTMX Results Template
-Create unified results template: `/templates/filter_events_results.incl.html`
-
-```html
-<!-- Results Header -->
-<div class="level">
-    <div class="level-left">
-        <div class="level-item">
-            <h1 class="title is-4">
-                {% if filter_criteria.search_term %}
-                    {{ t("filter-search-results-for", term=filter_criteria.search_term) }}
-                {% else %}
-                    {{ t("filter-all-events") }}
-                {% endif %}
-            </h1>
-        </div>
-    </div>
-    <div class="level-right">
-        <div class="level-item">
-            <p class="subtitle is-6">
-                {{ t("filter-results-count", count=total_count) }}
-            </p>
-        </div>
-    </div>
-</div>
-
-<!-- Events List -->
-{% if events %}
-    <div class="columns is-multiline">
-        {% for event in events %}
-        <div class="column is-half">
-            <div class="card">
-                <div class="card-content">
-                    <div class="media">
-                        <div class="media-content">
-                            <p class="title is-5">
-                                <a href="/events/{{ event.rkey }}">{{ event.name }}</a>
-                            </p>
-                            <p class="subtitle is-6">
-                                {% if event.creator_handle %}
-                                    {{ t("event-by-creator", creator=event.creator_handle) }}
-                                {% endif %}
-                            </p>
-                        </div>
-                    </div>
-                    
-                    <div class="content">
-                        {% if event.description %}
-                            <p>{{ event.description | truncate(150) }}</p>
-                        {% endif %}
-                        
-                        <div class="tags">
-                            {% if event.start_time %}
-                                <span class="tag is-info">
-                                    <i class="fas fa-calendar"></i>
-                                    {{ event.start_time | date("Y-m-d H:i") }}
-                                </span>
-                            {% endif %}
-                            
-                            {% if event.location %}
-                                <span class="tag is-success">
-                                    <i class="fas fa-map-marker-alt"></i>
-                                    {{ event.location }}
-                                </span>
-                            {% endif %}
-                            
-                            {% if event.rsvp_count %}
-                                <span class="tag is-warning">
-                                    <i class="fas fa-users"></i>
-                                    {{ t("event-rsvp-count", count=event.rsvp_count) }}
-                                </span>
-                            {% endif %}
-                        </div>
-                    </div>
-                </div>
-            </div>
-        </div>
-        {% endfor %}
-    </div>
-    
-    <!-- Pagination -->
-    {% if has_more_pages %}
-    <nav class="pagination is-centered" role="navigation">
-        <button class="pagination-previous button" 
-                hx-get="/events?page={{ current_page - 1 }}"
-                hx-target="#events-results"
-                hx-include="closest form"
-                hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-            {{ t("pagination-previous") }}
-        </button>
-        <button class="pagination-next button"
-                hx-get="/events?page={{ current_page + 1 }}"
-                hx-target="#events-results" 
-                hx-include="closest form"
-                hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-            {{ t("pagination-next") }}
-        </button>
-    </nav>
-    {% endif %}
-{% else %}
-    <div class="notification is-info">
-        <p>{{ t("filter-no-results") }}</p>
-        <p>{{ t("filter-try-different-criteria") }}</p>
-    </div>
-{% endif %}
-```
-
-### Task 6: Update Route Registration
-
-#### 6.1 Ensure I18n Middleware Integration
-**File**: `/src/http/mod.rs` (or main router setup)
-
-```rust
-// Ensure filtering routes have i18n middleware
-pub fn create_filtering_routes() -> Router<WebContext> {
-    Router::new()
-        .route("/events", get(handle_filter_events))
-        .route("/events/facets", get(handle_filter_facets))
-        .route("/events/suggestions", get(handle_filter_suggestions))
-        // Middleware stack includes i18n detection
-        .layer(from_fn(middleware_i18n::detect_language))
-        .layer(from_fn(middleware_filter::extract_filter_params))
-}
-```
-
-### Task 7: Testing Integration
-
-#### 7.1 Update Existing Tests
-**File**: `/src/filtering/facets.rs` - Add i18n tests
-
-```rust
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use unic_langid::langid;
-
-    #[test]
-    fn test_generate_category_i18n_key() {
-        assert_eq!(
-            FacetCalculator::generate_category_i18n_key("Technology & Innovation"),
-            "category.technology_and_innovation"
-        );
-        
-        assert_eq!(
-            FacetCalculator::generate_category_i18n_key("Arts & Culture"),
-            "category.arts_and_culture"
-        );
-    }
-
-    #[test]
-    fn test_get_translated_facet_name() {
-        let calculator = FacetCalculator::new(/* mock pool */);
-        let locale = langid!("en-US");
-        
-        // Test with existing translation key
-        let translated = calculator.get_translated_facet_name(
-            "category.technology_and_innovation", 
-            &locale
-        );
-        
-        // Should return translated text if key exists, otherwise formatted fallback
-        assert!(!translated.is_empty());
-    }
-
-    #[sqlx::test]
-    async fn test_facet_calculation_with_locale() {
-        // Integration test with real database
-        let pool = setup_test_db().await;
-        let calculator = FacetCalculator::new(pool);
-        let criteria = EventFilterCriteria::default();
-        let locale = langid!("en-US");
-        
-        let facets = calculator
-            .calculate_facets_with_locale(&criteria, &locale)
-            .await
-            .unwrap();
-        
-        // Verify facets have proper i18n keys and display names
-        for category in &facets.categories {
-            assert!(category.i18n_key.is_some());
-            assert!(category.display_name.is_some());
-        }
-    }
-}
-```
-
-#### 7.2 Add I18n Template Tests
-**File**: `/tests/integration/filter_i18n_test.rs`
-
-```rust
-#[tokio::test]
-async fn test_filter_page_renders_with_locale() {
-    let app = create_test_app().await;
-    
-    // Test English
-    let response = app
-        .oneshot(
-            Request::builder()
-                .uri("/events")
-                .header("Accept-Language", "en-US,en;q=0.9")
-                .body(Body::empty())
-                .unwrap(),
-        )
-        .await
-        .unwrap();
-    
-    assert_eq!(response.status(), StatusCode::OK);
-    let body = to_bytes(response.into_body(), usize::MAX).await.unwrap();
-    let html = String::from_utf8(body.to_vec()).unwrap();
-    
-    // Verify English translations are used
-    assert!(html.contains("Filter Options"));
-    assert!(html.contains("Categories"));
-    
-    // Test French
-    let response = app
-        .oneshot(
-            Request::builder()
-                .uri("/events")
-                .header("Accept-Language", "fr-CA,fr;q=0.9")
-                .body(Body::empty())
-                .unwrap(),
-        )
-        .await
-        .unwrap();
-    
-    let body = to_bytes(response.into_body(), usize::MAX).await.unwrap();
-    let html = String::from_utf8(body.to_vec()).unwrap();
-    
-    // Verify French translations are used
-    assert!(html.contains("Options de filtrage"));
-    assert!(html.contains("Catégories"));
-}
-
-#[tokio::test]
-async fn test_htmx_facet_updates_preserve_language() {
-    let app = create_test_app().await;
-    
-    let response = app
-        .oneshot(
-            Request::builder()
-                .uri("/events")
-                .method("GET")
-                .header("HX-Request", "true")
-                .header("HX-Current-Language", "fr-ca")
-                .body(Body::empty())
-                .unwrap(),
-        )
-        .await
-        .unwrap();
-    
-    assert_eq!(response.status(), StatusCode::OK);
-    
-    // Verify HTMX response includes proper language context
-    let headers = response.headers();
-    assert!(headers.contains_key("HX-Language"));
-}
-```
-
----
-
-## Implementation Order
-
-### Phase 4A: Foundation (Day 1)
-1. **Add translation keys** to both language files
-2. **Update FacetValue structure** with display_name field
-3. **Extend FacetCalculator** with locale-aware methods
-
-### Phase 4B: Service Integration (Day 1-2)
-1. **Update FilteringService** to accept locale parameter  
-2. **Modify HTTP handlers** to extract and use locale
-3. **Update cache keys** to include locale for proper separation
-
-### Phase 4C: Template Migration (Day 2)
-1. **Create unified templates** using i18n functions
-2. **Remove language-specific .common.html files**
-3. **Update HTMX result templates** with proper language headers
-
-### Phase 4D: Testing & Validation (Day 2-3)
-1. **Run existing test suite** to ensure no regressions
-2. **Add i18n-specific tests** for facet calculation and template rendering
-3. **Manual testing** of language switching and HTMX updates
-4. **Performance validation** with locale-aware caching
-
----
-
-## Expected Outcomes
-
-### ✅ Features Delivered
-
-1. **Locale-Aware Facets**: Category and date range facets display in user's language
-2. **Dynamic Template Functions**: All filter templates use `t()` functions instead of hardcoded text
-3. **HTMX Language Propagation**: Partial updates maintain language context
-4. **Intelligent Fallbacks**: Graceful degradation when translations missing
-5. **Cache Efficiency**: Locale-specific caching without excessive memory usage
-
-### 🚀 Performance Benefits
-
-- **Zero Runtime Translation Overhead**: fluent-templates static loading
-- **Intelligent Caching**: Locale-aware cache keys prevent cross-language contamination  
-- **Efficient Facet Calculation**: Pre-computed display names reduce template complexity
-- **HTMX Optimization**: Language headers minimize full page reloads
-
-### 🧪 Quality Assurance
-
-- **Comprehensive Test Coverage**: Unit, integration, and i18n-specific tests
-- **Translation Validation**: Automated checking for missing keys
-- **Manual Testing**: Cross-language functionality validation
-- **Performance Monitoring**: Cache hit rates and response times
-
----
-
-## Risk Mitigation
-
-### Potential Issues
-
-1. **Cache Key Explosion**: Including locale in cache keys increases memory usage
-   - **Solution**: Implement cache size limits and intelligent eviction
-   
-2. **Translation Key Mismatches**: Category names may not match translation keys
-   - **Solution**: Fallback logic to generate readable names from keys
-   
-3. **Template Complexity**: Unified templates may be harder to debug
-   - **Solution**: Maintain clear separation and good commenting
-
-### Rollback Plan
-
-- **Feature Flag**: Implement `enable_filter_i18n` flag for quick disable
-- **Template Fallback**: Keep original language-specific templates as backup
-- **Cache Compatibility**: Ensure new cache keys don't break existing cache
-
----
-
-## Conclusion
-
-Phase 4 delivers a fully internationalized filtering system that seamlessly integrates with the existing i18n infrastructure. The implementation maintains backward compatibility while providing significant improvements in user experience for French Canadian users and establishes a solid foundation for additional languages in the future.
-
-The approach emphasizes performance (static loading, intelligent caching), maintainability (unified templates, clear fallbacks), and user experience (HTMX-aware language propagation, locale-specific facets).

docs/filtering/FILTERING_PHASE_1_COMPLETED.md

···
-# Event Filtering System - Phase 1 Implementation Complete
-
-**Project**: smokesignal (Event & RSVP Management)  
-**Date**: June 1, 2025  
-**Phase**: 1 - Core Filtering Infrastructure  
-**Status**: ✅ **COMPLETE** - All compilation errors resolved, system ready for database integration
-
----
-
-## Table of Contents
-
-1. [Overview](#overview)
-2. [Architecture Implemented](#architecture-implemented)
-3. [Files Created](#files-created)
-4. [Database Schema](#database-schema)
-5. [Template System](#template-system)
-6. [Internationalization](#internationalization)
-7. [Compilation Fixes Applied](#compilation-fixes-applied)
-8. [Testing and Validation](#testing-and-validation)
-9. [Next Steps](#next-steps)
-10. [Usage Examples](#usage-examples)
-
----
-
-## Overview
-
-Phase 1 of the event filtering system has been successfully implemented, providing a complete foundation for faceted search and filtering of events in the smokesignal application. The system integrates seamlessly with the existing i18n infrastructure, supports HTMX for real-time filtering, and includes comprehensive template rendering with fallback support.
-
-### Key Features Implemented
-
-- ✅ **Faceted Search**: Text search, date ranges, categories, geolocation, creator filtering
-- ✅ **Dynamic SQL Query Building**: Secure, optimized database queries with proper indexing
-- ✅ **Event Hydration**: Rich event data enrichment with RSVP counts and metadata
-- ✅ **Template Rendering**: Full page, HTMX partial, and boosted navigation support
-- ✅ **Internationalization**: English and French Canadian translation support
-- ✅ **Performance Optimization**: Database indexes and caching infrastructure ready
-- ✅ **Type Safety**: Comprehensive error handling and validation
-
-### System Capabilities
-
-```rust
-// Example usage
-let criteria = EventFilterCriteria {
-    search_term: Some("tech conference".to_string()),
-    start_date: Some(Utc::now()),
-    categories: vec!["technology".to_string(), "networking".to_string()],
-    location: Some(LocationFilter {
-        latitude: 45.5017,
-        longitude: -73.5673,
-        radius_km: 25.0,
-    }),
-    sort_by: EventSortField::StartTime,
-    sort_order: SortOrder::Ascending,
-    page: 0,
-    page_size: 20,
-};
-
-let results = filtering_service.filter_events(&criteria, &options).await?;
-```
-
----
-
-## Architecture Implemented
-
-### Core Components
-
-```
-src/filtering/
-├── mod.rs                   # Module exports and FilterContext
-├── criteria.rs              # Filter criteria definitions and validation
-├── errors.rs               # Comprehensive error handling types
-├── query_builder.rs        # Dynamic SQL query construction
-├── facets.rs               # Facet calculation and aggregation logic
-├── hydration.rs            # Event data enrichment and RSVP counts
-└── service.rs              # Main filtering service coordination
-
-src/http/
-├── middleware_filter.rs     # HTTP parameter extraction and validation
-└── handle_filter_events.rs  # Route handlers for filtering endpoints
-
-templates/
-├── filter_events.{locale}.html              # Main filtering interface
-├── filter_events.{locale}.common.html       # Common filtering components
-└── filter_events_results.{locale}.incl.html # HTMX result updates
-
-migrations/
-└── 20250115000000_event_filtering_indexes.sql # Performance optimization indexes
-```
-
-### Service Architecture
-
-```rust
-// FilteringService - Main coordination layer
-pub struct FilteringService {
-    pool: PgPool,
-}
-
-// EventFilterCriteria - Type-safe filter parameters
-pub struct EventFilterCriteria {
-    pub search_term: Option<String>,
-    pub start_date: Option<DateTime<Utc>>,
-    pub end_date: Option<DateTime<Utc>>,
-    pub categories: Vec<String>,
-    pub creator_did: Option<String>,
-    pub location: Option<LocationFilter>,
-    pub sort_by: EventSortField,
-    pub sort_order: SortOrder,
-    pub page: usize,
-    pub page_size: usize,
-}
-
-// FilterResults - Comprehensive result structure
-pub struct FilterResults {
-    pub hydrated_events: Vec<EventView>,
-    pub facets: EventFacets,
-    pub total_count: i64,
-    pub page: usize,
-    pub page_size: usize,
-    pub has_more: bool,
-}
-```
-
----
-
-## Files Created
-
-### Core Filtering System
-
-#### `/src/filtering/mod.rs`
-- Module exports and public API
-- FilterContext for request-scoped data
-- Integration points for caching and middleware
-
-#### `/src/filtering/criteria.rs`
-- `EventFilterCriteria` struct with comprehensive validation
-- `LocationFilter` for geospatial queries
-- `EventSortField` and `SortOrder` enums
-- Default implementations and builder patterns
-
-#### `/src/filtering/errors.rs`
-- `FilterError` enum with detailed error variants
-- Database, validation, and hydration error handling
-- Integration with existing `WebError` system
-
-#### `/src/filtering/query_builder.rs`
-- `QueryBuilder` for dynamic SQL construction
-- Secure parameter binding and SQL injection prevention
-- Support for complex WHERE clauses and JOINs
-- PostGIS integration for geospatial queries
-
-#### `/src/filtering/facets.rs`
-- `EventFacets` calculation and aggregation
-- Category and creator facet counting
-- Date range aggregations
-- Efficient parallel facet computation
-
-#### `/src/filtering/hydration.rs`
-- `HydrationService` for event data enrichment
-- RSVP count calculation and caching
-- Event metadata enhancement
-- `EventView` creation for template rendering
-
-#### `/src/filtering/service.rs`
-- `FilteringService` main coordination layer
-- `FilterOptions` for performance tuning
-- Result pagination and streaming
-- Error handling and logging integration
-
-### HTTP Layer
-
-#### `/src/http/middleware_filter.rs`
-- `FilterQueryParams` struct for URL parameter parsing
-- `FilterCriteriaExtension` for request context
-- Parameter validation and normalization
-- `serde_urlencoded` integration
-
-#### `/src/http/handle_filter_events.rs`
-- `handle_filter_events` - Main filtering endpoint
-- `handle_filter_facets` - HTMX facets-only endpoint
-- `handle_filter_suggestions` - Autocomplete/suggestions
-- Template rendering with `RenderHtml` pattern
-
-### Database Schema
-
-#### `/migrations/20250115000000_event_filtering_indexes.sql`
-```sql
--- PostGIS spatial indexes for location-based queries
-CREATE INDEX CONCURRENTLY idx_events_location_gist 
-ON events USING GIST (ST_Point(longitude, latitude));
-
--- GIN indexes for JSON content search
-CREATE INDEX CONCURRENTLY idx_events_content_gin 
-ON events USING GIN (to_tsvector('english', name || ' ' || description));
-
--- Composite indexes for common filter combinations
-CREATE INDEX CONCURRENTLY idx_events_start_time_status 
-ON events (starts_at, status) WHERE status IN ('confirmed', 'published');
-
--- Category and creator indexes
-CREATE INDEX CONCURRENTLY idx_events_categories_gin 
-ON events USING GIN (categories);
-
-CREATE INDEX CONCURRENTLY idx_events_creator_start_time 
-ON events (organizer_did, starts_at);
-```
-
----
-
-## Template System
-
-### Template Hierarchy
-
-The filtering system implements a comprehensive template hierarchy supporting:
-
-1. **Full Page Templates** (`filter_events.{locale}.html`)
-   - Complete page structure with navigation
-   - SEO metadata and canonical URLs
-   - Full filtering interface
-
-2. **Common Components** (`filter_events.{locale}.common.html`)
-   - Reusable filtering interface components
-   - Form elements and controls
-   - JavaScript integration points
-
-3. **HTMX Partials** (`filter_events_results.{locale}.incl.html`)
-   - Result-only updates for dynamic filtering
-   - Optimized for fast partial page updates
-   - Maintains state and context
-
-### Template Features
-
-```html
-<!-- Example from filter_events.en-us.html -->
-<form hx-get="/events" 
-      hx-target="#event-results" 
-      hx-trigger="change, input delay:300ms"
-      hx-headers='{"HX-Current-Language": "{{ current_locale() }}"}'>
-    
-    <!-- Search input -->
-    <input type="text" 
-           name="q" 
-           placeholder="{{ tr('filter-search-placeholder') }}"
-           value="{{ criteria.search_term or '' }}">
-    
-    <!-- Date range filters -->
-    <input type="date" 
-           name="start_date" 
-           value="{{ criteria.start_date|date('Y-m-d') if criteria.start_date }}">
-    
-    <!-- Location filters -->
-    <input type="number" 
-           name="lat" 
-           placeholder="{{ tr('filter-latitude') }}"
-           step="any">
-</form>
-
-<!-- Results section -->
-<div id="event-results" class="event-results">
-    {% include "filter_events_results.en-us.incl.html" %}
-</div>
-```
-
----
-
-## Internationalization
-
-### Translation Keys Added
-
-#### English (`i18n/en-us/ui.ftl`)
-```fluent
-# Filtering Interface
-filter-search-placeholder = Search events...
-filter-date-start = Start date
-filter-date-end = End date
-filter-categories = Categories
-filter-location = Location
-filter-radius = Radius (km)
-filter-sort-by = Sort by
-filter-creator = Event creator
-
-# Filter Options
-filter-sort-start-time = Start time
-filter-sort-created = Recently added
-filter-sort-name = Event name
-filter-sort-popularity = Popularity
-
-# Results Display
-filter-results-count = { $count ->
-    [one] { $count } event found
-   *[other] { $count } events found
-}
-filter-results-showing = Showing { $start } to { $end } of { $total }
-filter-no-results = No events match your criteria
-filter-clear-all = Clear all filters
-
-# Facets
-facet-categories = Categories
-facet-creators = Event creators
-facet-date-ranges = Date ranges
-facet-locations = Locations
-```
-
-#### French Canadian (`i18n/fr-ca/ui.ftl`)
-```fluent
-# Interface de filtrage
-filter-search-placeholder = Rechercher des événements...
-filter-date-start = Date de début
-filter-date-end = Date de fin
-filter-categories = Catégories
-filter-location = Lieu
-filter-radius = Rayon (km)
-filter-sort-by = Trier par
-filter-creator = Créateur d'événement
-
-# Options de tri
-filter-sort-start-time = Heure de début
-filter-sort-created = Récemment ajouté
-filter-sort-name = Nom de l'événement
-filter-sort-popularity = Popularité
-
-# Affichage des résultats
-filter-results-count = { $count ->
-    [one] { $count } événement trouvé
-   *[other] { $count } événements trouvés
-}
-filter-results-showing = Affichage de { $start } à { $end } sur { $total }
-filter-no-results = Aucun événement ne correspond à vos critères
-filter-clear-all = Effacer tous les filtres
-
-# Facettes
-facet-categories = Catégories
-facet-creators = Créateurs d'événements
-facet-date-ranges = Plages de dates
-facet-locations = Lieux
-```
-
----
-
-## Compilation Fixes Applied
-
-### 1. Template Engine Method Calls
-
-**Problem**: Code was using `engine.get_template().render()` pattern
-**Solution**: Updated to use `RenderHtml` pattern throughout codebase
-
-```rust
-// Before (causing compilation errors)
-let rendered = ctx.web_context.engine
-    .get_template(&template_name)?
-    .render(template_ctx)?;
-Ok(Html(rendered).into_response())
-
-// After (working solution)
-Ok(RenderHtml(template_name, ctx.web_context.engine.clone(), template_ctx).into_response())
-```
-
-### 2. SQLx Macro Compilation
-
-**Problem**: SQLx macros require DATABASE_URL for compile-time verification
-**Solution**: Replaced with runtime query methods
-
-```rust
-// Before (requiring database at compile time)
-let count = sqlx::query_scalar!(
-    "SELECT COUNT(*) FROM rsvps WHERE event_aturi = $1 AND status = 'going'",
-    event_aturi
-).fetch_one(&self.pool).await?;
-
-// After (compiles without database)
-let count = sqlx::query_scalar::<_, i64>(
-    "SELECT COUNT(*) FROM rsvps WHERE event_aturi = $1 AND status = 'going'"
-)
-.bind(event_aturi)
-.fetch_one(&self.pool)
-.await
-.unwrap_or(0);
-```
-
-### 3. Handler Function Signatures
-
-**Problem**: Inconsistent parameter extraction patterns
-**Solution**: Standardized to direct extractor usage
-
-```rust
-// Before (causing type errors)
-pub async fn handle_filter_events(
-    Extension(ctx): Extension<UserRequestContext>,
-    Extension(pool): Extension<StoragePool>,
-    // ...
-) -> Result<Response, WebError>
-
-// After (working solution)
-pub async fn handle_filter_events(
-    ctx: UserRequestContext,
-    Query(page_query): Query<FilterPageQuery>,
-    HxBoosted(boosted): HxBoosted,
-    HxRequest(is_htmx): HxRequest,
-) -> Result<Response, WebError>
-```
-
-### 4. Import Cleanup
-
-**Problem**: Unused imports causing compilation warnings
-**Solution**: Systematically removed all unused imports
-
-```rust
-// Removed unused imports across all files:
-// - std::collections::HashMap
-// - axum::extract::Path
-// - tracing::trace
-// - Various other unused imports
-```
-
-### 5. Serialization Support
-
-**Problem**: Template context serialization errors
-**Solution**: Added `Serialize` derive to required structs
-
-```rust
-#[derive(Debug, Clone, Serialize)] // Added Serialize
-pub struct RsvpCounts {
-    pub going: i64,
-    pub interested: i64,
-    pub not_going: i64,
-    pub total: i64,
-}
-```
-
----
-
-## Testing and Validation
-
-### Compilation Status
-
-```bash
-$ cargo check
-   Compiling smokesignal v1.0.2 (/root/smokesignal)
-warning: field `pool` is never read
-  --> src/filtering/service.rs:18:5
-   |
-17 | pub struct FilteringService {
-   |            ---------------- field in this struct
-18 |     pool: PgPool,
-   |     ^^^^
-   |
-   = note: `FilteringService` has derived impls for the traits `Clone` and `Debug`, but these are intentionally ignored during dead code analysis
-
-    Finished `dev` profile [unoptimized + debuginfo] target(s) in 9.74s
-```
-
-**Result**: ✅ Successful compilation with only minor warnings (unused fields that will be used when database is connected)
-
-### Dependencies Verified
-
-- ✅ `serde_urlencoded = "0.7.1"` properly listed in Cargo.toml
-- ✅ All filtering system dependencies available
-- ✅ No missing imports or type conflicts
-
-### Code Quality
-
-- ✅ All functions properly documented
-- ✅ Error handling comprehensive and consistent
-- ✅ Type safety maintained throughout
-- ✅ No unsafe code patterns
-- ✅ Proper async/await usage
-
----
-
-## Next Steps
-
-### Phase 2: Database Integration
-
-1. **Database Setup**
-   - Configure DATABASE_URL environment variable
-   - Run database migrations for index creation
-   - Switch back to SQLx compile-time macros for better type safety
-
-2. **Route Integration**
-   - Add filtering routes to main server configuration
-   - Connect middleware to route handlers
-   - Test end-to-end filtering workflows
-
-3. **Performance Testing**
-   - Validate query performance with realistic datasets
-   - Optimize indexes based on actual usage patterns
-   - Implement Redis caching for facet data
-
-### Phase 3: Advanced Features
-
-1. **Search Enhancement**
-   - Full-text search with PostgreSQL
-   - Search result highlighting
-   - Autocomplete suggestions
-
-2. **Real-time Updates**
-   - WebSocket integration for live updates
-   - Real-time facet count updates
-   - Live event status changes
-
-3. **Analytics Integration**
-   - Search analytics and metrics
-   - Popular filter combinations
-   - Performance monitoring
-
----
-
-## Usage Examples
-
-### Basic Filtering Service Usage
-
-```rust
-use smokesignal::filtering::{FilteringService, EventFilterCriteria, FilterOptions};
-
-// Create service
-let filtering_service = FilteringService::new(pool);
-
-// Create filter criteria
-let mut criteria = EventFilterCriteria::new();
-criteria.search_term = Some("tech conference".to_string());
-criteria.categories = vec!["technology".to_string()];
-criteria.page_size = 10;
-
-// Execute filtering
-let options = FilterOptions::list_view();
-let results = filtering_service
-    .filter_events(&criteria, &options)
-    .await?;
-
-println!("Found {} events", results.total_count);
-for event in results.hydrated_events {
-    println!("Event: {}", event.name);
-}
-```
-
-### HTTP Handler Integration
-
-```rust
-// In your route handler
-#[instrument(skip(ctx))]
-pub async fn handle_events_page(
-    ctx: UserRequestContext,
-    Query(page_query): Query<FilterPageQuery>,
-    HxBoosted(boosted): HxBoosted,
-    HxRequest(is_htmx): HxRequest,
-) -> Result<Response, WebError> {
-    let criteria = EventFilterCriteria::default();
-    let filtering_service = FilteringService::new(ctx.web_context.pool.clone());
-    
-    let options = if is_htmx {
-        FilterOptions::list_view()
-    } else {
-        FilterOptions::detail_view()
-    };
-    
-    let results = filtering_service
-        .filter_events(&criteria, &options)
-        .await?;
-    
-    let template_ctx = template_context! {
-        events => results.hydrated_events,
-        facets => results.facets,
-        criteria => criteria,
-        total_count => results.total_count,
-    };
-    
-    let template_name = if is_htmx {
-        format!("filter_events_results.{}.incl.html", ctx.language.0)
-    } else {
-        format!("filter_events.{}.html", ctx.language.0)
-    };
-    
-    Ok(RenderHtml(template_name, ctx.web_context.engine.clone(), template_ctx).into_response())
-}
-```
-
-### Frontend Integration
-
-```html
-<!-- Filter form with HTMX -->
-<form hx-get="/events" 
-      hx-target="#event-results" 
-      hx-trigger="change, input delay:300ms"
-      class="event-filters">
-    
-    <input type="text" 
-           name="q" 
-           placeholder="{{ tr('filter-search-placeholder') }}"
-           value="{{ criteria.search_term or '' }}">
-    
-    <select name="sort">
-        <option value="start_time">{{ tr('filter-sort-start-time') }}</option>
-        <option value="created_at">{{ tr('filter-sort-created') }}</option>
-        <option value="name">{{ tr('filter-sort-name') }}</option>
-        <option value="popularity">{{ tr('filter-sort-popularity') }}</option>
-    </select>
-    
-    <button type="submit">{{ tr('filter-apply') }}</button>
-</form>
-
-<div id="event-results">
-    <!-- Results loaded here via HTMX -->
-</div>
-```
-
----
-
-## Conclusion
-
-Phase 1 of the event filtering system has been successfully completed with a robust, type-safe, and internationalized foundation. The system is now ready for database integration and testing with real data. All compilation errors have been resolved, and the codebase follows established patterns and best practices.
-
-The implementation provides a solid foundation for advanced filtering capabilities while maintaining performance, security, and user experience standards. The next phase will focus on database integration and real-world testing.
-
-**Status**: ✅ **Ready for Phase 2 - Database Integration**

docs/filtering/FILTERING_PHASE_2-3_COMPLETED.md

···
-# Filtering Module - Phase 2 & 3 Implementation Complete
-
-## Overview
-
-This document summarizes the successful completion of **Phase 2** (facet calculation and hydration) and **Phase 3** (cache integration) for the smokesignal filtering module. The implementation provides a robust faceted search and filtering system with Redis caching and ATproto hydration support.
-
-## Phase 2: Facet Calculation & Hydration ✅
-
-### Facet Calculation
-- **Category facets** - Dynamic categorization with i18n support
-- **Creator facets** - Event creator aggregation and counts  
-- **Date range facets** - Temporal filtering with flexible ranges
-- **Configurable facet limits** - Performance optimization for large datasets
-
-### Event Hydration
-- **RSVP counts** - Real-time attendance tracking
-- **Creator handles** - ATproto handle resolution
-- **Location data** - Geographic information enrichment
-- **Flexible hydration options** - Selective data loading for performance
-
-## Phase 3: Cache Integration ✅
-
-### Redis Cache Support
-- **Configurable TTL** - Default 5 minutes, customizable per environment
-- **Enable/disable flag** - Development vs production flexibility
-- **Graceful fallback** - Automatic database queries when cache unavailable
-- **Error handling** - Robust error recovery with detailed logging
-
-### Cache Key Generation
-- **Hash-based keys** - Consistent key generation using criteria hash
-- **Locale awareness** - Cache separation by language/locale
-- **Collision resistance** - Cryptographic hash functions prevent conflicts
-
-### Serialization Support
-- **Complete serialization** - All filter results cacheable via serde
-- **Efficient storage** - Optimized JSON serialization for Redis
-- **Type safety** - Strong typing maintained through cache layer
-
-## Implementation Details
-
-### Core Service Architecture
-
-```rust
-// Basic usage without cache
-let service = FilteringService::new(pool);
-let results = service.filter_events(criteria, options, "en").await?;
-
-// With cache support  
-let service = FilteringService::new_with_cache(
-    pool, 
-    Some(cache_pool),
-    FilterConfig {
-        cache_ttl: 600, // 10 minutes
-        enable_cache: true,
-    }
-);
-let results = service.filter_events(criteria, options, "en").await?;
-```
-
-### Cache Configuration
-
-```rust
-pub struct FilterConfig {
-    /// Cache TTL in seconds (default: 5 minutes)
-    pub cache_ttl: u64,
-    /// Enable caching
-    pub enable_cache: bool,
-}
-```
-
-### Files Modified
-
-#### Core Service Infrastructure
-- **`src/filtering/service.rs`** - Complete cache integration with FilterConfig, cache methods, and updated constructors
-- **`src/filtering/criteria.rs`** - Added Hash traits and cache_hash() method for cache key generation  
-- **`src/filtering/errors.rs`** - Added cache and serialization error handling
-
-#### Cache Compatibility
-- **`src/filtering/hydration.rs`** - Added serde::Deserialize traits for cache serialization
-- **`src/http/event_view.rs`** - Added serde::Deserialize trait for EventView
-
-#### Testing & Quality
-- **`src/filtering/facets.rs`** - Fixed test compilation with static method
-- **`src/filtering/cache_integration_test.rs`** - Comprehensive cache integration tests
-- **Various files** - Cleaned up unused imports and warnings
-
-## Testing Coverage
-
-### Comprehensive Test Suite ✅
-- **9/9 filtering tests passing**
-- **Cache configuration tests** - Verify TTL and enable/disable functionality
-- **Cache key generation tests** - Ensure consistent hash generation
-- **Serialization tests** - Validate cache storage/retrieval
-- **Criteria validation tests** - Input validation and error handling
-- **Integration tests** - End-to-end cache functionality
-
-### Test Examples
-
-```rust
-#[test]
-fn test_cache_configuration() {
-    let config = FilterConfig {
-        cache_ttl: 300, // 5 minutes
-        enable_cache: true,
-    };
-    assert_eq!(config.cache_ttl, 300);
-    assert!(config.enable_cache);
-}
-
-#[test]
-fn test_cache_key_generation() {
-    let criteria = EventFilterCriteria {
-        search_term: Some("test".to_string()),
-        categories: vec!["Technology".to_string()],
-        ..Default::default()
-    };
-    
-    let hash1 = criteria.cache_hash();
-    let hash2 = criteria.cache_hash();
-    assert_eq!(hash1, hash2); // Consistent hashing
-}
-```
-
-## Performance Features
-
-### Optimization Strategies
-- **Intelligent caching** - Only cache expensive queries with significant result sets
-- **Configurable TTL** - Balance between performance and data freshness
-- **Selective hydration** - Load only required data based on use case
-- **Graceful degradation** - System remains functional without cache
-
-### Cache Efficiency
-- **Hash-based keys** - O(1) cache lookups with collision resistance
-- **Compression-ready** - JSON serialization compatible with Redis compression
-- **Memory efficient** - Selective field serialization reduces cache footprint
-
-## Error Handling
-
-### Robust Error Recovery
-- **Cache operation failures** - Automatic fallback to database queries
-- **Serialization errors** - Detailed error messages with context
-- **Network timeouts** - Configurable timeouts with retry logic
-- **Data corruption** - Validation and error recovery mechanisms
-
-## Production Readiness
-
-### Deployment Considerations
-- **Environment-specific configuration** - Different settings for dev/staging/prod
-- **Monitoring integration** - Cache hit/miss metrics and performance tracking
-- **Scaling support** - Redis clustering and horizontal scaling ready
-- **Security** - No sensitive data cached, proper key isolation
-
-### Next Steps
-The filtering module is now production-ready for deployment. Future enhancements could include:
-- **Template integration** for HTMX-based UI components
-- **Advanced facet types** (numeric ranges, hierarchical categories)
-- **Cache warming strategies** for popular queries
-- **Real-time cache invalidation** for event updates
-
-## Conclusion
-
-Phase 2 and Phase 3 implementation successfully delivers:
-- **High-performance filtering** with intelligent cache optimization
-- **Flexible faceted search** supporting multiple facet types
-- **Rich event hydration** with external data integration  
-- **Production-ready architecture** with comprehensive error handling
-- **Extensive test coverage** ensuring reliability and maintainability
-
-The smokesignal filtering module now provides a robust foundation for scalable event discovery and filtering capabilities.

docs/filtering/FILTERING_PHASE_4_COMPLETE.md

···
-# Phase 4 I18n Integration - COMPLETE ✅
-
-## Implementation Summary
-
-The Event Filtering System I18n Integration (Phase 4) has been **successfully completed**. This phase integrated the existing event filtering system with i18n infrastructure to enable locale-aware facet calculation, template rendering with dynamic translation functions, and HTMX-aware language propagation.
-
-## Completed Phases
-
-### ✅ Phase 4A Foundation
-- **Translation Keys Added**: Added missing translation keys to both English (`en-us/ui.ftl`) and French (`fr-ca/ui.ftl`) language files
-- **FacetValue Enhanced**: Extended `FacetValue` structure with `display_name` field for locale-specific facet names
-- **Locale-Aware Facet Calculator**: Extended `FacetCalculator` with comprehensive locale-aware methods:
-  - `calculate_facets_with_locale()` - main entry point with locale support
-  - `calculate_mode_facets_with_locale()` - mode facets with translations
-  - `calculate_status_facets_with_locale()` - status facets with translations  
-  - `calculate_date_range_facets_with_locale()` - date range facets with translations
-  - `get_translated_facet_name()` - translation lookup with intelligent fallbacks
-
-### ✅ Phase 4B Service Integration
-- **Cache Key Enhancement**: Updated `FilteringService` with locale-aware cache keys
-- **Locale-Aware Methods**: Added new service methods:
-  - `filter_events_uncached_with_locale()` - locale-aware filtering without caching
-  - `get_facets_with_locale()` - facet retrieval with translations
-  - `filter_events_minimal_with_locale()` - minimal filtering with locale support
-- **HTTP Handler Updates**: Updated all HTTP handlers to use locale-aware methods:
-  - `handle_filter_events` - uses user's language preference
-  - `handle_filter_facets` - provides translated facet names
-  - `handle_filter_suggestions` - locale-aware suggestions
-
-### ✅ Phase 4C Template Migration
-- **Unified Templates**: Created locale-independent templates using `tr()` functions:
-  - `/templates/filter_events.common.html` - unified filtering interface
-  - `/templates/filter_events_results.incl.html` - unified results template
-  - `/templates/filter_events.html` - unified main template
-- **HTMX Integration**: Added proper language headers for HTMX requests:
-  ```html
-  hx-headers='{"Accept-Language": "{{ current_locale }}"}'
-  ```
-- **Enhanced Facet Rendering**: Implemented pre-calculated display names:
-  ```html
-  {{ mode.display_name | default(tr(mode.i18n_key)) }}
-  ```
-
-### ✅ Phase 4D Testing & Validation
-- **Duplicate Key Resolution**: Fixed all duplicate translation keys across `.ftl` files
-- **Fluent Loader Tests**: All i18n loader tests now pass successfully
-- **Test Suite**: All filtering and i18n tests pass (58/63 total tests pass, 5 database-related failures are expected without DATABASE_URL)
-- **Compilation**: Project compiles successfully with no errors
-
-## Key Technical Achievements
-
-### 1. Locale-Aware Facet Calculation
-```rust
-// FacetValue now includes pre-calculated display names
-pub struct FacetValue {
-    pub value: String,
-    pub count: i64,
-    pub i18n_key: Option<String>,
-    pub display_name: Option<String>, // ✅ NEW: Pre-calculated display name
-}
-```
-
-### 2. Translation Integration
-- Integrated `fluent-templates` for runtime translation
-- Implemented intelligent fallback mechanisms for missing translations
-- Added locale-specific caching to improve performance
-
-### 3. Template Unification
-- Eliminated duplicate locale-specific templates
-- Used dynamic `tr()` functions for all user-facing text
-- Maintained HTMX functionality with proper language propagation
-
-### 4. Cache Optimization
-- Cache keys now include locale information for proper isolation
-- Locale-aware facet pre-calculation reduces template rendering overhead
-- Backward compatibility maintained for existing cache entries
-
-## Translation Coverage
-
-### Facet Categories
-- **Event Modes**: In Person, Virtual, Hybrid (English/French)
-- **Event Statuses**: Scheduled, Cancelled, Draft, etc. (English/French)
-- **Date Ranges**: Today, This Week, This Month, etc. (English/French)
-- **UI Labels**: Categories, Event Creators, Date Ranges (English/French)
-
-### User Interface
-- **Filter Controls**: Labels, counts, clear actions (English/French)
-- **Pagination**: Previous/Next navigation (English/French)
-- **Messages**: RSVP status, error messages (English/French)
-
-## Performance Impact
-
-- **Positive**: Pre-calculated `display_name` fields reduce template rendering time
-- **Positive**: Locale-aware caching prevents cross-language cache pollution
-- **Minimal**: Translation lookup overhead is negligible due to fluent-templates optimization
-- **Scalable**: Infrastructure supports additional locales without code changes
-
-## Future Extensions
-
-The implemented infrastructure readily supports:
-1. **Additional Locales**: Simply add new `.ftl` files under `i18n/[locale]/`
-2. **Dynamic Facet Types**: New facet categories automatically inherit i18n support
-3. **Complex Pluralization**: Fluent's advanced plural rules are available
-4. **Regional Variants**: Locale-specific formatting and cultural adaptations
-
-## Validation Status
-
-- ✅ **Compilation**: No build errors
-- ✅ **Unit Tests**: All filtering and i18n tests pass
-- ✅ **Integration Tests**: Locale-aware facet calculation verified
-- ✅ **Template Rendering**: Unified templates with proper translation functions
-- ✅ **HTMX Compatibility**: Language headers propagate correctly
-- ✅ **Cache Isolation**: Locale-specific cache keys working properly
-
-## Files Modified
-
-### Core Implementation
-- `/src/filtering/facets.rs` - Locale-aware facet calculation
-- `/src/filtering/service.rs` - Service layer i18n integration
-- `/src/http/handle_filter_events.rs` - HTTP handler updates
-
-### Templates
-- `/templates/filter_events.common.html` - Unified filtering interface
-- `/templates/filter_events_results.incl.html` - Unified results template
-- `/templates/filter_events.html` - Main template
-- `/templates/filter_events.en-us.html` - Updated to use unified template
-- `/templates/filter_events.fr-ca.html` - Updated to use unified template
-
-### Translations
-- `/i18n/en-us/ui.ftl` - English translation keys (duplicates removed)
-- `/i18n/fr-ca/ui.ftl` - French translation keys (duplicates removed)
-
-### Tests
-- `/src/filtering/mode_status_integration_test.rs` - Updated for new FacetValue structure
-
-## Summary
-
-**Phase 4 I18n Integration is COMPLETE and SUCCESSFUL.** The event filtering system now provides:
-
-1. **Full Internationalization**: All user-facing text supports English and French
-2. **Locale-Aware Caching**: Performance optimized with language-specific cache isolation
-3. **Template Unification**: Eliminated code duplication across language variants
-4. **HTMX Integration**: Seamless language switching without full page reloads
-5. **Extensible Architecture**: Ready for additional languages and locales
-
-The implementation maintains backward compatibility, passes all relevant tests, and provides a solid foundation for future internationalization needs.
-
-
-
-
-
--------------------------
-
-
-
-
-
-
-## Summary of Completed Work
-
-✅ **All compilation issues resolved** - The binary, library, and all tests now compile successfully with only minor warnings about unused code (which is normal).
-
-### Key Achievements:
-
-1. **Made critical methods public for testing access:**
-   - `generate_mode_i18n_key()` - Now public for unit testing
-   - `generate_status_i18n_key()` - Now public for unit testing  
-   - `get_translated_facet_name()` - Now public for unit testing
-   - `calculate_mode_facets_with_locale()` - Now public for integration testing
-   - `calculate_status_facets_with_locale()` - Now public for integration testing
-   - `calculate_date_range_facets_with_locale()` - Now public for integration testing
-
-2. **Fixed i18n integration test module:**
-   - Corrected import from `FLUENT_LOADER` to `LOCALES`
-   - Added missing `fluent_templates::Loader` trait import
-   - Updated tests to focus on key generation functions
-   - Compilation successful with comprehensive test coverage
-
-3. **Fixed binary test file:**
-   - Added proper database connection handling with graceful fallback
-   - Updated constructor calls to include required PgPool parameter
-   - Made async method calls with proper error handling using `?` operator
-   - Added comprehensive database availability checking
-
-4. **Maintained backwards compatibility:**
-   - All existing functionality preserved
-   - Original private methods remain private where appropriate
-   - Public interface additions follow Rust visibility best practices
-
-### Final Status:
-- **✅ Library compilation**: Success (2 minor warnings about unused helper functions)
-- **✅ Test compilation**: Success (all tests compile and can run)
-- **✅ Binary compilation**: Success (i18n integration binary ready for execution)
-- **✅ All targets compilation**: Success (comprehensive check passed)
-
-The Phase 4 I18n Integration is now fully complete and ready for production use. The locale-aware facet calculation system can be thoroughly tested through both unit tests and the integration binary, with proper database connection handling and comprehensive error management.

docs/filtering/FILTERING_TODO.md

···
-# Smokesignal Event Filtering Module - Technical Summary
-
-## Project Context
-
-This document summarizes the design and implementation approach for a new event filtering module in the Smokesignal application, a Rust-based social platform built on ATproto. The module provides faceted search and filtering capabilities for events while integrating with the existing i18n and caching infrastructure.
-
-## Core Requirements
-
-1. **Filtering Capabilities**: Support filtering events by multiple criteria including text search, dates, categories, and geolocation
-2. **Faceted Navigation**: Display available filtering options with counts for each facet value
-3. **HTMX Integration**: Support partial page updates with stateful filtering
-4. **I18n Support**: Full internationalization of filters and facets
-5. **ATproto Hydration**: Populate events with user profiles and related data
-6. **Redis Cache Integration**: Optimize performance using existing cache infrastructure
-
-## Architecture Overview
-
-```
-src/filtering/
-├── mod.rs              # Module exports and organization
-├── query_builder.rs    # Dynamic SQL construction
-├── service.rs          # Main filtering coordination
-├── facets.rs           # Facet calculation logic
-├── hydration.rs        # Event data enrichment
-├── errors.rs           # Error handling types
-└── criteria.rs         # Filter criteria definitions
-
-src/http/
-└── middleware_filter.rs  # Filter extraction middleware
-
-templates/
-└── templates_filter.html # HTMX-compatible templates
-```
-
-## Event Filter Criteria Model
-
-```rust
-#[derive(Debug, Clone, Default, Hash)]
-pub struct EventFilterCriteria {
-    pub search_term: Option<String>,
-    pub categories: Vec<String>,
-    pub start_date: Option<chrono::DateTime<chrono::Utc>>,
-    pub end_date: Option<chrono::DateTime<chrono::Utc>>,
-    pub location: Option<LocationFilter>,
-    pub creator_did: Option<String>,
-    pub page: usize,
-    pub page_size: usize,
-    pub sort_by: EventSortField,
-    pub sort_order: SortOrder,
-}
-
-#[derive(Debug, Clone)]
-pub struct LocationFilter {
-    pub latitude: f64,
-    pub longitude: f64, 
-    pub radius_km: f64,
-}
-```
-
-## I18n Integration Requirements
-
-The filtering module must integrate with the application's existing i18n system:
-
-1. **Template Functions**: Use direct template functions instead of pre-rendered translations
-   ```html
-   <h3>{{ t(key="categories", locale=locale) }}</h3>
-   ```
-
-2. **Facet Translation**: Support translation of facet values
-   ```rust
-   // Create i18n keys for facet values
-   category.i18n_key = format!("category-{}", category.name.to_lowercase()
-       .replace(" ", "-").replace("&", "and"));
-   ```
-
-3. **HTMX Language Propagation**: Work with the language middleware
-   ```html
-   <form hx-get="/events" hx-target="#events-results">
-     <!-- HX-Current-Language automatically added by middleware -->
-   </form>
-   ```
-
-## QueryBuilder Pattern
-
-```rust
-pub struct EventQueryBuilder {
-    pool: PgPool,
-}
-
-impl EventQueryBuilder {
-    pub async fn build_and_execute(
-        &self, 
-        criteria: &EventFilterCriteria
-    ) -> Result<Vec<Event>, FilterError> {
-        let mut query = sqlx::QueryBuilder::new("SELECT * FROM events WHERE 1=1 ");
-        
-        // Apply filters conditionally
-        if let Some(term) = &criteria.search_term {
-            query.push(" AND (name ILIKE ");
-            query.push_bind(format!("%{}%", term));
-            query.push(")");
-        }
-        
-        // Location filtering using PostGIS
-        if let Some(location) = &criteria.location {
-            query.push(" AND ST_DWithin(
-                ST_MakePoint((record->'location'->>'longitude')::float8, 
-                             (record->'location'->>'latitude')::float8)::geography,
-                ST_MakePoint($1, $2)::geography,
-                $3
-            )");
-            query.push_bind(location.longitude);
-            query.push_bind(location.latitude);
-            query.push_bind(location.radius_km * 1000.0);
-        }
-        
-        // Pagination and sorting
-        query.push(" ORDER BY ");
-        // ... sorting logic
-        query.push(" LIMIT ")
-            .push_bind(criteria.page_size)
-            .push(" OFFSET ")
-            .push_bind(criteria.page * criteria.page_size);
-        
-        Ok(query.build().fetch_all(&self.pool).await?)
-    }
-}
-```
-
-## Cache Integration with Redis
-
-```rust
-impl EventFilterService {
-    pub async fn filter_and_hydrate(
-        &self, 
-        criteria: &EventFilterCriteria,
-        locale: &str
-    ) -> Result<FilterResults, FilterError> {
-        let cache_key = self.generate_filter_cache_key(criteria, locale);
-        
-        // Try cache first
-        if let Ok(Some(cached_data)) = self.cache_pool.get::<FilterResults>(&cache_key).await {
-            tracing::debug!("Cache hit for filter results: {}", cache_key);
-            return Ok(cached_data);
-        }
-        
-        // Cache miss - perform database query and hydration
-        tracing::debug!("Cache miss for filter results: {}", cache_key);
-        
-        // Execute query, hydrate events, calculate facets
-        // ...
-        
-        // Store in cache with TTL
-        let _ = self.cache_pool
-            .set_with_expiry(&cache_key, &results, self.config.cache_ttl)
-            .await;
-            
-        Ok(results)
-    }
-    
-    fn generate_filter_cache_key(&self, criteria: &EventFilterCriteria, locale: &str) -> String {
-        // Create a stable hash from filter criteria + language
-        let mut hasher = DefaultHasher::new();
-        criteria.hash(&mut hasher);
-        let criteria_hash = hasher.finish();
-        
-        format!("filter:results:{}:{}", locale, criteria_hash)
-    }
-}
-```
-
-## Facet Calculation Logic
-
-```rust
-pub async fn calculate_facets(
-    pool: &PgPool,
-    criteria: &EventFilterCriteria,
-    locale: &str
-) -> Result<EventFacets, FilterError> {
-    // Calculate categories without applying the category filter itself
-    let categories = sqlx::query!(
-        r#"
-        SELECT DISTINCT 
-            jsonb_array_elements_text(record->'content'->'categories') as category,
-            COUNT(*) as count
-        FROM events
-        WHERE 1=1
-        -- Apply all other criteria except categories
-        GROUP BY category
-        ORDER BY count DESC
-        LIMIT 20
-        "#
-    )
-    .fetch_all(pool)
-    .await?;
-    
-    // Transform into facets with i18n keys
-    let category_facets = categories.into_iter()
-        .map(|r| CategoryFacet {
-            name: r.category.unwrap_or_default(),
-            count: r.count as usize,
-            selected: criteria.categories.contains(&r.category.unwrap_or_default()),
-            i18n_key: format!("category-{}", r.category.unwrap_or_default()
-                              .to_lowercase().replace(" ", "-")),
-        })
-        .collect();
-    
-    // Calculate other facets (date ranges, locations)
-    // ...
-    
-    Ok(EventFacets {
-        categories: category_facets,
-        dates: calculate_date_facets(pool, criteria).await?,
-        locations: calculate_location_facets(pool, criteria).await?,
-    })
-}
-```
-
-## HTMX Template Integration
-
-```html
-<!-- events/filter.html -->
-<div class="filter-container">
-  <form hx-get="/events" 
-        hx-target="#events-results"
-        hx-push-url="true"
-        hx-trigger="change">
-    
-    <div class="search-bar">
-      <input type="search" 
-             name="q" 
-             value="{{ search_term }}"
-             placeholder="{{ t(key='search-events', locale=locale) }}"
-             hx-trigger="keyup changed delay:500ms">
-    </div>
-    
-    <div class="filter-section">
-      <h3>{{ t(key='categories', locale=locale) }}</h3>
-      {% for category in facets.categories %}
-        <label class="filter-checkbox">
-          <input type="checkbox" 
-                 name="category" 
-                 value="{{ category.name }}"
-                 {% if category.selected %}checked{% endif %}>
-          {{ t(key=category.i18n_key, locale=locale, default=category.name) }} ({{ category.count }})
-        </label>
-      {% endfor %}
-    </div>
-    
-    <!-- Other filter sections -->
-  </form>
-</div>
-
-<div id="events-results">
-  {% include "events/results.html" %}
-</div>
-```
-
-## HTTP Handler Implementation
-
-```rust
-pub async fn list_events(
-    ctx: UserRequestContext,
-    filter_criteria: Extension<EventFilterCriteria>,
-) -> impl IntoResponse {
-    let is_htmx = is_htmx_request(&ctx.request);
-    
-    // Filter & hydrate events
-    let filter_service = EventFilterService::new(
-        ctx.web_context.pool.clone(),
-        ctx.web_context.http_client.clone(),
-        ctx.web_context.cache_pool.clone()
-    );
-    
-    let results = match filter_service.filter_and_hydrate(
-        &filter_criteria, 
-        &ctx.language.0.to_string()
-    ).await {
-        Ok(r) => r,
-        Err(e) => {
-            tracing::error!(error = %e, "Failed to filter events");
-            return (StatusCode::INTERNAL_SERVER_ERROR, 
-                render_error_alert(&ctx, "error-filter-failed")).into_response();
-        }
-    };
-    
-    // Choose template based on request type
-    let template_name = if is_htmx {
-        format!("events/results.{}.html", ctx.language.0)
-    } else {
-        format!("events/index.{}.html", ctx.language.0)
-    };
-    
-    // Render with i18n
-    render_with_i18n(
-        ctx.web_context.engine.clone(),
-        template_name,
-        ctx.language.0,
-        template_context! {
-            events => results.events,
-            facets => results.facets,
-            search_term => filter_criteria.search_term,
-            // Other context values...
-        }
-    )
-}
-```
-
-## Implementation Strategy
-
-The module should be implemented in phases:
-
-1. **Phase 1**: Core filter criteria and query building
-   - Define filter criteria types
-   - Implement SQL query builder
-   - Create basic middleware for extraction
-
-2. **Phase 2**: Facet calculation and hydration
-   - Implement facet calculation queries
-   - Build ATproto hydration service
-   - Set up basic templates
-
-3. **Phase 3**: Cache integration
-   - Integrate with Redis cache
-   - Set up cache invalidation
-   - Implement progressive caching
-
-4. **Phase 4**: I18n integration
-   - Add i18n keys to facets
-   - Integrate with HTMX language propagation
-   - Update templates to use i18n functions
-
-5. **Phase 5**: UI refinement and optimization
-   - Improve template responsiveness
-   - Add mobile-friendly filters
-   - Optimize performance
-
-## Testing Requirements
-
-Tests should cover:
-
-1. **Unit tests** for filter criteria extraction and query building
-   ```rust
-   #[test]
-   fn test_location_filter_query_building() {
-       // Test geographical filtering
-   }
-   ```
-
-2. **Integration tests** for facet calculation
-   ```rust
-   #[sqlx::test]
-   async fn test_category_facets_calculation() {
-       // Test facet calculation with sample data
-   }
-   ```
-
-3. **I18n tests** for facet translation
-   ```rust
-   #[test]
-   fn test_facet_i18n_keys_generated_correctly() {
-       // Test i18n key generation for facets
-   }
-   ```
-
-4. **Cache tests** for proper invalidation
-   ```rust
-   #[test]
-   async fn test_cache_invalidation_on_event_update() {
-       // Test cache keys are properly invalidated
-   }
-   ```
-
-5. **HTMX interaction** tests
-   ```rust
-   #[test]
-   async fn test_htmx_filter_updates() {
-       // Test HTMX responses contain correct headers
-   }
-   ```
-
-## Performance Considerations
-
-- Use batch loading for ATproto hydration
-- Apply tiered caching (facets vs. hydrated events)
-- Implement conditional facet calculation
-- Use optimized SQL queries with appropriate indexes
-- Consider adding JSONB GIN indexes on event categories
-
-## Migration Plan
-
-When implementing this module:
-
-1. Create a feature flag `event-filtering` to enable/disable the feature
-2. Add a migration for geospatial indexes if needed
-3. Deploy the core filtering features first, without facets
-4. Add facets and i18n integration in subsequent releases
-5. Implement advanced caching as a final optimization
-
-## I18n Development Guidelines
-
-### I18n Architecture Goals
-
-- **HTMX-first design**: Seamless language propagation across partial page updates
-- **Performance-optimized**: On-demand translation calculation instead of pre-rendering
-- **Romance language support**: Gender agreement (masculine/feminine/neutral)
-- **Fluent-based**: Mozilla Fluent for sophisticated translation features
-- **Template integration**: Direct i18n functions in Jinja2 templates
-
-### Core Modules Structure
-
-```
-src/i18n/
-├── mod.rs              # Main i18n exports and Locales struct  
-├── errors.rs           # Structured error types for i18n operations
-├── fluent_loader.rs    # Fluent file loading (embed vs reload modes)
-└── template_helpers.rs # Template function integration
-
-src/http/
-├── middleware_i18n.rs  # HTMX-aware language detection middleware
-├── template_i18n.rs    # Template context with gender support
-└── templates.rs        # Template rendering with integrated i18n functions
-```
-
-### Language Detection Priority
-
-Implement language detection with this exact priority order for HTMX compatibility:
-
-1. **HX-Current-Language header** (highest priority for HTMX requests)
-2. **User profile language** (if authenticated)
-3. **lang cookie** (session preference)
-4. **Accept-Language header** (browser preference)
-5. **Default language** (fallback)
-
-### Template Integration Pattern
-
-Replace pre-rendered translation HashMap with direct template functions:
-
-#### ❌ Avoid (pre-rendering approach)
-```rust
-// Don't pre-calculate all translations
-let mut translations = HashMap::new();
-translations.insert("profile-greeting".to_string(), i18n_context.tg(...));
-```
-
-#### ✅ Use (on-demand functions)
-```rust
-// Register i18n functions in template engine
-env.add_function("t", |args| { /* basic translation */ });
-env.add_function("tg", |args| { /* gender-aware translation */ });
-env.add_function("tc", |args| { /* count-based pluralization */ });
-```
-
-### HTMX Integration Requirements
-
-#### Middleware Implementation
-```rust
-pub async fn htmx_language_middleware<B>(request: Request<B>, next: Next<B>) -> Response {
-    let is_htmx = request.headers().get("HX-Request").is_some();
-    
-    // Detect language with HTMX priority
-    let locale = detect_language_with_htmx_priority(&request);
-    
-    // Inject into request extensions
-    request.extensions_mut().insert(Language(locale.clone()));
-    
-    let mut response = next.run(request).await;
-    
-    // Add language propagation header for HTMX
-    if is_htmx {
-        response.headers_mut().insert("HX-Language", locale.to_string().parse().unwrap());
-    }
-    
-    response
-}
-```
-
-### Gender Support
-
-```rust
-#[derive(Debug, Clone)]
-pub enum Gender {
-    Masculine,
-    Feminine,
-    Neutral,
-}
-
-impl Gender {
-    pub fn as_str(&self) -> &'static str {
-        match self {
-            Gender::Masculine => "masculine",
-            Gender::Feminine => "feminine", 
-            Gender::Neutral => "neutral",
-        }
-    }
-}
-```
-
-### Fluent File Organization
-
-```
-i18n/
-├── en-us/
-│   ├── common.ftl    # Shared UI elements
-│   ├── errors.ftl    # Error messages
-│   └── ui.ftl        # Interface text
-└── fr-ca/
-    ├── common.ftl
-    ├── errors.ftl
-    └── ui.ftl
-```
-
-### Error Handling
-
-All i18n error strings must follow this format:
-```
-error-smokesignal-i18n-<domain>-<number> <message>: <details>
-```
-
-Example errors:
-```
-error-smokesignal-i18n-fluent-1 Translation key not found: profile-greeting
-error-smokesignal-i18n-locale-2 Unsupported language identifier: xx-XX
-error-smokesignal-i18n-template-3 Template function argument missing: locale
-```
-
-### Code Comments
-
-Keep all code comments in English:
-```rust
-// Create i18n context with user-specific gender preferences
-let i18n_context = TemplateI18nContext::new(locale, locales)
-    .with_gender(user_gender.unwrap_or(Gender::Neutral));
-```
-
-### Ressources 
-
-https://docs.rs/axum-template/3.0.0/axum_template/index.html
-https://docs.rs/minijinja/latest/minijinja/index.html
-https://github.com/projectfluent/fluent/wiki/

docs/i18n/COMMIT_SUMMARY-V1.md

···
-Template Rendering System Refactoring - Complete Summary
-
-## COMMIT READY: All 16+ compilation errors resolved ✅
-
-### Major Changes:
-- **NEW FILE**: `src/http/template_renderer.rs` (350 lines) - Unified template rendering system
-- **ENHANCED**: 11 existing files with API fixes and modernization
-- **DOCUMENTATION**: Updated README.md to correct CSS framework reference (Tailwind → Bulma)
-- **STATS**: +447 lines added, -167 lines removed (net +280 lines)
-
-### Key Fixes Applied:
-
-1. **API Compatibility (5 fixes)**:
-   - Fixed `merge_maps()` calls in OAuth handler with `.clone()`
-   - Corrected field access: `admin_ctx.user_handle` → `admin_ctx.admin_handle.handle`
-   - Fixed Handle deref: `auth.0.as_deref()` → `auth.0.as_ref().map(|h| h.handle.as_str())`
-   - Replaced manual Value.insert() with `minijinja::context!` macro
-   - Fixed Language type mismatches with `Language(language)` wrapper
-
-2. **Centralized Template Rendering**:
-   - Created `TemplateRenderer` struct with builder pattern
-   - Added `create_renderer!` macro for easy instantiation
-   - Enhanced `contextual_error!` macro with renderer support
-   - Unified context enrichment (i18n, HTMX, gender)
-
-3. **Performance Optimizations**:
-   - Added HTMX header constants for faster detection
-   - Optimized language detection with early exit
-   - Enhanced I18n template context for dynamic locale support
-
-4. **Modernized Handlers**:
-   - `handle_admin_index.rs` - Converted to TemplateRenderer
-   - `handle_oauth_login.rs` - Fixed API compatibility errors
-   - `handle_view_feed.rs` - Fixed Language type issues
-   - `handle_view_rsvp.rs` - Fixed Value insertion and Language types
-
-5. **Documentation Updates**:
-   - Corrected CSS framework references from Tailwind CSS to Bulma CSS
-   - Updated README.md Features and Technology Stack sections
-
-### Build Status: ✅ SUCCESSFUL
-```
-cargo build
-Finished `dev` profile [unoptimized + debuginfo] target(s) in 31.05s
-```
-
-### Files Changed:
-Modified: 11 files
-New: 1 file (`src/http/template_renderer.rs`)
-Documentation: 3 files (README.md corrected, 2 files in `docs/`)
-
-### Suggested Commit Message:
-```
-feat: implement unified template rendering system
-
-- Add centralized TemplateRenderer with i18n, HTMX, and gender context
-- Fix 16+ compilation errors from i18n migration
-- Enhance macros with create_renderer! and improved contextual_error!
-- Optimize i18n middleware with HTMX constants and early exit
-- Modernize all HTTP handlers to use unified rendering system
-- Add I18nTemplateContext for dynamic locale support
-- Improve error handling consistency across handlers
-- Update documentation to correct CSS framework (Tailwind → Bulma)
-
-BREAKING: Template rendering API consolidated into TemplateRenderer
-FIXED: All minijinja API compatibility issues resolved
-PERF: Optimized language detection and HTMX header parsing
-DOCS: Corrected CSS framework references in README.md
-
-Files: +350 lines template_renderer.rs, 11 modified files, README.md updated
-Status: All compilation errors resolved, system fully functional
-```
-
-### Ready for: Testing → Staging → Production
-
-This refactoring provides a solid foundation for future template enhancements while maintaining backward compatibility and improving code maintainability.

docs/i18n/Claude-TODO-V1.md

···
-This file provides guidance to Claude Code (claude.ai/code) when working with the i18n refactoring migration in this repository.
-
-**Project Overview**
-This is a comprehensive i18n refactoring guide for migrating Smokesignal's i18n system from a complex manual `.ftl` file loading system to `fluent-templates` for simplified architecture and improved performance.
-
-**Common Commands**
-* **Build**: `cargo build`
-* **Check code**: `cargo check --lib`
-* **Run tests**: `cargo test`
-* **Run specific test**: `cargo test fluent_loader`
-* **Run template tests**: `cargo test template_helpers`
-* **Run middleware tests**: `cargo test middleware_i18n`
-* **Run integration tests**: `cargo test template`
-* **Run i18n tests**: `cargo test i18n`
-* **Format code**: `cargo fmt`
-* **Lint**: `cargo clippy`
-
-* All translation files are in i18n folder. 
-
-**Migration Steps**
-
-**Step 1: Analysis of Existing System**
-Analyze current i18n implementation to understand dependencies and architecture.
-
-**Step 2: New fluent-templates Module**
-Reference documentation:
-* https://github.com/XAMPPRocky/fluent-templates
-* https://docs.rs/fluent/latest/fluent/all.html
-* https://docs.rs/minijinja/latest/minijinja/all.html
-
-Controls:
-* Module compiles: `cargo check --lib`
-* Tests pass: `cargo test fluent_loader`
-* No API regression
-
-**Step 3: Template Helpers Adaptation**
-Adapt existing template helpers to work with fluent-templates.
-
-Controls:
-* Helpers compile
-* Existing templates work
-* Test: `cargo test template_helpers`
-
-**Step 3.5: Context Adaptation**
-Update context.rs for simplified I18nContext.
-
-Controls:
-* Simplified I18nContext compiles
-* Translation helpers work
-* Template contexts include locale
-
-**Step 4: Architecture Simplification**
-Create new main module mod.rs for unified API.
-
-Controls:
-* Main module compiles
-* Compatible API maintained
-* Integration tests pass
-
-**Step 4.5: i18n Middleware Optimization**
-Update middleware_i18n.rs for performance improvements.
-
-Controls:
-* Middleware compiles with optimizations
-* Enriched HTMX headers work
-* Faster language detection
-* Tests pass: `cargo test middleware_i18n`
-
-**Step 5: Template Updates**
-Adapt template engine for fluent-templates integration.
-
-Controls:
-* Template engine compiles
-* i18n helpers work
-* Existing templates display correctly
-
-**Step 5.5: Template Handler Refactoring**
-Refactor template handler for complete functionality.
-
-Controls:
-* Template handler compiles without error
-* All template functions available
-* Extended tests pass: `cargo test template_handler`
-* Locale and gender validation works
-* HTMX/URL helpers available
-
-**Step 6: Testing and Validation**
-Complete system and integration testing.
-
-Controls:
-* Unit tests pass: `cargo test i18n`
-* Integration tests pass: `cargo test template`
-* Existing page rendering correct
-
-**Step 7: Cleanup and Optimization**
-Remove obsolete code and update dependencies.
-
-Controls:
-* Successful compilation after cleanup
-* Reduced dependency size
-* Improved performance (compilation time)
-
-**Step 8: Performance Testing and Final Validation**
-Benchmark performance improvements.
-
-Controls:
-* Benchmarks show performance improvement
-* Application starts without error
-* Pages load with correct translations
-* Language switching works
-
-**Step 9.5: Main Binary Update**
-Adapt smokesignal.rs for fluent-templates integration.
-
-Controls:
-* Application starts with fluent-templates
-* Translation validation at startup
-* Logs confirm proper functioning
-* Performance equal or superior to old system
-* Documentation updated to reflect changes
-* No functional regression
-
-**Final Migration Checklist**
-
-**Core Functionality**
-* fluent-templates integrated and functional
-* Gender support preserved (fr-ca)
-* Compatible API maintained
-* Existing templates work
-* Template helpers operational
-
-**Performance and Architecture**
-* Static loading at compile time
-* Reduced dependencies (5 crates removed)
-* Improved compilation time
-* Reduced memory usage
-* Simplified architecture
-
-**Compatibility**
-* No functional regression
-* All translations available (en-us, fr-ca)
-* 5 .ftl files per language loaded
-* Fallback to key if translation missing
-* Support for arguments in translations
-
-**Testing and Validation**
-* Unit tests pass
-* Integration tests pass
-* Application starts without error
-* Performance equal or superior
-* i18n_checker tool functional
-
-**Expected Results**
-* **Performance**: Static loading at compile time
-* **Architecture**: Code simplification (removal of ~500 lines)
-* **Dependencies**: Reduction of 5 external crates
-* **Maintenance**: Simpler and more robust API
-

docs/i18n/Claude.prompts.md

···
-# i18n Refactoring Prompts
-
-## Analysis and Assessment
-
-**Analyze current i18n implementation**
-Analyze the existing i18n system in this repository to understand the current architecture, dependencies, and manual `.ftl` file loading system. Identify all components that will need to be migrated to `fluent-templates`. Think very very hard about the dependencies and interconnections.
-
-**Review translation file completeness**
-Review all `.ftl` files in the i18n folder and ensure that all translations are complete across all supported languages (en-us, fr-ca). Identify any missing translations, inconsistent keys, duplicates across same locale files or unused translation strings. Think very very hard about translation coverage.
-
-**Identify i18n performance bottlenecks**
-Analyze the current i18n system for performance issues, including runtime file loading, memory usage, and translation lookup efficiency. Identify opportunities for compile-time optimization. Think very very hard about performance implications.
-
-## Migration and Implementation
-
-**Implement fluent-templates integration**
-Create a new fluent-templates module that replaces the manual `.ftl` file loading system. Ensure static loading at compile time and maintain compatibility with existing template helpers. Use `cargo check --lib` and `cargo test fluent_loader` to validate implementation.
-
-**Adapt template helpers for fluent-templates**
-Update existing template helpers to work seamlessly with the new fluent-templates system. Ensure all i18n functionality is preserved, including gender support for fr-ca. Test with `cargo test template_helpers` to verify functionality.
-
-**Optimize i18n middleware performance**
-Refactor middleware_i18n.rs to improve language detection speed and optimize HTMX header enrichment. Ensure the middleware compiles with optimizations and passes all tests with `cargo test middleware_i18n`.
-
-## Context and Architecture
-
-**Simplify I18nContext implementation**
-Update context.rs to create a simplified I18nContext that works efficiently with fluent-templates. Ensure translation helpers function correctly and template contexts properly include locale information.
-
-**Create unified i18n API module**
-Design and implement a new main module (mod.rs) that provides a unified, simplified API for the i18n system. Maintain API compatibility while reducing architectural complexity. Validate with integration tests.
-
-**Refactor template handler for i18n**
-Update the template handler to fully integrate with fluent-templates. Ensure all template functions remain available, locale and gender validation works correctly, and HTMX/URL helpers are preserved. Test with `cargo test template_handler`.
-
-## Testing and Validation
-
-**Validate i18n system functionality**
-Run comprehensive tests to ensure the migrated i18n system works correctly: `cargo test i18n`, `cargo test template`, and `cargo test template_helpers`. Verify that existing page rendering remains correct and all translations display properly.
-
-**Test gender support preservation**
-Specifically test that gender support for French Canadian (fr-ca) translations is fully preserved in the new fluent-templates system. Verify that gendered translations work correctly in all contexts.
-
-**Validate translation fallback behavior**
-Test that the system properly falls back to translation keys when translations are missing, and that this behavior is consistent across all supported languages and contexts.
-
-## Performance and Optimization
-
-**Benchmark i18n performance improvements**
-Create benchmarks to measure performance improvements from the migration to fluent-templates. Compare compilation time, memory usage, and translation lookup speed between the old and new systems.
-
-**Analyze dependency reduction impact**
-After migration, verify that the expected 5 external crates have been successfully removed from dependencies. Analyze the impact on compilation time and binary size. Use `cargo tree` to validate dependency reduction.
-
-**Optimize compile-time translation loading**
-Ensure that all translation files are loaded statically at compile time rather than runtime. Verify that this optimization is working correctly and measure the performance impact.
-
-## Cleanup and Maintenance
-
-**Update i18n documentation**
-Update all documentation to reflect the new fluent-templates architecture. Ensure that API documentation, README files, and inline comments accurately describe the simplified system.
-
-
-## Final Validation
-
-**Perform complete i18n regression testing**
-Run the complete test suite and verify that there are no functional regressions: all tests pass, the application starts without error, pages load with correct translations, and language switching works seamlessly.
-
-**Validate main binary i18n integration**
-Test that smokesignal.rs properly integrates with the new fluent-templates system. Verify that translation validation occurs at startup, logs confirm proper functioning, and performance is equal or superior to the old system.
-
-**Confirm translation completeness across languages**
-Perform a final verification that all 5 .ftl files per language are properly loaded and that all translations are available for both en-us and fr-ca locales. Test edge cases and ensure robust error handling.
-
-
-
-
-
-
-
-
-### rate limit lasts prompts for debug and restart
-
-Based on the progress tracker and the files listed, let's focus on completing 
- the acknowledgement templates, then move to cookie-policy, import, migrate_event, and create_rsvp.
-
-First, let's migrate the acknowledgement templates:

docs/i18n/Commit_sumary_migration-V2.md

···
-## Summary of Main View Template Migration
-
-I have successfully completed the migration of the main view templates for the smokesignal project's i18n integration. Here's what was accomplished:
-
-### **Templates Migrated and Created:**
-
-#### **English Templates (Migrated to use tr() functions):**
-- view_event.en-us.common.html - Main event view template
-- view_rsvp.en-us.common.html - RSVP viewer template
-- view_rsvp.en-us.partial.html - RSVP partial template
-
-#### **French Canadian Templates (Created with full i18n support):**
-- view_event.fr-ca.html - Event view page
-- view_event.fr-ca.common.html - Event view content
-- view_rsvp.fr-ca.html - RSVP viewer page
-- view_rsvp.fr-ca.common.html - RSVP viewer content
-- view_rsvp.fr-ca.partial.html - RSVP partial content
-
-### **Translation Keys Added:**
-
-#### **English Fluent Files Enhanced:**
-- **actions.ftl**: Added view actions, RSVP actions, migration actions
-- **common.ftl**: Added event statuses, modes, timing, RSVP messages, legacy event messages
-- **forms.ftl**: Added tooltips and helper messages
-
-#### **French Canadian Fluent Files Enhanced:**
-- **actions.ftl**: Complete French translations for all view actions
-- **common.ftl**: Full French translations with proper gender-aware variants
-- **forms.ftl**: French tooltips and helper messages
-
-### **Key Features Implemented:**
-
-1. **Complete Event Status i18n**: All event statuses (planned, scheduled, cancelled, etc.) with tooltips
-2. **Event Mode i18n**: In-person, virtual, hybrid event modes
-3. **RSVP System i18n**: Going, interested, not going statuses with user feedback messages
-4. **Legacy Event Support**: Messages for older event versions and migration options
-5. **Map Integration i18n**: Apple Maps and Google Maps link labels
-6. **Authentication Messages**: Login prompts for RSVP functionality
-7. **RSVP Viewer Tool**: Complete translation for the RSVP lookup interface
-
-### **Advanced i18n Features:**
-
-- **Parameterized Translations**: Using Fluent's parameterization for dynamic content (e.g., event counts, times)
-- **HTML-aware Translations**: Proper handling of HTML markup within translations
-- **Gender-aware French**: Appropriate masculine/feminine variants where applicable
-- **Contextual Tooltips**: Translated tooltip text for better UX
-
-### **Next Steps:**
-
-The main view template migration is now **complete**. The remaining work includes:
-
-1. **Admin Templates**: Migrate admin*.html templates for administrative interface
-2. **Remaining Templates**: Complete audit of remaining 60+ templates for any missed hardcoded text
-3. **Testing**: Language switching and HTMX partial rendering with i18n
-4. **Performance**: Template caching optimization and performance testing
-
-The smokesignal project now has fully internationalized event viewing and RSVP functionality, with both English and French Canadian language support ready for production use.
-
-
-
-
-
-
-
-----------------------
-
-
-
-
-
-
-
-
-
-
-
-
-✅ COMPLETED: Admin Templates Migration
-Admin Interface - Complete i18n Integration
-Main admin page: admin.en-us.html → admin.fr-ca.html
-Handles management: admin_handles.en-us.html → admin_handles.fr-ca.html
-Events management: admin_events.en-us.html → admin_events.fr-ca.html
-Denylist management: admin_denylist.en-us.html → admin_denylist.fr-ca.html
-RSVPs management: admin_rsvps.en-us.html → admin_rsvps.fr-ca.html
-Single event view: admin_event.en-us.html → admin_event.fr-ca.html
-Single RSVP view: admin_rsvp.en-us.html → admin_rsvp.fr-ca.html
-Translation Keys Added
-Admin interface: Complete admin navigation, page titles, form labels
-Admin actions: Import, view, edit, delete, remove functionality
-Admin data tables: Column headers for all admin list views
-Admin confirmations: Confirmation dialogs for destructive actions
-Admin status messages: Success messages, error handling
-French Canadian Translations
-Complete professional French translations for all admin functionality
-Gender-aware variants where applicable
-Administrative terminology appropriate for Quebec French
-Technical Implementation
-All hardcoded English text replaced with tr() i18n functions
-Parameterized translations for dynamic content (counts, timestamps)
-Consistent template structure between English and French variants
-Breadcrumb navigation fully internationalized
-HTMX integration maintained with i18n support
-Build Validation
-All admin templates compile successfully with cargo check
-No template syntax errors introduced during migration
-Maintains existing functionality while adding language support
-🚀 Next Priority Templates
-The remaining high-priority templates to migrate are:
-
-Settings templates (settings.en-us.html, settings.en-us.common.html)
-User profile (profile.en-us.html)
-Authentication (login.en-us.html)
-Event editing (edit_event.en-us.html)
-Legal pages (privacy-policy.en-us.html, terms-of-service.en-us.html)
-The project now has substantial completion of Phase 1 with most major user-facing and administrative functionality fully internationalized. The admin interface migration represents a significant milestone as it provides complete bilingual support for system administration.

docs/i18n/FINAL_STATUS-v1.md

···
-# Template Rendering System Refactoring - Complete
-
-## Summary
-
-Successfully completed a comprehensive refactoring of the smokesignal Rust web application's template rendering system. The goal was to implement a unified `TemplateRenderer` struct that centralizes i18n, HTMX, and gender context handling, replacing scattered template rendering logic throughout the codebase.
-
-**Status**: ✅ **COMPLETE - All compilation errors resolved, system fully functional**
-
-## Baseline
-
-Starting from commit `96310e5` (feat: migrate i18n system from custom fluent to fluent-templates), the codebase had 16+ compilation errors due to API changes from the i18n migration and scattered template rendering logic that needed centralization.
-
-## Objectives Achieved
-
-### 1. ✅ Centralized Template Rendering System
-- **Created**: `src/http/template_renderer.rs` - New unified template rendering system
-- **Implemented**: `TemplateRenderer` struct with builder pattern for consistent context enrichment
-- **Features**: Automatic i18n, HTMX, gender, and error context injection
-
-### 2. ✅ Fixed All Compilation Errors (16+ errors resolved)
-
-#### API Compatibility Issues Fixed:
-- **minijinja API changes**: Fixed 5 `merge_maps()` calls in OAuth handler by adding `.clone()` to pass owned Values
-- **Field access errors**: Corrected `admin_ctx.user_handle` → `admin_ctx.admin_handle.handle` in admin handler
-- **Handle deref issues**: Updated `auth.0.as_deref()` → `auth.0.as_ref().map(|h| h.handle.as_str())` since Handle doesn't implement Deref
-- **Value insertion errors**: Replaced manual `minijinja::Value.insert()` with proper `minijinja::context!` macro usage
-- **Language type mismatches**: Fixed `LanguageIdentifier` vs `Language` wrapper type issues using `Language(language)` constructor
-
-### 3. ✅ Enhanced Macro System
-- **Created**: `create_renderer!` macro for easy TemplateRenderer instantiation
-- **Enhanced**: `contextual_error!` macro with template renderer integration
-- **Improved**: Error handling consistency across all handlers
-
-### 4. ✅ Optimized I18n Integration
-- **Added**: HTMX header constants (`HX_REQUEST`, `HX_TRIGGER`) for performance
-- **Enhanced**: Language detection with early exit optimizations
-- **Created**: `I18nTemplateContext` for dynamic locale support in templates
-- **Improved**: Template helpers with better i18n integration
-
-### 5. ✅ Handler Modernization
-All HTTP handlers converted to use the unified TemplateRenderer:
-- `handle_admin_index.rs` - Admin interface with proper context
-- `handle_oauth_login.rs` - OAuth flow with fixed API compatibility
-- `handle_view_feed.rs` - Event feed rendering with i18n
-- `handle_view_rsvp.rs` - RSVP interface with gender context
-
-## Technical Implementation Details
-
-### Core Components Created
-
-#### TemplateRenderer (`src/http/template_renderer.rs`)
-```rust
-pub struct TemplateRenderer<'a> {
-    template_engine: &'a Environment<'a>,
-    i18n_context: &'a I18nTemplateContext,
-    language: Language,
-    is_htmx: bool,
-    gender_context: Option<&'a GenderContext>,
-}
-```
-
-**Key Features**:
-- Builder pattern for flexible context composition
-- Automatic context enrichment with i18n, HTMX, gender data
-- Consistent error template rendering
-- Type-safe template rendering with proper error handling
-
-#### Enhanced Macros (`src/http/macros.rs`)
-```rust
-// Simplified renderer creation
-create_renderer!(template_engine, i18n_context, language, is_htmx, gender_context)
-
-// Enhanced error handling with renderer support
-contextual_error!(renderer, "error_template", error_context)
-```
-
-#### I18n Template Context (`src/i18n/template_helpers.rs`)
-```rust
-pub struct I18nTemplateContext {
-    loader: Arc<FluentLoader>,
-}
-```
-- Dynamic locale support for templates
-- Efficient message lookup and formatting
-- Integration with gender context for personalized content
-
-### Performance Optimizations
-
-1. **HTMX Header Detection**: Added constants for faster header parsing
-2. **Language Detection**: Early exit optimization in middleware
-3. **Context Caching**: Efficient context reuse in template rendering
-4. **Clone Optimization**: Strategic cloning only where needed for API compatibility
-
-### Error Handling Improvements
-
-1. **Unified Error Templates**: Consistent error rendering across all handlers
-2. **Context Preservation**: Error context properly merged with base context
-3. **Type Safety**: Compile-time guarantees for template context validity
-4. **Graceful Degradation**: Fallback mechanisms for template failures
-
-## Files Modified
-
-### Core System Files
-- ✅ `src/http/template_renderer.rs` - **NEW** - Unified template rendering system
-- ✅ `src/http/macros.rs` - Enhanced macros for renderer creation and error handling
-- ✅ `src/http/mod.rs` - Added template_renderer module export
-
-### Handler Files (All Fixed & Modernized)
-- ✅ `src/http/handle_admin_index.rs` - Converted to TemplateRenderer, fixed field access
-- ✅ `src/http/handle_oauth_login.rs` - Fixed 5 API compatibility errors with `.clone()`
-- ✅ `src/http/handle_view_feed.rs` - Converted to TemplateRenderer, fixed Language types
-- ✅ `src/http/handle_view_rsvp.rs` - Converted to TemplateRenderer, fixed Value insertion
-
-### I18n System Files
-- ✅ `src/http/middleware_i18n.rs` - Added HTMX constants, optimized language detection
-- ✅ `src/http/templates.rs` - Updated to use I18nTemplateContext
-- ✅ `src/i18n/template_helpers.rs` - Enhanced with dynamic locale support
-- ✅ `src/i18n/mod.rs` - Added I18nTemplateContext export
-- ✅ `src/i18n/gender.rs` - Added Display trait for Gender enum
-
-## Quality Assurance
-
-### Build Status
-```bash
-$ cargo build
-✅ Finished `dev` profile [unoptimized + debuginfo] target(s) in 31.05s
-```
-- **No compilation errors**
-- **No warnings**
-- **All dependencies resolved**
-- **Full type safety maintained**
-
-### Code Quality Metrics
-- **16+ compilation errors resolved**
-- **5 API compatibility issues fixed**
-- **Unified template rendering across 4+ handlers**
-- **Enhanced error handling consistency**
-- **Improved i18n integration performance**
-
-## Benefits Delivered
-
-### For Developers
-1. **Simplified Template Rendering**: Single API for all template operations
-2. **Better Error Handling**: Consistent error templates with proper context
-3. **Type Safety**: Compile-time guarantees for template context validity
-4. **Code Reusability**: Centralized logic reduces duplication
-
-### For Application
-1. **Performance**: Optimized language detection and context handling
-2. **Consistency**: Uniform i18n, HTMX, and gender context across all templates
-3. **Maintainability**: Centralized template logic easier to modify and extend
-4. **Reliability**: Proper error handling prevents template rendering failures
-
-### For Users
-1. **Better I18n**: More consistent internationalization across the application
-2. **Enhanced UX**: Proper HTMX integration for dynamic content
-3. **Personalization**: Gender context properly applied in templates
-4. **Stability**: Reduced runtime errors from template rendering issues
-
-## Next Steps (Optional Future Enhancements)
-
-While the refactoring is complete and fully functional, potential future improvements could include:
-
-1. **Template Caching**: Add template compilation caching for performance
-2. **Context Validation**: Runtime validation of template context completeness
-3. **Testing Suite**: Integration tests for template rendering scenarios
-4. **Documentation**: API documentation for the TemplateRenderer system
-5. **Metrics**: Template rendering performance monitoring
-
-## Conclusion
-
-The template rendering system refactoring has been successfully completed. The codebase now has:
-
-- ✅ **Zero compilation errors**
-- ✅ **Unified template rendering system**
-- ✅ **Enhanced i18n integration**
-- ✅ **Improved error handling**
-- ✅ **Better code organization**
-- ✅ **Performance optimizations**
-
-The system is production-ready and provides a solid foundation for future template-related enhancements.
-
----
-**Completed**: December 2024  
-**Baseline Commit**: `96310e5` (feat: migrate i18n system from custom fluent to fluent-templates)  
-**Status**: Ready for testing and deployment

docs/i18n/Step4-V1-resume.md

···
-Perfect! The i18n refactoring migration to fluent-templates has been successfully completed. Here's a comprehensive summary of all the steps taken:
-
-## Migration Summary: Custom Fluent → fluent-templates
-
-### **Phase 1: Analysis & Planning**
-- **Error Analysis**: Identified compilation errors after initial migration attempt
-- **Research**: Studied fluent-templates API and FluentValue documentation
-- **Code Investigation**: Found form validation methods expecting `&Locales` parameter
-
-### **Phase 2: Core Infrastructure Updates**
-
-#### **Updated I18nContext Structure** (context.rs)
-- **Added `locales` field** back to `I18nContext` for backward compatibility
-- **Updated constructor** to create both `supported_languages` and `locales` internally
-- **Fixed FluentValue conversion logic**:
-  - Removed non-existent `DateTime` variant handling
-  - Added catch-all pattern `_` for unknown variants
-  - Fixed type mismatch by removing reference (`&converted_args` → `converted_args`)
-
-#### **Fixed Translation Methods** (mod.rs)
-- **Removed `.unwrap_or_else()` calls** since functions now return `String` directly
-- **Updated `format_error` method**: Added explicit empty string fallback logic
-- **Updated `format_message` method**: Removed unnecessary unwrap chain
-- **Preserved FluentValue conversion** for argument mapping
-
-#### **Fixed Binary Initialization** (smokesignal.rs)
-- **Updated I18nContext creation**: Changed from `I18nContext::new(supported_languages, locales)` to `I18nContext::new()`
-- **Simplified initialization**: Constructor now handles internal setup
-
-### **Phase 3: Type System Compatibility**
-
-#### **FluentValue Conversion Mapping**
-```rust
-// Old fluent::FluentValue → New fluent_templates::fluent_bundle::FluentValue
-fluent::FluentValue::String(s) → FluentValue::String(s)
-fluent::FluentValue::Number(n) → FluentValue::Number(n)
-fluent::FluentValue::None → FluentValue::String("".into())
-fluent::FluentValue::Error → FluentValue::String("".into())
-fluent::FluentValue::DateTime → REMOVED (not supported)
-_ → FluentValue::String("".into()) // Catch-all
-```
-
-#### **Method Signature Updates**
-- **Before**: Functions returned `Option<String>` requiring `.unwrap_or_else()`
-- **After**: Functions return `String` directly, no unwrapping needed
-
-### **Phase 4: Validation & Testing**
-- **Compilation**: ✅ All errors resolved, clean build
-- **I18n Tests**: ✅ All 10 i18n tests passing
-- **Backward Compatibility**: ✅ Existing form validation calls still work
-
----
-
-## **Suggested Changelog Entry**
-
-```markdown
-### Changed
-- **BREAKING**: Migrated i18n system from custom Fluent implementation to fluent-templates
-  - Updated FluentValue type conversions for compatibility
-  - Removed support for DateTime variants (converted to strings)
-  - Simplified translation function return types (now return String directly)
-  - Maintained backward compatibility for form validation methods
-
-### Fixed
-- Resolved compilation errors in i18n type conversions
-- Fixed method signature mismatches in translation functions
-- Corrected I18nContext initialization in main binary
-
-### Technical
-- Updated dependencies: fluent → fluent-templates
-- Refactored FluentValue conversion logic
-- Streamlined translation error handling
-```
-
-## **Suggested Commit Message**
-
-```
-feat: migrate i18n system from custom fluent to fluent-templates
-
-- Replace custom Fluent implementation with fluent-templates crate
-- Fix FluentValue type conversions and remove DateTime variant support  
-- Update translation methods to return String directly instead of Option<String>
-- Maintain backward compatibility for existing form validation calls
-- Resolve all compilation errors and ensure tests pass
-
-BREAKING CHANGE: i18n system now uses fluent-templates instead of custom implementation
-```
-
-The migration is now complete and the application compiles successfully with all i18n functionality preserved!