Recherche avancée

Sur d’autres sites (10196)

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

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

  Voici un patch qui traite typo() (celui de Textwheel) et ajoute une fonction extraire_idiome() symétrique à extraire_multi()

  Un des premiers problèmes soulevés, et que la fonction inc_traduire_dist() utilisée ne sait pas retourner/connaître la langue de la chaîne de langue.
  Or, cela permet (pour les multi) de mettre un span indiquant la langue du texte si le texte n’est pas dans la langue désiré au départ.
  En permettant d’inclure des chaînes de langues dans les articles, il semble qu’il faille avoir ce comportement également.

  Effectivement techniquement la fonction actuelle
  1) ne peut retourner que le texte, et pas, par exemple un tableau texte, langue (ça c’est facile à corriger)
  2) utilise différents fallbacks lorsque la langue n’est pas trouvée, ou le module de langue pas trouvé

  • si le module de langue n’existe pas, ça utilise le module de la langue du site, sinon le module de langue ’fr’ (langue par défaut)
  • avec ce module, si la clé de langue n’est pas trouvé, ça va utiliser le module de la langue du site, sinon le module de langue fr (langue par défaut)
    En gros, il y a 2 endroits où il faudrait pouvoir connaître et retourner la langue utilisée, dans i@nc_traduire_dist() et dans @charger_langue()

  Ce premier patch ne gère pas donc ce span de langue.

  D’autre part, peut être que ce comportement d’englober du span de langue doive être débrayable, pour l’utilisation de ce nouveau typo() pour gérer les configurations yaml ou autres, mais je n’en suis pas certain.
  Mes premiers tests de ce patch en tout cas ont montré que sans rien changer d’autre, les plugins saisies, champs_extras semblent fonctionner tout pareil (assez logique vu qu’ils utilisent une version de _T_ou_typo() qui applique typo seulement s’il n’y a pas de multi ou d’idiome…). Toujours est-il que cette nouvelle possibilité ne semble pas casser les plugins existants sur lesquels justement cela pourrait avoir un impact, donc c’est déjà une bonne chose.

• Nomenclature #4626 : Renommer le menu "Squelettes"

  1er mai 2021, par RastaPopoulos ♥

  Merci b_b, voici donc la liste seule triée alpha :

  acs adaptive_images campagnes champs_extras_synchronisation chosen cloudzoom comarquage comments compositions court-circuit dublin_core elements eva-web-bonus eva-web-habillage eva-web-install eva-web-mentions exclure_secteur fontawesome5 forkawesome kaye links mathjax mediaspip_player menu_langues_liens menus noizetier picto player porte_plume_enluminures_typographiques rainette recherche_mots_cles refbase saisies select2 seminaire seo sjcycle skeleditor slick sociaux spip_visuels squelettes_par_mots_cle switcher timecircles tooltip videos w3css xiti xray zinit

  des aspects aussi bien esthétiques que fonctionnels

  C’est un point qui me semble très important : ce menu ne sera jamais que pour l’apparence graphique, il y a aussi du fonctionnel mais qui a un rapport quand même avec l’affichage de la page sans que ce soit de l’éditorial. Par ex Compositions ou Noizetier ou Menus permettent de définir quoi afficher à certains endroits des pages, mais ce n’est pas de l’éditorial, c’est de la mise en page et de la config de navigation.

  que des métas dans le header que de la redirection que des outils de dev/débug que etc

  @nico justement, comme dit dans le texte de départ, il est très clair que parfois ce menu n’a strictement aucun sens quelque soit son nom :D car des gens y ont aussi mis tout et n’importe quoi.

  Il est donc de même très clair que certains plugins doivent se barrer ailleurs, c’est d’ailleurs ce que qu’a dit b_b aussi. Certains plugins devraient aller dans Configuration ou autre.

  Suivant la liste je vais essayer de faire une typologie, yen a pas tant que ça, et on va vite voir les quelques trucs à déplacer.

  L’idée c’est qu’il ne reste à peu près que des choses : styles graphiques + mise en page + navigation, en gros.

• Anomalie #4516 (Nouveau) : Fatal error en php 8.0

  9 juillet 2020, par Franck D

  Hello, :)

  Windows 10 (1909)
  Firefox 78.0.2
  Easyphp
  Apache 2.4.43 x64
  PHP 8.0.0 alpha1 x64
  MySQL 8.0.20 x64
  PhpMyAdmin 5.0.2

  memory_limit 512M
  post_max_size 130M
  upload_max_filesize 64M
  max_execution_time 300
  max_input_time -1

  Comme php 8.0 sort le 26 novembre, https://wiki.php.net/todo/php80 et que spip 3.4 ne sortira sans doute pas avant 2022... Je commence à faire des tests avec php 8 (plus c’est tôt mieux c’est) histoire de voir si cela posera de gros problèmes avec spip 3.3 !

  Si je lance spip_loader version 3.0.9, j’ai une page blanche avec :
  Fatal error : Uncaught Error : Call to undefined function get_magic_quotes_gpc() in C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\config\ecran_securite.php:350 Stack trace : #0 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\ecrire\inc_version.php(130) : include() #1 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\spip.php(17) : include_once(’C :\Program File...’) #2 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\index.php(3) : include(’C :\Program File...’) #3 main thrown in C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\config\ecran_securite.php on line 350

  Je monte la priorité à "haut" pour voir, si cela ne serait pas possible pour spip 3.3.0, mais c’est discutable...