Le moyen le plus efficace de créer un fichier de langage en PHP?
Questions mises à jour au lieu de créer une nouvelle question ...
Je souhaite vraiment proposer quelques langues autres que l'anglais sur mon site de réseau social que je suis en train de construire. Ce sera la première fois que je ferai n'importe quel type de traduction, veuillez donc supporter.
Je fais des recherches, je suis donc à l’écoute et ouvert aux idées, et j’ai déjà beaucoup de questions à poser.
1)
Que signifie i18n, je le vois souvent lors de mes recherches sur la traduction d'une langue sur SO?
2)
La plupart des gens disent que l'utilisation gettext } _ PHP a une extension ou un support pour cela,
eh bien, je me suis renseigné à ce sujet et j’en ai une compréhension élémentaire. Pour autant que je sache, il ya beaucoup de travail supplémentaire à faire pour aller dans cette voie,
Je parle de coder mon site pour qu’il utilise ses fonctions, c’est-à-dire; _ ('hello world, je suis en anglais pour l'instant') ou sinon gettext ('hello world, je suis en anglais pour l'instant') n'est pas un problème, quel que soit l'itinéraire emprunté nécessitera que.
Mais vous devez ensuite installer gettext sur votre serveur et le faire fonctionner,
puis utiliser des éditeurs spéciaux pour créer des fichiers spéciaux et les compiler, je pense?
Cela ressemble à une douleur, je crois comprendre que c’est censé être la meilleure voie à suivre, eh bien tout le monde semble le dire.
Alors, quelqu'un peut-il me dire pourquoi c'est la voie à suivre?
3)
J'aime beaucoup la simplicité de cette approche: il suffit de créer un tableau de langues et d’appeler la phrase dont vous avez besoin dans une fonction comme dans l’exemple ci-dessous. Il vous suffira d’inclure un fichier avec le tableau de langues approprié.
Ce que je veux vraiment savoir, est-ce que ce serait la méthode la moins performante sur un site à fort trafic et relativement grand par rapport à l’utilisation de gettext et si oui, pouvez-vous expliquer pourquoi, s'il vous plaît?
<?PHP
//Have seperate language files for each language I add, this would be english file
function lang($phrase){
static $lang = array(
'NO_PHOTO' => 'No photo\'s available',
'NEW_MEMBER' => 'This user is new'
);
return $lang[$phrase];
}
//Then in application where there is text from the site and not from users I would do something like this
echo lang('NO_PHOTO'); // No photo's available would show here
?>
* du code utilisé dans la réponse de brianreavis ci-dessous
Ne réinventez pas la roue. Utilisez par exemple gettext ou Zend_Translate .
Il serait probablement préférable de définir une fonction qui gère votre mappage de langue. Ainsi, si vous do souhaitez modifier son fonctionnement par la suite, vous n'êtes pas obligé de parcourir des centaines de scripts pour les cas où vous avez utilisé $lang[...] et de les remplacer par autre chose.
Quelque chose comme cela fonctionnerait et serait agréable et rapide:
function lang($phrase){
static $lang = array(
'NO_PHOTO' => 'No photo\'s available',
'NEW_MEMBER' => 'This user is new'
);
return $lang[$phrase];
}
Assurez sure le tableau est déclaré static à l'intérieur de la fonction afin qu'il ne soit pas réalloué à chaque appel de la fonction. Ceci est particulièrement important lorsque $lang est vraiment volumineux.
Pour l'utiliser:
echo lang('NO_PHOTO');
Pour gérer plusieurs langues, il suffit de définir cette fonction dans plusieurs fichiers (tels que en.php, fr.php, etc.) et require(), le fichier approprié pour l'utilisateur.
Cela pourrait mieux fonctionner:
function _L($phrase){
static $_L = array(
'NO_PHOTO' => 'No photo\'s available',
'NEW_MEMBER' => 'This user is new'
);
return (!array_key_exists($phrase,$_L)) ? $phrase : $_L[$phrase];
}
Cest ce que j’utilise pour le moment. Si la langue n'est pas trouvée, la phrase sera renvoyée à la place d'une erreur.
Notez qu'un tableau ne peut pas contenir plus de 65500 éléments. Ça devrait suffire mais bon, rien que dire.
Voici un code que j'utilise pour vérifier la langue de l'utilisateur:
<?php
function setSessionLanguageToDefault() {
$ip=$_SERVER['REMOTE_ADDR'];
$url='http://api.hostip.info/get_html.php?ip='.$ip;
$data=file_get_contents($url);
$s=explode (':',$data);
$s2=explode('(',$s[1]);
$country=str_replace(')','',substr($s2[1], 0, 3));
if ($country=='us') {
$country='en';
}
$country=strtolower(ereg_replace("[^A-Za-z0-9]", "", $country ));
$_SESSION["_LANGUAGE"]=$country;
}
if (!isset($_SESSION["_LANGUAGE"])) {
setSessionLanguageToDefault();
}
if (file_exists(APP_DIR.'/language/'.$_SESSION["_LANGUAGE"].'.php')) {
include(APP_DIR.'/language/'.$_SESSION["_LANGUAGE"].'.php');
} else {
include(APP_DIR.'/language/'.DEFAULT_LANG.'.php');
}
?>
Ce n'est pas encore fait, mais bon, cela pourrait aider beaucoup.
Malheureusement, gettext ne fonctionne pas bien et a des problèmes dans diverses situations, comme sur différents systèmes d’exploitation (Windows ou Linux), et le faire fonctionner est très difficile.
En outre, vous devez définir un grand nombre de variables d'environnement et de domaines, ce qui n'a aucun sens.
Si un développeur souhaite simplement obtenir la traduction d'un texte, il ne doit définir que le chemin du fichier .mo et obtenir la traduction avec une fonction telle que translate ("hello", "en_EN"); Avec gettext ce n'est pas possible.
Comme les autres réponses ne répondent pas vraiment à toutes les questions, je vais y répondre dans ma réponse et proposer une alternative raisonnable.
1) I18n est l'abréviation d'Internationalisation et présente certaines similitudes avec I-dix-huit-n.
2) À mon avis, gettext est une perte de temps.
3) Votre approche est bonne. Ce que vous devriez rechercher sont les variables de langue. Le WoltLab Community Framework 2.0 implémente un système linguistique bidirectionnel. Pour une fois, certaines variables de langue sont enregistrées dans la base de données. À l’intérieur d’un modèle, on utilise uniquement le nom de la variable, qui sera ensuite remplacé par le contenu de la variable dans la langue actuelle (le cas échéant). La deuxième partie du système fournit un moyen d’enregistrer le contenu généré par l’utilisateur dans plusieurs langues (saisie dans plusieurs langues requise).
En gros, vous avez le texte d'interface défini par le développeur et le contenu défini par l'utilisateur. Le texte multilingue du contenu est enregistré dans les variables de langue et le nom de la variable de langue est ensuite utilisé comme valeur pour le champ de texte dans la table de contenu spécifique (le contenu multilingue étant également possible).
Malheureusement, la structure de la WCF rend très difficile la réutilisation de code en dehors du cadre, mais vous pouvez vous en inspirer. La portée du système dépend uniquement de ce que vous voulez réaliser avec votre site. Si cela va être grand que vous devriez certainement jeter un oeil sur le système de la WCF. S'il est petit, quelques fichiers de langue dédiés (de.php, en.php, etc.), contenant le fichier correct pour la langue actuelle, feront l'affaire.
Tu peux le faire:
class T {
const language = "English";
const home = "Home";
const blog = "Blog";
const forum = "Forum";
const contact = "Support";
}
Vous auriez un fichier comme celui-ci pour chaque langue. Pour utiliser le texte:
There is no place like <?=T::home?>.
L'inconvénient est que si vous ajoutez une nouvelle constante, vous devez le faire pour chaque fichier de langue . Si vous en oubliez un, votre page se brise pour cette langue. C'est un peu vilain, mais c'est efficace car il n'a pas besoin de créer un grand tableau associatif et les valeurs peuvent même être en ligne.
Peut-être que l'accès pourrait être amélioré, par exemple:
class T {
const home = "home";
public static function _ ($name) {
$value = @constant("self::$name");
return $value ? $value : $name;
}
// Or maybe through an instance:
public function __get ($name) {
$value = @constant("self::$name");
return $value ? $value : $name;
}
}
echo "There is no " . T::_("place") . " like " . T::_("home");
$T = new T();
echo "There is no " . $T->place . " like " . $T->home;
Nous évitons toujours le tableau et nous nous appuyons sur constant pour effectuer la recherche, ce qui, je suppose, est plus onéreux que l’utilisation directe des constantes. Le côté supérieur est la recherche peut utiliser un repli lorsque la clé n'est pas trouvée.