TQ-Slator/assets/components/ProjectNav.tsx
Stephan Morand 9025c64c0b Socle complet de TQ-Slator : éditeur, API, CLI, administration
Système de gestion de traductions pensé en CMS headless : un back-office
pour ceux qui traduisent, une API pour ce qui consomme.

Architecture
- Symfony 7.4 / API Platform 4.3 / MariaDB 11.4, SPA React 19 servie en
  même origine — ce qui rend viable le cookie de session plutôt qu'un
  jeton en localStorage.
- Deux APIs séparées : Management (session ou clé) et Delivery
  (stateless, clé seule). Les fusionner ferait porter à chaque lecture de
  bundle le coût de la session.
- Stockage canonique en ICU MessageFormat, sérialisation par plateforme.
  Le format d'une plateforme ne contamine pas la base.
- Publication par releases immuables ; le déploiement est un déplacement
  de pointeur, donc le rollback aussi.
- Isolation multi-organisation par filtre Doctrine, avec un test
  d'architecture qui casse la CI si une entité échappe à l'invariant.

Éditeur, deux vues
- Par langue : source et cible, jamais douze colonnes. Grille virtualisée,
  saisie sans bouton « Enregistrer », panneau de contexte permanent.
- Par clé : une clé, toutes ses langues empilées et repliées. Répond à
  « ce libellé est-il prêt partout ? ».
- Mode Focus dans les deux : une file à vider, ⌘↵ pour enchaîner.
- Le traducteur ne voit jamais d'ICU : pastilles de variables, un champ
  par catégorie CLDR de la langue cible.

Administration
- Deux niveaux : projet (membres, clés API, plateformes) et organisation
  (annuaire des comptes, création de projets).
- Invitations par e-mail, jeton 256 bits stocké haché.
- Désactiver un compte coupe les sessions en cours, pas seulement les
  connexions suivantes.
- Les plateformes s'archivent ; ni elles ni les environnements ne se
  suppriment — la trace explique pourquoi telle clé existe.

CLI tqs
- PHAR autonome de 3 Mo, autoloader généré : le dépôt client ne dépend
  ni de Composer ni de la disponibilité de TQ-Slator.
- init / push / pull / status ; le sync est non destructif par défaut et
  son prune est scopé plateforme.

126 tests, PHPStan niveau 8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 08:16:05 +02:00

53 lines
2 KiB
TypeScript

import { Link, NavLink } from 'react-router-dom';
import { useAuth } from '@/auth/AuthProvider';
/**
* Navigation d'un projet.
*
* Les entrées réservées aux administrateurs ne sont pas grisées : elles sont
* ABSENTES. Un menu plein d'options inaccessibles apprend à l'utilisateur que
* l'interface ne le concerne pas — c'est exactement l'inverse du but recherché.
*
* Le rôle n'est pas encore exposé par l'API de projet ; en attendant, on affiche
* l'administration aux comptes qui ont un rôle global élevé, et le serveur reste
* l'autorité — chaque endpoint refuse ce qu'il doit refuser.
*/
export function ProjectNav({ projectUuid, canAdminister }: { projectUuid: string; canAdminister: boolean }) {
const { user, logout } = useAuth();
const item = (to: string, label: string) => (
<NavLink
key={to}
to={to}
className={({ isActive }) =>
`rounded px-2.5 py-1 text-sm transition-colors ${
isActive ? 'bg-accent-soft font-medium text-accent' : 'text-ink-600 hover:bg-ink-100'
}`
}
>
{label}
</NavLink>
);
return (
<div className="flex items-center gap-1">
<Link to="/projects" className="mr-2 text-sm font-semibold text-ink-900 hover:text-accent">
TQ-Slator
</Link>
<div className="h-5 w-px bg-ink-200" />
{item(`/p/${projectUuid}/editor`, 'Éditeur')}
{canAdminister && item(`/p/${projectUuid}/members`, 'Membres')}
{canAdminister && item(`/p/${projectUuid}/platforms`, 'Plateformes')}
{canAdminister && item(`/p/${projectUuid}/integration`, 'Intégration')}
<span className="ml-auto flex items-center gap-3 text-xs text-ink-400">
<span>{user?.name}</span>
<button onClick={() => void logout()} className="hover:text-ink-700">
Déconnexion
</button>
</span>
</div>
);
}