Je me débat avec cette question depuis plusieurs mois maintenant, mais je n'ai pas été dans une situation où j'avais besoin d'explorer toutes les options possibles auparavant. En ce moment, j'ai l'impression qu'il est temps de connaître les possibilités et de créer ma propre préférence personnelle à utiliser dans mes projets à venir.
Laissez-moi d'abord esquisser la situation que je recherche
Je suis sur le point de mettre à niveau / redévelopper un système de gestion de contenu que j'utilise depuis un certain temps maintenant. Cependant, je pense que le multilinguisme est une grande amélioration de ce système. Avant, je n'utilisais aucun framework mais je vais utiliser Laraval4 pour le projet à venir. Laravel semble le meilleur choix d'une manière plus propre de coder PHP. Sidenote: Laraval4 should be no factor in your answer
. Je recherche des moyens de traduction généraux indépendants de la plateforme / du framework.
Que faut-il traduire
Comme le système que je recherche doit être aussi convivial que possible, la méthode de gestion de la traduction doit se trouver à l'intérieur du CMS. Il ne devrait pas être nécessaire de démarrer une connexion FTP pour modifier les fichiers de traduction ou tout autre modèle analysé html / php.
De plus, je recherche le moyen le plus simple de traduire plusieurs tables de base de données, peut-être sans avoir besoin de créer des tables supplémentaires.
Qu'est-ce que je suis venu avec moi-même
Comme j'ai déjà cherché, lu et essayé des choses moi-même. J'ai plusieurs options. Mais je n'ai toujours pas l'impression d'avoir atteint une méthode des meilleures pratiques pour ce que je recherche vraiment. Pour le moment, c'est ce que j'ai proposé, mais cette méthode a aussi des effets secondaires.
- Modèles PHP analysés : le système de modèles doit être analysé par PHP. De cette façon, je suis capable d'insérer les paramètres traduits dans le HTML sans avoir à ouvrir les modèles et à les modifier. En plus de cela, les modèles PHP analysés me donnent la possibilité d'avoir 1 modèle pour le site Web complet au lieu d'avoir un sous-dossier pour chaque langue (ce que j'avais auparavant). La méthode pour atteindre cette cible peut être Smarty, TemplatePower, Laravel's Blade ou tout autre analyseur de modèle. Comme je l'ai dit, cela devrait être indépendant de la solution écrite.
- Database Driven : peut-être que je n'ai pas besoin de le mentionner à nouveau. Mais la solution doit être basée sur une base de données. Le CMS est destiné à être orienté objet et MVC, je devrais donc penser à une structure de données logique pour les chaînes. Comme mes modèles seraient structurés: templates / contrôleur / view.php peut - être cette structure serait le plus logique:
Controller.View.parameter
. La table de base de données aurait ces champs un long avec unvalue
champ. Dans les modèles, nous pourrions utiliser une méthode de tri commeecho __('Controller.View.welcome', array('name', 'Joshua'))
et le paramètre contientWelcome, :name
. Ainsi le résultat étantWelcome, Joshua
. Cela semble être un bon moyen de le faire, car les paramètres tels que: nom sont faciles à comprendre par l'éditeur. - Faible charge de la base de données: Bien sûr, le système ci-dessus entraînerait des charges de base de données si ces chaînes sont chargées en déplacement. Par conséquent, j'aurais besoin d'un système de mise en cache qui restitue les fichiers de langue dès qu'ils sont modifiés / enregistrés dans l'environnement d'administration. Étant donné que les fichiers sont générés, une bonne disposition du système de fichiers est également nécessaire. Je suppose que nous pouvons utiliser
languages/en_EN/Controller/View.php
ou .ini, ce qui vous convient le mieux. Peut-être qu'un .ini est même analysé plus rapidement à la fin. Ce fichier doit contenir les données du fichierformat parameter=value;
. Je suppose que c'est la meilleure façon de le faire, car chaque vue rendue peut inclure son propre fichier de langue s'il existe. Les paramètres de langage doivent alors être chargés dans une vue spécifique et non dans une portée globale pour éviter que les paramètres ne s'écrasent les uns les autres. - Traduction de la table de base de données : c'est en fait ce qui m'inquiète le plus. Je cherche un moyen de créer des traductions de News / Pages / etc. aussi vite que possible. Avoir deux tables pour chaque module (par exemple
News
etNews_translations
) est une option, mais cela demande beaucoup de travail pour obtenir un bon système. L'une des choses que j'ai proposées est basée sur undata versioning
système que j'ai écrit: il y a un nom de table de base de donnéesTranslations
, cette table a une combinaison unique delanguage
,tablename
etprimarykey
. Par exemple: en_En / News / 1 (Se référant à la version anglaise de l'actualité avec ID = 1). Mais il y a 2 énormes inconvénients à cette méthode: tout d'abord, cette table a tendance à devenir assez longue avec beaucoup de données dans la base de données et deuxièmement, ce serait un sacré travail d'utiliser cette configuration pour rechercher la table. Par exemple, la recherche du slug SEO de l'élément serait une recherche en texte intégral, ce qui est assez stupide. Mais d'un autre côté: c'est un moyen rapide de créer très rapidement du contenu traduisible dans chaque table, mais je ne pense pas que ce pro surpasse les inconvénients. - Travail frontal: Le front-end nécessiterait également une réflexion. Bien sûr, nous stockerions les langues disponibles dans une base de données et (dés) activerions celles dont nous avons besoin. De cette façon, le script peut générer une liste déroulante pour sélectionner une langue et le back-end peut décider automatiquement quelles traductions peuvent être effectuées à l'aide du CMS. La langue choisie (par exemple en_EN) serait alors utilisée lors de l'obtention du fichier de langue pour une vue ou pour obtenir la bonne traduction pour un élément de contenu sur le site Web.
Alors, les voilà. Mes idées jusqu'à présent. Ils n'incluent même pas encore d'options de localisation pour les dates, etc., mais comme mon serveur prend en charge PHP5.3.2 +, la meilleure option est d'utiliser l'extension intl comme expliqué ici: http://devzone.zend.com/1500/internationalization-in -php-53 / - mais cela serait utile dans tout stade de développement ultérieur. Pour l'instant, le principal problème est de savoir comment disposer des meilleures pratiques de traduction du contenu d'un site Web.
Outre tout ce que j'ai expliqué ici, j'ai encore une autre chose que je n'ai pas encore décidé, cela ressemble à une question simple, mais en fait cela me donne des maux de tête:
Traduction d'URL? Devrions-nous faire cela ou pas? et de quelle manière?
Donc .. si j'ai cette url: http://www.domain.com/about-us
et l'anglais est ma langue par défaut. Cette URL doit-elle être traduite http://www.domain.com/over-ons
lorsque je choisis le néerlandais comme langue? Ou devrions-nous emprunter la voie facile et simplement changer le contenu de la page visible sur /about
. La dernière chose ne semble pas être une option valable car cela générerait plusieurs versions de la même URL, cette indexation du contenu échouera dans le bon sens.
Une autre option consiste à utiliser à la http://www.domain.com/nl/about-us
place. Cela génère au moins une URL unique pour chaque contenu. De plus, il serait plus facile d'aller dans une autre langue, par exemple, http://www.domain.com/en/about-us
et l'URL fournie est plus facile à comprendre pour les visiteurs Google et humains. En utilisant cette option, que faisons-nous avec les langues par défaut? La langue par défaut doit-elle supprimer la langue sélectionnée par défaut? Donc, rediriger http://www.domain.com/en/about-us
vers http://www.domain.com/about-us
... A mes yeux, c'est la meilleure solution, car lorsque le CMS est configuré pour une seule langue, il n'est pas nécessaire d'avoir cette identification de langue dans l'URL.
Et une troisième option est une combinaison des deux options: en utilisant le "language-identification-less" -URL ( http://www.domain.com/about-us
) pour la langue principale. Et utilisez une URL avec un slug SEO traduit pour les sous-langues: http://www.domain.com/nl/over-ons
&http://www.domain.com/de/uber-uns
J'espère que ma question vous fera craquer, ils ont craqué la mienne à coup sûr! Cela m'a aidé déjà à régler les choses comme une question ici. M'a donné la possibilité de revoir les méthodes que j'ai utilisées auparavant et l'idée que j'ai pour mon prochain CMS.
Je voudrais déjà vous remercier d'avoir pris le temps de lire ce tas de texte!
// Edit #1
:
J'ai oublié de mentionner: la fonction __ () est un alias pour traduire une chaîne donnée. Dans cette méthode, il devrait évidemment y avoir une sorte de méthode de secours où le texte par défaut est chargé lorsqu'il n'y a pas encore de traductions disponibles. Si la traduction est manquante, elle doit être insérée ou le fichier de traduction doit être régénéré.