Skip to content

Conversation

@ArnavBallinCode
Copy link
Member

@ArnavBallinCode ArnavBallinCode commented Dec 13, 2025

Screen.Recording.2025-12-13.at.7.38.19.PM.mov

fixes #1472

Summary by Sourcery

Add separate active language and content language configuration to the event creation wizard and ensure content languages are constrained to active languages.

New Features:

  • Introduce a dedicated content languages field in the event foundation form to control which languages proposals can be submitted in.

Bug Fixes:

  • Ensure content languages default to and remain a subset of the selected active languages, preventing invalid configuration states.

Enhancements:

  • Refine localization labels and help text in the event foundation form and group language settings under a dedicated Localization section in the UI.

@sourcery-ai
Copy link
Contributor

sourcery-ai bot commented Dec 13, 2025

Reviewer's Guide

Adds a separate Content Languages field to the event creation foundation step, validates it as a subset of Active Languages, wires it through the event wizard flow, and updates templates and defaults accordingly.

Sequence diagram for event creation wizard handling active and content languages

sequenceDiagram
    actor Organizer
    participant Wizard as EventCreationWizard
    participant FoundationForm as EventWizardFoundationForm
    participant BasicsForm as EventWizardBasicsForm
    participant Event as EventSettings

    Organizer->>Wizard: Start event creation
    Wizard->>Wizard: get_form_initial(step = foundation)
    Wizard->>Wizard: initial.locales = [en]
    Wizard->>Wizard: initial.content_locales = [en]

    Organizer->>FoundationForm: Submit foundation step
    FoundationForm->>FoundationForm: clean()
    FoundationForm->>FoundationForm: Validate content_locales ⊆ locales
    alt Invalid content_locales
        FoundationForm-->>Organizer: ValidationError on content_locales
    else Valid or empty content_locales
        FoundationForm-->>Wizard: cleaned_data with locales, content_locales
    end

    Organizer->>BasicsForm: Proceed to basics step
    Wizard->>BasicsForm: __init__(..., content_locales)
    BasicsForm->>BasicsForm: kwargs.pop(content_locales, None)
    BasicsForm-->>Wizard: basics_data

    Organizer->>Wizard: Finish wizard
    Wizard->>Wizard: foundation_data = storage.get_step_data(foundation)
    Wizard->>Wizard: content_locales = foundation_data.content_locales or foundation_data.locales
    Wizard->>Event: set(locales, foundation_data.locales)
    Wizard->>Event: set(content_locales, content_locales)
    Wizard-->>Organizer: Event created with active and content languages
Loading

Updated class diagram for event creation forms and settings

classDiagram
    class EventWizardFoundationForm {
        +MultipleChoiceField locales
        +MultipleChoiceField content_locales
        +BooleanField has_subevents
        +__init__(*args, **kwargs)
        +clean()
    }

    class EventWizardBasicsForm {
        +__init__(*args, **kwargs)
    }

    class EventCreationWizardView {
        +get_form_initial(step)
        +done(form_list, form_dict, **kwargs)
    }

    class EventSettings {
        +set(key, value)
        +get(key, as_type)
        +locale
        +locales
    }

    EventCreationWizardView --> EventWizardFoundationForm : uses
    EventCreationWizardView --> EventWizardBasicsForm : uses
    EventCreationWizardView --> EventSettings : configures
    EventWizardBasicsForm --> EventSettings : reads timezone, locale
    EventWizardFoundationForm --> EventSettings : defines locales, content_locales
Loading

File-Level Changes

Change Details Files
Introduce distinct Active languages and Content languages fields in the event foundation form and validate their relationship.
  • Rename the existing locales field label and help text to clarify it as Active languages for both UI usage and text provision.
  • Add a new optional content_locales MultipleChoiceField using the same language choices and widget, with help text explaining it controls proposal submission languages.
  • Implement a clean() method on the foundation form that enforces content_locales to be a subset of locales, raising a ValidationError on violation.
app/eventyay/control/forms/event.py
Propagate the new content_locales value through the event creation wizard without impacting unrelated steps.
  • Pop content_locales from kwargs in EventWizardBasicsForm.init so it can be passed through the wizard without causing unexpected form field errors.
  • Set default initial content_locales to ['en'] alongside locales in the foundation step initial data, keeping them aligned by default.
  • Ensure event.settings.content_locales is persisted from the submitted content_locales if provided, otherwise falling back to locales, and reuse this resolved value when constructing the creation flow response payload.
app/eventyay/eventyay_common/views/event.py
Update the foundation step template to present localization options clearly, including the new content_locales field.
  • Wrap localization-related fields in a dedicated fieldset with a Localization legend for better grouping.
  • Render both locales (Active languages) and content_locales (Content languages) with horizontal bootstrap layout within this fieldset.
app/eventyay/eventyay_common/templates/eventyay_common/events/create_foundation.html

Assessment against linked issues

Issue Objective Addressed Explanation
#1472 Add Active Languages and Content Languages fields to the event creation form using the same UI component and behavior as on the Common Settings page.
#1472 Ensure the selected Active Languages and Content Languages are correctly validated, defaulted, and stored during initial event creation.

Possibly linked issues

  • #N/A: The PR implements Active and Content Languages on event creation with proper defaults and validation, matching the issue request.

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there - I've reviewed your changes - here's some feedback:

  • The clean method on EventWizardFoundationForm raises ValidationError, but there’s no import shown in this file diff; verify that ValidationError is imported from django.core.exceptions (or use forms.ValidationError) to avoid a runtime error.
  • Since content_locales must always be a subset of locales, consider mentioning this constraint explicitly in the content_locales help text so users understand why some options may be unavailable or cause validation errors.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The `clean` method on `EventWizardFoundationForm` raises `ValidationError`, but there’s no import shown in this file diff; verify that `ValidationError` is imported from `django.core.exceptions` (or use `forms.ValidationError`) to avoid a runtime error.
- Since `content_locales` must always be a subset of `locales`, consider mentioning this constraint explicitly in the `content_locales` help text so users understand why some options may be unavailable or cause validation errors.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request adds separate configuration for active languages and content languages in the event creation wizard. Active languages control which languages the eventyay interface is available in, while content languages specifically control which languages users can submit proposals in. The change ensures content languages are validated to be a subset of active languages, preventing invalid configuration states.

Key changes:

  • Added a dedicated content_locales field to the event foundation form with appropriate validation
  • Grouped language settings under a "Localization" section in the UI for better organization
  • Updated help text to clearly distinguish between active languages and content languages

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
app/eventyay/control/forms/event.py Added content_locales field to EventWizardFoundationForm with validation ensuring it's a subset of active languages; updated help text for both locale fields; added logic to pop content_locales from kwargs in EventWizardBasicsForm
app/eventyay/eventyay_common/views/event.py Added default initialization of content_locales to ['en']; updated done() method to use content_locales from form data with fallback to locales
app/eventyay/eventyay_common/templates/eventyay_common/events/create_foundation.html Wrapped language fields in a fieldset with "Localization" legend; added content_locales field to the form

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

label=_('Active languages'),
widget=MultipleLanguagesWidget,
help_text=_('Choose all languages that your event should be available in.'),
help_text=_(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This help text is too long, is it necessary?

locales = cleaned_data.get('locales', [])
content_locales = cleaned_data.get('content_locales')

if not isinstance(locales, list):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The MultipleChoiceField already guarantees this value to be a list, the isinstance is not necessary.
If your purpose is to help Pyright / your IDE infer type correctly, you can use:

assert isinstance(locales, list)

to keep the code flat.

if not isinstance(locales, list):
locales = list(locales)

if content_locales is not None:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block is too deeply nested, try to make code flatter.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +114 to +119
assert isinstance(locales, list)

if content_locales is None or not content_locales:
return cleaned_data

assert isinstance(content_locales, list)
Copy link

Copilot AI Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using assertions for runtime validation is inappropriate. Assertions can be disabled with Python's -O flag and are meant for debugging, not user input validation. Replace with proper error handling that raises a ValidationError with a clear message if the type check fails.

Suggested change
assert isinstance(locales, list)
if content_locales is None or not content_locales:
return cleaned_data
assert isinstance(content_locales, list)
if not isinstance(locales, list):
raise ValidationError({'locales': _('Active languages data is invalid.')})
if content_locales is None or not content_locales:
return cleaned_data
if not isinstance(content_locales, list):
raise ValidationError({'content_locales': _('Content languages data is invalid.')})

Copilot uses AI. Check for mistakes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hongquan shall I revert it back then

if content_locales is None or not content_locales:
return cleaned_data

assert isinstance(content_locales, list)
Copy link

Copilot AI Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using assertions for runtime validation is inappropriate. Assertions can be disabled with Python's -O flag and are meant for debugging, not user input validation. Replace with proper error handling that raises a ValidationError with a clear message if the type check fails.

Suggested change
assert isinstance(content_locales, list)
if not isinstance(content_locales, list):
raise ValidationError({
'content_locales': _('Content languages must be provided as a list.')
})

Copilot uses AI. Check for mistakes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

Event Creation: Ensure Active Languages and Content Languages options are available

3 participants