Je dirais qu'il faut bien situer les différents problèmes dans la localisation d'une application, et je le découperais comme ça :

• La définition de la langue : ça c'est très classique, et je n'en ai même pas parlé. On vérifie si un cookie ou un $_GET['lang'] est défini. Si oui on utilise ça, sinon on extrait le code langue de l'entête envoyé par le navigateur pour trouver la langue par défaut, et on met en place le cookie. Classique, éprouvé, on ne reviendra pas dessus.
• La traduction de l'interface (partie statique) : là on a 2 grandes méthodes. La méthode base de données me paraît complètement absurde, faire une requête pour aller chercher l'intitulé du bouton "Envoyer" me semble démesuré, mais bon il faut y refléchir pourquoi pas. La méthode par fichier se découpe en deux "sous-méthodes" : gettext et include. On ne reviendra pas sur les avantages/inconvénients des deux méthodes on en a à peu près fait le tour je pense.
• La traduction du contenu (partie dynamique) : là pareil on a la méthode base de données ou fichiers. Mais la méthode par fichier PO me paraît inadaptée, vu le caractère fortement dynamique du contenu d'un site. Utiliser des fichiers PO pour le contenu rendrait impossible la mise en place d'un CMS. On pourra cependant utiliser de la traduction de contenu statique pour définir la source de données (nom de la table ou chemin du fichier contenu le texte localisé).

Je sens poindre la rédaction d'une FAQ ou d'un tuto au vu de ce topic

Je sens poindre la rédaction d'une FAQ ou d'un tuto au vu de ce topic

Exemple, j'ai un client (spécifique ciblé uniquement labo pharma) qui à un site de 6 pages simples de présentation avec guère plus de 5 ou 6 lignes de texte par page, le tout en 5 langues.

Une $var en cookie et de simples fichiers txt ont suffit pour gérer les langues.
L'evolution du site est inexistante car les explications sont tellement ciblées que seuls les gens concernés par cette technologie ont un pouvoir de compréhension.

include gettext('/contenu/aide/index.html');

• La définition de la langue : ça c'est très classique, et je n'en ai même pas parlé. On vérifie si un cookie ou un $_GET['lang'] est défini. Si oui on utilise ça, sinon on extrait le code langue de l'entête envoyé par le navigateur pour trouver la langue par défaut, et on met en place le cookie. Classique, éprouvé, on ne reviendra pas dessus.
• La traduction de l'interface (partie statique) : là on a 2 grandes méthodes. La méthode base de données me paraît complètement absurde, faire une requête pour aller chercher l'intitulé du bouton "Envoyer" me semble démesuré, mais bon il faut y refléchir pourquoi pas. La méthode par fichier se découpe en deux "sous-méthodes" : gettext et include. On ne reviendra pas sur les avantages/inconvénients des deux méthodes on en a à peu près fait le tour je pense.
• La traduction du contenu (partie dynamique) : là pareil on a la méthode base de données ou fichiers. Mais la méthode par fichier PO me paraît inadaptée, vu le caractère fortement dynamique du contenu d'un site. Utiliser des fichiers PO pour le contenu rendrait impossible la mise en place d'un CMS. On pourra cependant utiliser de la traduction de contenu statique pour définir la source de données (nom de la table ou chemin du fichier contenu le texte localisé).

Comme toutes les méthodes «pro» : l'utilisation d'un framework, le respect de standards, la mise en place d'un dépôt SVN, le commentaire du code, etc...

La question est de savoirsi on travaille vraiment sur un petit projet, car ne pas utiliser ces méthodes le condamne souvent d'office à rester petit

$str = array ("Hello" => "Bonjour", .... , "Bye" => "Au revoir");

Pourquoi ne pas simplement utiliser gettext(), qui constitue le standard en la matière ?

N'y aurait-il pas le mot "simplement" en trop dans ta phrase?

Pourquoi ne pas simplement utiliser gettext(), qui constitue le standard en la matière ?

<?php

// Choix de la langue
setlocale(LC_ALL, 'fr');

// Spécifie la localisation des tables de traduction (le dossier contenant l'arborescence) pour le domaine indiqué
bindtextdomain("MonAppli", "./locale");

// Choix du domaine
textdomain("MonAppli");

// La traduction est cherché dans ./locale/fr/LC_MESSAGES/MonAppli.mo

// Affichage d'un message de test
printf(gettext("Hello %s !") . "\n", getenv('USER'));

// Or use the alias _() for gettext()
echo _("Bye bye :)") . "\n";

?>

• La localisation d'une appli non localisée au départ est très simple (cf. mon Post-Scriptum).
• On utilise la méthode standard GNU, ce qui signifie qu'un éventuel portage ne posera jamais le moindre problème.
• On utilise la richesse de gettext, pour en avoir une idée jeter un oeil par exemple à la fonction ngettext(), comment gérer aussi simplement les pluriels avec une autre méthode ?
• On a une performance accrue (utilisation de la RAM, et rapidité de la traduction amoindries).
• L'utilisation est vraiment simplissime avec la fonction _()
• La définition de la langue de travail repose sur setlocale(), ce qui localise toute l'application et certaines fonctions comme date() en profiteront du même coup.
• On peut gérer plusieurs encodages (des pages en UTF-8, d'autres en ISO-quelquechose, etc...) avec la génération de fichiers .po au bon encodage, et de la fonction bind_textdomain_codeset()

• Nécessite de compiler les fichier *.po avant de les envoyer sur le serveur.
• Nécessite la présence du module gettext dans la version de PHP (pas vraiment une difficulté puisque c'est activé par défaut)

//définition de la durée du cookie (1 an)
$durée_cook = "time()+ 365*3600*24";
//si le visiteur envoie la variable $_GET['lang'] pour choisir sa langue, on l'enregistre dans un cookie nommé 'lang'
isset($_GET['lang'])? setcookie("lang", $_GET['lang'], $durée_cook) : '' ; 

//si le cookie existe on le récupère sinon on donne la langue par défaut 
$lang = isset($_COOKIE['lang'])? $_COOKIE['lang'] : 'fr' ; 
//si $_GET['lang'] est envoyé on la récupère sinon on donne la valeur du cookie s'il existe sinon la valeur par défaut 
$lang = isset($_GET['lang'])? $_GET['lang'] : $lang ; 

//suivant la valeur de $lang on fait la correspondance avec le champ de la table dans la bdd. Si les champs de la table se nomment 'commentaire_fr',
//'commentaire_en' etc. cela donne :

switch ($lang) 
    { 
    case 'fr': $champ = 'commentaire_fr'; 
        break; 
    case 'en': $champ = 'commentaire_en'; 
        break; 
    case 'es': $champ = 'commentaire_es'; 
        break; 
    default : $champ = 'commentaire_fr'; 
    }
 
//puis la requête
$query = "SELECT $champ FROM table etc.