views.py — DRF Views for Module Info and Add-or-Update

[whisper67265]

Problem

The boost endpoint needs HTTP-facing views that accept requests, validate input, and delegate heavy work to Celery tasks. Currently no views exist. The views must be thin: validate the request payload, enqueue the Celery task, and immediately return a 202 Accepted with the task ID. No service-layer logic (file I/O, Weblate API calls, translation processing) should run in the request path.

Acceptance Criteria

• GET /info/ returns a JSON response with module name, version, and supported capabilities
• POST /add-or-update/ accepts a JSON body with at least project_slug, repo_url, and languages fields
• Input validation returns 400 with a structured error body when required fields are missing or malformed
• On valid input, the view enqueues a Celery task via tasks.add_or_update.delay(...) and returns 202 Accepted with {"task_id": "<uuid>"}
• Authentication is enforced (Weblate's token auth or DRF's IsAuthenticated permission class); unauthenticated requests return 401 or 403
• No service-layer code executes synchronously in the request handler
• Views use DRF serializers or manual validation, not raw request.data access without checks

Implementation Notes

Use @api_view decorators or APIView subclasses from Django REST Framework. The serializer for add-or-update should validate project_slug as a slug field, repo_url as a URL, and languages as a list of ISO 639-1 codes. The Celery task signature should accept all validated fields plus the requesting user's ID (from request.user) so the worker can set up the correct Weblate user context. Keep the views module focused on HTTP concerns only — the remaining 3pt of the views+tasks+services split lands in tasks.py and services.py.

References

• Related files: src/boost_weblate/views.py, src/boost_weblate/serializers.py (if created), src/boost_weblate/urls.py
• Depends on: urls.py route table, tasks.py Celery task signature