Re-bonjour,
Voilà , j’ai besoin d’un petit conseil concernant globalize :
Dans la table globalize_translate l’identifiant de texte à traduire
tr_key est en VARCHAR(255).
Or, ayant des textes parfois plus grands dans mon appli, ils sont
tronqués et globalize n’arrive plus à retrouver la bonne tr_key.
Depuis la version MySQL 5.0.3 de MySQL, il est possible de spécifier des
VARCHAR jusqu’Ã 65535.
Pour palier à cette limitation, vaut-il mieux alors étendre la valeur
max du VARCHAR de la tr_key (migrate créé par défaut du VARCHAR(255))
ou alors passer la tr_key en type TEXT ?
Sinon, une autre solution plus propre ?
++
Jérémy.
On 6/1/07, Jérémy Dierx [email protected] wrote:
VARCHAR jusqu’Ã 65535.
Je n’ai pas d’expérience avec globalize particulièrement mais je suis
très
étonné de te voir avec des clés si longues. Il est fréquent d’utiliser
directement le texte à traduire comme clé. Ca permet d’avoir une des
langues
automatiquement sans rien faire et c’est plus clair dans le code. Ceci
dit,
ça reste une clé. Si tu fais autre chose que des simples phrases (qui
devraient tenir dans 100 caractères), tu devrais bien utiliser une clé.
En
plus ça facilitera tes traductions si tu dois changer un truc dans la
langue
principale et pas dans les autres.
Sur un second point, si je me rappelle bien globalize, il y a d’un côté
les
traductions de l’interface et de l’autre côté les traductions des
contenus.
Si je comprend bien tu parles là du côté interface, et je vois mal des
choses si longues dans l’interface. Si tu as besoin d’un type TEXT c’est
probablement directement des paragraphes complets, Ã stocker dans un
modèle
dédié.
–
Éric Daspet
http://eric.daspet.name/
Le vendredi 01 juin 2007 à 14:43 +0200, Eric D. a écrit :
On 6/1/07, Jérémy Dierx [email protected] wrote:
autres.
Merci pour ta réponse.
Effectivement, je vais utiliser les tr_key comme il se doit, c’est Ã
dire surtout pas comme texte original (c’était bien pratique
pourtant :-S) mais comme des identifiants pour TOUTES les traductions.
En plus cela va accélérer la recherche en base.
Quand même…c’était bien pratique…
Du coup j’ai encore du boulot de réécriture des tr_key et des textes en
langue de base. Bon j’y retourne sinon je suis pas coucher ce soir moi !
Sur un second point, si je me rappelle bien globalize, il y a d’un
côté les traductions de l’interface et de l’autre côté les traductions
des contenus. Si je comprend bien tu parles là du côté interface, et
je vois mal des choses si longues dans l’interface. Si tu as besoin
d’un type TEXT c’est probablement directement des paragraphes
complets, à stocker dans un modèle dédié.
hein? moi pas compris ! Heu je parle de la traduction du contenu
(statique en l’occurrence) : <%“=mon texte qui doit être une clé”.t%>
En tout cas, merci de m’avoir fait prendre conscience qu’une clé doit
rester une clé 
Rails me rendrait-il feignant ?
Bon week end à tous !
Jérémy.