Recherche avancée

Sur d’autres sites (5788)

• Evolution #3173 (Nouveau) : Faciliter la lecture/écriture d’un modèle pour rédacteur

  26 février 2014, par Fabrice Véronneau

  Soit un modele du type qui se retrouve donc sous la forme /modeles/truc_machin
  Soit différentes variables ajoutée histoire de compliquer un peu les choses, exemple etc
  Soit un rédacteur qui rédige (oui hein) donc en arial dans l’interface, on se retrouve avec un fourbi illisible du genre :
  

  On a la possibilité d’écrire comme ça :
  

  
  Chouette c’est beau, nickel, sauf que ça fonctionne pas avec |machin, avec les variables, oui, mais pas la première.

  Je propose donc d’ajouter un petit trim() pour ça dans le fichier assembler.php :
  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L436

      $soustype = strtolower($soustype) ;
  

  
  Deviendrait
  

      $soustype = strtolower(trim($soustype)) ;
  

  Bon chez moi ca semble fonctionner, mais peut-être ça casse quelque chose chez d’autres, je sais pas.

• Evolution #3758 : Redirection des urls propres vers propres+.html

  23 mars 2016, par RastaPopoulos ♥

  Je viens d’avoir le signalement de ce bug (qui fait en fait des contenus dupliqués, puisque les adresses sont reconnues comme plusieurs différentes) mais pour une autre option de décoration que les "terminaisons".

  Moi c’est pour le choix "minuscule" ou "garder la casse". Quelque soit le choix, tant que les lettres sont les mêmes SPIP reconnait le contenu quand même (la reconnaissance est case-insensitive) MAIS il laisse ensuite sur la même page !

  Alors que si dans la config on a choisit "tout en minuscule", il faudrait vraiment que SPIP redirige vers l’adresse principale réelle en minuscule.

  Et on peut extrapoler de nos deux premiers cas, que cela vaut aussi pour toutes les autres décorations, options, etc !

  En effet, si avec les define() PHP, on a choisit explicitement que les rubriques devaient être générées comme ça : "/ marubrique ", alors si quelqu’un tombe sur l’URL "/marubrique", ça reconnait l’objet SPIP, ça affiche le bon contenu mais ça DOIT rediriger vers l’URL avec les décorations demandées. Sinon c’est reconnu comme deux URL différents pour le même contenu. :(

  Du coup, vu que ce n’est pas juste qu’une histoire de terminaison, je ne suis pas certain que ça puisse se résoudre uniquement dans le HTACESS. Car à priori faut que ça passe dans des fonctions de SPIP pour tester et comparer si c’est vraiment la "forme principale" demandée ou pas.

• Evolution #3897 (Nouveau) : Traduction des configurations (yaml, xml, json) et certains formulaire...

  6 février 2017, par marcimat ☺☮☯♫

  Je remets le texte d’un mail envoyé sur spip-devel (comme il n’y a plus de liens gmane pour les voir), sur le sujet parlant de la fonction _T_ou_typo() qui permet de pouvoir traiter des chaînes contenant

  • soit "du texte"
  • soit une "<:chaine_de_langue:>"
  • soit des "<multi>...</multi>"

  La fonction _T_ou_typo() a comme usage principal d’appliquer la fonction typo() sur le texte qui lui est envoyé, ou récursivement sur chaque valeur si un tableau lui est donné.
  Et, si un des textes est de la forme <:cle_de_langue:> ou <:module:cle_de_langue:> (une forme simple de l’écriture de chaîne de langue dans les squelettes donc), alors c’est la valeur de traduction de cette chaîne de langue qui est retourné.

  Autrement dit :
  

  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo("<:module:bonjour :>") == "Coucou" (avec le fichier de langue qui va bien quand même)
  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo(["Coucou", "<:module:bonjour :>", "Coucou"]) == ["Coucou", "Coucou", "Coucou"]
  

  Cette intégration pose plusieurs questions sur l’usage / le besoin d’origine et sur la réponse apportée.

  L’usage et solution actuelle¶

  Le besoin est de permettre dans des fichiers de configuration (yaml, xml, json) de certains plugins, ou dans des options de configuration de certains plugins directement dans l’interface privée de SPIP (Menus, Formidable, Champs Extras, ...), de pouvoir indiquer soit un texte quelconque, soit de se référer à une chaîne de langue quelque part.

  Par exemple, dans une déclaration .yaml d’une saisie, on peut trouver : label: '<:saisies:option_groupe_description:>'. On pourrait utiliser pour des saisies spécifiques à un site label: 'Description' si on sait que le site n’est pas multilingue par exemple.

  La difficulté d’utiliser directement le code de langue (ie : label: 'saisies:option_groupe_description'" qui paraît pourtant plus simple) est qu’il est impossible de discriminer les cas où on écrirait un code de langue, des cas où c’est réellement le texte voulu, par exemple avec "label: 'todo'", qui si on utilise le code de langue retournerait ’à venir’ (dans spip_fr.php), alors que ce n’était pas forcément ce qui serait souhaité.

  D’où donc l’apparition de cette écriture <:truc:muche:> pour les textes de configuration, écriture connue déjà dans les squelettes SPIP, avec les nuances qu’on parle bien ici d’une syntaxe simplifiée.
  On ne peut pas écrire label: '<:module:nb_elephants{nb=5}:>' par exemple.

  Proposition¶

  Il me semble qu’on pourrait voir la chose autrement, en considérant que toute présence d’un idiome doit être transformé par la fonction typo().
  La fonction typo() traite déjà en fait le cas des polyglottes <multi>...</multi> que l’on peut écrire à la fois dans les squelettes SPIP et à la fois dans le texte d’un article.
  Il suffirait d’ajouter la gestion de l’idiome <:module:cle:> également. Ainsi typo("<:module:bonjour:>") retournerait "Coucou" en allant piocher la chaîne de langue correspondante.

  La conséquence est que ça permettrait plus de possibilités que le besoin d’origine (on pourrait mettre des chaines de langue dans les textes d’articles par exemple)
  (je ne dis pas que ça serait recommandé non plus, mais dans certains cas ça serait pratique !), tout en répondant au problème avec les configurations de type .yaml ou d’autres déclarations multilingues : il leur suffirait d’appliquer typo() sans autre question, du moins en théorie.