Bonjour Jean-Christopha aka ProgFou et bienvenue sur Wikini, merci pour ta proposition de patches, tu peux même, si tu le désires, participer directement au DeveloppementDeWikini.
-- DavidDelon

Oui, c'est une bonne idée de participer directement au developpement de WikiNi, plus on est de fou plus on rit ;-)
-- GarfieldFr

• Plus on est de fous moins ya de riz ;-) Plus sérieusement, ya moyen de faire converger WackoWiki et wikini ? wacko = international dès le début, wikini = fonctionnalités compréhensibles et opérationnelles. Pour mémoire je ne serai qu'utilisateur et testeur mais motivé pour faire converger les choses (et je peux traduire en anglais ce qui le nécessite...) -- BenoitAudouard

• WackoWiki n'est apparement pas vraiment "international dès le début" puisqu'il est parti des sources de wakkawiki qui ne l'était pas au départ, n'est-ce pas ?! ;-) Quant à la convergence, je suis d'accord sur le fait qu'il y a apparement plusieurs bonnes "petites idées" à reprendre ! Mais je ne connais pas encore l'avis des développeur de WikiNi sur la question d'essayer de suivre les développements parallèles de WakkaWiki et WackoWiki ... Pour ma part je vais effectivement regarder un peu le code de ces deux là pour voir ce que je vais "piocher" dedans pour le miens, sachant que mon objectif est de dériver le moins possible de WikiNi, ou de le faire de manière à pouvoir rejoindre la branche principale à n'importe quel moment. Une autre solution serait que j'intègre ou fasse intégrer mes développements dans WikiNi. ;-) -- ProgFou
  • Oui, il y a de bonnes idées à prendre sur WackoWiki... mais WackoWiki souffre également de défauts que nous voulons éviter dans WikiNi : WackoWiki est devenu peut-être "trop" riche si bien qu'il devient plus difficile que WikiNi à prendre en main ; WackoWiki, de l'avis même de ses concepteurs, a fait des choix techniques qui grèvent les performances, alors même que WikiNi est resté très léger. Par ailleurs, le développement de WackoWiki me donne l'impression de ne pas être correctement maitrisé : ça part dans tous les sens et je ne sais pas si les choix prennent le temps d'être correctement discutés. WikiNi est peut-être trop frileux sur cet aspect là ; on peut sans doute trouver des compromis et c'est en ce sens que nous avons développé la modularisation des handlers et la modularisation de la coloration syntaxique (%%(language) %%) -- il est aussi possible d'envisager une meilleure modularisation de WikiNi sans affecter les performances (formatters, mise en page, etc.). Je suis assez en faveur d'un rapprochement avec WackoWiki mais sur l'idée d'un coeur commun ou similaire, les projets pouvant diverger sur les fonctions annexes. -- CharlesNepote
    • Je suis tout à fait d'accord avec ces arguments ! -- ProgFou

• Ce que je voulais dire, c'est que la version actuelle de wacko (et celle en cvs) gère l'international (Français, Russe, Allemand, ... manque l'Espagnol) et gère l'affichage des caractères dans la bonne langue de l'utilisateur sélectionnée lors de l'inscription. Il y a des bonnes fonctionnalités complémentaires dans wikini et wacko, il manque néanmoins une doc' commune en anglais et faire converger les deux projets en un seul produit dans la mesure du possible (quelques backports à faire)... sachant que j'ai une petite préférence pour wikini... -- BenoitAudouard
• Pour l'affichage, WackoWiki utilise la sélection du jeu de caractère local (on peut le voir dans l'en-tête de leur page), ce qui n'est pas la meilleure méthode ÀMHA ... Il vaut probablement mieux passer par l'UTF-8 qui est la solution d'avenir pour le multilingue (toujours ÀMHA), en particulier dans une même page ! Et l'équipe de WikiNi a déjà lancé une réflexion sur le sujet sur la page WakkaMultilingue.
• Quant à la convergence de WackoWiki et WikiNi, ayant jetté un oeil rapide sur les sources, ce ne serait pas juste "quelques backports", mais un travail de fond ! Mais on pourrait déjà commencer par y piocher les petits "plus" qui ne changent pas radicalement la structure du code ou de la base de données. :) -- ProgFou
• ok j'ai déjà une liste des fonctionnalités qui m'intéressent (sur ma page), j'essaierai dans la mesure du possible d'en dresser une liste synthétique pour effectuer une comparaison des deux - dans un tableau ;-) . Je raisonne bien au niveau besoin et non développements, sur lesquels je ne suis pas juge (sauf quand je chercherai à en évaluer la faisabilité...). Pour l'UTF-8, entièrement d'accord pour la solution si mixité de données en plusieurs langues, mais il me semble avoir eu le problème - il y a de cela un an et quelques - que la sélection du navigateur prend le pas sur l'en-tête envoyé par le serveur : nous avions tout en base de données en UTF-8 mais la présentation sur le client s'adaptait à la langue (bug avec le japonais notamment...) d'où saisie sur client (japonais) - conversion vers UTF-8 - stockage en base en UTF-8 - conversion vers client (japonais) - affichage sur client (japonais), m'enfin c'était avec de l'Oracle tout ça... -- BenoitAudouard 20031216
• J'ai vu ta page : impressionant ! Mais vivement la version synthétique ! ;-)
• Pour UTF-8 ton problème m'étonne, mais je ne le mets pas en doute. Il faut savoir que la première chose à faire pour bien faire de l'UTF-8, c'est d'indiquer correctement au navigateur que l'on fonctionne en UTF-8, ce qui n'est pas toujours fait correctement (page encodée en UTF-8 mais sans spécification de charset => ISO-8859-1 par défaut). Ça se fait au niveau des en-têtes HTTP, et c'est là l'essentiel du problème : si on se contente d'un <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />, tous les navigateurs ne le prennent pas en compte ; si on fait ça au niveau de PHP avec un Header('Content-Type: text/html; charset="UTF-8"'); c'est déjà mieux, mais on risque d'avoir des problèmes avec les proxies/cache qui ne stoquent pas les headers et/ou la lecture offline (est-ce souhaité ici ?). Par contre, une fois l'encodage bien spécifié, il n'y a normalement aucun problème pour l'affichage ; reste à voir la saisie. Je travaille dans un environnement UTF-8 depuis plus d'un an (Debian Sid), sans trop de souci. Les dernières versions des navigateurs web fonctionnent très bien et font la conversion à la volée entre codage de la page et codage de l'environnement utilisateur. Il faudrait néanmoins vérifier les anciens navigateurs encore présents sur l'Internet (en particulier Netscape 4.x) ... -- ProgFou
  • Je ne voudrai pas vous couper dans votre élan, mais MySQL ne supporte pas encore l'UTF-8. Bien sûr on peut faire des conversions, mais cela ajoute un léger surcoût et ne permet plus la recherche en texte intégral dans MySQL... Une dernière remarque : ce serait vraiment super si vous pouviez faire des synthèses aux bons endroits ;-) Bien sûr on peut réserver une partie à la discussion mais ce n'est quand même pas le but d'un wiki : mieux vaut créer ou modifier des pages "thématiques" et synthétiser les discussions. On peut par exemple créer une page sur le sujet particulier du codage des caractères si nécessaire. -- CharlesNepote
  • Ça tombe bien que tu abordes le sujet, car j'entends souvent cette réponse, mais je ne vois pas le rapport entre MySQL et l'UTF-8 ... MySQL permet de stoquer du texte sans l'interpréter, c'est tout ce dont nous avons besoin a priori : on stoque le corps des pages en UTF-8, MySQL n'en sait rien (tant mieux), et on l'affiche tel-quel avec une bonne en-tête HTTP/HTML spécifiant le jeu de caractère et le tour est joué ! Le seul niveau ou le jeu de caractère pourrait être important, c'est au niveau des tris ; fait-on des tris sur des caractères autre que ISO-646 (ASCII) ? Au niveau des recherches pas de problème : on cherche une chaîne de caractères (UTF-8) dans un corps de page (UTF-8), c'est normalement indépendant du jeu de caractère employé. La chaîne de recherche devrait être automatiquement envoyée en UTF-8 par le navigateur du moment que la page est déclarée codée comme telle : c'est le seul point à vraiment vérifier à cause des anciens navigateurs web, ÀMHA. Pour le fait de faire des pages "thématiques", je suis d'accord, je vais essayer de nettoyer un peu ma page et de reclasser dans les pages existantes ... Il faut que je finisse de parcourir "tout" votre site ! ;-) -- ProgFou
    • Il me semble que le problème vient de l'indexation en texte intégral. MySQL ne doit pas pouvoir indexer correctement du texte en UTF-8. Il est sans doute possible de stocker des données en UTF-8 dans MySQL, mais on ne peut alors plus profiter de l'indexation en texte intégral et donc du moteur de recherche. -- CharlesNepote

Merci pour votre accueil ! :)
Je ne suis pas certain d'avoir le temps de m'impliquer "à fond" dans WikiNi, même si j'avoue que ça me plairait assez, mais une chose est certaine : vu que je l'utilise et que je suis aussi développeur (par goût), j'y participerai de près ou de loin ! ;-)
Dans ce que j'ai patché, cela concerne la Francophonie (typo), la gestion des droits d'accès (méthode UserIsAdmin? + config["admin_list"]), ou encore des fonctionnalités (comme la mise en fluo suggérée sur votre site). Tout ne sera probablement pas intéressant pour vous, selon votre vision de WikiNi, mais puisque j'ai fait ce boulo pour mon agence, en essayant de respecter votre façon d'écrire le code, autant que ça puisse vous servir aussi ! À vous d'en disposer selon vos choix ! ;-)
Quel est le meilleur moyen pour vous envoyer des patches à appliquer sur le CVS du 20031210 ? Par courriel, via une page WikiNi (genre ProgFouPatches?) ou autre ?
-- ProgFou

Je pense que le mieux est de te donner un accès au CVS, si DavidDelon est d'accord [Je ne suis pas le seul à décider : en fait la procédure est de proposer quelques patchs puis de candidater ensuite l'équipe des participants actifs de wikini approuve ou pas -- DavidDelon] .Note bien qu'il y a un tag "TEST" dans le CVS qui permet de mettre du code à tester. Je l'utilise assez souvent et il y a une page de log pour ce tag. Si tu l'utilise, ne met que du code qui fonctionne. --GarfieldFr

Pourquoi pas ... Je n'ai encore jamais utilisé CVS sérieusement (de manière collaborative) jusqu'ici, je l'ai toujours utilisé uniquement comme stoquage de révisions de sources (sans branchage typiquement) mais ce serait l'occasion de m'y mettre ! :)
-- ProgFou

Ok pour moi, n'hésites pas à me contacter si tu a besoin d'informations supplémentaires sur le fonctionnement de CVS (on est là aussi pour apprendre ...) , première étape indispensable, tu dois ouvrir un compte chez tuxfamily -- DavidDelon

C'est fait : jcandre. J'ai vu qu'on pouvait accéder au CVS via SSH ; à quel adél j'envoie ma clé ? ;-) -- ProgFou

---