{"partition": "head_middle", "source_domain": "linuxfr.org", "digest": "sha1:AW5Y5GSUQFVPH3X5UIQDB4PJSC6II6BC", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00046.parquet"}
Communauté Appel à traduction de SPIP
Posté par Benitron le 20/01/13 à 18:06. Édité par Nÿco et Xavier Claude. Modéré par Xavier Claude.
20jan.2013
Vous connaissez SPIP ? SPIP est un CMS sous licence libre permettant la création de site internet avec de nombreux ajouts de fonctionnalités.
SPIP est un système de publication pour l’Internet qui s’attache particulièrement au fonctionnement collectif, au multilinguisme et à la facilité d’emploi. C’est un logiciel libre, distribué sous la licence GNU/GPL. Il peut ainsi être utilisé pour tout site Internet, qu’il soit associatif ou institutionnel, personnel ou marchand.
SPIP est développé (programmé, documenté, traduit, etc.) et utilisé par une communauté de personnes que chacun est invité à rejoindre (ou simplement à contacter) sur différents sites Web, listes de discussion par e-mail et rencontres (les fameux « Apéros-SPIP »).
Depuis 2004, SPIP est multilingue. Pour aider cet outil pratique et très utilisé en France, à sortir un peu plus de l’hexagone, un site de traduction en ligne à été mis en place
Alors, si vous souhaitez participer et traduire le site dans d'autres langues. Rendez-vous sur le site ! Un tutoriel vidéo est accessible, afin de voir comment le site fonctionne (surtout pour montrer que c'est très simple).
Traduire SPIP
(80 clics)
SPIP.net
(155 clics)
Plus urgent que la traduction ?
Posté par Gauthier le 22/01/13 à 06:57.
SPIP est un produit incontournable auprès du corps enseignant français et certainement francophone. Depuis plusieurs années nous (informaticiens) essayons t'en bien que mal de proposer une solution d'hébergement mutualiser. Or visiblement la mutualisation du moteur SPIP n'est pas une priorité pour ces développeurs, contrairement à des projets comme Wordpress qui est lui pensé nativement dans ce mode.
Je trouve vraiment ça dommage, je ne parle même pas des divers extensions pourtant bien pensé (Evaweb, SarkaSpip …).
Ce n'est pas aux enseignants à assurer l'installation, les mises à jour de l'outil. Je pense qu'il est préférable qu'il se concentre sur le contenu, qui correspond plus à leur savoir faire.
Je profite donc de cet article pour interpeller les auteurs de cet outils. Merci.
Re: Plus urgent que la traduction ?
Posté par azerttyu (page perso) le 22/01/13 à 07:40.
La mutualisation de spip est tout à fait possible. Par exemple si on utilise le paquet Debian, le mainteneur assure ces fonctionnalités. Certaines administrations ont déployé avec succès du SPIP mutualisé, version un peu spécifique mais cela reste de la mutu.
Enfin je connais au moins 2 entreprises du libre qui travaille avec et pour SPIP et qui fournissent du SPIP mutualisé pour leurs hébergés. Je ne cite pas de nom volontairement, l'idée n'étant pas de faire de la publicité mais juste de dire que la mutu c'est possible :)
Est ce plus urgent ou non, c'est une question à laquelle je ne saurais répondre …
Posté par axel584 le 22/01/13 à 12:30.
Dans le monde du libre, on travaille en priorité sur ce qu'on est capable de faire (ou que l'on a envie de faire)…
Je suis sûr qu'il y a beaucoup d'administrateurs systèmes qui n'aideront pas à la traduction et beaucoup de traducteurs potentiels qui ne pourront pas aider à faire une solution mutualisée…
Spip est mutualisable facilement, depuis au moins 2009.
Contrairement à WP, Spip intègre un système de cache en natif, qui permet d'améliorer la vitesse de rendu des pages.
Enfin, faut pas confondre un script pour blog (WP) et un CMS (Spip).
Oui Spip est mutualisable "facilement" depuis plusieurs années, mais cette mutualisation n'est pas native et donc mal géré par les divers extensions et thèmes. Ça reste du bricolage. Par exemple, le simple fait de proposer un mot de passe unique pour activer tous les sites SPIP est un problème (que nous avons contourner). Mais il reste de nombreux autres problèmes plus bloquants. Si vous désirez une liste plus ou moins complète des problèmes rencontrés par mon équipe, je peux les référencer et les ajouter dans un autre commentaire.
Wordpress n'est en effet pas un CMS, mais beaucoup de nos utilisateurs utilisent SPIP uniquement pour poster des actualités, nous leur proposons donc de migrer sur Wordpress. Pour les autres nous les faisons patienter sur leur SPIP autogéré ou nous leur proposons de migrer sur Plone. Je sais qu'ici Plone n'est pas très bien perçu, car son administration n'est pas évidente. Mais dans le cas d'un hébergement mutualisé comme le notre Plone est une excellente solution, car comme Wordpress il a été pensée dès le départ pour être multi-site.
De mon coté, j'essaie de convaincre mes supérieurs de dédier des ressources pour participer au projet SPIP, car nous avons une dizaine de développeur PHP, mais malheureusement ce n'est pas encore un projet prioritaire. Ils préfèrent que je cherche une solution de remplacement.
Visiblement la communauté francophone de Wordpress n'est pas du même avis concernant la rubrique (CMS/Blog) dans laquelle on place ce logiciel.
Voici ce que l'on trouve sur leur page d'accueil http://www.wordpress-fr.net/ :
WordPress est un système de gestion de contenu (CMS) qui permet de créer et gérer facilement l'ensemble d'un site web ou simplement un blog. Gratuit et libre, WordPress est personnalisable grâce à de nombreux thèmes et plugins.
Posté par jean-jacques (page perso) le 25/01/13 à 15:09.
Concernant Spip, oui il est mutualisable.
Cela se fait par le plugin "mutualisation facile"Plugin ICI et à l'aide de cette documentation
Ensuite il faut bidouiller le fichier "mes_options.php" et c'est parti.
Donc, dans les faits, c'est simple à mettre en œuvre.
Dans la pratique, ça marche oui, mais ça marchouille plus que ça ne fonctionne réellement.
Les données qui sont ""mutualisés"" sont les dossier "IMG", "config", "local" et "tmp".
Comme le souligne Gauthier, on fait face à des problèmes qui, pour ma part, sont un peu des problèmes sorti du fin fond de la pré-histoire.
Le "super-admin", chef de la plateforme entière ne peux pas rentrer dans le panel admin de chaque site Spip…
C'est la première chose qui m'a choqué.
En cas de soucis sur un site, on ne peut pas intervenir directement dans le panel admin, il faut bidouiller le mot de passe ou se créer un utilisateur à chaque fois…
Quand on a fini de digérer le coup du super-admin on se dit :
"Tiens je vais changer le thème et ajouter des plug-ins pour mon nouveau petit sous-site".
Que néni !
Là encore, l'écureuil frappe fort !
Suivant le plugin, cela fonctionne ou non. Car pour l'esprit Spip, c'est le plugin qui s'adapte à l'architecture et non l'inverse.
Suivant si l'on est en mode mutualisé ou non, le même plugin/le même code ne réagit pas pareil !
Pour contre exemple, sous Wordpress qui est un CMS lui aussi (avec WP Super cache pour le cache ;) ), le moteur s'adapte et crée un vrai environnement pour le plugin.
Sous Spip, on se retrouve, en fonction de quelles ressources à besoin le plugin, avec le plugin qui fonctionne ou non.
Après ce deuxième coup, on attaque la partie thème et là on se fait carrément dérober le sac de noisettes sous les yeux !
Toujours le cas du mutu/pas mutu, certains thèmes fonctionnent, d'autres non et d'autres en partie, suivant quelle page on affiche.
(cas classique : la page d'accueil bug, mais quand on va sur le '/ecrire/' il fonctionne).
En creusant un peu, on s'aperçoit qu'en modifiant le plugin mutualisation, en lui ajoutant la création d'un dossier "squelettes", certains thèmes daigne bien fonctionner.
Avec des CMS vraiment multi-site, ou les développeurs pensent multi-site, mange multi-site, vivent multi-site ont à droit à des architectures vraiment bien pensées.
PS : Pour pas se fâcher, je ne parlerai pas de la mise à jour qui doit s'appliquer sur chaque site via un bouton "update" alors que les autres mettent directement le moteur et ses dépendances à jour.
Posté par rpnpif le 25/01/13 à 17:08.
Pour moi, SPIP est le Debian stable du CMS/blog, solide comme un rock, WordPress serait plutôt de l'Ubuntu dernière version, relativement instable mais plein de gadgets. Le problème de ma comparaison, quand même, est que le cœur des SPIP et WordPress sont très différents.
Sinon l'idée de faire participer plus de développeurs en faisant des versions internationales me parait excellente pour… aider à améliorer la mutualisation. Je ne vois pas où est la contradiction puisque traduire et développer font souvent appel à des compétences différentes. Donc, il n'y a pas forcément concurrence de temps disponible. Cela attirera plus de développeurs, CQFD.
Les rédacteurs précédents semblent vouloir dire, (semblent !) : laissez tomber vos préoccupations, occupez-vous de moi d'abord.
Non Ce n'est pas l'idée du tout. L'idée est qu'avant de lancer un CMS à l'international, autant qu'il soit fonctionnel de bout en bout. Et de nos jours, avec la virtualisation de serveurs, de postes de travail et autre, le mode multisite des CMS en général est un atout majeur à son déploiement.
c'est vraiment dommage que tu rencontres tout ces désagréments dans Spip mutualisé.
Il faudrait en parler sur la liste spip-dev ou créer des tickets dans le tracker.
Il se trouve que j'ai toujours DES dossiers squelettes, et je choisis dans la config (fichier mes_options.php) quel(s) squelette(s) sont activés. Du coups, plus de soucis! Ben oui, comment Spip pourraît découvrir que tu veux utiliser tel ou tel dossier de squelettes, heureusement qu'il faut lui dire, parce que mon dossier contient une dizaine de versions, chaque site utilisant l'une ou l'autre.
Pour les plugins, oui, cela doit être activé pour chaque sites, sauf ceux présents dans le dossier "extensions" qui sont activés par défaut pour tous les sites.
Pour chacun de mes sites, j'utilise une coquille vide, avec des rubriques et des articles, ainsi que quelques accès. A l'installation d'un nouveau site, il me suffit d'importer la coquille vide et voilà. Je peux changer le mot de passe ensuite, c'est bien plus sécurisé ainsi. Heureusement qu'il n'y a pas un super admin ayant accès à tout trop facilement. Chacun ses choix
Les plugins dans un mode mutualisés s'installent aussi chacun dans un dossier, pour chaque site, alors je ne comprends pas pourquoi tu as un problème, donne-moi un nom et je l'essaye (en mutu et sans).
Pareil pour les thèmes, comment ont-ils été conçu? en respectant la structure d'un site? Il y a longtemps, j'en avais vu un avec des chemins écrits en dur… Si un thème déconne, ce n'est pas la faute de Spip… mais celle du thème.
Peut être que certains thèmes sont prévus pour ne fonctionner qu'en présence du dossier "squelettes", il faudrait le signaler à ceux qui ont créés ce thème, plutôt que de jeter la pierre à Spip.
Enfin, pour la mise à jour, je créé une copie de la racine (sans le dossier "sites" qui contient tous les sites), j'installe les nouveaux fichiers, puis je fais un lien symbolique du dossier sites. Pour tester, j'ai un aiguilleurs qui va faire pointer pour moi le nouveau dossier Spip à la place de l'ancien, et généralement tout va bien. S'il y a besoin de mettre à jour la base de donnée, je le fais pour quelques sites de tests. C'est normal que ce soit fait au cas par cas… histoire de d'abord tester si tout va bien, surtout au niveau des plugins, on sait jamais. D'autant plus que j'utilise souvent des versions de développement (pour Spip et les plugins). Quand tout va bien, je peux alors mettre à jour l'ancien version.
En terme de charge serveur, je préfère avoir un Spip plutôt qu'un WP même avec le super-cache.
Grégoire
Re: FramaGame ?