Laurent Pelecq a écrit :
En fait je ne sais pas du tout.
Il faudrait surtout éviter de trop complexifier le mécanisme (que ca reste intuitif) et que cette traduction ne soit pas obligatoire... Une idée ?



Mon idée se serait d'avoir une combo-box en haut de la page de configuration des champs pour la langue. Par défaut elle est positionnée sur la langue d'installation. Si on séléctionne une autre langue, la traduction des noms de champs apparaît (ou est initialisé avec la langue par défaut si elle n'existe pas).

Si on ne rentre aucune traduction, le nom des champs seront dans la langue par défaut.

Ca me parait être une bonne solution. En libellant cette combo box "Traduction (facultative)" (ou quelquechose du même genre), ce devrait être assez intuitif (et ne pas rebuter ceux qui n'ont aucun intéret à traduire les libellés).

Les traductions serait stockées dans une table galette_i18n avec la chaîne originale, la langue, la traduction et un compteur de référence. Si on supprime un champ, on décrémente le compteur de référence des traductions. Si le compteur est à zéro, on supprime la traduction. Actuellement, ce n'est pas necéssaire mais si d'autres parties utilisent la traduction dynamique, il ne faut pas supprimer une traduction qui est toujours utilisée.

Là aussi ça me parait techniquement correct. La structure de la table galette_i18n étant trés générique, on devrait aussi pouvoir l'utiliser pour d'autres éléments dynamiques. La lecture de cette table et la déclaration des variables associées doit pouvoir se faire dans le lang.inc.php actuel et complêter le tableau $lang déclaré par les fichiers lang. Ainsi on pourra continuer à utiliser la fonction _T() pour la traduction des libellés.

Fred

Répondre à