Zend FR

Bonjour,

A priori, je pense que c'est un faux problème : Si ces infos sont stockées en bases, elles viennent vraissemblablement d'une interface d'admin.
Si ton site est en plusieurs langues, il faut que ton interface d'admin permette de saisir ces informations en plusieurs langues. Ensuite lors de l'affichage, tu récupères la bonne version en base et tu l'affiches...

A priori, dans ton cas, j'aurais dans ma base une table ville qui contient les infos non localisées et une table villeDisplay qui contient les infos par langue (nom de la ville, description,...) et comme clé, ton ville_id et la langue.

A+, Philippe

Je procède exactement de cette manière (je n'ai pas dit que c'est la meilleure solution, je ne suis pas spécialiste en I18N). Je travaillais justement cette semaine sur une table avec des fuseaux horaires et une table pour les pays.

Voilà ce que ça donne au niveau des définitions des tables :

-- 
-- Table structure for table `countries`
-- 

DROP TABLE IF EXISTS `countries`;
CREATE TABLE IF NOT EXISTS `countries` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `alpha2` char(2) NOT NULL,
  `alpha3` char(3) NOT NULL,
  `numeric3` SMALLINT(6) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `alpha2` (`alpha2`),
  UNIQUE KEY `alpha3` (`alpha3`),
  UNIQUE KEY `numeric3` (`numeric3`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

-- 
-- Table structure for table `countries_localized`
-- 

DROP TABLE IF EXISTS `countries_localized`;
CREATE TABLE IF NOT EXISTS `countries_localized` (
  `id` int(11) unsigned NOT NULL,
  `language` enum('en','fr') NOT NULL,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`,`language`),
  CONSTRAINT `country_is_localized` FOREIGN KEY (`id`)
    REFERENCES `countries`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Et des enregistrements :

-- 
-- Dumping data for table `countries`
-- 

INSERT INTO `countries` VALUES (1, 'AF', 'AFG', 4);
INSERT INTO `countries` VALUES (2, 'AX', 'ALA', 248);
INSERT INTO `countries` VALUES (3, 'AL', 'ALB', 8);
...

-- --------------------------------------------------------

-- 
-- Dumping data for table `countries_localized`
-- 

INSERT INTO `countries_localized` VALUES (1, 'en', 'Afghanistan');
INSERT INTO `countries_localized` VALUES (1, 'fr', 'Afghanistan');
INSERT INTO `countries_localized` VALUES (2, 'en', 'Ã…land Islands');
INSERT INTO `countries_localized` VALUES (2, 'fr', 'Ã…land, ÃŽles');
INSERT INTO `countries_localized` VALUES (3, 'en', 'Albania');
INSERT INTO `countries_localized` VALUES (3, 'fr', 'Albanie');
...

Comme l'a dit Philippe, j'ai une table qui contient toutes les informations sur les pays (dans mon cas les différents codes ISO 3166-1) et une autre table qui contient seulement les traductions. Après, l'affichage se fait très simplement en récupérant la locale de l'utilisateur avec Zend_Locale. La prochaine étape, c'est de cacher ces listes avec Zend_Cache afin de limiter les accès à la base de données (ce sont des requêtes très gourmandes vu le nombre d'enregistrements renvoyés à chaque fois).

Mais j'aimerais bien avoir d'autres retours de la part de la communauté...

Dernière modification par stephane (19-04-2007 14:59:23)

Tu peux en dire plus philippe ca m'interesse car j'ai fait comme stéphane. Et le seul truc que je vois dans locale c'est des fichiers xml mais ils comportent juste te language et territory.

Edit : a non c bon j'ai trouvé le xml dont tu parle y a plus qu' atrouver comment zend local l'attaque ^^ merci pour le tuyau.

Edit 2 : en fait c'est dans la doc http://framework.zend.com/manual/en/zen … tions.html je suis passé un peu vite dessus apparement

Edit 3 : dommage z'on pas integré les plages d'IP associé au pays ca m'aurais bien arrangé

Dernière modification par Isilgawen (19-04-2007 17:44:16)

C'est un point qui m'avait échappé aussi ! Si j'avais su, je n'aurais pas perdu autant de temps à implémenter ma propre solution. Malgré tout, je n'ai pas fait ça pour rien, puisque cela me permet de renforcer l'intégrité de ma base de données en m'assurant qu'un pays qui a été fournit en entrée est valide.

Par ailleurs, la liste retournée par Zend_Locale n'est pas à jour. En effet, cette classe référence 256 pays alors qu'il n'en existe officiellement que 244 (par exemple la Serbie et le Monténégro ont maintenant chacun leur propre dénomination).

Le dernier avantage, c'est de pouvoir maîtriser la traduction elle-même. Zend_Locale contient d'ailleurs des noms qui ne correspondent pas à la nomenclature ISO. Et il y a 256 traductions (et donc pays) en anglais contre 240 en français. Mais il est également possible de changer certains noms pour qu'ils puissent rentrer dans une boite de sélection, comme par exemple 'Géorgie Du Sud Et Les Îles Sandwich Du Sud' (je suis sûr que vous ne connaissiez pas celui-là ).

Mais si ces trois points ne sont pas pertinents dans votre cas (ce qui est tout à fait compréhensible, surtout si vous n'avez pas de temps à perdre), alors Zend_Locale fait parfaitement l'affaire !

Je n'ai pas encore travaillé sur les langages (je vais le faire aujourd'hui), mais ils doivent suivre les mêmes principes.

En ce qui concerne les fuseaux horaires, il faut également savoir que la liste n'est pas à jour :

$locale = new Zend_Locale();
$list = $locale->getTranslationList('timezone');

J'ai droit à 20 fuseaux en anglais (dont les trois quarts sont vides) alors qu'il en existe 551 au total (ou alors j'ai raté quelque chose) !

Au fait Isilgawen, je vais également travailler sur ce problème de localisation IP ces prochains jours. Je ne sais pas où tu en es, mais j'ai trouvé ce site qui pourrait t'aider.

Dernière modification par stephane (20-04-2007 09:15:02)

Hello,

Je fais remonter le post car je m'interroge sur le même sujet.

Il y a trois points qui me dérangent avec une traduction directement en base de données :

1) Au final les traducteurs auront plusieurs interfaces pour faire leur travail. Par exemple :
- PoEDIT pour traduire les .po  (j'utilise gettext)
- La partie backoffice du site pour traduire spécifiquement les données de la base de données.

2) Il y a un petit risque d'avoir des informations redondantes entre la base et les fichiers .po à traduire, ce qui se traduit par du travail de traduction à faire en double.

3) Au niveau code, la trad n'est pas gérée de la même façon entre les deux systèmes.


Pour palier à ces problèmes j'ai tenté une autre approche, mais elle est loin d'être parfaite :
J'ai fait un script qui exporte les données à traduire de mes tables au format .ini , puis PoEdit parse ce fichier (tout comme il parse le reste de mon projet) pour générer une liste de traductions à faire.
Au final, tout le boulot de traduction est fait avec PoEdit.
S'il y a des données redondantes, elles ne seront traduites qu'une fois.

Le problème c'est qu'il faut exécuter manuellement le script à chaque nouvelle entrée en base de donnée (En général ce sont des tables de nomenclature qui ne bougent pas beaucoup donc ça va).
En pratique ça se fait bien, mais j'ai l'impression que c'est pas idéal non plus.

Qu'en pensez vous ? Vous voyez d'autres alternatives pour avoir un système de traduction centralisé ?