Bon alors déjà, moi je suis contre les .inc, mais pour les .inc.php (faudrait pas qu'on puisse voir nos belles failles quand même
)
Sinon, pour gérer des traductions en php, je connais plusieurs méthodes, ayant travaillé sur des projets qui en avaient besoin :
* Stocker toute les traductions dans une base sql avec un champ int (tid), et plusieurs champs varchar (french, english, etc...) => ça bouffe des ressources serveur à fond pour rien, et c'est (très) lent.
* Une fonction translate("string") avec string par défaut en français, et un fichier langage.php qui définit la fonction translate ainsi : function translate($string) { switch($string) { ... case "string1": return("traduction1"); break; case "string2": return("traduction2"); break; ... } } => Ca prend moins de ressources, mais dès qu'on a quelques dizaines de cas, le switch devient malheureusement très lent
* Un tableau (toujours défini dans langage.php) défini comme ça : ... $txt[i] = "stringi"; ... => Pas mal, mais plus lent que la dernière solution (et moins pratique à cause des global $txt à ressortir un peu partout).
* Des defines (eux aussi dans langage.php) comme ceci : ... define("_STRING1","traduction1"); ... (le underscore est là pour facilement reconnaitre les constantes de langage...) => Pour moi, cette solution est la meilleure, et en ressources, et en temps.
).
)
Depuis quand y'a des failles dans des initialisation de variables (par des chaines de caractères)? 
