GGThedandClaude Opus 5 a92600c305 feat(i18n): francais comme langue principale, anglais accessible
Le site s'affiche desormais en francais par defaut, avec un selecteur de
langue permettant de basculer vers l'anglais.

Choix de conception : les chaines sources restent en anglais
  Elles servent d'identifiants gettext, et le francais est fourni par
  catalogue avec BABEL_DEFAULT_LOCALE = 'fr'. Le code reste ainsi dans une
  seule langue -- la meme que ses commentaires et docstrings -- tandis que
  ce qu'un membre voit est du francais.

  Consequence qui rend la migration praticable : une chaine non encore
  traduite retombe en anglais, pas sur un identifiant brut. Les gabarits
  peuvent donc etre migres un par un sans jamais laisser le site a moitie
  casse.

Selection de la langue (app/i18n.py)
  1. choix explicite via le selecteur, garde en session
  2. sinon en-tete Accept-Language du navigateur, restreint a fr et en
  3. sinon francais
  Un choix explicite prime toujours, y compris sur un navigateur anglophone.

Selecteur
  Extrait en partiel et inclus dans les deux branches de la mise en page :
  barre laterale une fois connecte, ET page d'authentification. Quelqu'un
  qui ne lit pas la langue courante doit pouvoir en changer AVANT de se
  connecter -- le laisser derriere l'authentification aurait ete un defaut
  d'accessibilite. Chaque langue est ecrite dans sa propre langue.

  La route /lang/<locale> valide le Referer avant de rediriger : sans ce
  controle, elle constituait une redirection ouverte.

Migre dans cette passe
  navigation complete, page de connexion, les cinq pages d'erreur, et
  l'integralite des messages flash de routes/auth.py. 64 chaines, dont
  aucune non traduite.

Verification
  25 tests, dont deux garde-fous d'integrite : un catalogue .mo manquant
  ou une entree non traduite font echouer la suite. Sans cela, une
  compilation oubliee servirait de l'anglais partout, en silence et sans
  rien dans les journaux.

Un test existant a du etre corrige, et c'est instructif
  test_login_failure_message_does_not_reveal_account_existence cherchait la
  sous-chaine anglaise 'attempt(s) remaining'. La page etant desormais en
  francais, elle etait absente des deux cotes, l'assertion passait, et le
  mode strict a signale le faux succes. Le test comparait donc l'anglais,
  pas le comportement. Il compare desormais les messages flash rendus,
  quelle que soit la langue. La faille SEC-AUTH-006 reste ouverte, et le
  test la documente toujours.

Les catalogues .po ET .mo sont versionnes : le deploiement est un simple
miroir de fichiers, sans etape de compilation. messages.pot, regenerable,
ne l'est pas.

docs/translations.md documente le processus, les deux pieges (concatenation
de phrases, traduction a l'import), et l'etat de la migration. A noter pour
la suite : les chaines dans les blocs <script> ne peuvent pas etre balisees
telles quelles, il faudra les passer par des attributs data- -- ce qui
rejoint le chantier de sortie de unsafe-inline (OPS-010).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-07 20:31:25 -04:00
2026-08-06 14:46:51 -04:00
2026-07-30 09:52:32 -04:00
2026-08-03 16:43:46 -04:00

Plateforme centralisée de tryouts

Security Configuration

Required Environment Variables

Before deploying, create a .env file which integrates everything in the .env.exemple. Ensure you follow the comments of the exemple if you are to use this tool in production.

Security Features Implemented

  • Rate Limiting: Login endpoint limited to 10 requests per minute to prevent brute-force attacks
  • Secure Session Cookies: HTTPSOnly, SameSite=Lax, and Secure flags enabled
  • CSRF Protection: Enabled by default on all forms
  • HTTPS Enforcement: Automatic redirect to HTTPS in production
  • Security Headers: X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, HSTS
  • Open Redirect Prevention: URL validation on login redirect
  • Authorization Checks: Proper ownership validation on all sensitive operations
  • nginx: reverse-proxy and load balancer
  • Waitress WSGI: Production ready WSGI

When true in .env:

  • Forces HTTPS only
  • Forcer secure cookies

App details

Code

  • Full python backend using flask
  • statics are pure HTML and CSS
  • Some js to add logic to styling and showing certain pages/cards

Functionalities

  • User base with sign-ins: Forces users to create an account and register pertinent information for tryouts and teams. The admin can attribute them a role.
  • User-Role-Based Permissions: admin - full acces, coach/manager - access to team management, player - views what he is registered in (no management), scout - view only
  • Tryout Management: manage internal tryout teams, organise internal tryouts matches (3 formats, team vs team, PvP, scrim). Coaches can Evaluate players based on 10 criteria
  • Team Management: manage teams for the season, create matches and practices. When planning a practice there will be a calendar showing player availabitlities slots to help chose a time
  • Coach and Player Availabilities: Allow better planning for the coaches, and for players to book One on Ones with their coach.
  • Player Notes: Coaches can give notes to their players. The players will see them and there is a history which keeps the most recent notes.
  • Team Notes: Coaches can give notes to their teams, where all players from that team can see the note.
  • One on One: Players can request a One on One meeting with their coach. This sends a discord dm to the coach to accept or refuse. The player is then notified of the response.
  • Availabilities: Allow players and coach to enter the moments they are available. Allows for easier practice setup and One on One planning.

Discord Integration

The application supports sending Discord direct messages to coaches when players request One on One sessions, when matches/tryouts/practices are created and a player is in it, and the players get match reminders 24h before a match.

When sending a One on One request, the coach can accept via the platform or react to the discord message to answer the booking request. Same thing with matches and practices, the players can react or answer on the platform.

Setup Instructions

1. Create a Discord Bot (Not needed for UdeS user, the bot already exists)

  1. Go to the Discord Developer Portal
  2. Create a new application
  3. Go to the "Bot" tab and create a bot user
  4. Copy the bot token - this will be your DISCORD_BOT_TOKEN
  5. Enable the "Message Content Intent" under Privileged Gateway Intents (required for sending messages)

2. Add Bot to your server

For the bot to send DMs:

  1. Each user must have the bot added to their Discord server OR be friends with the bot
  2. Users need to add their Discord User ID to their profile:
    • Enable Developer Mode in Discord (User Settings → Advanced → Developer Mode)
    • Right-click on their profile → Copy ID
    • Enter this numeric ID in the "Discord User ID" field in their profile settings

How It Works

When a player submits a One on One request:

  1. The system checks if the coach has a Discord User ID configured
  2. If configured, a direct message is sent to the coach via the Discord bot

Message Format

The Discord DM includes:

  • Player name
  • Team name
  • Requested date and time slot
  • Discussion points (if provided)
  • Link to the application for approval/rejection
  • Two provided reactions to accept or refuse via discord
S
Description
No description provided
Readme
2.3 MiB
Languages
Python 67.9%
HTML 27%
CSS 3.5%
JavaScript 1.6%