D'une manière générale, je dirai qu'il y a trois façons de faire la chose (du moins, les trois les plus courants) :
- - En codant la chose directement dans un fichier PHP.
- En mettant les chaînes de caractères dans un fichier à part, type INI ou XML.
- En utilisant une base de données.
A voir les langues que tu comptes utiliser (à savoir surtout le chinois), la première solution n'est pas envisageable, vu qu'un fichier .php avec les caractères unicode, c'est un peu...
Pareil pour INI, c'est pas très bien lorsqu'il est question d'unicode. En revanche, ça peut marcher, je pense, avec un XML. L'avantage, ensuite, c'est que c'est facilement gérable, et tu peux définir la structure qui te convient le mieux à ton XML (à savoir, soit un élément avec les différents langues, ou bien inversement un élément pour chaque langue...).
Finalement, la version SQL me semble être la plus raisonnable. C'est, a priori, plus rapide que de lire à chaque fois un fichier XML ; de plus, c'est facilement gérable par la suite. Quant à ta question concernant l'encodage à sélectionner, s'il y a UTF-8, c'est bon.
Si je le faisais avec une BdD, j'aurais une table spécifique pour l'interface linguistique. Dans cette table, j'aurais les champs suivants:
id
nom_page (une zone texte où noter les principales pages utlisant ces textes)
fr
en
es
ch (c'est quoi le code du chinois?)
timestamp (pour garder en note la date de la mise à jour)
Il suffirait alors de l'exploiter en fonction d'un code langue choisi par l'usager et utilisé avec mysql_fetch_array
$ContenuLinguistique[$ChxLng]
Je doute que c'est la meilleure solution ; je conseillerai plutôt le tableau avec les champs :
- - id (PRMARY)
- language (VARCHAR(5))
- body (TEXT) ou (VARCHAR...)
L'avantage, c'est que, déjà, si on doit changer ou ajouter une langue, c'est plus facile de faire et on a pas à changer la structure du tableau par la suite ; en plus, le même site n'a pas forcement les mêmes chaines de caractères en toutes les langues. (Exemple : la mention CNIL en chinois, j'vois pas trop l'intérêt.

) Et finalement, c'est plus élégant d'avoir la langue en WHERE plutôt qu'en nom de colonne d'un tableau (par exemple, si on retire les chaines de caractères avec une stored procedure, c'est vraiment moche de passer le nom de colonne en paramètre de la procédure).