class CategoryTrad
{
$langue (obj)
$catName;
// …
}

Excuse-moi de revenir si tardivement (j’avais peu d’espoir que tu répondes ).

Tout d’abord, je te remercie de cette réponse qui me conforte dans ce que j’avais commencé.

Ensuite pour l’objet “Category”, tu dis :
“Quant à l’objet Category, encore une fois ça dépend, mais je pense que j’ajouterais un paramètre “lang” au constructeur/getter, pour ne sélectionner que la langue concernée. Avec éventuellement une méthode pour sélectionner toutes les langues en cas de besoin (dans le backend notamment).”

Effectivement dans mon backend je vais devoir lister toutes mes catégories de cette façon :
id – catName – langues
1,cat1,fr-en-ita
2,cat2,fr

Pour réaliser cet affichage, je fais appel à une requête qui me renvoie :
1,cat1,fr
1,cat1_en,en
1,cat1_ita,ita
2,cat2,fr

Et je crée un objet “Category” par langue. Je ne pense pas que ce soit très judicieux. J’avais pensé créer un objet Category_trad avec les champs à traduire uniquement (cf.annexe). J’obtenais alors deux objets Category. Cette solution me parait encore plus bizarre, car elle ne correspond plus à l’idée que je me faisais d’un objet métier.

Qu’en penses-tu ?
Cdt,
Pierre

——————
Annexe
——————

class Category
{
$id;
$dateAdd;
$arrayTrad;
// …
}

class CategoryTrad
{
$catName;
// …
}

L’admin des langues en back est toujours problématique et j’avoue ne pas avoir de solution idéale. D’abord il faut une table qui liste toutes les langues possibles. Ensuite pour les catégories (par exemple), si je dois gérer beaucoup de langues, je fais un formulaire normal qui insère la langue obligatoire par défaut (par exemple le français) ainsi que les valeurs communes (genre date, etc.). Ensuite je fais une autre page pour insérer/editer/supprimer les autres langues (mais sans toucher aux valeurs communes), genre “Ajouter une langue”. L’autre solution, s’il y a peu de langues, c’est de faire directement un formulaire avec deux ou trois champs (un par langue).

Quant à l’objet Category, encore une fois ça dépend, mais je pense que j’ajouterais un paramètre “lang” au constructeur/getter, pour ne selectionner que la langue concernée. Avec eventuellement une méthode pour selectionner toutes les langues en cas de besoin (dans le backend notamment).

Petite note au passage, car je m’apperçois d’une petite erreur dans l’article: si le code de langue utilisé est au format ISO 639-1 (“fr”, “en”, …) il vaut mieux utiliser le type CHAR(2), plus compact et plus rapide. Le type que j’utilise dans l’article, VARCHAR(6) date d’un vieux projet pour stocker le tag IETF (genre “en-US”, “en-CA”, “fr-FR”, etc.), mais c’était une mauvaise idée au final (en plus, ça rend la PK plus grosse).

Voila voila, j’espère que ces quelques pistes pourront t’aider.

a+