sepehr 2da2c4765c
All checks were successful
Deploy to Production / Build and Deploy (push) Successful in 2m30s
feat(format): B3.9 — preserve PDF table column structure during translation
User reported that the page 6 table on the test PDF ('6. Performance
and Scaling' page) was completely broken: the 3-column table
('Document size | Avg latency (s) | Throughput (docs/min)' with
5 data rows) was rendered as a vertical list of label/value pairs
instead of as a proper table.

Root cause: a PDF 'block' that contains multiple LINES at the SAME
y but different x positions is a table row (3 cells side-by-side).
The extractor was treating the whole row as one paragraph, joining
all cell texts with newline. When the smart-fit logic wrote the
text back, it used the row's full-width bbox and \insert_textbox\
wrote everything left-aligned, collapsing all columns into one.

Fix: at extraction time, detect horizontal-layout blocks (lines at
the same y, different x within 5pt tolerance) and split them into
one sub-block per line. Each cell gets its own bbox, so the
translator writes each cell at its original x position, preserving
the column structure.

Detection heuristic:
  - Block has >= 2 lines
  - All lines have y0 within 3pt of each other (SAME_ROW_Y_TOLERANCE)
  - At least 2 lines have different x0 (within > 5pt)
If all three hold, it's a table row. Otherwise, keep the old
multi-line-paragraph behavior.

Note: PyMuPDF re-groups cells into row-blocks when reading the
output back (so 'len(blocks)' looks unchanged), but the LINES
within each block are at their correct x positions. Tests check
the line x0 values, not the block count.

Visual proof: page 7 of sample_files/test_corpus/test_pdf_translated.pdf
now shows the table with proper 3-column structure (Taille du document
| Latence moyenne (s) | Débit (docs/min)) instead of an '[translation
overflow]' placeholder.

4 new tests added:
  - test_horizontal_layout_detected: 3 lines at same y -> 3 blocks
  - test_vertical_layout_kept_as_one_block: 3 lines at different y -> 1 block
  - test_single_line_block_unchanged: 1 line -> 1 block
  - test_table_cell_each_at_own_x: e2e table translation, cells at
    correct x positions

Total: 457 tests pass (was 453), zero regression.
2026-07-14 19:25:24 +02:00

📄 Wordly.art — Document Translation Portal

Wordly.art est une application complète et prête pour la production (SaaS-ready) permettant de traduire des documents bureautiques complexes (Excel, Word, PowerPoint) tout en préservant strictement la mise en page originale, le style, les formules et les médias intégrés.

Ce fichier sert de portail central pour accéder à toutes les documentations techniques, guides d'exploitation, de déploiement et de secours de l'application.


🗺️ Carte de la Documentation

Pour faciliter la navigation, utilisez les liens ci-dessous pour accéder directement aux guides spécialisés :

🚀 Démarrage & Utilisation

🏗️ Architecture & Conception

🌐 Déploiement en Production

🛡️ Sauvegarde, Résilience & Secours (Disaster Recovery)


Fonctionnalités Clés

🔄 Multi-fournisseurs de Traduction

L'application supporte 7 moteurs de traduction, activables à la volée :

  • Google Translate (Gratuit, rapide, par défaut)
  • DeepL API (Haute qualité pour l'entreprise)
  • OpenAI (Modèles GPT-4o, support de la vision)
  • DeepSeek, OpenRouter, Minimax, x.ai (Zai) (Modèles de pointe pour traductions complexes)

📁 Traduction Intelligente par Fichier

  • Excel (.xlsx) : Conserve la fusion des cellules, les formules, les polices de caractères, les styles de bordures et traduit également le texte contenu dans les images (via modèles vision).
  • Word (.docx) : Préserve les en-têtes, pieds de page, tableaux, listes à puces et la mise en forme des paragraphes.
  • PowerPoint (.pptx) : Conserve la mise en page des diapositives, les animations et transitions.

🏢 Sécurité & Exploitation (SaaS-Ready)

  • 🚦 Limitation de débit (Rate Limiting) : Par IP client avec algorithme Token Bucket stocké dans Redis.
  • 🧹 Nettoyage automatique (Auto Cleanup) : Suppression automatique des fichiers temporaires après expiration de la durée de vie (TTL).
  • 📊 Monitoring complet : Route /health détaillée et intégration Prometheus + Grafana pour suivre les performances physiques et logicielles.

🛠️ Stack Technique

Backend

  • FastAPI (Python 3.11+) : API asynchrone rapide et documentée (Swagger disponible sur http://localhost:8000/docs).
  • openpyxl, python-docx, python-pptx : Moteurs de manipulation de documents sans dépendance Microsoft Office.
  • Docker / Docker Compose : Isolation complète de l'application, de la base PostgreSQL et du cache Redis.

Frontend

  • Next.js 15 (React) & Tailwind CSS : Interface utilisateur moderne, ergonomique et responsive.
  • Lucide Icons : Bibliothèque d'icônes vectorielles.

🚀 Lancement Rapide (Mode Dev)

Pour un déploiement complet en production ou homelab, veuillez vous référer aux fichiers de déploiement listés dans la Carte de la Documentation.

# 1. Cloner le projet
git clone https://gitea.parsanet.org/sepehr/office_translator.git /opt/wordly
cd /opt/wordly

# 2. Configurer l'environnement
cp .env.example .env
# Modifiez les variables dans le .env selon vos besoins

# 3. Lancer avec Docker Compose
docker compose up -d --build
  • API (Backend) : http://localhost:8000 (Documentation Swagger sur /docs)
  • Interface Web (Frontend) : http://localhost:3000
Description
No description provided
Readme MIT 14 MiB
Languages
Python 52.3%
TypeScript 33.3%
HTML 12.6%
CSS 1.1%
PowerShell 0.5%
Other 0.2%