UX/UI: Multi-language CV Support

[rorar]

Description:

I'd like to discuss adding support for multi-language CVs. Currently, the language setting only affects UI labels, not CV content. I'm thinking about:

Concept:

1. Language tabs in the UI to switch between language versions of the same CV

2. API endpoint that returns the CV in the requested language:

   GET /api/cv?lang=de
   

3. Simplified export - Export multiple languages at once:

   • Select languages (e.g., EN + DE)
   • Add filename patterns like <date>-<timestamp>-<username><filename>foo etc.
   • Export as individual files or ZIP with language folder structure:

     20261504-rorar-cv-en.pdf
     20261504-rorar-cv-de.pdf
     /en/20261504-rorar-cv.pdf
     /de/20261504-rorar-cv.pdf
     

Existing related features to leverage:

Feature	Current State	Could be extended?
Datasets	One dataset = one CV version	One dataset = one language
Settings language	UI labels only	Content language
JSON Import/Export	Single-language CV structure	Add lang field per entry
Static site export	Single HTML + data.json	Per-language exports
Section display_name	Custom section names	Already stores per-entry names
ATS localized setting	Section names in export	Already implemented

Current JSON import/export structure:

{
  "profile": { "name": "...", "bio": "...", ... },
  "experiences": [{ "job_title": "...", "company": "...", ... }],
  "certifications": [...],
  "education": [...],
  "skills": [...],
  "projects": [...],
  "customSections": [...],
  "sectionOrder": [...],
  "sectionVisibility": {...}
}

For multi-language, could add lang field:

{
  "lang": "de",
  "profile": { ... },
  "experiences": [{ "job_title": "...", ... }],
  ...
}

Key questions for discussion:

1. Data model - Should translations be stored as:

   • Separate columns per language (job_title_de, job_title_fr, ...)
   • Separate table with lang column
   • Leveraging existing datasets (one dataset per language) - uses existing slug/public infrastructure
   • JSON with lang field per import/export

2. Sync strategy - When adding a new experience, should it auto-create empty translations in all languages? Maybe also warn the user that translation is missing?

3. Fallback behavior - What if a translation is missing? Fall back to English?

4. Public site - How should the public site handle multiple languages?

   • Subdirectory (/de/, /fr/)
   • Query param (/?lang=de)
   • Different domains?

5. Translation workflow - Manual entry? LLM-assisted? Both?

6. Structure sync - When adding/removing an experience, should it propagate to all languages?

Use cases:

• User writes CV in English, then adds German/French translations OR sets a base language and adds another translation like German/French
• Export all language versions as ZIP for different job applications
• Import existing translations via JSON
• Public CV served in visitor's browser language + Language selection

---

Prospects for the future: Automatic Translation via Translation Tool / LLM

Once multi-language support is established, automatic translation could be a powerful addition:

1. One-click translate - Button to translate all content to a new language using an LLM API
2. Selective translation - Translate only new/edited entries, preserving manual corrections
3. Quality levels - Quick (LLM) vs. professional (import existing translations)
4. API integration - Support for OpenAI, DeepL, Google Translate, etc.
5. Human review - Flag machine translations for manual review before publishing
6. Privacy options - Local translation model option for sensitive data

Potential UX flow:

0. User selects base language
1. Write CV in base language
2. Click "Add German version"
3. LLM translates all content to German
4. Review/Edit translations
5. Publish or export German version

Usecase

Recently I was often asked: Could you please send your CV either in

• english only
• german only
• german + english

So having a centralized point (cv-manager) where I can just push two buttons to have it at the right time in the right place would be awesome and a total time saver!

Edit: Typos, formatting and added USecase

[vincentmakes]

Let's see if other users are interested but I see your point regarding keeping track of sub-versions of the same CVs in two languages.

The current (manual) workflow is the following:

1. Starting with your CV in english, save it with a _EN name.
2. Export the CV in JSON and import it into your favorite LLM for translation in DE
3. Import the JSON in DE, save it with _DE extension
   It does the job but localization is global, not per CV, and dealing with multiple dual language CV can be painful.

Architecture wise I would probably extend the /v/slug feature and saving the localization as well but guardrails would need to be considered.

PDF export of multiple CVs: I would drop that feature as right now we're relying on the PDF print via browser (client side) which allow some fine tuning of the output and offload the complexity. Generating PDFs in he backend has proven to cause many issues which are honestly not worth the trouble.

I have an upcoming change which includes better versioning (that'd be a foundational pre-requisite), and I could build on top of that afterwards. Just that versioning implementation in the backend is going to be heavy so the next PR is going to be UI only for now.

[vincentmakes]

New version out which includes proper versioning, multi language support of the same dataset, and a redesigned UI to manage all of this.
This was a significant change on the backend - it works on my end and tested all the features impacted but let me know if there's any issue

[rorar]

Many thanks Vincent! I'll check it out! :)