Avec chris, pour notre méga soft de la mort, on avait fait un truc de fou furieux dont on était très fiers En gros, on foutait tous les messages dans divers fichiers avec le nom de la langue (genre messages_en.txt, messages_de.txt, etc...), on parsait le tout en Java pour convertir tout ça dans le bon charset et ça créait un fichier .cpp avec tout dans des namespaces de la mort (ainsi que les bons fichiers de setup pour NSIS). Le fichier .cpp était ensuite inclus dans le reste du projet

Sondage serieux:
 
Comment vous gérez l'internationalisation dans vos applis ? vous utilisez des "ressources" ? des base de données ? des fichiers plats ? des fichiers xml ? vous appelez babelfish en ajax via webservice ?
 
Je dois faire une étude pour refondre l'internationalisation de notre appli et je voualis savoir si vous faisiez des trucs "by the book" ou si vous avez des solutions custom.

Regroupons nos bookmarks pr0n.

C'est géré en natif dans windev

super Trac... j'installe Python 2.5 puis Trac et rien... pas un raccourci, pas une icone, rien. Super
 
on y accede comment a cette merde, et comment on configure la connexion string pour lui dire d'aller se coller dans SQL Serveur ?

Sondage serieux:
 
Comment vous gérez l'internationalisation dans vos applis ? vous utilisez des "ressources" ? des base de données ? des fichiers plats ? des fichiers xml ? vous appelez babelfish en ajax via webservice ?
 
Je dois faire une étude pour refondre l'internationalisation de notre appli et je voualis savoir si vous faisiez des trucs "by the book" ou si vous avez des solutions custom.

Merci pour ces liens. La modération a été prévenue.

Merci pour ces liens. La modération a été prévenue.

super Trac... j'installe Python 2.5 puis Trac et rien... pas un raccourci, pas une icone, rien. Super
 
on y accede comment a cette merde, et comment on configure la connexion string pour lui dire d'aller se coller dans SQL Serveur ?

ok, c'est de la merde -> poubelle

ok, c'est de la merde -> poubelle

ce comportement me rapelle quelque chose

ce comportement me rapelle quelque chose

Tes parents

Tes parents

euh non mais j'ai IIS et SQL Server, et ce truc fonctionne avec Apache et mySql. Loul.

http://membres.lycos.fr/kadreg/
 
la vache back il y a longtemps

Y'a 4 ans quand je faisais du .net j'avais plein de liens, j'était à fond dedans... Maintenant je m'en rappelle moins

Merci pour ces liens. La modération a été prévenue.

euh non mais j'ai IIS et SQL Server, et ce truc fonctionne avec Apache et mySql. Loul.

 
Dans l'échelle de l'évolution, tu te situes dans les barreaux du bas.
 
3 - You fail at understanding readmes.
2 - You fail at reading readmes. (ici)
1 - You fail at not messing up your pants.
0 - You fail.

vous connaissez quoi comme outil de bugtrack gratos qui pourrait s'installer en stand alone sur la machine d'un dev ? (genre avec IIS+sql server express de préférence)

you fail at reading thread.

Que ça vous serve de leçon, punaises.

Que ça vous serve de leçon, punaises.

 
T'as dit "de préférence".
Si tu saisis pas la différence entre "doit" et "devrait", t'es mal barré pour lire des specs

Fais du python, bordel de mairde !

nous on avait utilisé des .properties standard de java et des messageBundle.

ben dans le .properties, je viens de le dire

J'suis en train, de voir si c'est faisable avec mod_jk  

Avec chris, pour notre méga soft de la mort, on avait fait un truc de fou furieux dont on était très fiers En gros, on foutait tous les messages dans divers fichiers avec le nom de la langue (genre messages_en.txt, messages_de.txt, etc...), on parsait le tout en Java pour convertir tout ça dans le bon charset et ça créait un fichier .cpp avec tout dans des namespaces de la mort (ainsi que les bons fichiers de setup pour NSIS). Le fichier .cpp était ensuite inclus dans le reste du projet
On voulait pas de fichier des traducs qui se baladaient partout sur le disque, on avait de toute façon besoin de convertir des caractères pour le setup et c'est chris qui est venu avec cette soluce (la partie Java vient de moi, historiquement j'avais fait un p'tit soft à la con pour passer un texte d'un charset à l'autre ).
 
Bref, l'éclate

On utilise i18n (avec ruby) pour tout ce qui est statique (formulaires, titres statiques,...), et des table + table_trsls pour les contenus dynamique.

Contre-sondage dans la même veine :
- Comment sont gérés les pluriels avec vos solutions respectives ?
- Vous tappez quoi dans le code ? (des identifiants pour chaque chaine traduite ou du texte dans une langue "de référence" qui sert d'identifiant)
- Vous suivez la langue du système (ou langue de l'accompte pour les systèmes multi-utilisateurs pouvant être avoir une locale différente par accompte) automatiquement ou vous demandez à l'utilisateur lors du setup ?

Globalite pour Rails, qui utilise des fichiers yaml pour les trads. J'utilisait au début Globalize, qui stocke tout en DB, mais le nombre de requete ( une requete par string traduite en gros ) a vite fini par me faire peur ( même si avec le cache y avait moyen d'optimiser tout ça ).

pour un site que j'avais developpé pour renault , j'avais utilisé la solution suivante :
 
chaque phrase etait remplacé, dans le code par un appel à la fonction traduire(CODEPHRASE,LANGUECIBLE)
 
la fonction traduire recuperait les données depuis la BDD avec un petit cache en session pour accelererla recup  
 
par contre, le debuggae etait super chiant à lire , et il y avait des problème de césure, si par exempl on souhaite mettre une partie d'une phrase en gras.  Sans compter que la mise en page etait un peu lourde du fait de langues trop longues ( neerlandais ) ou trop courtes ( anglais )  
 
Le choix de la BDD s'est imposé pour permette une interface de traduction directement a dispo des traducteurs ( système qui n'a d'ailleurs jamais été utilisé )

On a plusieurs méthodes, chacune vise un rôle bien précis dans l'appli
 
1/ Pour traduire l'interface à la volée, on a un addin qui pilote un OCX glissé sur les interfaces et ajoute un bout de code. Grosso modo, on change de langue avec l'addin, on change les textes dans les properties voulues de l'interface, et ça roule. Tout est stocké dans un fichier texte portant le même nom que le fichier contenant l'interface. Ce bordel est pas super au point mais on a assez d'expérience pour contourner les bugs (c'est fourni par le client)
 
2/ Les messages d'erreur, avertissements, notifications, sont stockés dans une table, une ligne par message, un champ par langue.
 
3/ Pour les combo/listboxes, c'est en fait des contrôles spéciaux qui associent un code à chaque libellé, ça se traduit à la volée également et la source est un jeu de tables dans une DB indépendante de celle de l'appli. Les combos gèrent un tas de choses comme le masquage/affichage de certains libellés, un range de libellés, et même la taille car on peut spécifier une taille de libellés (faut que tout ça soit pré-encodé évidemment). C'est aussi fourni par le client mais ça marche mieux que le brol décrit au point 1/

C'est géré en natif dans windev

Le seul projet internationalisé auquel j'avais participé c'était une plateforme de paiement en Perl FCGI et on avait fait ça avec gettext.

Si t'abandonne au premier problème, tu risques pas d'y arriver, en informatique

Que ça vous serve de leçon, punaises.

 
donc pour toi "de préférence" c'est direct le contraire ?

Je veux un langage qui compile en natif et qui ne fait pas comme s'il était le premier et le seul langage de prog de l'humanité
 
Mais j'aimerai surtout un Visual D en fait

Comment tu voudrais que je réponde à une question sur tomcat ? c'est un truc GNU pour faire du web et du java bordel !

http://www.izipik.com/images/20071 [...] elmott.gif