services.py — Project, Component, and Translation Flows

[whisper67265]

Problem

With the constants, helpers, and scan pipeline in place, the service layer needs the higher-level orchestration: creating or updating Weblate projects, creating components for each discovered translatable file, and triggering translation imports. It also needs a process_all entry point that the Celery task calls, plus cleanup logic and error handling that maintains parity with the expected Weblate state.

Acceptance Criteria

• get_or_create_project(user, project_slug, repo_url) creates a Weblate project if it doesn't exist, or returns the existing one
• get_or_create_component(project, relative_path, format_class) creates a Weblate component with the correct file mask, format, and VCS settings
• import_translations(component, language_code) triggers a translation file import for the given language
• process_all(user, project_slug, repo_url, languages) orchestrates the full flow: ensure project -> scan repo -> for each file, ensure component -> for each language, import translations
• Cleanup: temporary workspaces are removed after processing (or on error), using try/finally or a context manager
• Error handling: individual component or language failures are logged and collected but do not abort the entire batch; a summary of successes and failures is returned
• Function signatures and return types are consistent with the helpers from the 5pt services item

Implementation Notes

Use Weblate's internal API (weblate.trans.models.Project, Component, etc.) rather than HTTP calls when running inside the same process. The process_all function should return a structured result dict: {"created": [...], "updated": [...], "failed": [...]}. Error handling should catch Component.DoesNotExist, VCS errors, and format parse errors separately. Consider a @contextmanager for workspace lifecycle.

References

• Related files: src/boost_weblate/services.py, src/boost_weblate/tasks.py
• Depends on: services.py constants/helpers/scan (5pt item above)