Je continue ici la discussion entamée sur la liste utilisateur.
Ce n'est pas en dynamique. Il s'agit juste de générer avec ce script les
différentes versions traduites qui sont ensuite mises à disposition sur leur
site :
http://phpwebsite.appstate.edu/mod.php?mod=userpage&menu=16&page_id=10
La version avec les TRANSLATE et le script sont disponibles via leur CVS
Ce n'est pas en dynamique. Il s'agit juste de générer avec ce script les
différentes versions traduites qui sont ensuite mises à disposition sur
leur site
Donc on ne peut avoir qu'une langue à la fois dans l'appli installée, ce qui ne
permet pas à tout utilisateur de naviguer dans la langue de son choix ...
Bof.
Ce qu'il faut, c'est ce qui est fait par exemple dans phpMyChat depuis le début
et phpMyAdmin depuis la 2.2 :
http://www.phpheaven.net/chat/
http://phpmyadmin.sourceforge.net/phpMyAdmin/
Dans les deux, c'est basé sur phpLang :
http://www.phpheaven.net/projects/phpLang/
-Nicolas
Salut tout le monde,
Comme je tra=EEnais hier =E0 Paris avec un cahier, j'ai not=E9 quelques
id=E9es pour la suite des =E9v=E9nements.
=3D> Fonctions messagerie plus pouss=E9es
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pour l'instant, la messagerie donne l'impression d'un truc pas
totalement fini. Je l'utilise quotidiennement sur uZine, mais j'ai un
sentiment d'inachev=E9 de ce c=F4t=E9 :-))
+ meilleure utilisation du calendrier. Je sais pas comment
exactement, mais il me semble qu'il doit y avoir mieux =E0 faire du
c=F4t=E9 du calendrier; ce type de pr=E9sentation, c'est tr=E8s sympa, mais
sous-exploit=E9;
+ transformer _le_ forum interne en multiples _forums_ th=E9matiques;
possibilit=E9 de forums r=E9serv=E9s aux admins; inscription opt-in (on
peut s'"abonner" =E0 un forum th=E9matique pour =EAtre pr=E9venu des nouveau=
x
messages);
+ fiches r=E9dacteurs plus compl=E8tes, avec les infos habituelles d'un
carnet d'adresse (t=E9l=E9phones, adresses, vrai nom...); choix
individuel de chaque r=E9dacteur pour que les diff=E9rentes infos soient
accessibles aux admins seuls, =E0 tous les r=E9dacteurs, sur le site
public. De cette fa=E7on, groupware (j'aurais plus =E0 rechercher dans
mes feuilles volantes tach=E9es de caf=E9 pour retrouver des t=E9l=E9phones)=
Salut,
Je ne commente pas tout tout de suite, y en a un paquet :))
+ transformer _le_ forum interne en multiples _forums_ thématiques;
possibilité de forums réservés aux admins; inscription opt-in (on
peut s'"abonner" à un forum thématique pour être prévenu des nouveaux
messages);
Est-ce que c'est prioritaire ? Je ne suis pas sûr qu'une
profusion de moyens de communication soit une bonne idée
(déjà : mail, forums d'articles, forum interne, messagerie).
Le problème après c'est que la participation aux débats
devient un truc d'initiés, parce qu'il faut maîtriser
tous les moyens de communication et se faire une place
sur chaque. C'est déjà un problème sur uzine : en se
mettant à la place d'un nouveau venu sur l'espace privé,
on comprend qu'il faut beaucoup de temps pour s'habituer
aux modalités de discussion, et donc que les habitués
soient les mêmes depuis 6 mois.
+ fiches rédacteurs plus complètes, avec les infos habituelles d'un
carnet d'adresse (téléphones, adresses, vrai nom...); choix
individuel de chaque rédacteur pour que les différentes infos soient
accessibles aux admins seuls, à tous les rédacteurs, sur le site
public. De cette façon, groupware (j'aurais plus à rechercher dans
mes feuilles volantes tachées de café pour retrouver des téléphones),
et possibilité d'infos aux visiteurs du site (il n'est pas rare qu'un
journal ou une entreprise fournisse les téléphones de ses
collaborateurs).
Bof, SPIP ne doit pas devenir Outlook 
Classer tes numéros de
téléphone, ce n'est pas dévolu à un système de publication....
Les onglets permettraient de découper certaines pages de l'interface
privée, sans pour autant nuire à l'unicité de cette page. Par
exemple, la page "auteur" devient très chargée en mode admin; on
pourrait sans difficulté séparer la liste des articles, la
présentation de l'auteur, les données de connexion, le réglage de la
messagerie interne, selon un système d'onglets.
Oui....
pourrait être fait dans l'espace privé lors du calcul des rubriques
actives (avec stockage de la "date" de la rubrique à ce moment).
Oui, bonne idée.
+ Critère négatif. Ca pourrait prendre la forme {NOT id_rubrique=6}.
Le "NOT" (ou une traduction en français?) applicable à _tous_ les
critères.
Heu, pardon, c'est déjà fait Il faut ajouter un point d'exclamation :
{id_rubrique!=6}, {titre!==^[Aa]}....
+ Améliorer le moteur de recherche: recherche dans une rubrique,
selon la date des articles...
C'est plutôt à voir dans les squelettes. Pour la date, ça doit déjà
fonctionner. Pour la rubrique, faut voir avec les idées de stockage
de la hiérarchie (cf. liens de Nicolas).
+ comment s'utilisent les critères type ARTICLES avec les mots-clés?
(Pb. documentation?) Est-ce que je peux faire une sélection
d'articles liés au mot-clé "France" avec un simple
BOUCLE...(ARTICLES){mot=France)?
En effet, c'est pas documenté. C'est exactement comme les auteurs :
critère {id_mot} dans une boucle articles imbriquée dans une boucle
mots, et critère {id_auteur} dans une boucle mots imbriquée dans
une boucle articles. Et possibilité d'utiliser directement les ids,
ou le titre, etc, pour court-circuiter :
<BOUCLE (MOTS){titre=france}>
<BOUCLE (ARTICLES){id_mot}>
...
Dans LaTeX, on utilise le raccourci //
pour provoquer un simple retour à la ligne (<BR> du HTML).
Problème, c'est une marque de commentaires dans certains langages
(php, c++, java...). Du coup, du code de ces langages inclus dans
une page spip risque de foirer la mise en page. En plus, ce n'est
pas très intuitif (personne ne connaît latex, enfin dans un milieu
non hyper-connoté techniquement), il faudrait trouver autre chose.
(et est-ce que c'est couramment utilisé ? ce n'est pas toi qui
disais qu'un retour chariot sans saut de ligne ne correspond à rien
typographiquement parlant ?)
fait très chier, mais si on gère des documents externes (ci-après),
Les documents externes seraient plutôt gérés comme les images, avec
des balises spécifiques (<DOC45> par exemple, avec la variante
<DOC45|EMBED> pour l'afficher "en ligne" (sons, vidéo, java...)).
Non ?
+ Upload uniquement par FTP (pour cause sécurité, et parce qu'un
"gros" document n'a pas vocation à être uploader par un formulaire
Web).
Non, il suffit de définir une liste d'extensions autorisées au
niveau de la configuration du site (on peut fournir des valeurs
par défaut raisonnables : i.e. doc, xls, ppt, pdf....). Un doc
Word ou PDF peut être très petit.
+ Nouvelle table dans la base, contenant uniquement les informations
sur ces documents "externes" (type, description...)
Rajouter les images dedans à mon avis, parce que le stockage actuel
est bidouillesque (mea culpa).
+ Globalement, il y a beaucoup à améliorer dans la syndication:
programmation (ne pas se connecter à chaque recalcul de page), et
interface (c'est assez bordélique pour l'instant). Problème de
timeout du fsocket_open pour éviter de planter un recalcul; j'ai
cherché dans les docs, j'ai pas trouvé de solutions (la variable de
timeout directement dans la fonction fsocket n'est pas active sur
tous les serveurs, par exemple ça n'a pas l'air de changer grand
chose sur uZine :-))
La solution est d'appeler ça après l'affichage, à la fin de inc-public,
comme pour l'indexation. Ainsi s'il y a timeout, il y au pire un
petit message PHP en bas de page, mais ça ne gêne pas le reste.
+ Vu passer une histoire de RSS 1.0, incompatible avec SPIP? Faudrait
creuser ça...
A vue de nez, c'est à cause des valeurs d'attributs dans les balises
(<item attribut=...> au lieu de <item> tout court, etc). Suffit d'appeler
les routines XML de l'espace privé (à prendre dans inc-import, et à
mettre dans un fichier séparé, puisqu'elles serviront à plusieurs
trucs).
Le soft "visiteurs" qui fait le comptage des visites, avec un tableau
d'affichage très complet, fait un excellent complément à SPIP quand
on n'a pas d'autre outil de comptage. C'est vraiment pas mal.
L'intégrer directement à SPIP? (je crois que c'est GPL, pas certain,
en tout cas l'auteur est français).
Est-ce que c'est le truc qui était intégré sur www.minirezo.net ?
Si oui, c'est une horreur, il y avait une table MySQL de 180 Mo
(nommée "visiteurs" justement) qui était mise à jour à chaque appel
de page. Quand j'ai supprimé l'appel visiteurs, le site est devenu
moins lent
a+
Antoine.
Les documents externes seraient plutôt gérés comme les images, avec
des balises spécifiques (<DOC45> par exemple, avec la variante
<DOC45|EMBED> pour l'afficher "en ligne" (sons, vidéo, java...))
Et si tous les documents externes, images et autres, étaient composés
de deux éléments : le document et une vignette optionnelle.
Comme ça, s'il y a une vignette, <DOCn> l'affiche avec un lien vers le
réel document, et s'il n'y en a pas, <DOCn> affiche soit le document
brut si c'est possible ou précisé, soit une icône par défaut
correspondant au type de doc, avec un lien vers le doc ...
Evidemment, <DOCn> et <IMGn> donnent la même chose dans le cas d'une
image ... 
Le soft "visiteurs"
Est-ce que c'est le truc qui était intégré sur www.minirezo.net ?
Si oui, c'est une horreur
"Les Visiteurs" est assez intéressant à utiliser, mais il me semble
qu'il est beaucoup trop riche pour SPIP.
-Nicolas
Comme je traînais hier à Paris avec un cahier, j'ai noté quelques
idées pour la suite des événements.
Dis donc, il était gros ton cahier !!!
=>> Interface avec layers (quand possible)
Ouh la la, grosse prise de tête en perspective, à moins de se reposer
entièrement sur une librairie DHTML cross-browser fournie par un tier
qui la tient bien à jour ...
Possibilités d'inclusion d'autres squelettes (y compris en PHP)
Comment ça "y compris en PHP" ???
Un petit tag bien senti pour indiquer d'inclure un squelette
'toto.html' et il suffit de le traiter en premier, avant tout autre
"parsing" du squelette principal. Attention tout de même à prévoir un
nombre de récurrences maximal pour éviter les boucles infinies.
améliorer le passage de variables "exotiques" à un squelette (ou
alors, mieux expliquer ça dans la doc :-))
Du genre $flag_preserver et autres subtilités non documentées ?
Possibilité d'envoyer directement un fichier texte (pour le "#TEXTE"
de l'article) par upload, conversion (simple!) à partir de HTML
(XML?)
Pour ça, il faut définir quels tags transformer en quelle mise en
page, à moins de se limiter à un format bien défini, avec une DTD,
comme DocBook XML ...
faut-il finalement un raccourci dans les liens hypertextes pour
ouvrir une nouvelle fenêtre ?
Je pense qu'il faut plutôt proposer dans l'interface de configuration
de rajouter automatiquement un 'target="_blank"' aux liens externes
(uniquement).
provoquer l'ouverture d'une nouvelle fenêtre, dont on aurait
éventuellement fixé la taille ?
Bof, ouvrir une autre fenêtre pour envoyer le lecteur sur un autre
site sans qu'il perde l'article en cours de lecture, oui, mais faire
de SPIP un popup-o-matic, franchement bof ...
Je n'aime personnelement pas qu'on m'ouvre une fenêtre dont je ne peux
pas disposer à ma guise, taille, barres de boutons, etc, ce n'est pas
"user friendly" à mon avis.
=>> Améliorer la syndication
Problème de timeout du fsocket_open pour éviter de planter un
recalcul; j'ai cherché dans les docs, j'ai pas trouvé de solutions
Peut-être qu'utiliser l'extension curl quand elle est disponible
pourrait aider.
histoire de RSS 1.0, incompatible avec SPIP ?
Oui, il y a des différences entre RSS 1.0 et le RSS 0.92 que SPIP sait
gérer ...
-Nicolas
Nicolas Hoizey wrote:
Et si tous les documents externes, images et autres, étaient composés
de deux éléments : le document et une vignette optionnelle.
Très bonne idée
Si on conserve dans cet affichage le nom de ceux qui étaient connectés
il y a quelques minutes, même s'ils ne le sont plus, il faut sans
doute changer le libellé ...
Ben, de toute façon, il n'y a pas de connection persistante visible
en PHP, donc l'énoncé est _de toute façon_ superfétatoire (mais plus
simple que "ces personnes ont affiché une page de l'espace public
il y a moins de X minutes).
a+
Ben, de toute façon, il n'y a pas de connection persistante visible
en PHP, donc l'énoncé est _de toute façon_ superfétatoire (mais plus
simple que "ces personnes ont affiché une page de l'espace public
il y a moins de X minutes).
On pourrait mettre "Potentiellement en ligne" avec une explication
dans l'aide ...
-Nicolas
Salut a tous,
De=A0: Antoine Pitrou <pitrou@free.fr>
Date=A0: Wed, 17 Oct 2001 21:47:59 +0200
Cc=A0: spip-dev@rezo.net
Objet=A0: Re: [spip-dev] Cht'tites id=E9es pour la suite...
=20+ Nouvelle table dans la base, contenant uniquement les informations
sur ces documents "externes" (type, description...)=20
Rajouter les images dedans =E0 mon avis, parce que le stockage actuel
est bidouillesque (mea culpa).
je suis tout a fait d'accord. J'en avais d=E9j=E0 fait la proposition qui avait
=E9t=E9 ignor=E9e (2 fois, c'est vexant).
En ce qui me concerne, je vais me retrouver avec 50 groupes de zic, 40
compagnies de th=E9=E2tre, autant de danse de la r=E9gion PACA et pour chaque
"ensemble", des images (faut pas que j'oublie les cr=E9dits photos sinon pan
sur les doigts !) , des vid=E9os et du son.
Internet, ce n'est pas la presse =E9crite. Il faudrait a mon avis que le cot=E9
multimedia de SPIP soit plus d=E9velopp=E9. Ca me semble plus int=E9ressant que
des fonctionnalit=E9s de carnet d'adresse.
Manolo
En réponse à manolobimbo <manolobimbo@manolobimbo.com>:
Salut,
Dans le meme genre d'idée
le calendrier est bien utile,
mais plus que la possibilité de modifier la date de publication
d'un article apres l'ecriture de celui ci,
l'acces à la création d'un nouvel article ou breve par le calendrier
serait quelque chose de sympa
ARNO* wrote:
Les onglets permettraient de découper certaines pages de l'interface
privée, sans pour autant nuire à l'unicité de cette page. Par
exemple, la page "auteur" devient très chargée en mode admin; on
pourrait sans difficulté séparer la liste des articles, la
présentation de l'auteur, les données de connexion, le réglage de la
messagerie interne, selon un système d'onglets.
Il y a mieux à mon avis : pouvoir déplier/replier certains éléments
de l'interface (comme on peut déplier l'arborescence dans "tout le
site"). Du coup, l'affichage par défaut serait beaucoup plus concis,
mais on pourrait aussi avoir tout sous les yeux à la fois si on en
a envie (logos, mots-clés, options de pétition, etc.).
Les onglets ne sont pas aussi bien car ils fragmentent l'interface
et détruisent la vue d'ensemble qu'on peut avoir d'un objet (article...).
a+
Hello,
Pour préciser :
Le soft "visiteurs" qui fait le comptage des visites, avec un tableau
d'affichage très complet, fait un excellent complément à SPIP quand
on n'a pas d'autre outil de comptage. C'est vraiment pas mal.
Je suis allé voir le soft en question. Alors :
- ça nécessite la librairie GD (pas installée partout, et plusieurs
versions incompatibles entre elles)
- pas d'install "propre" : il faut envoyer des requêtes mysql à la
main, et faire la config dans un include php
- la base de données, c'est n'importe quoi. une entrée différente
est stockée à chaque visite, et la table principale n'est pas optimisée
en taille. pour un site faisant 2000 visites par jour, compter 1.2 Mo
de données en plus par jour. Les archives de la base n'étant pas
automatiques, en ne faisant pas gaffe il est normal qu'on se retrouve
dans la situation de www.minirezo.net : un INSERT à chaque nouvelle
visite (plus deux SELECT même s'il ne s'agit pas d'une nouvelle visite),
sur une table de 180 Mo, le tout avec seulement 32 ou 64 Mo de RAM
dans la machine, bonjour la rapidité
- toujours niveau rapidité, au lieu d'utiliser le REMOTE_HOST fourni
par Apache, ça le recalcule avec un gethostbyaddr() : complètement
idiot (de plus, Apache a certainement un cache interne pour éviter
d'aller faire des requêtes DNS à chaque fois, tandis que les Visiteurs...)
- sémantiquement, c'est assez peu intéressant : une visite n'est pas
définie par une durée maximale entre deux requêtes (genre une heure),
mais par le nombre d'autres visites depuis la dernière requête (réglé
par défaut à 50). Non seulement il y a un biais mais il dépend de la
fréquentation du site : sur un site beaucoup visité, les résultats
seront proches de ceux renvoyés par un Webalizer-like, mais sur un
site peu visité, ce sera beaucoup plus faible (il y a même le risque,
si le site est en majorité visité toujours par les 50 mêmes personnes,
qu'aucune nouvelle visite ne soit comptabilisée !). Plutôt que ce
genre de mesures, il serait encore plus intelligent de compter
directement le nombre de pages vues....
Donc ça ne vaut vraiment pas le coup.
a+