Voilà, j'ai codé la notation <<toto>> dans le CVS et dans les squelettes de spip.net : cliquez sur "télécharger le squelette de cette page" pour voir à
quoi ça ressemble.
* * *
<<toto>>, par défaut, va chercher dans le module nommé nommé 'local'
(ecrire/lang/local_xx.php3) : c'est donc l'équivalent de <<local:toto>>, ou
encore de [(#LANG|traduire{"local:toto"})]
Par ailleurs, le module qu'on va pouvoir construire collectivement pourrait
s'appeler 'public', ce qui ferait que :
<<toto>> va cherche la chaine toto dans le module 'local' (celui qui sera
éditable directement, par les admins, depuis l'espace privé).
<<public:download>> va chercher la chaîne 'publique' qui s'appelle
'download'.
<<spip:login>> va chercher la chaîne 'login' du module 'spip' (qui n'est
donc pas le module par défaut depuis les squelettes).
'local' est maintenu en local ; 'public' est maintenu collectivement et
intègre les chaînes les plus intéressantes des fichiers 'local' que chacun
édite dans son coin.
Ca me paraît assez intuitif, en tous cas cohérent. Non ?
<<toto>>, par défaut, va chercher dans le module nommé nommé 'local'
(ecrire/lang/local_xx.php3) : c'est donc l'équivalent de <<local:toto>>, ou
encore de [(#LANG|traduire{"local:toto"})]
Par ailleurs, le module qu'on va pouvoir construire collectivement pourrait
s'appeler 'public', ce qui ferait que :
<<toto>> va cherche la chaine toto dans le module 'local' (celui qui sera
éditable directement, par les admins, depuis l'espace privé).
<<public:download>> va chercher la chaîne 'publique' qui s'appelle
'download'.
<<spip:login>> va chercher la chaîne 'login' du module 'spip' (qui n'est
donc pas le module par défaut depuis les squelettes).
Je préfère franchement que ça aille chercher dans "public" par défaut,
et que "local" (ou autre) soit laissé aux bidouilleurs.
D'autre part, je trouve que laisser les admins éditer des chaînes
dans l'espace privé serait très incohérent par rapport à la séparation
classique des rôles : les squelettes et l'espace public pour le
webmaster, la ligne éditoriale pour les admins, le contenu pour les
rédacteurs. On aurait un élément de l'espace public qui serait
éditable directement par les admins, un peu comme si la config du
site avait un pop-up pour choisir la couleur des squelettes et
le nombre de colonnes du site public.
Il vaudrait mieux centraliser un certain nombre de chaînes
courantes dans "public" et éventuellement fournir un outil
séparé pour les autres chaînes. Ou alors définir un espace
"webmestre" dans l'espace public (qui peut servir à d'autres
choses aussi) mais je propose que ce soit post-1.7
Ah oui, heu, il y a un problème avec les <<code>> : ça ne
s'affiche pas dans le HTML avec certains brouteurs, par
exemple Galeon.
(autre limitation : comment faire pour appliquer des
filtres ? y a-t-il un filtre par défaut ?)
Ben ouais, il me semblait que <:toto:> était meilleur candidat.
Ou alors le code était déjà bien avancé avec << >> ?
Ca n'est rien à changer, pas de panique
Par contre, pour répondre à Antoine, je préfère 'local' par défaut, et
'public' si on le demande ; ça me paraît plus judicieux que l'inverse, car
'public' ne sera composé que de propositions venant de la communauté, alors
que 'local' est vraiment ce qu'en fait le webmestre.
Par ailleurs le fait que l'outil d'édition du module 'local' soit
accessibles aux admins (y compris restreints, et pas au seul webmestre) est
essentiel : le webmestre ne sait pas traduire dans 10 langues
Dans ce cas, est-ce réellement la meilleure solution ?
Je suis 100% d'accord avec Antoine. SPIP est très pratique car il isole
clairement les trois métiers nécessaires à la réalisation d'un site WEB.
Si tu mélange un peu de l'un et de l'autre, tu introduit confusion et
usine à gaz.
Mais qu'est-ce que tout le monde veut dire exactement par " Uzine à gaz "?
Est-ce une expression qui n'a pas traversé l'atlantique ou juste un
néologisme propre à la communauté SPIP?
> Mais qu'est-ce que tout le monde veut dire exactement par « Uzine à gaz »?
^
> Est-ce une expression qui n'a pas traversé l'atlantique ou juste un
> néologisme propre à la communauté SPIP?
Ce sont des logiciels avec plein de fonctions inutiles, ce qui les rend
gros et lourds Les exemples communément utilisés comprennent Windows ou
Emacs.
Je pense qu'il voulait parler d'une coquille insidieusement glissée dans
mon texte
et est-ce qu'il esy prevu un ''local_path"
le fonctionnement que tu decris y ressemble, mais pas tout a fait.
moi je serai pour qq chose comme ca :
<<chaine_a_traduire>> (exploite le local_path, par defaut, local:public)
- si chaine non trouvée dans le premier, va voir dans le second domaine.
<<chemin:autre_chaine>> (exploite seulement le chemin, et strictement ce chemin)
question vocabulaire :
- local : dans le sens de localisation (mode unix)
- domaine : les chemins d'acces aux espaces de localisation,
- un public, construit par l'ensemble des acteurs de SPIP
- un privé : géré localement par les admistrateurs de sites
Je pense que <:toto:> posera les mêmes problèmes puisque
ça ressemble à un tag HTML aussi. Cela risque en plus de
compliquer la vie de ceux qui éditent leurs squelettes
avec Dreamweaver &co.
De plus ce serait bien qu'on puisse y appliquer des filtres,
comme pour les champs. Mettons que je veuille afficher la
traduction de "Télécharger" en survol d'une icone, j'ai
intérêt à appliquer le filtre "attibut_html".
Du coup je verrais bien une syntaxe similaire à celle des
filtres :
%TELECHARGER
pour afficher la chaîne "download" (majuscules
pour des questions de lisibilité).
[ ... (%TELECHARGER|attribut_html) ... ]
pour appliquer un filtre en plus.
De plus ce serait bien qu'on puisse y appliquer des filtres,
comme pour les champs. Mettons que je veuille afficher la
traduction de "Télécharger" en survol d'une icone, j'ai
intérêt à appliquer le filtre "attibut_html".
pas con
Du coup je verrais bien une syntaxe similaire à celle des
filtres :
%TELECHARGER
pour afficher la chaîne "download" (majuscules
pour des questions de lisibilité).
[ ... (%TELECHARGER|attribut_html) ... ]
pour appliquer un filtre en plus.
Il faut voir : attention à ne pas casser des squelettes existants.
> Par ailleurs le fait que l'outil d'édition du module 'local' soit
> accessibles aux admins (y compris restreints, et pas au seul webmestre)
> est essentiel : le webmestre ne sait pas traduire dans 10 langues
Dans ce cas, est-ce réellement la meilleure solution ?
Je suis 100% d'accord avec Antoine. SPIP est très pratique car il isole
clairement les trois métiers nécessaires à la réalisation d'un site WEB.
Si tu mélange un peu de l'un et de l'autre, tu introduit confusion et
usine à gaz.
Les chaînes de traduction font partie du contenu du site plus que de sa
structure (tu ne vas pas tout casser si tu changes un mot dans le fichier de
langues 'local'). Donc ça reste cohérent avec ce qui existe : je ne vois pas
le problème : si un admin ajoute une chaîne, qui n'est pas appelée dans les
squelettes, l'impact est nul ; s'il supprime une chaîne, la chaîne ne
s'affiche plus et c'est tout (comme s'il dépubliait un article).
> comme pour les champs. Mettons que je veuille afficher la
> traduction de "Télécharger" en survol d'une icone, j'ai
> intérêt à appliquer le filtre "attibut_html".
pas con
Maintenant la notation <<module:code|filtre1|filtre2{"toto"}|...>>
fonctionne ; par contre, je pense que <<...>> est mieux que #XXXXXXXX ou
%XXXXXXX, parce que cela permet de définir la chaine plus librement (espace
de nommage séparé de celui des balises SPIP) et que, en général, c'est plus
joli d'avoir un truc qui ouvre et qui ferme.
Certes, le défaut qui fait que ça ne s'affiche pas dans le brouteur est
important ; il faudrait donc trouver mieux, mais qui ressemble. <:toto:>
s'affiche bien, c'est peut-être la solution ?
Par ailleurs je remets 'local' par défaut, car, à mon sens, 'public' ne sera
qu'une proposition, collective mais pas adaptée nécessairement au contenu du
site (donc on va "la chercher dans 'public'", alors que 'local' sera le truc
éditable via le site.
Les exemples communément utilisés comprennent Windows ou
Les exemples communément utilisés comprennent Windows ou