Re: [Galette-devel] vers la version 0.63...
GruiicK wrote: Dans l'idéal, une version stable 0.63 avant le début de l'année 2007, ce serait pas mal, non ? :o) Effectivement :) Il reste à : - faire série de tests pour installation fraiche et upgrade * installation from scratch et upgrade pour Mysql (qui s'en charge ?) * installation from scratch et upgrade pour Postgresql (stéphane est déjà en train) * support EasyPhp ? (même si je suis pas hyper chaud...) * fonctionnement chez Free.fr ou autre hébergeur restrictif ? Je propose deux trucs pour accélérer la sortie de la 0.63 : * Laisser de côté la gestion des transactions : Ca ma parait plus être du ressort d'un éventuel plugin pour la comptabilité (en plus, la notion de transaction n'est pas du tout intuitive en l'état actuel) * Laisser de côté la possibilité de s'inscrire (il faut faire quelques modifs, notamment en virant le catcha qui n'est pas accessible) et le prévoir pour la release suivante. Si on fait une feature freeze à ce stade, il n'y a quasiment plus qu'à se concentrer sur les script d'install/upgrade + mettre à jour les fichiers de traduction. - créer la branche 0.63 - ça, je m'en charge dès que j'ai votre feu vert. On peut peut être déjà créer une branche 0.63a, puis retirer les transactions et l'inscription, et s'atteler dés maintenant aux procédures d'install/upgrade ? A noter que dans l'idéal, il faudrait mettre une bonne partie des champs autrefois fixes (ICQ, Jabber, GNUpg...) dans la nouvelle structure de champs dynamiques lors de l'upgrade, et ne pas les imposer lors d'une install fraîche (je ne pense pas que tout le monde en ait l'utilité). Est-ce que cela vous semble OK ? Fred ___ Galette-devel mailing list Galette-devel@gna.org https://mail.gna.org/listinfo/galette-devel
[Galette-devel] Fiches et champs dynamiques
Salut, J'étais en train de vérifier la validité du xhtml sur plusieurs pages de la version CVS, et j'ai pas mal de problèmes avec les champs dynamiques. Quand on en crée, on a des problemes de cellules de tableau mal fermées dans les formulaires de saisie et les fiches de visualisation. Etant donné la complexité du système, je pense qu'on devrait passer à une mise en page plus simple en deux colonne : libellé - champ, à la ligne. On éviterait d'avoir à gerer des colspans tordus et des structures de tableau trop complexes. En clair, les formulaires de saisie de cotiz, de transaction et de membres ressembleraient au formulaire de préférences. Pareil pour l'affichage : libellé - valeur, à la ligne. Du coup pour la déclaration de champs dynamiques, il n'y aurait plus à préciser le positionnement horizontal (left, middle, right), et je pense qu'on y gagnerait en ergonomie. Je veux bien m'y coller mais j'aurais besoin de votre avis avant de me lancer... Frédéric
Re: [Galette-devel] Re: Localisation des champs dynamiques
[EMAIL PROTECTED] a écrit : Deelight writes: Avec aucun champ dynamique défini, j'obtiens l'erreur : - SQL error: [SELECT DISTINCT(text_orig) FROM galette_l10n ORDER BY text_orig] (alors que cette requete est OK) J'ai corrigé ça. Ok Si j'ai un champ défini, je ne vois jamais le formulaire permettant la traduction. Je n'ai pas encore fouillé niveau code pour voir si je trouvais d'où cela venait. Je poursuis les tests. C'est curieux. Est-ce que tu reviens bien à la page initiale en recliquant sur configurer les fiches dans le menu de gauche ? Oui mais je ne vois que la liste déroulante proposant de modifier les fiches adhérent et contribution. Mon install de Galette (faite hier soir/nuit à partir de la version CVS) est dispo sur http://deelight.free.fr/galette (compte admin/admin). Frédéric
Re: [Galette-devel] Re: Localisation des champs dynamiques
Deelight a écrit : C'est curieux. Est-ce que tu reviens bien à la page initiale en recliquant sur configurer les fiches dans le menu de gauche ? Oui mais je ne vois que la liste déroulante proposant de modifier les fiches adhérent et contribution. Mon install de Galette (faite hier soir/nuit à partir de la version CVS) est dispo sur http://deelight.free.fr/galette (compte admin/admin). Après test, le bug ne se produit que lorsque je met Galette chez Free, chez moi tout est ok. Je continue à chercher. Fred
Re: [Galette-devel] Re: Modifs sur les champs dynamiques
[EMAIL PROTECTED] a écrit : Je viens de faire un update et cette modif est vraiment bien. On va finir par avoir un système vraiment trés souple. Je pense d'ailleurs qu'à terme il faudra passer quelques champs actuellement 'en dur' vers du dynamique (genre les champs jabber, icq, msn, entre autres). Ca impliquera un peu de developpement pour l'upgrade mais ce sera nettement plus propre. Oui ce serait bien. On pourrait aussi gérer les champs statiques (du moins certains). Par exemple pour pouvoir changer l'énuméré du champ status. Je n'ai pas d'idée précise pour le faire proprement. Il faudrait aussi pouvoir positionner les champs sur deux colonnes. Il y a un champs field_pos qui pourrait contenir l'info (genre droite, gauche, centré). Mais il n'est pas utilisépour l'instant. D'ailleurs j'avais imaginé à un moment de permettre la modification de ces fiches en wysiwyg. Techniquement ce devrait être possible, mais avec l'utilisation de templates, ça peut être un peu plus délicat. Il s'agirait d'afficher les fiches telles qu'elles sont affichées en réalité + pour chaque champ modifiable une icone pour la modification, et des icones pour le déplacement. C'est sur la todolist mais c'est loin d'être une priorité :) Frédéric
Re: [Galette-devel] Index erroné dans les préférences
[EMAIL PROTECTED] a écrit : Les préférences pref_ville et pref_pays ont le même index. Il y a une erreur dans install/index.php ligne 833. Est-ce que c'est un problème de changer cet index lors d'un upgrade. Est-il utilisé directement ? C'est en effet une erreur mais comme il n'y avait pas de verification à l'inserting, je pense que pref_pays n'était tout simplement pas déclaré... Bien vu. Frédéric
Re: [Galette-devel] Re: Cotisation par exercice
[EMAIL PROTECTED] a écrit : - si on a une cotisation le 01/01/2004, elle court jusqu'au 31/12/2004 - si on a une nouvelle costisation le 05/01/2005, elle court jusqu'au 04/01/2006. On considèré que la personne n'était plus adhérente du 01/01/2005 au 04/01/2005. Ca permet notamment de ne pas se planter pour une personne qui avait résilié son adhésion, et qui se réinscrit au bout d'un certain temps. Oui tu as raison. Si la cotisation en cours n'a pas expiré, on pré-remplit avec le lendemain de la fin de la cotisation. Sinon on prend la date courante. Ca me paraît plus logique aussi. Ok. Cependant je trouve la méthode actuelle plus souple puisqu'elle n'impose pas cette restriction à l'administrateur, et elle se débrouille avec ce qu'on lui fournit. C'est plus souple mais est-ce que c'est vraiment ce qu'attend l'utilisateur puisque de toute façon on fait comme si la date de début était la fin de la précédente cotisation. C'est le principe même du report. Bien qu'on fasse croire qu'on prend en compte la date qu'il donne, on calcule la date d'échéance en décalant les périodes de cotisation pour corriger le chevauchement. Il me semble plus clair d'interdire le chevauchement. Effectivement, c'est mieux d'avoir quelquechose d'explicite. Enfin si on part sur l'idée de ce champ je pense qu'il faudrait le préremplir de cette manière : - Année glissantes : - si c'est une premiere cotisation, date du jour - si c'est une nouvelle cotisation, date prévue de fin de la précédente adhésion si elle court encore, et date du jour si elle est révolue. On considère donc que la personne n'était plus adhérente entre les deux (comme c'est le cas actuellement). Libre à l'administrateur de modifier la date de cotisation pour qu'elle corresponde à la fin de la précédente adhésion. - Par exercice - si c'est une premiere cotisation, date définie de début d'exercice, pour la période en cours (on considèrerait que l'adhérent s'inscrit pour l'exercice en cours, et pas le prochain... mais il faudrait eventuellement en discuter pour voir ce qui concient le mieux) - si c'est une nouvelle cotisation, date définie de début d'exercice pour l'année en cours, on la suivante l'adhésion n'était pas révolue. Oui ça me paraît bien. Ok aussi. Il y a tout de même quelquechose qui me pose un peu problème avec ce fonctionnement, c'est que cas de saisie d'une ancienne cotisation pour un membre, les échéances ne sont pas recalculées. Ce n'est pas la peine puisque l'échéance ne change pas. C'est de toute façon le max des fins des cotisations. Je pensais en fait à l'histoire du report. Si on saisit la première cotisation au 01/01/2004 et qu'on tombe ensuite sur une cotisation antérieure datant du 10/01/2003, on se rend compte que la première cotisation saisie était anticipée, et il faudra la décaler de 10 jours avant de pouvoir saisir la précédente. Quand on installe Galette, il y a généralement une phase on l'on saisit toutes les cotisations des membres, sur une ou plusieurs années. Dans l'état actuel, l'ordre de saisie importe peu puisque l'échéance est dynamiquement recalculée. Avec ce nouveau système, il faudrait absolument saisir les cotisations dans l'ordre pour que l'échéance soit correcte... Non ce n'est pas la peine de les remplir dans l'ordre. Ce serait plus simple parce que la date pré-remplie serait correcte. Mais rien n'empêche de changer la date dans le passé pour peu que la cotisation qu'on rentre ne chevauche pas la suivante (càd celle qui a été déjà rentrée). Le champs date_echeance de la table des adhérent sera recalculée à chaque fois mais comme le max. Ok, c'est le cas auquel je pensais, mais effectivement, ce système apportera plus de souplesse que d'inconvénients. J'aimerai bien faire ça. Je suis optimiste en ce moment. Libre à toi de tenter le coup alors :) Je ne veux pas imposer mon point de vue. Si ça correspond bien à l'utilisation que tous les autres attendent, alors ça m'intéresse de changer le fonctionnement en deux temps : - Ajout de la date d'enregistrement et non chevauchement des cotis. - Ajout de la table des paiements et possibilité de saisir les contributions qui s'y rapportent dans la foulée. Personellement, je pense qu'il faut surtout que le comportement par défaut avec le nouveau système ne soit pas contradictoire avec ce que Galette faisait précédemment. A savoir, ne pas oublier des jours d'adhésion pour quelqu'un qui cotise en avance (en interdisant le chevauchement, ce sera bon) et considèrer la date d'adhésion comme la date du jour pour un cotisation en retard (donc par défaut ne pas prendre la date de fin d'adhésion correspondant à la dernier cotisation si celle ci est révolue). Après, l'admin sera libre de modifier la date de début d'adhésion selon ses souhaits. Sinon cette idée parait trés bonne, d'autant que cela explicitera un peu plus ce que Galette
Re: [Galette-devel] Cotisation par exercice
[EMAIL PROTECTED] a écrit : Mon idée serait de pouvoir spécifier la date de fin de l'adhésion. Par exemple le 30 septembre 2004 et cette date soit dans les préférences de l'admin. Si dans les préférences la date de fin de cotisation est vide, on crée les cotisation par année glissante comme aujourd'hui. Si la date est précisé, on crée les cotisations jusqu'à la fin de l'exercice (qui n'est pas forcément l'année civile). Est-ce que ça conviendrait ? Salut, Je ne sais pas si c'est ce que tu veux faire, mais l'implémentation des cotisations par exercice peut se limiter a un préremplissage du champ date de la cotisation. Il faut tout le même le laisser éditable pour la saisie de cotisations antérieures ou ulterieures à l'exercice en cours. Il faudrait d'ailleurs sans doute permettre de préciser la durée par defaut des cotisations (en mois) dans la page de préférences (actuellement on considère que c'est 12 mois, mais peut être que des associations/clubs/etc fonctionne avec d'autres durées). Dans les deux cas ce devraient être des modifications assez simples. Qu'en penses-tu ? Frédéric
Re: [Galette-devel] Re: Cotisation par exercice
[EMAIL PROTECTED] a écrit : Je ne sais pas si c'est ce que tu veux faire, mais l'implémentation des cotisations par exercice peut se limiter a un préremplissage du champ date de la cotisation. Il faut tout le même le laisser éditable pour la saisie de cotisations antérieures ou ulterieures à l'exercice en cours. En fait ça ne correspond pas exactement à ce qu'on veut. On a des cotisations qui sont valables du 1er octobre au 30 septembre. Si quelqu'un adhère en avril, sa cotisation ne sera valable que jusqu'au 30 septembre de toute façon. Ce qui est fixe c'est la date de fin. On peut tricher en mettant une date de début au 1er octobre. Ou alors on peut changer la durée mais ce n'est plus automatique. Ce serait mieux de garder la date de cosisation réelle et de fixer la fin. Ok, je comprends le principe. Ca doit effectivement être faisable en calculant les échéances par rapport à cette date butoir. Il faudrait donc ne plus utiliser la durée de cotisation lorsque l'on est dans ce mode. Ce n'est pas non plus super évident car si on imagine : Exercice du 01/10 au 30/09 - 1e cotisation le 05/10/2003 - 2e cotisation le 20/09/2004 (en avance, donc) Les deux cotisations sont effectuées pendant le même exercice mais la date échéance pour la 2e n'est pas le 30/09/2004 mais le 30/09/2005. Ce cas se retrouve cependant dans le mode de calcul actuel, on les jours d'adhésions restants sont reportés. Dans les cotisations par exercice, on reporte en fait une année lorsque l'adhérent se réinscrit avant l'échéance. Il faut à mon avis creer une deuxieme fonction pour le calcul des échéances, qui est utilisée lorsque la date de fin d'exercice a été définie dans les préférences (il faudra d'ailleurs remettre à jour la date d'échéance de tous les adhérents lorsque ce paramètre est changé). Frédéric
Re: [Galette-devel] Positionnement de la langue d'install
[EMAIL PROTECTED] a écrit : Salut à tous, Ca fait longtemps que je n'ai pas lancé galette et je n'arrive même plus à l'installer. Je ne comprends pas comment le positionnement initial de la langue marche. Chez moi, ça donne ceci (voir le code ci-dessous) : - dans install/index.php, le $pref_lang est mis à english. - Puis dans i18n.inc.php, comme je n'ai ni $_POST['pref_lang'], ni $_GET['pref_lang'] positionné, il est écrasé par $_SESSION[pref_lang] qui est vide. - On récupère un chaîne vide aussi pour $language. - Après on écrase LANG par la chaîne vide et le setlocale renvoie C. - Ensuite on tente de charger lang/lang_.$pref_lang..php qui n'existe pas parce que $pref_lang est vide. Est-ce que j'ai raté quelque chose ? Salut, En effet, le script d'installation du CVS ne fonctionne plus. Les fichier i18n.inc.php et lang.inc.php on été fusionnés et les script d'install pas encore mis à jour. Je vais essayer dans la semaine de me pencher là dessus pour que le script d'installation soit à nouveau fonctionnel (par contre le script d'update, je le garde pour plus tard car c'est une autre paire de manches...). D'autres pages sont aussi totalement en chantier et ne fonctionnent plus (de mémoire, visualisation d'une fiche adhérent, mailing et etiquettes, configuration des fiches...). Rien de dramatique, je n'ai juste pas encore eu le temps de les modifier pour l'utilisation d'un template. Voilà. Donc si tu as le courage d'essayer de faire un install à la main, ça peut fonctionner, sinon tu peux attendre mon prochain commit :) Frédéric
[Galette-devel] [Fwd: galette-0.62]
Message original
To: [EMAIL PROTECTED]
Subject: galette-0.62
From: Gildas COTOMALE [EMAIL PROTECTED]
Date: Fri, 1 Oct 2004 14:37:25 GMT
Notifications dans la page des préférences
Notice: Undefined variable: pref_pays_req in WEBROOT.preferences.php on
line 404
id=libellePays :
Notice: Undefined variable: pref_adresse2 in WEBROOT.preferences.php
on line 393
Notice: Undefined variable: pref_pays in WEBROOT.preferences.php on
line 405
avertissement dans la page d'enregistrement/modification fiche adhérant
(il en est de même pour le logo dans la page des préférences)
- Le fichier transmis n'est pas une image valide (PNG ou JPEG).
L'enregistrement a cependant été effectué.
Or il se trouve que le fichier transmis est une image JPEG 200x150 avec
l'extension .jpg
Suggestion au sujet des dates et des pays...
Dans le formulaire d'ajout d'adhérant, il y a deux champs réservés aux
dates (de naissance et de création). Il serait plus ergonomique si
l'utilisateur n'avait pas à se préoccuper du format de la date
(jj/mm/), ce qui est réalisable en proposant des listes déroulantes
:
- pour le jour
select name=jj
option value=00inconnu/option
option value=011er/option
option value=02nbsp;2/option
option value=03nbsp;3/option
option value=04nbsp;4/option
option value=05nbsp;5/option
option value=06nbsp;6/option
option value=07nbsp;7/option
option value=08nbsp;8/option
option value=09nbsp;9/option
option value=1010/option
option value=/option
option value=1212/option
option value=1313/option
option value=1414/option
option value=1515/option
option value=1616/option
option value=1717/option
option value=1818/option
option value=1919/option
option value=2020/option
option value=2121/option
option value=/option
option value=2323/option
option value=2424/option
option value=2525/option
option value=2626/option
option value=2727/option
option value=2828/option
option value=2929/option
option value=3030/option
option value=3131/option
/select
- pour le mois
select name=mm
option value=00inconnu/option
option value=01janvier/option
option value=02feacute;vrier/option
option value=03mars/option
option value=04avril/option
option value=05mai/option
option value=06juin/option
option value=07juillet/option
option value=08aoucirc;t/option
option value=09septembre/option
option value=10octobre/option
option value=11novembre/option
option value=12deacute;cembre/option
/select
- pour l'année
input type=text name= size=4 mawlength=4
Les différents champs peuvent ensuite être rassemblés ensemble avec le
délimitateur de son choix ou directement passé à la fonction php
checkdate(jj,mm,) ou être directement passé à MySQL au format iso
(aaammjj avec ou sans délimitateur...)
Pour réafficher les données récuppérées depuis la base de données, le
principe est aussi trivial que décrit plus loin au sujet des pays...
Pour les pays en effet, il est devenu fréquent dans les web-appliances
d'avoir la liste des pays... Même principe donc. Voici une des façons
d'implémenter cela (mais je crois qu'une fonction isSelected est déjà
prévue pour faire cela) :
select name=pays
?php $cc=''; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?choisir : /option
?php $cc='af'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Afghanistan/option
?php $cc='za'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Afrique du sud/option
?php $cc='al'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Albanie/option
?php $cc='dz'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Algeacute;rie/option
?php $cc='de'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Allemagne/option
?php $cc='ad'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Andorre/option
?php $cc='ao'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Angola/option
?php $cc='ai'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Anguilla/option
?php $cc='aq'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Antarctique/option
?php $cc='ag'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Antigua-et-barbuda/option
?php $cc='an'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Antilles neacute;erlandaises/option
?php $cc='sa'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Arabie saoudite/option
?php $cc='ar'; echo('option value='.$cc.''); if($cc==$pays) echo('
selected'); echo(''); ?Argentine/option
?php $cc='am'; echo('option value='.$cc.'');
[Galette-devel] Re: difficulté d'install Galette
samana a écrit : Merci pour votre support. Ca tourne et c'est du beau boulot. C'est exactement ce qu'il nous faut. Nous cherchons aussi un bon programme comptable avec facturation pour notre association qui a un bureau en Belgique et un autre au Maroc... Si vous avez une idée? Cordiales salutations et encouragement aux développeurs du LIBRE Luc Bonjour et merci pour le compliment, je transmet votre message aux autres développeurs. En ce qui concerne la facturation, peut être que l'un d'entre eux pourra vous répondre car pour ma part, je n'ai pas d'idée. Il n'est pas inenvisageable que Galette permette un jour la facturation, mais ce n'est pas encore dans nos priorités. Je pense qu'un jour il faudra qu'on se penche sérieusement sur la modularité de Galette, afin que l'utilisateur puisse ajouter à l'application de base uniquement les modules dont il a besoin (Génération d'étiquettes, Facturation, Agenda partagé... etc). Merci pour vos encouragement ! Frédéric
[Galette-devel] Re: ended with gettext i18n
Georges Khaznadar a écrit : Bon c'est fait. Dans le répertoire lang/, make lang regénère les fichiers lang_*.php, et make tout court aussi. Ok je vient de tester et j'ai a peinde touché au code python pour escaper les simple quotes. Maintenant il faudrait voir si tu peux faire un truc qui nous eviterait de trop remplir le CVS. En effet, dés qu'on fait un make, il met à jour tous les fichiers de langues et si on fait un CVS commit, on crée une nouvelle version de ces fichiers alors que parfois, seule la date dans l'en-tête a changé. Je n'ai pas su le faire en python, et encore moins dans la Makefile. Je pense qu'il faudrait intègrer cette procédur dans make_lang_l12n.py. Exemple de ce que je souhaitais faire (en bash) : ./make_lang_l12n.py en_US.po lang_english.php.new old=$(cat lang_english.php | tail -$(expr $(cat lang_english.php | wc -l) - 2) | md5sum) new=$(cat lang_english.php.new | tail -$(expr $(cat lang_english.php.new | wc -l) - 2) | md5sum) Il suffit ensuite de comparer $old et $new pour savoir si le fichier est réellement modifié (dans ce cas, mv lang_english.php.new lang_english.php), ou s'il est identique hormis l'entete (alors rm lang_english.php.new). Ce n'est pas urgent mais si tu sais faire, ça m'éviterait de trop galèrer dessus. Je vais pour ma part commencer à coder la détection gettext() et modifier l'encapsultation de chaines (_T). Je pense aussi faire quelques tests sous PHP5, juste histoire de :) Merci, a++ Fred
Re: [Galette-devel] Re: [Galette-cvs] ended with gettext i18n
Georges Khaznadar a écrit : _T() (lang.inc.php) pour que dans un premier temps, elle passe simplement le relai à _(). Ça c'est relativement simple à faire. De même que paramétrer xgettext pour qu'il considère le préfixe _T. Parfait. Je vais ensuite étudier la possibilité de déclarer les tables lang[] par lecture directe du .po. Si j'arrive a quelquechose de fonctionnel, il suffira de rajouter le choix de la methode de localisation dans la page de préférences, et tenir compte de ce reglage dans la fonction _T(). De toute façon à chaque changement de chaîne dans les sources je dois lancer le Makefile du répertoire lang/ J'ai une commande en python qui saura te faire des fichiers lang_*.php directement à partir des fichiers .po, c'est celle que j'ai utilisée pour fouiner dans les sources et y remplacer le français par de l'anglais, et en faire de même pour les msgids des fichiers po. Donc on la déclare dans une des cibles du Makefile et zou. On fait comme ça ? Ca me parait parfait comme méthode ! Comme ça on peut utiliser les outils de traduction associés à gettext et permettre la localisation meme lorsque php a été compilé sans support gettext. Après reflexion je pense meme qu'il ne sera pas necessaire de rajouter un reglage dans la page de préférences : on pourrait directement en PHP détecter si les fonctions gettext sont présentes et quelles locales sont dispos, non ? A++ Fred
Re: [Galette-devel] Re: [Galette-cvs] ended with gettext i18n
Georges Khaznadar a écrit : Est-ce qu'on pourrait envisager de conserver les deux méthodes de localisation : gettext() et une autre qui extrairait les messages des .po pour les déclarer en global (ou autre méthode) ? Je pense surtout aux personnes qui n'ont pas compilé php avec le support gettext et notamment aux hébergeurs (qui n'auront en plus pas forcément les bonnes locales). Ce pourrait etre un parametre dans l'interface d'admin (localisation method : gettext / oldschool). Qu'en pensez-vous (et surtout toi Georges vu le boulot que tu as effectué a dessus !). Il y a peu de différence dans le code entre les deux approches : faut voir si on peut redéfinir la fonction _() dans une source PHP. Salut, En fait, c'est un peu pour cette raison que j'avais defini une fonction _T() pour la traduction. On peut tout à fait se débrouiller pour que _T() fasse appel à _() pour la traduction gettext. De plus, il était assez simple d'indiquer à xgettext qu'il devait isoler les chaines encapsulées dans _T() plutot que _(). Chacune des méthodes a ses avantages : - la méthode du tableau des traductions est portable même sans gettext - la méthode avec gettext hérite des fonctionnalités de cette suite gnu : facilité de générer automatiquement la table des chaînes à traduire à chaque évolution du code, répartition automatique dans les fichiers .po, mode po d'emacs qui permet d'aller droit à l'essentiel, et de visualiser les sources en regard des traductions en cas de doute, récupération de dictionnaire flous. En effet, je suis tout à fait d'accord avec toi concernant les avantages de gettext et c'est pour cette raison que je comptais éventuellement utiliser les fichier .po meme lorsque l'on n'utilise pas gettext. Ca permettrait surtout de faire un traduction unique, sans aucune redondance. Pour moi l'inconvénient principal de gettext c'est le pivot en anglais obligatoire (l'algorithme actuel de gettext refuse de prendre en considération un pivot qui n'est pas en ascii). Personellement ça ne me dérange pas de coder directement en anglais, mais il est vrai qu'il vaut mieux etre sur du terme dés le départ car il me semble que si l'on fait une modif sur une chaine en anglais, il faut recreer tous les .po et .mo. Ceci dit, ce n'est pas vraiment genant. Ce que nous pouvons faire, c'est une fourche dans le développement (cvs tab -b), mais à mon avis pour que les développements ne soient pas trop incompatibles, il faudra conserver des messages en anglais dans la source. Je peux recoder les tables lang[] pour que la référence soit en anglais plutôt qu'en français de façon automatique. Qu'en penses-tu ? Je pense qu'il faut laisser les messages en anglais dans le source et peut etre ramplacer les appels à _() par _T() et redéfinir la fonction _T() (lang.inc.php) pour que dans un premier temps, elle passe simplement le relai à _(). Je vais ensuite étudier la possibilité de déclarer les tables lang[] par lecture directe du .po. Si j'arrive a quelquechose de fonctionnel, il suffira de rajouter le choix de la methode de localisation dans la page de préférences, et tenir compte de ce reglage dans la fonction _T(). A ton tour, qu'en penses-tu ? ;) Frédéric
[Galette-devel] Re: [Galette-cvs] ended with gettext i18n
Georges Khaznadar a écrit : *Commit from /georgesk/*2004-08-07 20:38 CEST ended with gettext i18n : automagically switched the base language for messages in the sources to english, rewrittent the po files, etc. Now it is working. Just check that you have the locales [EMAIL PROTECTED] and [EMAIL PROTECTED] installed. If not, you must reconfigure the locale package. Salut, Est-ce qu'on pourrait envisager de conserver les deux méthodes de localisation : gettext() et une autre qui extrairait les messages des .po pour les déclarer en global (ou autre méthode) ? Je pense surtout aux personnes qui n'ont pas compilé php avec le support gettext et notamment aux hébergeurs (qui n'auront en plus pas forcément les bonnes locales). Ce pourrait etre un parametre dans l'interface d'admin (localisation method : gettext / oldschool). Qu'en pensez-vous (et surtout toi Georges vu le boulot que tu as effectué a dessus !). Fred
[Galette-devel] [task #608] Localisation des libellés des c hamps dynamiques
Laurent Pelecq wrote: Il faudrait une table galette_l10n qui puisse contenir les traductions et qu'on puisse le mettre à jour dans l'application de configuration des fiches. Si c'est ça, je peux le faire. En fait je ne sais pas du tout. Il faudrait surtout éviter de trop complexifier le mécanisme (que ca reste intuitif) et que cette traduction ne soit pas obligatoire... Une idée ?
[Galette-devel] Patch - ajout de champs
Laurent Pelecq wrote: J'ai posté un patch pour ajouter des champs directement à partir de l'interface. Ca évite de rajouter des champs fixes qui n'ont pas d'intérêt pour tout le monde. Il y a un nouvel écran où on déclare les champs et où on les ordonnent. Coool ! Merci pour ton boulot. J'avais posté une adaptation de ton patch pour Galette 0.62 mais je l'ai retiré car il y a un petit bug lorsque l'on est sous MySQL (à cause d'une requete imbriquée). Je viens juste de le corriger pour que ça tourne correctement sous MySQL mais je ne pense pas poster de patch, je commiterai le tout dans le CVS une fois que j'aurais fini de m'amuser avec cette nouvelle fonction :) A++ Frédéric
[Galette-devel] Re: refonte du MCD
GruiicK wrote: Salut à tous, j'ai comme un petit soucis. Un nouveau membre vient d'arriver, et il a un patronyme trés long. Trés long. Ça rentre pas !! C'est vrai que dans la version CVS actuelle, le nom et le prenom sont encore limités à 20 caractères... 50 ça irait ?
[Galette-devel] Re: Champs d'informations génériques
Laurent Pelecq wrote: Je rajouterai aussi (c'était peut être sous-entendu) un index numérique pour la clé. Je n'y avais pas pensé mais j'ai vu que c'était fait comme ça pour les autres séquences. En passant, je ne comprends pas comment sont crées les index (au sens bd) en psql. Je m'attendais à un 'CREATE INDEX' dans pgsql.sql Je ne pense pas avoir défini de vrais index et clés primaires en pgsql. A la base je maitrise mieux mysql et je me suis inspiré des structures de base de données de phpbb2 pour creer les script pgsql. Il y a surement des améliorations à faire de ce côté là... A part ça je pense qu'il faudra sans doute nuancer le type de contenu pour indiquer son type (pour effectuer les validations adequates dans les formulaires), le type de controle (champ texte, textarea, liste déroulante, bouton radio...), la longeur max (pour les champs texte) et une liste de valeurs pour les liste déroulantes par exemple. Là je suis un peu largué. Je pensais que les infos seraient des données libres (donc un texte multiligne comme les infos actuelles ou une liste de champs). Par exemple une info comme la couleur préférée serait un texte, alors que pour des adresses courriers supplémentaires, l'adhérent pourrait en entrer plusieurs (avec un genre de bouton plus pour ajouter une valeur). Oui ok, je vois ton idée. Si on a un type de contrôle, on donne à l'administrateur la possibilité de faire évoluer l'interface. Mais par exemple pour les boutons radio, je ne vois pas l'intérêt pour l'utilisateur de définir lui-même ses boutons. Ce serait plutôt l'administrateur qui le ferai. Et les valeurs possibles ne seraient pas stockées dans la table des infos mais dans la table de description des catégories, pour qu'elles soient les mêmes pour tous les adhérents. Mais là c'est beaucoup plus ambitieux que ce que je pensais. Effectivement moi je voyais plutôt ton idée comme une possibilité pour l'administrateur de pouvoir définir totalement les données à saisir dans les fiches adhérent. Quitte à rendre les champs des fiches dynamiques (pour pouvoir par exemple saisir plusieurs adresses mail), je pense qu'on peut aussi offrir cette fonctionnalité. Du coup il faudrait sans doute rajouter dans la structure de la table définissant les types de contenu un attribut valeurs multiples (yes/no) qui permettrait à l'utilisateur de rajouter des champs pour un meme attribut (adresse mail par exemple). Il faudrait sans doute aussi prévoir un attribut non_modifiable (yes/no aussi) pour éviter que l'admin puisse supprimer des champs obligatoires (le nom de l'adhérent principalement). Est-ce que c'est ça ? Oui c'était bien ça. J'avais un peu extrapolé ton idée. Frédéric
[Galette-devel] Re: Champs d'informations génériques
Laurent Pelecq wrote: Ce n'est pas la peine de me mettre dans la liste des développeurs pour l'instant. Je vais plutôt essayer de faire une première implémentation sommaire pour me familiariser avec PHP et galette. Je connais d'autres langages mais pas celui-là. Ce que je pensais faire c'est discuter des solutions techniques sur la liste et de les appliquer si on tombe d'accord. Par exemple, il me semble qu'il faille deux nouvelles tables (je ne suis pas un pro des bases de données non plus): - gallete_info_categories: pour stocker les paramètres des catégories (ce que j'avais appelé classes) avec comme colonnes: le nom, le visibilité (admin, tous), le type de contenu (une seule valeur ou une liste de valeurs). Je rajouterai aussi (c'était peut être sous-entendu) un index numérique pour la clé. Je pense qu'il faudra aussi nuancer la visibilité en indiquant un niveau d'accès à partir duquel la valeur est visible. Pour le moment la gestion des droits sur Galette est basique (on est admin ou non) mais une gestion plus fine des droits est au programme (pour notamment avec une meilleure granularité des droits concernants l'admin, le président, secrétaire, trésorier...). Cependant, dans un premier temps on pourrait se contenter d'un champ de type entier (0 - admin, 1 - tous), il suffira de le réutiliser lorsque la nouvelle gestion des droits sera implémentée. A part ça je pense qu'il faudra sans doute nuancer le type de contenu pour indiquer son type (pour effectuer les validations adequates dans les formulaires), le type de controle (champ texte, textarea, liste déroulante, bouton radio...), la longeur max (pour les champs texte) et une liste de valeurs pour les liste déroulantes par exemple. - galette_adh_infos: pour les infos elles-mêmes avec comme colonnes le numéro d'adhérent, le nom de catégorie, la valeur. Indéxée sur le numéro d'adhérent. Dans le cas d'une catégorie qui accepte une liste de valeurs, la clé n'est pas unique. Du coup là aussi je rajouterai une clé de type numérique. A part ça, sur le papier ce modèle me parait ok, reste à voir la complexité de l'implémentation. Frédéric
Re: [Galette-devel] Premiers tests du nouveau script d'installation
Hello, Je viens de finir les test du nouveau script d'install avec MySQL, pas de problème. Il y a sûrement des cas particuliers auxquels je n'ai pas pensé mais ça devrait aller dans 99% des cas. Il reste à tester : - L'install de base - La mise à jour de Galette 0.61 - PostgreSQL - La mise à jour de Galette 0.61 - PostgreSQL Si vous voulez mener des tests, la version CVS de Galette se trouve à l'adresse : http://galette.logeek.com/download/cvs-version/galette-cvs-20040420.tgz Et toutes les anciennes versions de Galette sont dans le dossier : http://galette.logeek.com/download/ Je précise que Galette ne dispose d'un script d'install qu'à partir de la version 0.56 donc n'essayez une version plus vieille que si vous êtes vraiment motivé :) Frédéric
[Galette-devel] Premiers tests du nouveau script d'installation
Hello, Je viens de tester la nouvelle version du script d'installation en mettant à jour Galette 0.56 vers la version actuellement sur le CVS (à priori la future 0.62), avec une base MySQL. A part un léger bug vite corrigé, tout s'est bien passé ! C'est plutôt encourageant. Il reste à tester : - L'install de base - La mise à jour de Galette 0.61 - PostgreSQL - La mise à jour de Galette 0.61 - MySQL - La mise à jour de Galette 0.61 - PostgreSQL A priori vu le test qu'il vient de passer, le script d'install ne devrait pas trop mal s'en sortir. Je pense que dés que ces configurations auront été testées, on pourra envisager une release. Si vous voulez mener des tests, la version CVS de Galette se trouve à l'adresse : http://galette.logeek.com/download/cvs-version/galette-cvs-20040420.tgz Et toutes les anciennes versions de Galette sont dans le dossier : http://galette.logeek.com/download/ Je précise que Galette ne dispose d'un script d'install qu'à partir de la version 0.56 donc n'essayez une version plus vieille que si vous êtes vraiment motivé :) Frédéric
[Galette-devel] Re: A propos de galette : suggestions
Olivier Tétard a écrit : Hello, J'utilise galette pour une association dont je fait partie (« Cosedia Arena Team » = http://www.cat-lan.com), et j'aurais aimé faire part de quelques idée et améliorations possible (à mon humble avis ;)). La principale chose que j'aimerais voir c'est l'encryptage des mots de passe. Dans la base de donnée (ça ne demande pas trop de grand changement, mis à part que si l'utilisateur a oublié son mot de passe, il faut en régénérer un autre), mais aussi dans l'interface. Ce qui me gene c'est qu'en tant qu'administrateur je puisse voir les mot de passes de tout le monde. Je verrais plus des input type=password / pour les mots de passe (ca nécessite quelques changements : obliger l'utilisateur à taper 2 fois son mot de passe etc...). Bref, je vais sûrement essayer coder ca à partir de la version 0.61, si ça peu vous intéresser dites le moi ;) Bonjour, Le fait que les mots de passe ne soient pas cryptés au niveau de la base est principalement lié au manque de temps :). C'est cependant tout à fait faisable (et même nécessaire). Nous sommes bien evidemment intéressé si vous souhaitez apporter votre contribution au projet sur ce point ;) Frédéric
[Galette-devel] Re: [Galette-cvs] added the possibility to be visible or not in the members list
Stéphane Salès a écrit : added the possibility to be visible or not in the members list Je pense que par defaut, il faudrait masquer cette option et donner la possibilité à l'administrateur de l'activer ou non. En effet, elle n'a aucun intéret pour les associations qui n'associent pas Galette à un site web. Ca pourrait meme prêter à confusion pour les administrateur Galette qui pourraient penser que cette option masque l'utilisateur dans la liste des adhérents (au niveau de Galette). Peut être qu'on pourrait modifier le libellé en Apparaitre de le site de [Nom de l'association] ou un truc du genre... Qu'en pensez-vous ? Frédéric
[Galette-devel] Fusion ajouter_adherent.php / gestion_informations.php
Salut ! Comme ces deux fichiers faisaient presque la même chose (edition d'une fiche adhérent) sans être destinés aux mêmes personnes (une pour les admins, l'autre pour les membres), j'ai tenté ce matin de les fusionner. A priori la version que je viens de publier sur le CVS doit fonctionner. Cependant, si vous avez un peu de temps, il faut chercher des bugs de ce coté. J'ai mis en place une version cvs de galette à l'adresse http://cvs.logeek.com/galette (me contacter en privé pour avoir les identifiants adminsitrateur, si vous ne les avez pas déjà). Il faut surtout s'assurer que l'administrateur peut tout éditer, qu'un membre ne peut editer que ses infos, qu'il ne peut pas modifier son nom et son prenom... bref, surtout des points de securité. C'est tout :) Deelight
[Galette-devel] CVS checkout
J'ai reussi à faire le checkout CVS, donc tu peux faire tes tests :)
