Description:
Currently, our translation functionality is tightly coupled to a single hardcoded model. Since different event organizers have varying hardware constraints and budgets, we need an abstraction layer that allows them to select their preferred translation or LLM provider (e.g., local models vs. external APIs) at runtime.
This issue focuses strictly on building the underlying architecture. Specific provider implementations (like NLLB or DeepL) will be handled in separate follow-up issues.
Core Objectives:
-
Provider Interface: An abstract base class to standardize inputs and outputs across all providers from plugin
-
Dynamic Configuration: Allow provider selection and API keys to be passed per-session via API, rather than relying on global hardcoding.
-
Multi-tenant Support: Ensure multiple events can run simultaneously on the same server using different provider configurations.
-
Lazy Loading: Ensure the registry does not load heavy models into memory at import time to prevent server startup delays.
Description:
Currently, our translation functionality is tightly coupled to a single hardcoded model. Since different event organizers have varying hardware constraints and budgets, we need an abstraction layer that allows them to select their preferred translation or LLM provider (e.g., local models vs. external APIs) at runtime.
This issue focuses strictly on building the underlying architecture. Specific provider implementations (like NLLB or DeepL) will be handled in separate follow-up issues.
Core Objectives:
Provider Interface: An abstract base class to standardize inputs and outputs across all providers from plugin
Dynamic Configuration: Allow provider selection and API keys to be passed per-session via API, rather than relying on global hardcoding.
Multi-tenant Support: Ensure multiple events can run simultaneously on the same server using different provider configurations.
Lazy Loading: Ensure the registry does not load heavy models into memory at import time to prevent server startup delays.