Repository navigation
Conversation
Put provider selection alongside profile identity and limit new providers to the installed PySubtrans registry. Replace free-text setting creation with a searchable list of the selected provider's known settings, with descriptions and type hints. Preserve inherited and legacy profile values while surfacing provider availability before selectable profiles are saved. Keep reference results tied to the current registry so retries can recover when providers become available.
A base profile can affect selectable descendants even when it is not selectable itself. Keep Save disabled while the provider reference is unavailable so an unset provider cannot reach a guaranteed backend rejection. Limit setting search to providers present in the reference and update the container E2E flow to select Provider and add reasoning_effort through the new combobox.
Pending setting additions were retained when Provider or Parent changed, allowing a key from the previous provider to become a new unknown setting. Compare the effective provider before and after draft edits and discard unfinished additions and their parse errors when it changes. Keep completed profile settings intact, including existing custom and legacy keys. Cover direct provider changes, inherited provider changes, Unset, and Remove local.
Completing a new setting moved it into the draft and let it survive a provider change as an unknown key. Track the keys present when editing began and remove only session-added keys that the next effective provider does not support. Keep persisted custom settings and session-added keys shared by both providers. Apply the same behavior to inherited provider changes through Parent, and clear errors for removed keys.
Treat keys inherited when the editor opens as existing profile settings alongside local keys. A later override of one of those keys now survives a provider change, while newly introduced unsupported keys are still removed.
Leave selectable descendant validation to the server when saving an ancestor. The editor now requires a loaded provider registry and a known effective provider only for the selectable profile being edited, so non-selectable bases can submit even when the reference is unavailable. Update the validation message and cover both form states.
kfstorm
added a commit
that referenced
this pull request
Sep 28, 2026
## Summary - Replace inheritable Model Profiles with standalone configurations containing a name, a provider, and sparse provider settings. - Build the provider form from PySubtrans runtime "GetOptions()" results and refresh it according to "refresh_when_changed", including network-backed model discovery. - Render PySubtrans field types directly and keep runtime defaults and environment fallbacks out of the browser; only explicit profile settings are persisted. - Reconcile missing or invalid models using PySubtrans's available models and persist explicit runtime updates such as an auto-selected model. - Preserve drafts across refresh errors, reject stale responses, and clear provider-specific settings when the provider changes. - Keep Jobs linked by "model_profile_id" and resolve the current profile when each translation attempt starts. ## Migration The existing "0004_model_profiles" migration remains unchanged because it has already been deployed. A new migration rebuilds the Model Profile tables with the standalone schema and removes "parent_id", "selectable", setting kinds, and unset tombstones. There is no existing Model Profile data to preserve, so the migration intentionally does not flatten inheritance or provide a legacy data-conversion path. ## Context This PR replaces the configuration UX direction from the closed #215. It does not reopen that PR or continue from its branch. Removing inheritance and Base Profile semantics makes each profile understandable on its own. Reading option visibility, types, choices, descriptions, and refresh behavior from PySubtrans also removes CueWeaver's AST-derived configuration schema. Sparse explicit settings keep PySubtrans defaults and environment configuration at runtime without exposing their effective values through the configuration API. The result is a shorter first-time setup flow with less provider-specific configuration logic for CueWeaver to maintain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Compatibility
Profiles still store Provider as the existing
providersetting. Existing unknown providers and custom settings, including inherited settings overridden in the editor, remain editable across Provider changes. The editor removes settings added in the current session if the new Provider does not support them, while retaining settings supported by both Providers. New unknown providers and setting keys cannot be added through the editor.