⚡ [Feature]: Standardize day types to English and improve initial data

[PPeitsch]

Problem Description

The application's day types are currently inconsistent and not user-friendly for a general audience. There are two main problems:

1. Inconsistent Language: The types are a mix of English and Spanish. The default state is "Work Day" (English), but the initial absence codes seeded into the database are in Spanish (e.g., "LAR", "FRANCO COMPENSATORIO", "LICENCIA MÉDICA"). This creates a confusing user experience and is a significant blocker for future internationalization (i18n) efforts.

2. Hardcoded Example Data: The initial Spanish codes are merely examples. While the new CRUD functionality (Issue ⚡ [Feature]: Implement CRUD management for absence codes #6) allows users to change them, the default state of the application should provide a set of sensible, universally understood defaults in a single language. New users are currently forced to immediately go to the settings to delete or rename these example codes to make the application useful.

Proposed Solution

To create a cleaner, more professional baseline and prepare the application for future i18n, we will standardize all default day types to English.

1. Update Initial Seed Data: The init_data() function in app/utils/init_data.py will be modified. The hardcoded list of Spanish absence codes will be replaced with a set of common, English-language defaults. For example:

   • LAR -> Personal Leave
   • FRANCO COMPENSATORIO -> Compensatory Time
   • LICENCIA MÉDICA -> Sick Leave
   • COMISIÓN DE SERVICIO -> Off-site Duty

2. Maintain "Work Day" as Base Type: The special "Work Day" type, which is a logical state representing the absence of an absence code, will be kept as is. It serves as the fundamental building block.

3. Leverage Existing CRUD: After this change, users will start with a clean, English-only set of absence codes. They can then use the existing CRUD management page (/settings/absences) to rename, delete, or add new codes to perfectly match their specific needs.

This change provides a much better "out-of-the-box" experience for new users and establishes a consistent language standard across the application.

Alternatives Considered

• Keep the current mixed-language system: This is not a viable option as it creates a confusing user experience and prevents any future attempts at internationalization.
• Add a language configuration file for defaults: This is overly complex for the current stage of the project. The standard practice is to use English as the base language in the codebase and data, and then build i18n systems on top of that foundation.

Additional Context

This change will only affect new database initializations. Existing users who have already set up their database will not have their existing absence codes modified. This is a foundational improvement for the application's long-term maintainability and global usability.

Implementation

• I would be willing to implement this feature myself