Hello,
- Quand tu es destinataire d'un message, tu peux d'un clic te
supprimer de la "conversation" (tu n'es plus dans les destinataires,
c'est tout).
- Quand tu es l'expéditeur (et que le message est déjà envoyé), tu ne
peux plus d'exclure du message tant qu'il y a encore des
destinataires (quand tous les destinataires se sont exclus, là tu
peux le sucrer).
Oui mais l'idée c'est de pouvoir gérer correctement la liste des
messages quand il commence à y en avoir plusieurs dizaines. i.e.
pouvoir réellement ne plus voir les messages qui ne nous intéressent
plus.
- L'utilisation des liens à côté des noms rend l'interface
ultra-simplissime de chez simplissime. Tu vois un nom et tu cliques,
et t'as plus qu'à rédiger ton message. A l'inverse, si tu ouvres un
page sans destinataire, il faut traiter ça comme de véritables mails,
bien penser à ajouter le destinataire,
On peut donner le choix entre les deux possibilités, non ? Soit
cliquer sur le machin vert n'importe où, soit composer le truc
directement sur la page de messagerie. Ce que je veux dire, c'est
qu'il est plus logique et immédiat de pouvoir composer depuis la
messagerie que depuis la liste "rédacteurs" (qui est de plus pas
instantanée s'il y a beaucoup de rédacteurs).
Donc: je
ne l'utilise vraiment ni comme le mail, ni comme un chat.
Tu pourrais parfaitement utiliser le mail de cette façon.
Que tu prennes des habitudes différentes avec les deux outils
est une chose, cependant l'outil lui-même est bien redondant
avec le mail : rien ne t'interdit d'avoir une conversation
fournie et réactive par mail.
Bon, la
messagerie n'est pas complète, mais c'est tout de même ce qu'il faut
aussi prévoir: possibilité d'organiser des discussions entre admins,
des forums de gestion éditoriale du site, dialogues entre tous les
rédacteurs...
Ouhla, heu, t'as l'intention d'ajouter tout ça ?
(Je suppose qu'il est illusoire d'espérer crypter les messages dans
la base de données?)
Oui ;))
- pendant un délais que _nous_ fixons arbitrairement (par exemple 10
minutes - grosso modo le temps qu'on passe habituellement sur le
formulaire de l'article sans le valider), les autres utilisateurs qui
arriveraient sur la page de cet article seraient prévenus que c'est
en travaux (par exemple, le logo "modifier cet article" serait
accompagné d'un petit cadenas).
Mmmmh. Je ne suis pas sûr qu'un délai arbitraire puisse être très
pertinent, et ça peut être perturbant de façon inutile. D'autre part,
quelqu'un qui travaille hors ligne aura envie de verrouiller l'article
bien avant de cliquer sur "modifier" pour répercuter les ajouts qu'il
aura faits dans son éditeur de texte.
- j'ai pas testé, mais d'après ce que le code de inc-calcul, il me
semble qu'on ne peut pas faire de sélection du genre
{id_article<>23}. Non?
Non, faudra que j'ajoute.
Personnellement, je crois que le site multilingue, si on veut faire
bien, est indissociable de la localisation de SPIP. En effet, ça ne
concerne pas que l'affichage d'un petit drapeau (je plaisante), d'un
charset... Ca implique rapidement la traduction des dates, la
modification de la typo... et du coup ça revient à fabriquer des
"localisations" pour chaque langue (des localisations très réduites,
mais où l'on commence déjà à traduire le nom des mois et des jours de
la semaine...).
Oui, enfin c'est deux choses différentes : internationalisation
d'un site et internationalisation de SPIP lui-même. Le coup des
dates, c'est assez accessoire, en tout cas de façon exhaustive :
on peut faire anglais et français, et rester en chiffres (20-12-1998)
pour les autres. Heu, quant à la typo, oui, faut juste espérer que
ça aille plus vite à fignoler que la typo française 
Ce que j'appelle "Headers corrects" c'est quelque chose qui 1) permet de
trier tout ce qui provient d'un site (n'importe quel entete de type X-SPIP:
votre spip, discussion numero tant, etc.) et 2) comporte des champs
Message-Id: et In-Reply-To: cohérents, qui permettent à mon système de mail
de m'afficher l'arborescence de la discussion.
Franchement, pour moi, le seul intérêt de la messagerie interne
de SPIP peut justement être de communiquer hors mail (pour diverses
raisons : meilleur cloisonnement, messages plus éphémères...). Si
c'est pour fournir une passerelle et transformer SPIP en client mail
(encore des tas de lignes de code en plus ;-)), bofffff.....
Donc forwarder des notifications, pourquoi pas, mais commencer
à se faire chier à créer les headers de façon à ce que l'arborescence
soit gérée convenablement ! (de plus, QUI utilise un client mail
en mode arborescence ? jamais vu personne, personnellement....)
D'autre part si la messagerie ne te plaît pas tu peux la désactiver
pour toi-même, donc dans ce cas ça force les autres à te contacter
autrement.
Sur miel, qui est une machine rapide, une passe sur 1130 rubriques prend
0.60s. S'il y a trois passes, cela peut mener à une grosse seconde. Et quand
un robot-fou passe sur le site, mieux vaut ne pas perdre trop de secondes
Expérience faite, avec un index posé sur le champ statut cela ne va pas plus
vite : puisque presque tous les articles sont de statut 'publie', le calcul
le plus important est probablement DISTINCT. (Pour ce que j'en comprends.)
Bon, si on veut optimiser ça radicalement, la meilleure chose à faire
est peut-être d'ajouter une colonne dans spip_rubriques pour stocker
qu'une rubrique est publique ou non. Ou optimiser le calcul, mais je
ne vois pas trop comment....
Cependant le problème de cacher ce calcul est que ça interfère avec les
articles post-datés (chiant hein ;-)). On dira qu'on ignore cette légère
incohérence potentielle ?
> Sinon il y a une demande qui revient très très souvent : gestion
> d'un site multilingue. Sans aller jusqu'à pouvoir avoir plusieurs
> versions d'un même article, on pourrait régler la langue des articles
Je préférerais avoir un champ "technique" qui pourrait servir à plein de
choses, dont la langue.
oh non oh non.... la langue, c'est une fonctionnalité par défaut, pas
une bidouille hardcodée par le webmaster.....
> - variable lang dans l'URL d'appel ($HTTP_GET_VARS['lang'])
> - si pas, variable lang en cookie ($HTTP_COOKIE_VARS['lang'])
> - si pas, langues acceptées par le navigateur ($HTTP_ACCEPT_LANGUAGE)
Je déteste ces deux dernières propositions : quasi personne ne règle son
navigateur, et souvent il est mal réglé
Heu... Un navigateur est réglé pour la langue dans laquelle il a été
choisi (français pour un navigateur français, etc.). De plus c'est
une proposition par défaut, prise en compte sur de nombreux sites
(cf. debian), et que le webmestre peut remplacer par une variable
d'URL ou un cookie s'il a envie de proposer un choix explicite.
Mieux vaut proposer ça que de ne rien proposer, non ?
a+
Antoine.
