Reprise du message précédent :
Avec un BDD MySQL, un champ une langue et un champ pour le nom de variable ?

oui, je l'ai testé aussi, sur un gros système, et ça fonctionne aussi très bien, même pour du chinois!
PS: on utilisait Postgres et des chaînes binaires

jsuis pas convaincu par un acces BDD pour un fichier linguistique quand meme. En plus c'est plus relou de les modifier que dans un fichier texte je trouve.

Ça dépends pour quelle application. On avait une grosse appli, et les traductions étaient faites par des traducteurs pro, donc on avait fait une BDD à part avec backoffice.

l'avantage en effet des BDD c'est qu'on modifie les champs des langues d'un coup et ajouter des variables, donc une ligne de plus, avec les fichiers  txt ou php, il faut aussi ajouter pour chaque langue la variable ou ne pas se tromper dans les lignes.
La BDD semble fournir moins d'erreur, mais quelles sont les caractéristiques les plus optimales? UTF8 ?

Pour un BDD le plus simple c'est de mettre carrément du binaire.
Tu n'a alors qu'une chose à configurer: le charset utilisé dans tes pages web. Genre t'a du chinois, il y a plusieurs charset possibles, tu en choisit un (genre BIG5), tu fait tes pages d'ajout/modifiaction de chaîne avec ce charset, et dans ta base tu a directement la chaîne binaire correspondante, sans avoir à te soucier si ta BDD supporte le charset.
Pour avoir une liste de charset, regarde dans les menus de ton navigateur. Pour spécifier un charset, change le doctype (voir w3c.org) et le header de tes pages (Content-type: text/html; charset=... ).
Clic clac ça roule.

Mais dans ma BDD, le champ FR par exemple, les é sont remplacé par des ? quand je passe vers binary comme interclassement, mais bon s'il n'y a que ça je remet à jour à la main.
Donc si j'ai bien compris, je choisi l'interclassement en fonction de la langue?
Et si je choisi utf_bin pour tous?

plutôt un blob avec MySql.

le blob est de toute manière en binary, c'est ça le truc, je vois.

sympa ton truc nargy.
Question très con, comment on faire pour avoir une chaîne de caractère en binaire. J'y capte rien à ces trucs

> sympa ton truc nargy.  
- heu, je ne souhaite pas récupérer une gloire qui ne m'est pas dû: c'est une méthode russe! (si,si, des fois les méthodes russes sont efficaces)
 
> Question très con, comment on faire pour avoir une chaîne de caractère en binaire. J'y capte rien à ces trucs
- t'a rien à faire pour transformer ta chaîne en binaire: de toutes façon toute donnée est codée en binaire dans un ordinateur.

avec phpmyadmin il faut changer le champ en blob et ça vient automatiquement en binary.
Le PB, c'est qu'avec mon phpmyadmin, on ne peut plus modifier le contenu, il y a un bouton parcourir.
Je crois que l'on peut garder varchar(200) par exemple et choisir l'interclassement: utf8_unicode_ci.
Il faut juste mettre:
<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=UTF-8">
Entre les balise <header>.
Je vais tester, mais si qqun pense qu'il est mieux de faire autrement?

Attention à ne pas oublier de mettre: charset=utf8_general ou utf8_unicode car juste utf-8 ne fonctionne pas.

En utilisant un charset, tu perds une partie du bénéfice d'avoir tes messages dans une BDD. Laisse tomber PHPMyAdmin pour la modification des messages, fait plutot une page de backoffice et utilise PhpMyAdmin pour ajouter/supprimer.

et dans un fichier texte, tu peux avoir ton texte en binaire pour faire la même chose ? Ou il est forcément encodé dans un charset ?

> et dans un fichier texte, tu peux avoir ton texte en binaire pour faire la même chose ? Ou il est forcément encodé dans un charset ?
- il est forcément encodé. C'est à cause que l'éditeur de texte est obligé, à un moment donné, d'enregistrer les caractères que tu a écrit, et il l'enregistre avec des 1 et des 0 (binaire) et il doit connaître quel charset utiliser, histoire de savoir si 'A' est 00101000101 ou 011010100101 (et encore, je simplifie).
Au final, c'est codé eb binaire, seulement il faut bien définir si ``1`` veut dire ``vrai`` et ``0`` faux, ou si ``0`` veut dire ``vrai`` et ``1`` faux. C'est le charset qui indique celà.

donc si je créé un fichier fr.txt avec windows, le charset sera celui de windows ?
J'ai déjà fait des scripts avec ces fichiers lang.txt mais selon des serveurs, ca ne s'affiche pas de la même manière.

l'un fait de l'utf-8 par défaut tandis que l'autre , ce serait plus de l'ISO8859-1

> donc si je créé un fichier fr.txt avec windows, le charset sera celui de windows ?  
- oui, sauf si ton éditeur supporte d'autres charsets (ce doit être le cas de word).

Si tu a que des langues européennes, ça ne pose pas de problème, tu utilise le charset iso-western partout. Dans ce cas un fichier texte ou un include fait l'affaire. Et encore, même en franco-français tu voit des grands sites faits avec un charset windows faussement déclaré dans la page HTML qui n'affiche pas certains caractères (comme l'apostrophe).
 
Si tu doit faire cohabiter du russe et du chinois, c'est plus délicat, ça nécessite d'avoir un éditeur capable de changer de charset. La solution de facilité est d'utiliser l'Unicode, avec UTF-8, qui est théoriquement capable d'afficher tous les caractères.
 
Si tu utilise une BDD, tu va avoir des problèmes avec PHPMyAdmin, tu devra changer le charset à la main dans ton navigateur, en utilisant le menu Affichage->Encodage.
 
Toutes les solutions ci-dessus fonctionnent à peu près correctement quand tu est seul à entrer des messages dans la base de donnée. Si tu doit faire traduire les messages par quelqu'un d'autre, c'est déjà plus délicat puisque tu doit lui expliquer qu'il faut choisir le bon charset.
 
Dans la solution avec stockage binaire, tes traducteurs n'ont plus à se soucier de ce détail, et de ton côté ça te facilite la tâche car tu n'est plus obligé de faire correspondre le charset à la fois dans l'HTML et dans la base de donnée. Comme toutes les bases de données ont un stockage binaire, tu peut plus facilement changer de base de donnée ou avoir de multiples bases sans te soucier quelle base supporte quel charset.
 
À chaque langue traduite, tu as un charset associé, et c'est le navigateur qui se charge d'afficher proprement lorsqu'il rencontre le tag <DOCTYPE>. Le navigateur séléctionne aussi le bon clavier, c'est important pour certaines langues qui supportent à la fois plusieurs dispositions de clavier.
 
Ça donne une structure qui ressemble à ça:
Table Traductions:

• varchar langue
• varchar nom_message
• blob message

Table Langues:

• varchar langue // par ex. ``fr``
• varchar nom // par ex. ``Français``
• varchar charset

Indexes:
(Traductions.langue)
(Traductions.nom_message)
(Traductions.langue, Traductions.nom_message)
(Langues.langue)
Jointures:
(Langues.langue, Traductions.langue)
requêtes principales:

• Requête pour lister les langues:

SELECT langue, nom, charset FROM Langues;

• Requête pour lister les messages:

SELECT nom_message FROM Traductions WHERE langue='$langue';

• Requête pour extraire un message:

SELECT message FROM Traductions WHERE langue='$langue' AND nom_message='$nom_message';

• Requête pour modifier un message:

UPDATE Traductions set message='".mysql_real_escape_string($message)."' WHERE langue='$langue' AND nom_message='$nom_message';
 
Structure de la page de modification des messages:

• choisir une langue
• choisir un message
• donner la traduction
• enregistrer