Reprise du message précédent :

Tu parles de la 3.0 alpha ?

 
J'avais pas vu ton edit, merci beaucoup
 
Tu pourrai me préciser les width inutiles s'il te plait ?
 
Pour styliser le A, je vais voir ça dès que je peux.
 
Quand tu parles du prologue xml, c'est bien ça :
 
<?xml version="1.0" encoding="UTF-8"?>
 

Yay

ouais cette merde fait chier et ne sert à rien, sauf si tu sers ta page en text/xml a part ça keudal

 
Merci
 
Je vais donc devoir toucher au code source de dotclear.

C'est application/xhtml+xml le type recommandé pour les xhtml 1.x

vu le peu de support et les emmerdes que ca génère, j'ai tjs pas compris l'intéret de faire du XHTML 1.1 ou plus...

Il n'y en a aucun.

Super, je vais faire du JS intrusif \o/

laisse moi deviner l'argumentation : c'est pour un intranet, OSEF, on a pas le temps, on doit livrer pour hier ?

 
Wala, avec une jolie balise noscript "pour profiter pleinement de ce site blablabla" \:o/

voila pour nous c'est pareil
 
 
et de toute facon, je vois pas comment on aurais certaines choses sans js...

moi si : on a vendu aux décideurs que le web ct facile, que ca se développait "vite", que ct simple à maintenir (pas de déploiement sur des postes clients), etc...
 
on a oublié de dire aux users que y'avait 2-3 restrictions, qu'on pouvait pas avoir la convivialité d'un client lourd sauf au prix de bidouilles sauvages, que la techno meme introduisant certaines contraintes dans la navigation entre écrans (gestion du retour arrière, etc...)...
 
bilan, tu vois des specs où ce qu'il faudrait c'est un client lourd...ou alors il faudrait expliquer au client que c'est pas fait pour...mais là y'a tjs un connard qui vient et dit : mais si on peut, en gros JS sale qui tache, ou en flash de partout...

Java web start ?

Pour un site multilangue, le texte dans la page est de la forme
echo __('Ma phrase blabla');
 
Avec traduction etc.
 
Mais quand on veut mettre une description dans une BDD par exemple, quelle est la meilleure solution ?
 
ID
NAME
DESC_FR
DESC_EN
DESC_DE
DESC_ES
etc...
 
?
 
Une table de langues à part ?
 
J'ai un peu de mal à trouver LA bonne solution.
 
Marchi

bah si ton identifiant c'est directement la phrase en français je dirais une table de la forme :
 
message_langue_de_base | id_autre_langue | message_autre_langue.
 
Après faut voir si une BDD c'est le truc le plus pratique pour des traducteurs, t'as une interface de traduction ?

http://www.digital-web.com/article [...] f_the_web/

oui donc en gros y'a une vision théorique et une vision pragmatique, et c'est la vision pragmatique qui va l'emporter...
 
étonnant, non ?

 
Pour le moment je n'ai rien du tout, on est en train d'établir la structure "sur le papier", le SI, le cahier des charges...
 
On va utiliser Symfony pour ce projet (c'est un projet assez monstrueux), donc pour la traduction du texte "dur" ça ne posera pas de problème. Pour la traduction du texte en BDD il y 'aura soit une interface de trad, soit un export/import de la base.
 
Par contre dans ton exemple j'ai du mal à saisir.
Admettons une table X qui contient

 
Dans description le texte serait donc français. En gros lors du SELECT il faudrait faire une jointure de la table de trad, entre le champ "description" et "message_langue_de_base", pour sélectionner "message_autre_langue" grace à l'id de langue ? Je suis pas sûr d'avoir bien compris là
 
Sinon est-ce qu'on pourrait pas faire comme ça :

 
avec une table des langues

 
Je sais pas si c'est clair...

 
Non, dans mon idée ça ressemble à ça :
 
Message | Langue | Traduction
"Bob aime les bananes" | Anglais | " Bob likes bananas"
"Bob aime les bananes" | Espagnol | "Bob gusta los bananas"
 
Select Traduction from LaTable Where Langue=Anglais and Message="Bob aime les bananes"
Si tu trouve rien 1) tu envoie une alerte sur l'interface de traduction 2) tu utilise le texte en langue d'origine.

 
Je vois ... mais si le texte à traduire fait 40 lignes et que le site est en 25 langues ? Ça risque pas d'être un peu violent pour la BDD ?

Si un texte fait 40 lignes personne le lira sur un site

( plus sérieusement, 40l*80c*25langues = ~80 Ko, je crois qu'une BDD peut le supporter non ? )

Oui non c'est sûr... Je trouvais juste étrange de stocker une "clé" qui pouvait dans certains cas faire plusieurs paragraphes, et ce, autant de fois qu'il y a de langue.

Ça roule merci

Edit :

Juste une chose, dans ton exemple tu mets

SELECT traduction FROM laTable WHERE langue = "Anglais" AND message = "Bob aime les bananes"

Mais dans le cas présent ça serait plutôt une jointure non ?

SELECT t1.name, t1.msg, t2.trad
LEFT JOIN table2 t2 ON t2.msg = t1.msg
FROM table1 t1
WHERE id = 999

Puis à l'affiche si "t2.trad" est vide, alors on affiche "t1.msg" non ?

Tu risques pas d'avoir des problèmes de perf sur ta DB si t'utilises comme clef des longues chaines ? Globalize pour Rails utilise justement la DB pour stocker les clefs des chaines à traduire, mais sur un VARCHAR seulement. La plupart du temps les chaines sont pas si longues, donc pour le texte dans la langue de base sa suffit, mais pour des chaines plus longues t'es obligé de mettre la trad même pour la langue d'origine, parce que le VARCHAR coupe le truc. J'avais vu que c'était pour des questions de perfs, la recherche en VARCHAR étant bien plus rapide que sur un champ TEXT MySQL.

Superbe idée. Et le jour où tu dois modifier le texte de la langue principale, tu te retrouves soit à "traduire" ta langue principale pour avoir ton nouveau texte dans la langue principale, soit à modifier des dizaines de lignes dans la base pour que les traductions suivent le mouvement.
Et je ne te dis pas si en faisant la modif dans la langue principale tu te retrouve à avoir deux fois le même texte mais avec des traductions différentes (ça arrive parfois)  
 
Enfin, bon, c'est pas la première fois qu'on en parle sur ce forum et personne n'a trouvé de solution qui contente tout le monde.

C'est quand même le principe de gettext d'avoir chaque chaine qui est référencé par la chaine dans la langue principale

Ce qui se fait en une seule requète, et est de toute façon est une bonne chose, si le message d'origine change les traductions doivent être vérifiées et soit validées soit modifiées par les traducteurs.

Lorsque ça arrive tu rajoute le principe de contexte avec une colonne en plus pour le spécifier, la valeur par défaut de Null ne génant aucunement les enregistrements existants. (tant qu'à faire tu peut le faire dessuite mais c'était pas nécessaire pour l'explication au dessus).

C'est bien ce que je disais, c'est une discussion qu'on a déjà eu plusieurs fois sur ce forum sans qu'on arrive à être tous d'accord (à force, je connais les arguments et contre arguments quasiment par cœur. ) alors ça ne sert à rien de la refaire à nouveau vu qu'on ne changera pas d'avis ni les un ni les autres.
 
Je dirais juste un dernier petit truc : 0x90 > C'est vrai une seule requête suffit, à condition de ne pas se planter en la faisant (donc à condition de s'être noté l'ancien texte et de ne pas louper la requête sinon gros dégâts en vue) et à condition de ne pas oublier de l'exécuter à chaque changement d'un texte. Ca devient très vite lourd pour le développeur. Mais l'avantage de votre système, c'est qu'on comprend plus facilement une phrase du genre "Voulez vous vraiment supprimer cet utilisateur?" qu'un indice du genre "CONF_DESTRUCT_UTIL".
 
Bon, maintenant qu'on a dit les principaux pour et contre, je pense qu'on a pas besoin de continuer sur ce sujet.

 
Euh ouais mais non, je parle de faire un truc avec une vrai interface utilisable, pas d'attaquer la base comme un gros sale et de tout faire à la main à chaque modifs ou nouvelle langue.

De toute manière, même si t'as une interface d'administration, à partir du moment où tu modifies le texte dans le code du site, tu es obligé d'indiquer l'ancien et le nouveau texte dans la partie d'administration sinon comment elle fait pour savoir quoi modifier? J'imagine que le plus simple que tu as trouvé, c'est d'ouvrir la partie d'administration de ton site, d'aller dans la partie de gestion de la langue principale, d'y sélectionner l'ancien texte puis de le modifier dans le code et de saisir la modif dans l'administration du site. Même dit comme ça, je trouve ça lourd comme méthode de travail.
 
Si tu as fait un système plus légé que ça alors je veux bien voir ce que ça donne sous forme de démo par ce que pour le moment je n'ai rien vu de probant dans ce domaine et le plus simple que j'ai vu aussi bien d'un point de vue développeur qu'administrateur, c'est l'utilisation des codes à la "CONF_DESTRUCT_UTIL" vu qu'ils ont le mérite de ne pas changer même si on change les traductions correspondantes dans quasiment toutes les langues.

dites, y'a un moyen de retenir le sens des &lt; &gt ?
 
je me grourre tout le temps entre les 2

Texte modifié dans le code -> Visite de la page dans une langue X -> traduction non trouvée -> alerte au traducteur :

Le traducteur reçoit l'instance non traduite dans une petite page qui ressemble en gros à (attention les yeux) :
----------------------------------------------------------------------------
 Message à traduire : [____________] (non-editable)
 (*)  Utiliser une traduction orpheline : [______________| V ]  (liste à choix)
 (  )  Nouvelle traduction : [___________] (editable librement)
            [ OK ]
----------------------------------------------------------------------------
Les traductions orphelines sont listées d'après la base de donnée auxquelles ont soustraits le contenu des macros __(), c'est les traductions qui servent plus à rien. et SURTOUT, on les liste par distance de leveinstein (ou simmilaire) entre ce qu'elles traduisaient et le message à traduire.

• Si c'est un quickfix de la langue d'origine, 99% de chance que la seule action du traducteur soit de clicker sur OK.
• Si faut vraiment changer, il tappe le texte et valide.

Ne me dis rien, toi t'as été designer d'UI ASCII pour les softs d'install Linux, hein ?

lower than
greater than

et non pas left et gright

 
Oui, mais utiliser LefT et riGhT comme moyen mnémotechnique fonctionne également, puisque ces symboles sont toujours représentés dans cet ordre : < >

 
ah voila, je cherchais un rapport avec Left et Right, merci