SPIP

Principe général

BoOz, cent20, cerdic, dani, Maïeul, mortimer — 2007-05-20T10:22:28Z

Sommaire

Tout le contenu d'un site géré sous SPIP est installé dans une base de données MySQL. Pour présenter ces informations aux visiteurs du site, il faut donc réaliser l'opération qui consiste à lire les informations, à les organiser et à les mettre en page, afin d'afficher une page HTML dans le navigateur Web.

A moins d'utiliser un gestionnaire de contenu avancé comme SPIP, cette opération est assez fastidieuse :
- il faut connaître la programmation PHP et MySQL, et écrire des « routines » relativement complexes ;
- l'intégration de telles routines dans une mise en page HTML élaborée est assez pénible ;
- il faut développer toute une interface pour que les utilisateurs autorisés modifient le contenu de la base de données ;
- il faut prendre en compte des problèmes de performances : le recours systématique à du code MySQL et PHP est gourmand en ressources, ralentit la visite et, dans des cas extrêmes, provoque des plantages du serveur Web.

SPIP propose une solution complète pour contourner ces difficultés :
- la mise en page du site est effectuée au moyen de gabarits au format HTML nommés squelettes, contenant des instructions simplifiées permettant d'indiquer où et comment se placent les informations tirées de la base de données dans la page ;
- un système de cache permet de stocker chaque page et ainsi d'éviter de provoquer des appels à la base de données à chaque visite. Non seulement la charge sur le serveur est réduite, la vitesse très largement accélérée, de plus un site sous SPIP reste consultable même lorsque la base MySQL est plantée ;
- un « espace privé » permettant aux administrateurs et aux rédacteurs de gérer l'ensemble des données du site.

Pour chaque type de page, un squelette

L'intérêt (et la limite) d'un système de publication automatisé, est de définir un gabarit pour, par exemple, tous les articles. On indique dans ce gabarit (le squelette) où viendront se placer, par exemple, le titre, le texte, les liens de navigation... de l'article, et le système fabriquera chaque page individuelle d'article en plaçant automatiquement ces éléments tirés de la base de données, dans la mise en page conçue par la/le webmestre.

Ce système automatisé permet donc une présentation cohérente à l'intérieur d'un site... Et c'est aussi sa limite : il ne permet pas de définir une interface différente pour chaque page isolée (on verra plus loin que SPIP autorise cependant une certaine souplesse).

Lorsque vous installez SPIP, un jeu de squelettes est proposé par défaut. Il se trouve dans le répertoire squelettes-dist/, à la racine de votre site. Dès que vous modifiez ces fichiers pour les adapter à vos besoins, ou si vous voulez installer un autre jeu de squelettes, il convient de créer un répertoire nommé squelettes/ au même niveau. Pour plus de détails sur cette question, lire l'article Où placer ses squelettes .

Lorsqu'un visiteur demande la page http://exemple.org/spip.php?article3437, SPIP va chercher un squelette nommé « article.html ». SPIP se base donc sur l'adresse URL de la page pour déterminer le squelette à utiliser :

L'URL	appellera le squelette
`spip.php?article3437`	`article.html`
`spip.php?rubrique143`	`rubrique.html`
`spip.php?mot12`	`mot.html`
`spip.php?auteur5`	`auteur.html`
`spip.php?site364`	`site.html`

Avec deux cas particuliers :

- L'URL spip.php appelle le squelette sommaire.html. Il s'agit de la page d'accueil du site.
- L'URL spip.php?page=abcd appelle le squelette abcd.html. En d'autres termes, vous pouvez créer des squelettes qui ne sont pas prévus par le système et les nommer comme vous le souhaitez.

Cette syntaxe sert également pour les pages telles que le plan du site ou les résultats de recherche par exemple : spip.php?page=plan, spip.php?page=recherche&recherche=ecureuil.

Lorsque SPIP appelle un squelette, il lui passe un contexte

Par ailleurs, vous aurez constaté que l'URL fournit d'autres éléments que le nom du squelette. Par exemple, dans spip.php?article3437, le numéro de l'article demandé (3437) ; dans spip.php?page=recherche&recherche=ecureuil, le mot recherché (ecureuil).

Il s'agit d'un « contexte », c'est-à-dire, une ou plusieurs « variables d'environnement », que SPIP va fournir au squelette pour qu'elles puissent être utilisées dans la composition de la page. En effet, le squelette article.html a besoin de connaître le numéro de l'article demandé pour rechercher son titre, son texte,... dans la base de données. De même, le squelette recherche.html doit connaitre les mots recherchés par le visiteur pour trouver les enregistrements de la base de données qui contiennent ces termes.

Dans toute URL, les variables d'environnement apparaissent après le « ? ». Lorsqu'il y en a plusieurs, elles sont séparées par des « & ».

Dans l'URL spip.php?page=recherche&recherche=ecureuil, on a donc deux variables : page et recherche, auxquelles on attribue les valeurs respectives « recherche » et « écureuil ».

Dans le cas de spip.php?article3437, SPIP a simplifié l'URL qui correspond en fait à : spip.php?page=article&id_article=3437 (si si, vous pouvez essayer !). On a donc ici aussi deux variables : page a la valeur "article" et id_article a la valeur "3437". Ces variables permettent à SPIP d'utiliser les données de l'article 3437 dans le squelette article.html.

Le principe de fonctionnement du cache, de manière simplifiée

Schéma simplifié du système de cache

SPIP regarde si une page correspondante à l'URL demandée se situe dans le CACHE

Si la page existe, SPIP vérifie qu'elle n'est pas trop ancienne.
1. Si la page est trop ancienne, SPIP la recalcule à partir du squelette et de la base MySQL, puis la stocke dans le CACHE, avant de l'envoyer à l'utilisateur.
2. Si la page est assez récente, SPIP la retourne à l'utilisateur.
Si la page n'existe pas, SPIP la calcule à partir du squelette et de la base MySQL, puis la stocke dans le CACHE, avant de l'envoyer à l'utilisateur.

Lors d'une visite suivante, si le délai entre les deux visites est suffisamment court, c'est donc cette nouvelle page stockée dans /tmp/cache qui est retournée, sans avoir à faire un nouveau calcul à partir de la base de données. En cas de plantage de la base de données, c'est forcément la page en cache qui est retournée, même si elle est « trop âgée ».

Remarque. On voit ici que chaque page du site est mise en cache individuellement, et chaque recalcul est provoqué par les visites du site. Il n'y a pas, en particulier, un recalcul de toutes les pages du site d'un seul coup à échéance régulière (ce genre de « grosse manœuvres » ayant le bon goût de surcharger le serveur et de le faire parfois planter).

Par défaut, si aucune balise #CACHE n'est utilisée en début de squelette, une page est considérée comme trop vieille au bout de 24 heures. [1]

Le fichier .html

Dans SPIP, nous appelons les fichiers .html les squelettes. Ce sont eux qui décrivent l'interface graphique de vos pages.

Ces fichiers sont rédigés directement en HTML, auquel on ajoute des instructions permettant d'indiquer à SPIP où il devra placer les éléments tirés de la base de données (du genre : « placer le titre ici », « indiquer à cet endroit la liste des articles portant sur le même thème »...).

Les instructions de placement des éléments sont rédigées dans un langage spécifique, qui fait l'objet du présent manuel d'utilisation. Ce langage constitue par ailleurs la seule difficulté de SPIP.

« Encore un langage ? » Hé oui, il va vous falloir apprendre un nouveau langage. Il n'est cependant pas très compliqué, et il permet de créer des interfaces complexes très rapidement. Par rapport au couple PHP/MySQL, vous verrez qu'il vous fait gagner un temps fou (surtout : il est beaucoup plus simple). C'est un markup language, c'est-à-dire un langage utilisant des balises similaires à celles du HTML.

Que peut-on mettre dans un fichier .html

Les fichiers .html sont essentiellement des fichiers « texte », complétés d'instructions de placement des éléments de la base de données.

SPIP analyse uniquement les instructions de placement des éléments de la base de données (codées selon le langage spécifique de SPIP) ; il se contrefiche de ce qui est placé dans ce fichier et qui ne correspond pas à ces instructions.

Leur contenu essentiel est donc du HTML. Vous déterminez la mise en page, la version du HTML désiré, etc. Vous pouvez évidemment y inclure des feuilles de style (CSS), mais également du JavaScript, du Flash... en gros : tout ce qu'on place habituellement dans une page Web.

Mais vous pouvez également (tout cela n'est jamais que du texte) créer du XML (par exemple, « backend.html » génère du XML).

Plus original : toutes les pages retournées au visiteur sont tirées du CACHE par une page écrite en PHP. Vous pouvez donc inclure dans vos squelettes des instructions en PHP, elles seront exécutées lors de la visite. Utilisée de manière assez fine, cette possibilité apporte une grande souplesse à SPIP, que vous pouvez ainsi compléter (par exemple ajouter un compteur, etc.), ou même faire évoluer certains éléments de mise en page en fonction des informations tirées de la base de données.

[1] Une fois que vous aurez compris le langage SPIP, vous pourrez modifier ce délai en vous servant de la balise #CACHE.

Les variantes de squelette

dani — 2006-08-21T14:19:00Z

SPIP permet de gérer des variantes de squelettes par rubrique, par branche ou par langue.

Sommaire

Attention version de SPIP

C'est le plugin "squelettes par rubriques" qui permet la personnalisation de l'apparence selon la langue ou la rubrique de l'objet principal concerné. Ce plugin a été intégré à la distribution de base de SPIP jusqu'à la version 3.2.

À partir de SPIP 4.0.0, il faut installer et activer le plugin "squelettes par rubriques" pour en bénéficier.

Des mises en page différentes

Comme mentionné dans le Principe général et dans la documentation sur le multilinguisme, SPIP permet de gérer des variantes des squelettes, par langue, par rubrique ou les deux.

On peut souhaiter, par exemple, que tous les articles d'une rubrique aient une mise en page différente : couleur de fond et taille de texte différentes, informations relatives aux mots clés mises en évidence, etc.

Ou encore que le contenu d'une rubrique donnée soit présenté différemment parce qu'il correspond à un type de données différent : par exemple en listant tous les articles par numéro, y compris leur contenu qui serait court, plutôt que les derniers en dates suivis d'une pagination de tous les articles, avec des liens vers les pages d'articles.

Enfin, on pourra aussi vouloir que l'interface du site soit différente selon la langue de l'article ou de la rubrique.

Les variantes de squelettes sont une solution simple — mais du coup, pas forcément très souple — pour permettre à SPIP de faire cela.

Pour bénéficier de mises en pages différentes, il suffit de réaliser des squelettes différents auxquels on donnera des noms de fichier dont le suffixe indique quand il faut les utiliser :

- article.en.html : squelette pour les articles en langue anglaise,
- rubrique.html et article.html : squelettes par défaut, s'appliquant à toutes les rubriques et articles n'ayant pas de squelette particulier, leur présence est obligatoire dans le même répertoire que les variantes pour que celles-ci soient prises en compte.

- rubrique=22.html : squelette pour la seule rubrique numéro 22,
- rubrique-22.html : squelette pour la rubrique numéro 22 et toutes ses sous-rubriques,
- article=22.html : squelette pour tous les articles de la seule rubrique 22,
- article-22.html : squelette pour tous les articles de la rubrique 22 ainsi que tous ceux de toutes ses sous-rubriques,

Ordre exhaustif des variantes de squelette

Prenons l'exemple des squelettes d'article, avec des valeurs données de langue et de rubriques (mais l'explication ci-dessous reste valable pour les squelettes de rubriques ou les brèves, et bien sûr, quelles que soient les langues et les numéros de rubriques).

Rappelons avant tout que SPIP recherche d'abord le répertoire où il prendra le squelette, comme détaillé dans « Où placer les fichiers de squelettes ? », en cherchant s'il existe un fichier article.html. Il ne faut donc pas créer de variante de squelette (par exemple un fichier article.cs.html) sans créer dans le même répertoire un fichier article.html, au risque de voir notre variante ignorée au profit du squelette générique d'un répertoire de priorité moindre.

Si ce fichier existe, SPIP utilise les fichiers de squelettes selon leur nom en commençant par « les plus précis », avec précédence du rubricage par rapport à la langue. Voici donc l'ordre (par priorité décroissante) dans lequel sont utilisés les fichiers de squelettes selon leur nom :

- article=8.cs.html : si ce fichier existe, il ne s'applique qu'aux articles en langue tchèque de la rubrique numéro 8 (mais pas aux articles contenus par ses sous-rubriques).

- article=8.html : si ce fichier existe, il s'applique aux articles de la rubrique 8 (sauf aux articles concernés par un fichier spécifiant aussi la langue, tel que précédemment).

- article-2.es.html : si ce fichier existe, il s'applique aux articles en espagnol contenus dans la rubrique 2 et ses sous-rubriques. Si la rubrique 8 est une sous-rubrique de la 2 et si les fichiers ci-dessus existent, ils prévaudront.

- article-2.html : si ce fichier existe, il s'applique aux articles contenus dans la rubrique 2 et ses sous-rubriques (sauf aux articles concernés par les fichiers indiqués ci-dessus).

- article.vi.html : si ce fichier existe, il s'applique aux articles en vietnamien, dans toutes les rubriques (sauf aux articles concernés par les fichiers indiqués ci-dessus).

- Enfin, le fichier article.html s'applique à tous les articles qui ne sont pas concernés par les fichiers indiqués ci-dessus. Et, répétons-le, il est nécessaire que ce fichier existe.

Sauvegarder vos données

dani, L'équipe de SPIP, tetue — 2006-07-23T02:40:00Z

Que ce soit pour effectuer une mise à jour de SPIP, ou pour déménager votre site, vous aurez besoin de sauvegarder vos données. Ou simplement, vous êtes une personne précautionneuse et vous vous préoccupez de faire régulièrement des sauvegardes de votre site. C'est bien.

Sommaire

1. D'abord vider le cache

Pour éviter de récupérer un lourd tas de fichiers inutiles, pensez à vider le cache de votre site SPIP avant d'en récupérer les données (surtout si votre site compte beaucoup de visites).

Pour vider le cache de votre site, rendez-vous en tant qu'administrateur, à la page « Configuration du site > Vider le cache » de l'espace privé, sans oublier de cliquer ensuite sur le bouton « Vider le cache » de la page affichée. Le message « Le cache est vide » confirme l'action.

2. Sauvegarder la base de données

La base de données est le cœur de votre système d'information : tout le contenu des articles, des brèves, des rubriques, des auteurs et des forums y est stocké.

Pour réaliser la sauvegarde de votre base de données (c'est-à-dire de l'intégralité de vos documents réalisés avec SPIP), rendez-vous dans la page « Sauvegarder la base » du menu maintenance de l'espace privé

La sauvegarde générée à partir du site est sous le format SQLite : nom_site_aaaammjj.sqlite [1] Une fois le fichier de sauvegarde généré, vous pouvez le récupérer en FTP à l'adresse ./tmp/dump/

Remarque importante : Cette sauvegarde n'est utilisable qu'avec la version de SPIP dans laquelle elle a été effectuée. Pensez à la noter ou à télécharger cette version de SPIP pour pouvoir tout retrouver comme avant en cas de problème. Répétons ce conseil, car c'est une erreur très classique : en cas de mise à jour de SPIP, ne réinstallez pas la base de données à partir de la sauvegarde effectuée précédemment avec un SPIP de version antérieure. Utilisez votre sauvegarde pour déménager votre site vers un SPIP de même version.

Il est aussi possible de faire une sauvegarde de la base sans passer par SPIP en effectuant un export de la base sous phpMyAdmin qui permettra alors des montées en version.

Réaliser une sauvegarde complète

Dans le cadre d'une simple mise à jour de SPIP, il n'est pas nécessaire de sauvegarder l'intégralité de votre site. Par contre, c'est indispensable si vous souhaitez déménager votre site.

Pour avoir une sauvegarde complète de vos données SPIP, il faut également penser à récupérer (par FTP) :

votre dossier /IMG (et ses sous-répertoires), qui contient toutes les images et les documents joints du site
vos squelettes et tout ce que contient votre dossier « squelettes »
vos fichiers personnalisés mes_options.php et mes_fonctions.php
les contributions et les plugins que vous aviez installés et tout ce que contient votre dossier « plugins »
Les fichiers config/clés

Automatiser les sauvegardes

A noter, qu'il existe le plugin Saveauto qui permet de sauvegarder quotidiennement sa base de données.

[1] jusqu'à SPIP 2.1| XML| dump.xml ou dump.xml.gz

Déménagement d'un site SPIP

dani — 2006-06-20T06:25:17Z

Changer l'hébergement d'un site SPIP est presque aussi simple que de l'installer. Viennent s'y ajouter la récupération des données de la base et de la personnalisation du site hors SPIP. Il faut également adapter sa configuration au nouvel hébergement.

Sommaire

Tant que le site reste dans le cadre des recommandations de SPIP, il est aussi facile de transférer un site SPIP que de l'installer.

Avant de commencer

Avant de commencer il faudra aussi s'assurer d'avoir :
- un compte d'administrateur SPIP,
- un client FTP configuré ou configurable,
- les données d'accès FTP à l'ancien et au nouvel hébergements (URL, login et password pour chacun)
- les données d'accès à la base de données de l'ancien et du nouvel hébergements (URL ou localhost ; login et password pour chacun)

Préparer le site

Avertir !

Si votre site a une activité importante, il est préférable d'éviter qu'il y ait des contributions pendant le déménagement du site. SPIP n'a pas de mécanisme spécifique pour cela, mais on peut déjà (et de préférence plusieurs jours avant les opérations) :
- avertir par mail les auteurs, si l'on maintient une liste de ceux-ci,
- mettre un post général dans la messagerie interne de SPIP,
- éventuellement le publier sur le site lui même, par exemple au moyen du plugin "En travaux" ou "alerte urgence".

A priori, il sera toujours possible, une fois le site déménagé, de vérifier dans le calendrier du site et dans le suivi des forums de l'ancien site, s'il y a eu de nouvelles contributions, et recommencer l'exportation et importation, cette fois-ci uniquement les données vers un site déjà préparé. Mais si pendant ce temps il y a eu des contributions dans le nouveau site, vous êtes coincé : il vous faudra choisir entre un jeu de données ou l'autre [1].

Nous n'abordons pas ici les considérations relatives à l'URL du site, en particulier pour savoir si l'on en change ou si l'on a un DNS propre et que l'on fait suivre. Dans le premier cas, il faudra quoi qu'il en soit chercher un moyen de prévenir les utilisateurs. Une bonne mesure est de prévoir un temps de coexistence des deux URLs et de mettre dans la première une page de travaux le temps du déménagement, puis une page de redirection vers le nouveau site dès qu'il est prêt. Dans le deuxième cas si l'on veut conserver son nom de domaine, cela fait intervenir des modifications dans le DNS, ce sur quoi il faut être vigilant, en particulier parce qu'ils y a un temps de propagation des données, qui peut aller jusqu'à 48h ou plus [2].

Vider le cache avant de faire une copie de sauvegarde de la base de données. Cette procédure est expliquée dans cet article : « Sauvegarder vos données ».

Deux manières de générer le nouveau site

On peut distinguer deux manières de déménager le site :
- la première consiste à télécharger vers votre ordinateur la totalité des fichiers de l'ancien hébergement, à les télécharger dans le nouveau, puis à finaliser la configuration SPIP,
- la deuxième consiste à ne récupérer que les données et la personnalisation du site SPIP, installer SPIP dans le nouvel hébergement et remonter les données et la personnalisation.

La première solution est a priori plus simple, mais télécharger toutes les fichiers de SPIP est inutile et peut finir par prendre du temps. La deuxième est plus élégante, et ça peut être l'occasion pour le webmestre de « nettoyer » un peu le code d'un site et ne récupérer que ce qui est utile.

Option 1 : télécharger tous les fichiers

Sur le site initial

vider le cache du site (pour éviter de récupérer trop de fichiers inutiles)
Une sauvegarde de la base (dump).
Avec le client FTP, téléchargez la totalité des fichiers et dossiers

Sur le nouveau site

Placer l'ensemble des fichiers et dossiers précédents.
Effacer le fichier de connection à la base de données config/connect.php pour forcer la réinstallation du site.
Avec un navigateur, visitez le dossier ecrire/ de votre nouvel hébergement et terminez la dernière phase du processus d'installation de SPIP. Dans cette étape, seront nécessaires les codes de connexion à la base de données du nouvel hébergement et il sera éventuellement nécessaire de régler les droits d'accès aux dossiers de SPIP.
Entrez dans l'espace privé avec le compte administrateur que vous venez de créer et allez dans « Configuration du site », « Maintenance du site », et exécutez : « Restaurer la base », et c'est tout.

Il convient de noter que le compte administrateur que l'on crée en configurant SPIP est perdu dès que l'on a importé la base complète. A partir de ce moment là il faut utiliser les comptes de rédacteurs tel qu'ils existaient dans le site initial.

- Il vous restera juste à vérifier et re-configurer quelques informations sur le site, en particulier :

régler le jeu de caractères, si vous l'avez modifié par rapport à la configuration par défaut de SPIP et si vous voyez des zigouigouis sur votre espace public,
définir la (nouvelle) adresse URL du site, le nom du site et l'adresse du webmestre, dans la configuration du site,
vérifier d'autres réglages, tels que l'interactivité ou les langues.

Option 2 : ne récupérer que les données et la personnalisation

Il faudra d'abord identifier avec précision le numéro de version de SPIP [3] installé dans le site que l'on veut déménager.

Sur l'ancien site
Il faut récupérer les données :

La base de données que l'on pourra par exemple exporter depuis phpMyAdmin.
tout le contenu du dossier IMG/, qui contient les images et les documents joints du site.
Depuis SPIP 4.0, il faut aussi récupérer le fichier config/cles.php qui contient les clés cryptographiques du site

Sur le nouveau site

Installer le SPIP "nu" dans la même version
Placer les fichiers de l'ancien site en respectant les positions des dossiers
Importer la base de données de l'ancien site via phpmyadmin du nouveau site
Se connecter à l'espace privé. Aller dans le menu de configuration du site et modifier l'URL principale du site.
Eventuellement vider le cache du site

A partir de ce moment là, vous devriez être en mesure de voir le contenu de votre site avec les squelettes de la distribution de SPIP. Il ne nous reste plus qu'à récupérer la personnalisation du site SPIP.

Il faut récupérer dans l'ancien hébergement et mettre dans le nouveau :
les squelettes : comme expliqué ici, selon la version de SPIP, ils seront :

soit dans le dossier squelettes,
soit dans le dossier personnalisé dont le nom est défini dans mes_options.php
soit dans sous forme de plugin qu'il faudra réactiver dans le menu configuration, section plugins

les filtres personnels et options :

mes_fonctions.php
config/mes_options.php

les plugins et librairies additionnels
placés dans les répertoires /plugins et /lib

Il faudra aussi faire les mêmes ajustements dans l'espace privé que lors du déménagement par copie de tous les fichiers.

Voilà. Si votre site n'a pas d'extensions ou modules exotiques, c'est tout !

Recalculez vos pages et vous devriez voir votre site déménagé.

[1] celles de l'ancien site ou celles du nouveau site, chacune avec les évolutions depuis le premier transfert de données.

[2] C'est hors de portée de cette doc, mais tant sur le sujet de la redirection d'une page, en HTML ou en PHP, comme sur les modifications et propagations de DNS, il y a sur le net de nombreuses documentations de différents niveaux.

[3] Le numéro de version de SPIP est indiqué dans toutes les pages de l'espace privé, en bas à droite. Et toutes les versions de SPIP sont disponibles dans les archives.

Traduction des images

dani, tetue — 2003-12-13T14:43:48Z

Sommaire

Utiliser les mêmes fichiers image

Idéalement, on ré-utilisera le même fichier image que dans l'article d'origine. Par exemple, pour la traduction de l'article 3336, les images seront conservées telles qu'elles, c'est-à-dire appelées avec les mêmes raccourcis () que dans l'article d'origine. Pour qu'elles soient ainsi utilisables dans toutes les langues, on ne leur attribue ni titre, ni description.

Traduire le texte des images

Autant que possible, on évitera de créer des images contenant du texte. Si une explication textuelle est nécessaire, mieux vaut la placer dans les champs prévus (« titre » et « description ») de façon à faciliter les traductions. Ainsi un schéma nécessitant des explications sera plus aisé à traduire s'il n'affiche que des numéros, et que les explications correspondant à ces numéros sont reportées dans le champ de description : on fait alors une copie de l'image pour en traduire le titre et la description directement dans l'espace privé, sans qu'il soit nécessaire de faire appel à un logiciel de retouche d'images.

Cependant, il est parfois nécessaire de « traduire » certaines images, lorsqu'elles contiennent du texte. Pour traduire les textes sur des images de la documentation de SPIP, il faut utiliser un logiciel de retouche d'images.

Esquema simplificado del sistema de caché

Par exemple, le document ci-dessus a été réalisé avec Fireworks à partir de l'image en français (de l'article Principe général), où les textes sont traduits en espagnol (pour l'article Principio general). Vous pouvez reprendre ce document pour en faire plus rapidement une traduction vers une autre langue.

Des captures d'écran dans la bonne langue

De nombreuses illustrations de la documentation sont des captures d'écran de l'espace privé de SPIP. Lorsque le texte y est lisible, mieux vaut réaliser une nouvelle capture d'écran dans la même langue que celle de l'article qu'elle illustre, afin de faciliter la compréhension.

Ainsi la capture d'écran ci-dessus est utilisée dans l'article 3049 (en langue arabe), pour remplacer avantageusement celle de l'article 3024 (en langue française).