[PHP] Comment gérer les langues dans un jeu multijoueur ?

[Zamentur]

Je ne suis pas du même avis. Ce n'est pas parce qu'on a pas le besoin de faire un site multilangue qu'il ne faut pas avoir un système de gestion des textes. Or la frontière est très mince entre une application multilangue et une application bien construite qui a pensé à rassembler tous ses textes dans un dossier...

Parmi les gens qui ont créé un jeu je ne pense pas être le seul à avoir fait l'erreur de débutant de mettre mes textes dans mon application. Si on m'avait donné une classe comme celle que je viens de fournir, je n'aurai pas fait cette erreur, et j'aurai été en mesure de corrigé les fautes d'orthographe et de remanier la syntaxe de mes phrases.

Alors si en plus de çà on à la possibilité d'une traduction facilement faisable par ses joueurs... Pourquoi s'en priver!
Évidement, un jeu multilingue demande un administrateur pour chaque langue et je pense que c'est là la vrai limite.

Mais vu qu'une fois mis en place un tel système ne demande strictement rien, pourquoi s'en priver?

[keke]

Zamenture,

Je trouve ta manière de procédé intéressante. Cependant, comment fais-tu pour les éléments de traduction en base de données ?

Code :

$text->message_coup_avec_arme("épée");

Je réfléchis à passer Magdales en anglais. Mon idée principale est de définir dans toutes mes tables, un identifiant pour chaque champs textes. Ainsi, sur ma table objet, comme il y'a un simple nom d'objet, il y aura un identifiant unique par catégorie d'objet.

Ensuite, définir une table traduction avec, en clé primaire, l'identifiant de la traduction, puis, une colonne par langue répertoriée.

Je me heurte cependant à pas mal de problèmes théoriques : conjugaison, genre, nombre, ...

As-tu mis en place ta solution et trouvé des moyens pour éviter des problèmes assez classique ? As-tu un retour d'expérience de projet qui sont passés d'un système mono-linguistique à un autre système ?

kéké

[Zamentur]

#Texte en base de donnée

Cependant, comment fais-tu pour les éléments de traduction en base de données ?

Ah là base je faisais comme ce que tu décris ci dessous avec des autojointures grâce à la propriété $text->lang.
En fait il faut une table pour les varchars, une autre pour les blob.

Je réfléchis à passer Magdales en anglais. Mon idée principale est de définir dans toutes mes tables, un identifiant pour chaque champs textes. Ainsi, sur ma table objet, comme il y'a un simple nom d'objet, il y aura un identifiant unique par catégorie d'objet.

Ensuite, définir une table traduction avec, en clé primaire, l'identifiant de la traduction, puis, une colonne par langue répertoriée.

Il est d'ailleurs possible de rajouter dans la classe précédente quelques choses pour aller chercher un texte en bdd. Mais je vois pas pourquoi il serait en bdd si c'est pour qu'on l'appel directement via sa clé. (le système de fichier présenté auparavant suffit pour çà)
NB: je suis peut être pas clair sur cette dernière phrase.

#La vrai internationalisation

Je me heurte cependant à pas mal de problèmes théoriques : conjugaison, genre, nombre, ...

Là on attaque la meilleur partie de la gestion de texte
J'en avais parlé en décembre sur le forum d'ailleurs.

Donc depuis j'ai un ensemble de classe presque finalisé qui permet de gérer complètement tout ces problèmes. En fait j'en suis arrivé non plus à une gestion des textes mais à une gestion des sens.
Le principe général de la classe reste le même, sauf que les paramètres de phrase ne sont plus des bout de texte exemple:

Code PHP :

<?php 

$text->message_coup_avec_arme("épée"); 

[keke]

Attention, le mieux est l'opposé du bien.

Ne fais pas un système trop complexe, sous prétexte de mieux faire. GetText me semble suffisamment complet pour chercher à vraiment améliorer les choses ...

Mais je vois pas pourquoi il serait en bdd si c'est pour qu'on l'appel directement via sa clé. (le système de fichier présenté auparavant suffit pour çà)

Là, je pense pouvoir opposer une forte argumentation, mais j'ai beaucoup de mal à la coucher par écris. Désolé ... je ne trouve qu'un exemple simple à expliquer, alors que y'a un gros truc à dire ... mais j'y arrive pas :-)
Peut-être que si tu nous donnais un exemple un peu plus poussé ... j'arriverais à te dire ce qui me chagrine. Sinon, c'est pas le plus important de la discussion.

--> (tout petit exemple facile Pour les homonymes. La langue française, aussi belle soit-t-elle, dispose de nombreux homonymes ... d'autant plus important quand on utilise des langues comme l'anglais qui dispose de 3 fois moins de mots. (hô je suis mauvaise langue : http://www.academie-francaise.fr/langue/....html#mots )

Kéké
PS : Selon les langues, la notion de pluriel n'est pas la même.
PS : En français, le masculin et le féminin sont les seuls genres. en anglais il existe la troisième notion de "chose" : It. Je crois qu'il existe d'autres genres dans d'autres langues ...

[Zamentur]

Gettext n'est clairement pas assez puissant, sans compter que c'est une extension qu'on ne trouve pas chez tout les hébergeurs.

Pour le fait que ce soit complexe, çà semble comme çà assez complexe, mais c'est l'intérieur de la boite qui est complexe, pas l'extérieur.
D'ailleurs pour une utilisation normal (simple demande de texte) mon package ne consomme rien de plus que la classe au dessus en termes de ressource.

PS : Selon les langues, la notion de pluriel n'est pas la même.
PS : En français, le masculin et le féminin sont les seuls genres. en anglais il existe la troisième notion de "chose" : It. Je crois qu'il existe d'autres genres dans d'autres langues ...

J'y ai pensé (on en avait d'ailleurs discuté en décembre), en fait chaque langue est représenté par une classe regroupant toutes les méthodes pour faire les accords. Les objets peuvent quand à eux contenir n'importe quel propriété (comme le genre) par contre le nombre est commun à toutes les langues, peut être d'ailleurs est ce une faiblesse mais j'ai inclus les notions de dénombrable/indénombrable et de nombre connu.

Ainsi le champs number contient un nombre positif précis si le nombre d'objet est connu (et donc dénombrable), 0 si il n'y en a pas, -1 si c'est indénombrable (du pain), -2 si c'est un dénombrable dont le nombre est inconnus avec eventuellement un indicateur subjectif -2 quelques un, -3 beaucoup, -4 énormément mais je ne l'ai pas encore définis car je ne m'en sert pas pour le moment:
pour l'instant un sens retournera "il y avait des chasseurs"
plutôt que
"il y avait beaucoup de chasseurs"

Ça peut être intéressant, mais il ne faut pas que çà rentre en collision avec le cas ou mon application sais combien il y en a 20 par exemple et qu'elle décide de dire beaucoup à la place de 20 donc -3 dans le champs number.

Je ne pense pas qu'il y ai d'autre différence possible(à travers toutes les langues) à faire sur ce seul critère, critère qui d'ailleurs n'appartient pas au mots lui même à l'inverse des critère comme le genre ou l'élision(d'où le fait qu'il soit traité différemment).

Enfin bref je pense de toute manière faire un site de présentation dédié à ce trucs. Je pense aussi l'implémenter en d'autres langages le tout surement distribuer sous une licence libre. Parce que sans exemple, çà doit effectivement être dur de s'imaginer tout çà.

[cipic]

merci pour toutes ces contributions intéressantes ! malheureusement je risque de ne pas pouvoir me pencher dessus avant ce week-end, mais c'est exactement le type de problèmes que je voulais envisager avant d'être trop avancé dans la conception de mon code. ce serait bête de devoir tout recommencer.

la gestion par sens est un point qui me semble très intéressant. je reviendrai bientôt !

[keke]

Ha ! cool Cipic ^^.

Zamenture -> Je ne cherche pas à te décourager, mais j'ai peur du système à mettre en place vu de l'utilisateur :
Y'a des langues dans lequel les chiffres s'arrêtent au delà d'un certains nombre. Je pense au système romain qui dépasse pas les 5000, mais je suis persuadé que dans les langues vivantes, ça existe aussi ^^.

http://fr.wikipedia.org/wiki/Num%C3%A9ration_romaine

Ce système, qui simplifiait les anciennes numérations grecques et phéniciennes, permet d’écrire tous les nombres de 1 à 4999, en utilisant les lettres de l’alphabet latin les plus ressemblantes aux anciens systèmes unaires

Y'a eu quelques systèmes experts qui ont tenté de faire ce que tu cherchais ... Un listing ici :
http://www.yrelay.com/article244.html

J'ai du mal à concevoir le biniou final. C'est assurément passionnant à réaliser, mais pour quelle finalité ?
Le Français n'est pas le langage modèle sur lequel il faudrait structurer ta conception. Y'a tellement de variantes. L'espagnole par exemple, élude systématiquement le sujet des phrases. La base du phrase n'est donc plus SUJET VERBE COMPLEMENT, mais uniquement VERBE COMPLEMENT : ex : "gusto la informatica".

Il me semble que les langues asiatiques n'emploient pas de conjugaison dans les verbes .... "hier je aller au cinéma."

Les allemands peuvent concaténer les compléments et les adjectifs directement aux verbes. La notion chez eux du mot le plus long n'a aucun sens.

Il s'agit de reprendre une structure dans la quelle, le sujet et le complément peuvent être omis, le temps peut être omis, les quantités peuvent être omis, l'ordre d'affichage peut être omis ...

Donc, si tu pars sur une ré-écriture des phrases à partir des sens ... et réciproquement. Tu as intérêts à voir ce qui a déjà été réalisé, et recopier des pans entiers de travaux fait par des linguistes de chaque langues ^^.

Voilou mon ressenti sur cette affaire ^^.

kéké

[Zamentur]

Je crois que j'ai pas vraiment su te faire comprendre ma démarche...

Déjà à la base j'ai développé ce système pour la langue française (et eventuellement anglaise). Les intérêt qu'il y a sont ceux que j'ai cité précédemment au niveau des fonctionnalités, qui dépassent de loin les fonctions de base d'une gestion de textes classiques.

L'idée n'est pas d'analyser du texte (c'est pas du tout ce que je fais d'ailleurs), en fait chaque phrase "dynamique" à un format définis par la classe d'accord qui va éventuellement la traiter.

Ainsi le format varie selon la langue, prenant donc en compte n'importe quel spécificité de cette dernière. Le traitement est aussi particulier à chaque langue puisque j'ai une classe "accord" par langue.
Donc une langue qui n'a pas de conjugaison n'est pas un problème (je dirais même que c'est plutôt plus simple. Les langues peuvent mettre le sujet après le complément ou pas du tout en mettre peu importe en fait c'est définis dans le format.
Pour l'histoire des chiffres s'arrêtant à 5000 dans ce cas si on veux dire plus que ce nombre là çà dépend encore de l'usage que font les gens peut être remplaceront il par énormément, ou alors diront-il 2 fois 5000...

Bref le système actuel pourrait très bien s'y adapter! Parce que la plus part des choses sont géré par le format (en fait tout ce qui est possible).

Et il n'y a effectivement aucun intérêt à essayer d'analyser un texte. L'analyse est déjà faite dans mon cas. Elle est faite par le format. Alors certes le format peut devenir complexe pour certaine phrase, d'où l'idée d'une IHM ou on pourrait avec des jeu de sélection et de bouton (comme un wisiwyg en fait) indiquer les liens nécessaire à la bonne construction de la phrase
Si le format est mal fait la phrase sera accordé bizarrement.

J'ai du mal à concevoir le biniou final. C'est assurément passionnant à réaliser, mais pour quelle finalité ?

J'en ai parlé tout du long:
Le but c'est d'avoir des textes qui s'adaptent vraiment aux inconnu qu'on y met. Ainsi on ne biaisera pas avec des trucs du style (s) ou des mauvaises tournures de phrase pour éviter la conjugaison d'un verbe.
L'autre solution c'est de faire un trucs du style if ($number>1) $text.="s";

Sauf que c'est super crade.

Actuellement, sans ce que je présente on a le choix entre:
- des tournure de phrase arrangé voir limite cas du (s) ou encore "Le bâtiment: %s vient d'être construit"
- des phrase pour chaque cas, mais dans ce cas l'internationalisation et le code en prenne un coup
- du code du style if ($number>1) $text.="s"; qui alors là est une honte

Donc on ne peux pas dire qu'il n'y a pas de finalité!

Sans compter, que comme je l'ai montré, une fois le système construit, on peut gérer des choses plus fines comme les notions de distances. Exemple:
un PNJ pourrait dire :
Si tu passes dans la cité de Bould, emmène-moi! Là bas, je pourrai te montrer des trésors que tu n'imagines même pas en rêve!
Ou
Si vous passez dans la citez de Bould, emmenez-moi! Là bas, je pourrai vous montrer des trésors que vous n'imaginez même pas en rêve!
Selon qu'il connait déjà le personnage, il est même envisageable de faire passer des sous entendu.

J'ai aussi parlé tout à l'heure des notions de quantité subjective, qui peuvent être assez intéressants à utiliser:
Plutôt que de dire "j'ai perdu 64 PV sur 100.", on peux dire "j'ai perdu beaucoup de force vitale" c'est déjà un peu mieux.

Et puis sinon j'ai déjà expliquer mon projet de position dans le temps, qui pourrait être utile pour des historiques ou des prophéties... Ou même des questions d'univers parallèle (j'ai déjà fait çà une fois dans Ragol).
Mais c'est certainement le point le plus complexe je pense, et pour l'instant je ne pourrais y arriver que dans des cas de phrase simple.

J'ai aussi parlé de mon système d'émetteur/récepteur il n'ya pas que des cas de jeu ou çà peu servir, mais par exemple le gestionnaire d'erreur qui parle à l'application...

Bref des utilités j'en vois plein, on peu penser que c'est du détail, mais un bon nombre de jeu son quasi que du texte et des images, alors autant avoir des textes de qualité qui ne ressemble pas au rébarbatif rapport de combat qui vous énerve au bout d'un an de jeu!

Voilà pour toutes les finalité que je prévois

[Ter Rowan]

je trouve très intéressant ce que tu racontes Zamentur

cependant j'ai une question concernant la performance (temps pour afficher une page, etc...) d'un jeu suivant de tels développements

Est ce que, par un tel système bien sophistiqué, tu ne perds pas trop de temps ?

En effet, non seulement je trouve vachement intéressant l'idée mais ça me fait penser, en terme de complexité, à des modules "riches" que j'essaie de développer (modules qui n'ont rien à voir avec le sujet, tels les combats mais qui sont sur la même démarche, même si codés probablement plus crades ^^, enfin j'en suis qu'au début) Et je me demande si je ne me casse pas la tête pour rien (genre c'est bien gentil le biniou, mais faut un serveur de dans 15ans pour que ca tourne avec deux connections simultanées)

sinon même si ce n'est pas très malin comme technique, pourquoi penses tu que le 'if >1 ==>s' est si catastrophique que cela ?

- du code du style if ($number>1) $text.="s"; qui alors là est une honte

[Zamentur]

Les performances dépendent en fait de la complexité de la phrase. Effectivement plus une phrase est complexe plus elle est susceptible de prendre du temps.

Ainsi les simples phrases prennent exactement le même temps que les systèmes normaux.
Pour les phrases plus complexe avec des accords, ou prenant en compte des spécificité de langage çà fait appel à la classe accord. En gros elles font un petit détour pour être transformer puis son renvoyer sur le chemin des phrases normal.

Et c'est pas si long que çà, pour l'instant ma gestion accord/conjugaison/article prend seulement 300 lignes Et çà gère toutes les exceptions.

En fait le plus long est surement l'accès au fichier de langue lui même, mais faudrait que je vérifie.

if ($number>1) $text.="s"; c'est catastrophique car on mélange du texte et du code. La clairement les textes sont dépendant du code ils ne peuvent pas être remanié.
Et surtout on a pas à mettre ce genre de trucs dans un algo qui fait une action, çà empêche une bonne lisibilité!
En d'autre termes, si j'ai l'action attaquer() il est impensable de mettre dans son code des trucs complètement à l'ouest comme un test pour mettre un s. Sinon on obtient un trucs qui sera illisible.