Re: [Galette-devel] Localisation des champs dynamiques

[Deelight <deelight@xxxxxxxxxx>]

laurent.pelecq@xxxxxxxxxx a écrit :
> Salut,
>
> J'ai modifié l'interface de configuration des fiches pour pouvoir 
> traduire les champs dynamiques. Si ça vous intéresse, vous pouvez 
> tester. L'interface n'est pas géniale. On pourrait l'améliorer.
>
> Dès qu'au moins un champ dynamique est crée, un formulaire apparaît sur 
> la première page de configuration des fiches (il faut revenir cette la 
> page). Le nom du champ apparaît dans la traduction pour la langue 
> courante de l'utilisateur (on suppose qu'il donne des noms dans sa 
> langue). On peut y ajouter les traductions des autres langues.

Avec aucun champ dynamique défini, j'obtiens l'erreur :
"- SQL error: [SELECT DISTINCT(text_orig) FROM galette_l10n ORDER BY 
text_orig]" (alors que cette requete est OK)

Si j'ai un champ défini, je ne vois jamais le formulaire permettant la 
traduction. Je n'ai pas encore fouillé niveau code pour voir si je 
trouvais d'où cela venait. Je poursuis les tests.

> D'un point de vue du dev, il y a une table galette_l10n qui contient les 
> traductions et un compteur de référence au cas où le même texte apparaît 
> dans plusieurs champs. Il y a des fonctions supplémentaires dans 
> i18n.inc.php pour manipuler la table. La fonction _T est modifiée pour 
> aller chercher la traduction dans la table si elle n'est pas dans les 
> fichiers statiques. Si on passait à gettext, ça pourraît poser un 
> problème parce que la fonction _T de gettext ne ferait plus ce traitement.

Je pense que l'on peut modifier l'appel à _() dans _T() pour aller 
vérifier les traductions dynamiques si la valeur retournée par _() est 
identifique à la chaîne passée en arguement (c'est le comportement de 
_() quand il ne trouve pas de traduction). Il faut juste espèrer qu'une 
chaine ne soit pas équivalente à l'anglais une fois traduite dans un 
contexte, et équivalente à une chaine totalement différent dans les 
champs dynamiques (c'est le seul cas où ça poserait problème mais à mon 
avis c'est rarissime).

> La table pourrait aussi servir à traduire les différents status ou types 
> de cotisation plutôt que de les avoir en statique. Il faudrait modifier 
> les .sql. Le jour où on pourra configurer ces champs, les traductions 
> seraient à leur place.

Oui tout à fait.
Je pense d'ailleurs me pencher la dessus assez rapidement après mon 
déménagement car c'est quelquechose qui a plusieurs fois été demandé.

Frédéric