Site multi langue + ordonnancement de requetes SQL

[Dragohn]

Bonsoir,

J'ai fait quelques recherches ici, et à gauche droite, sans trouver de réponses, je me permets de vous demander 2 conseils.

1ère question:

Je me fais un petit site bilingue (fr/en). Pour les textes 'fixes' je gère ca dans des fichiers de langue en définissant des constantes. Par contre, pour le contenu dynamique, je me pose une question: comment gérer le biliguisme?

Pour le moment je gère celà en ayant dans chaque table un champ 'fr' et le champ 'en' qui lui correspond.

Par exemple si j'ai un champ title_fr, j'ai dans la même table un champ title_en. Lorsque je veux récupérer le champ qui m'intéresse, je fais donc dans ma requete quelque chose du genreen php:

$req = 'SELECT title_'.$page->lang.' as title FROM mytable';

Avec $page->lang qui donne 'fr' ou 'en'.

Ma question est donc: ma solution est elle bonne, ou vaut il mieux découper et avoir 2 tables différentes pour chaque langue à chaque fois? Je pense que les 2 solutions se valent, mais je peux me tromper, et autant faire au mieux.

Ou s'il y a une autre solution que les 2 susmentionnées, je serai assez preneur.

2ème question:

j'ai lu qu'il valait mieux, dans le cas d'accès à une base de données, regrouper les requêtes pour les traiter directement, et seulement ensuite faire le traitement d'affichage. Est ce vraiment meilleur que de faire les requêtes dispersées dans le code?

Je demande ça, car je découpe pas mal mon code en différents fichiers pour que mes pages soient des blocks inclus. Le souci c'est que pour regrouper mes requêtes cela veut dire les sortir des blocks auxquels ils appartiennent, et j'ai l'impression que niveau maintenance de code ce sera moins pratique.

Y a t il une méhode à privilégier? Que me conseillez vous?

Les 2 questions peuvent sembler bateau, mais j'essaie de prendre de bonnes habitudes. Donc si vous pouviez éclairer ma lanterne, ce serait sympa!

Merci, et bonne soirée

[astero-H]

1ère partie:

Mauvaise idée, quand tu rajoutes des langues t'as pas l'air con

Perso je verrais plus un truc du genre :

$req = 'SELECT title FROM mytable WHERE lang="'.$page->lang.'"';

En changeant ta clé primaire en (id, lang), ça pourrait être bien aussi.

Ou alors si tous les champs sont pas à traduire et que tu veux faire ça propre, tu créés une table enfant pour la localisation

2ème partie:

Aucun rapport avec avec les perfs... sauf si tu ouvres/fermes la connexion à chaque requête lol

En fait ce que tu décris ça s'apelle tout simplement être organisé :)

Après ça dépend des gouts, certains s'en foutent totalement de la gueule de leur code tant que ça marche... je pense pas que ceux là iront bien loin....

[windu.2b]

Je suis d'accord avec astero-H en ce qui concerne la 2° partie ("où mettre les requêtes SQL?"): les laisser là où tu en as besoin ne pose pas de pb d'exécution (modulo le cas où tu ouvrirais/fermerais sans cesse la connexion à la BDD, action qui est "gourmande" en temps [comparé au temps mis pour exécuter une requête]).

Pour ce qui est de la première partie, c'est plus délicat à dire. Il existe différentes écoles: ceux qui prônent le tout-tableau dans des fichiers (gain en récupération), ceux qui prônent le tout-BDD (+ facile pour gérer l'ajout/modification/suppression des chaînes de caractère)...

[Dragohn]

Merci beaucoup pour vos réponses, ça m'éclaire énormément.

Pour la gestion des données dynamiques, je vais partir sur l'idée de la clé primaire (id, lang), avec une table regroupant mes langues disponibles... Ca me permettra de mieux gérer l'ajout d'autres données (multilangues) par la suite.

Oki pour les requêtes. Je prèfère les laisser dans mes blocks, mon code est mieux découpé, et je peux réutiliser facilement les blocks dans différentes pages... de toute façon je me connecte à la base de données en début de traitement et je referme une fois fini. Je ne fais pas d'ouverture/fermeture à chaque requête, j'avais cru comprendre que c'était la pire des choses à faire...

J'ai encore une nouvelle petite question où là j'ai du mal à gérer proprement sans faire un truc de 'goret' à mon gout: gérer les mots clefs d'une page (dans les meta) en gérant le mutli langue. Pour le moment je stocke les mots clefs dans les fichiers de langue avec le texte 'statique', et donc ça marche.

Mais j'ai l'impression que ça ne doit pas être la meilleure des solutions... auriez vous un conseil ou approche différente?

En fait, j'ai l'impression de trouver peu de doc (ou alors je cherche très mal) qui traite de ce cas des sites à contenus multi langue et à la gestion correcte de tout (texte statique, dynamique, keywords...). Si vous avez des liens ou articles à ce sujet, je serai assez preneur, car ça m'intéresse vraiment beaucoup!

Encore merci à vous 2, ça me permet de mieux avancer avec des avis extérieurs

[windu.2b]

Salut,

pour tes mot-clés tu peux là aussi avoir recours à une BDD et/ou à un tableau php dans un fichier, pour les stocker...

La façon de les afficher sera sensiblement la même:

<meta keywords="<?php echo $listeMotsCles; ?>" />

avec $listeMotsCles qui contient tous les mots-clés pour une langue précise, chaque mot étant séparé par une virgule.

[Dragohn]

Ok, en gros ce que j'avais fait. Pour chaque page, un fichier de langue est associé (textes fixes + keywords), et dedans j'ai définis avec un define(KEYWORDS, 'mot1, mot2, ....'); et après je fais un echo de KEYWORDS.

Ca me gênait dans le sens où il faut faire ça pour chaque page, mais en y réfléchissant bien, on est bien obligé de faire le boulot pour chaque page dans tous les cas (les mots clefs vont pas apparaitre tout seul)

Encore merci pour les conseils, ça m'aide bien :)

[windu.2b]

Plutot que de faire ca pour chaque page, tu peux au moins faire ca pour chaque langue (là, t'as pas le choix), mais en décomposant mot à mot.

Ainsi, il te suffira d'assembler les mots que tu vveux pour chaque page, pratique si tu as des mots qui reviennent dans plusieurs pages