SPIP-Contrib

Toutes les contributions à SPIP

Accueil > Contribs à ranger > Traducteurs pour Boutons texte wanted !

Traducteurs pour Boutons texte wanted !

mercredi 8 novembre 2006

La proposition boutons texte demande des traducteurs.

En interne, le plugin est seulement français ou allemand , la doc allemande arrive bientôt.

Si vous êtes anglais , espagnol ou napolitains :) , vous pouvez contribuer, contactez-moi (toggg) irc , mail , réponse ici ...

Pour l’interne ce sera sur le svn de la zone , pour la doc , ici.

toggg


Voir en ligne : http://www.spip-contrib.net/ecrire/...

36063 discussions

  • 11

    Le plugin insère #DESCRIPTIF et ce descriptif se calcule en fonction des 1res lignes du texte. Dans les squelettes on (je) utilise plutôt #TEXTE qui automatiquement concatène le chapeau + le texte.

    Quand on lit le manuel des balises à propos de #DESCRIPTIF, c’est très éloquent : https://www.spip.net/fr_article3854.html

    Je ne me sers pas de la balise #INTRODUCTION, néanmoins c’est elle qu’on devrait utiliser en fait. https://www.spip.net/fr_article3965.html

    Vaut-il mieux que je crée une variante article.html pour utiliser #INTRODUCTION, ou bien est-ce une amélioration à apporter au plugin ?

    Je ne pense pas être le seul à utiliser chapeau

    • C’est censé utiliser #INTRODUCTION en priorité, et seulement si cette balise ne renvoie rien, on se rabat sur #DESCRIPTIF : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/metasplus/trunk/inclure/metasplus/dist.html#L88

      Si ça n’utilise pas l’introduction, c’est qu’il doit y avoir un souci avec la balise #INFO, à investiguer.

    • Merci de la réponse rapide.

      Sur la rubrique où ça me pose souci, j’ai fait le test en insérant

      • #INTRODUCTION dans le squelette de l’article et la balise me retourne bien le contenu du chapeau suivi du début du texte.
      • #INFO_CHAPOarticle,XXX dans le squelette et la balise me retourne bien le contenu du chapeau

      Quel autre test mener ? Désolé mais je ne suis pas développeur, même si je commence à connaître certains basiques

    • Ah mais attends, c’est comme ça que fonctionne la balise #INTRODUCTION en fait : elle prend en priorité le descriptif, et à défaut le chapeau puis le texte : https://www.spip.net/fr_article3965.html
      Donc pas de bug.

      Si tu souhaites utiliser le chapeau, crée un squelette inclure/metasplus/article.html :

      <BOUCLE_art(ARTICLES){id_article}>
      <INCLURE{fond=inclure/metasplus/dist, desc=#CHAPO|sinon{#INTRODUCTION}} />
      </BOUCLE_art>
    • J’aimerai bien comprendre ce que contient la balise #DESCRIPTIF car la doc spip ne dit rien : https://www.spip.net/fr_article3854.html

    • OK j’ai trouvé ce qu’est le descriptif. Je ne l’ai pas activé.
      Quand je fais le test sur un article de la rubrique incriminée, l’ajout de la balise #INTRODUCTION génère bien le chapeau en 1 et le texte en 2.
      Comment trouver l’erreur ?

    • Effectivement l’aide en ligne est plus bavarde sur l’utilisation de ce champ :

      Le descriptif rapide est utilisé pour la navigation à l’intérieur du site : il permet d’indiquer brièvement, dans les sommaires par exemple, le thème de l’article.

      Ce descriptif est optionnel ; de même, on peut le rédiger de la longueur que l’on veut. Cependant, il a été prévu à l’origine pour des textes très courts (une ou deux phrases), qui figureront dans les listes d’articles (sommaires, listes des articles de tel auteur, tri d’articles par mot-clé, réponses du moteur de recherche, etc.). »

      N’hésite pas à te créer un compte sur spip.net et à proposer une amélioration dans le forum de l’article.

      Après, son utilisation peut changer selon tes besoins éditoriaux et les squelettes utilisés. Mais très souvent, elle sert juste à avoir un « vrai » résumé avec la balise #INTRODUCTION.

    • Quand je fais le test sur un article de la rubrique incriminée, l’ajout de la balise #INTRODUCTION génère bien le chapeau en 1 et le texte en 2.
      Comment trouver l’erreur ?

      Mais quelle erreur ? Sans descriptif oui, #INTRODUCTION prend le chapo et le texte.

    • Avec 11000 articles et 15000 urls, le moindre changement peut avoir un impact casse-c...

      Ma balise meta description que j’utlise depuis... retourne bien le chapeau en 1er et si pas de chapeau, le début du texte

      Si je fais le test sur une page : https://www.tendancehotellerie.fr/articles-breves/communique-de-presse/10967-article/reseaux-sociaux-une-influence-tres-forte-sur-les-voyageurs-d-apres-booking-com, ma méta description [<meta name="description" content="(#INTRODUCTION{150}|textebrut)" />] donne :

      <meta name="description" content="17% des voyageurs du monde entier s’inspirent des vacances de leur influenceur préféré pour organiser leur vacances 7% des sondés avouent avoir déjà (...) " />

      ce qui est mon chapeau

      le plugin METAS+ genère

      <meta name="DC.Description.Abstract" lang="fr" content="Avec la publication des photos de vacances des influenceurs voyage et des applications li&#233;es au tourisme, les voyageurs sont sans cesse connect&#233;s sur les r&#233;seaux afin de trouver de l&#039;inspiration&#8230;" />
      <meta property="og:description" content="Avec la publication des photos de vacances des influenceurs voyage et des applications li&#233;es au tourisme, les voyageurs sont sans cesse connect&#233;s sur les r&#233;seaux afin de trouver de l&#039;inspiration&#8230;" />

      ce qui est mon texte

      S’il y a avait un problème avec mon chapeau, pourquoi ma balise « historique » arrive-t-elle à trouver le chapeau et pas METAS+ ?

    • Pfiou, on va y arriver...
      Donc il y a bien un bug avec #INFO_INTRODUCTION.
      En attendant que ce soit corrigé dans SPIP, il faut utiliser la solution indiquée dans mon message précédent : https://contrib.spip.net/Metas-version-2#comment500043-500036

    • Merciiiii

      Avec spip ya des fois où je tourne bourrique mais là, en effet, je vois qu’on va y arriver :)

      En attendant une prochaine version de spip, je mettrai en place un squelette

      Bon weekend

    Répondre à ce message

  • 4

    Bonjour,

    Comment peut-on contribuer à la traduction du plugin ? C’est sur un dépôt git ?

    Répondre à ce message

  • 2

    Bonjour,
    Je suis très heureux ou presque de pouvoir utiliser ce plugin parce qu’il semble y avoir une incompatibilité avec pdf.js.

    En effet, tous les pdf incrusté dans mes articles pour être directement lus s’affichent désormais sur tous les articles du site avec une hauteur fixe très petite empêchant de voir l’intégralité du document.
     : Un exemple ici

    Quand je désactive CIBLOC tout revient à la normal mais quelle catastrophe pour le bel article publié avec CIBLOC. Pensez-vous pouvoir résoudre ce problème ?
    J’ai bien essayé d’indiquer une hauteur de mon choix au PDF, mais rien ne change...

    En vous remerciant par avance :)

    • Pour éviter ce problème, il convient de supprimer les lignes suivantes dans le fichier cibloc/_config_cibloc/_css/cibloc.css :

      .spip_documents {
        max-width: 100% !important;
        height: auto;
      }
    • La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec le plugin Pdf.js

    Répondre à ce message

  • 3

    Bonjour,
    Encore 1000 mercis pour ce formidable outil.
    Deux petits retours utilisateur :

    1 - pb de redimensionnement
    J’ai rencontre un souci lors du redimensionnement d’une page contenant un formulaire « formidable » selon que celui-ci est inséré dans un bloc multi_colonnes ou un bloc multi_colonnes_sans-marge (voir copie d’écran).
    J’ai corrigé en modifiant la feuille de style (patch sur la copie d’écran). Je ne sais pas si ce patch est le meilleur possible mais il marche. Par contre, il présente peut-être des effets de bord indésirables...


    2 - crayons
    Si on configure les crayons pour que la barre d’outils soit présente, la fenêtre popup permettant de choisir les blocs est toute embrouillée.
    On peut corriger le problème en recopiant dans perso.css les déclarations /*========== cibloc : cibloc_popin_blocs (ne pas modifier) ==============*/ présentes dans cibloc_modal.css
    Je ne sais pas trop où ça se tient, mais est-ce que ça ne serait pas intéressant de faire les modifications pour que l’affichage via les crayons soit propre « out of box » ?

    Encore 1000 mercis (10 000, même !) pour ce chouette outil

    • 1- Redimensionnement du formulaire

      Pour contourner le problème, il convient d’ajouter dans la CSS les lignes suivantes (et non pas recopier celles relatives aux colonnes sans marges) :

      @media (max-width: 959px) {
          .cimulti_colonnes div[class^='col-sm-'] {
              width: 100%;        
          }
      }

      2 - crayons
      La question a déjà été posée et j’ai déjà répondu :
      https://contrib.spip.net/cibloc-mettre-en-forme-le-texte-d-articles-avec-des?debut_comments-list=@497714#comment497714

    • OK pour -1
      Pour crayons, j’avais vu la réponse. Mais je ne sais pas très bien comment la comprendre... Les crayons sont très répandus (et sacrément commodes) et c’est dommage que les blocs ciblocs soient si mal présentés dans la boîte modale à cause d’une petite question de css, non ?
      (mais peut-être n’ai-je pas bien compris)

    • La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec le plugin Formidable.

    Répondre à ce message

  • 10

    Saut de ligne non pris en compte ?
    Dans un article, j’ai inséré un bloc 50% / 50%.
    Les sauts de paragraphe (2 retours « touche entrée ») sont OK mis les sauts de ligne (1 retour « touche entrée ») ne sont pas pris en compte (voir copie d’écran jointe)
    Est-ce qu’il y a quelque chose que je fais mal ou est-ce un bug ?

    SPIP 3.2.1 + dernière version cibloc

    • En laissant une ligne vide entre la balise de début du bloc et le début du texte, est-ce que le problème se produit ?

    • Ah, effectivement avec une ligne vide après [colonne50], les sauts de ligne sont bien respectés

    • La prochaine version du plugin CIBLOC apportera une solution à ce problème.

    • Pouvez vous m’indiquer si le patch ci-joint règle le problème :
      patch

    • Ah, alors c’est super !
       ;-)))

    • Ah, les messages se sont croisés : le « Ah, super » concernait le fait d’un patch à venir.
      Le patch proposé ne résout pas le dysfonctionnement observé ;-((

    • Après avoir copié le fichier du patch (au bon endroit), il est indispensable de vider le cache de SPIP.

    • C’est OK avec ce patch.


      Le cache de SPIP a des fonctionnements qui restent parfais un peu mystérieux : j’avais testé le patch en faisant un « recalcul » de la page. Pourquoi cela n’a-t-il pas donné le même résultat qu’après avoir vidé le cache ? Je pensais que ces deux manip’s étaient équivalentes (au détail près, bien sûr, que le recalcul n’affecte que la page en cours)

    • Cette nouvelle version du patch évite un effet de bord :
      patch

    • La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec un saut de ligne simple (un seul retour « touche entrée »).

    Répondre à ce message

  • 3

    Bonjour,

    Testé avec succès, avec un spip 3.2.3, l’ensemble de plugins :
    documentation, latexwheel, zippeur, documentation2latex, et suivant_precedent

    De petites modifications dans le fichier paquet.xml des plugins suivants ont été nécessaires :

    • documentation :
      1. <necessite nom="zcore" compatibilite="[2.0.6;]" />
    • latexwheel et documentation2latex :
      1. compatibilite="[3.0.0;3.2.*]"
    • remplacer ’Gill Sans" par ’FreeSans’ (p.ex) à la ligne 4 de inclure/preambule.tex fourni par le .zip créé afin que le compliateur xelatex ne butte pas sur une police introuvable sur mon ubuntu
      1. \setsansfont[Scale=MatchLowercase,Mapping=tex-text]{FreeSans}

    Donc, cela semble bien tourner sous spip3.2 :-)
    Je suis ravi
    Merci les développeurs !

    Répondre à ce message

  • Un ticket mal placé sur programmer.spip.net demande :

    Il est mentionné des noms de pipeline erronés me semble-t’il :
    https://contrib.spip.net/Porte-Plume-documentation-technique#Completer-une-barre-d-outil
    il y est écrit :
    porte_plume_barre_outils_pre_charger sert à ajouter des boutons à une barre.
    porte_plume_barre_outils_charger sert à afficher ou masquer certains boutons

    Mais comme le dit quelqu’un en 2016 dans les commentaires
    https://contrib.spip.net/Porte-Plume-documentation-technique#comment485720

    Ce serait plutôt porte_plume_barre_pre_charger et porte_plume_barre_charger

    Répondre à ce message

  • 1

    Pour faire des sous-rubriques en espace public j’ai mis [(#FORMULAIRE_EDITER_RUBRIQUE{oui, #ID_RUBRIQUE, [(#SELF|parametre_url{id_rubrique, #ID_RUBRIQUE})]})] et pour faire afficher la sous-rubrique j’ai mis <BOUCLE_sous_rubriques(RUBRIQUES) {id_parent}{tout} {par num titre}{!par date}> jusque la tout va bien.
    Maintenant si je clique sur le lien de la nouvelle rubrique que je viens de créer, j’obtiens une erreur 404 puisqu’il n’y a pas encore d’articles de créer. Pour palier à cela j’ai mis dans head/rubriques <BOUCLE_rubrique_head(RUBRIQUES) {id_rubrique}{tout}> mais cela ne fonctionne pas. Il y a toujours une erreur 404. Que puis-je faire ?

    • Bonjour,
      je vous conseille de poster cette question sur la liste SPIP, vous aurez beaucoup plus de chance d’avoir une réponse, ou même plusieurs...
      Mais donc c’est possible, à condition de changer l’action du formulaire, pour faire en sorte de donner un statut « publie » à la rubrique dès sa création. Cela se passera dans la fonction traiter du formulaire. Pour ne pas polluer la création générique des rubriques, il faudra certainement dupliquer le formulaire, les deux fichiers html et php, pour le renommer par exemple editer_rubrique_publique, et renommer à l’intérieur les fonctions aussi.... on peut continuer la discussion sur la liste SPIP si vous voulez : https://listes.rezo.net/mailman/listinfo/spip

    Répondre à ce message

  • je voulais poster un petit message de mise a jour.

    nous utilisons cette contributions maintenant depuis presque 2 ans et nous en somme tres content.

    nous servons +- 300,000 pages vue par jour avec une charge server tres faible.

    nous ’push’ons desormais nos fichiers cache vers ’google cloud storage’ (simple et pas cher) et nous indiquons a notre CDN d’aller chercher les fichiers en deux temps, en premier sur le cloud storage et si non disponible (trop recent) sur le server live.

    Ce system isole completement le server du traffic web. Nous avons eu des piques de traffic enorme sans aucune charge de server supplementaire.

    Seul point ennuyeux, le nombre de taches de fonds pour rafraichir le contenu editorial ralenti parfois les mises a jours de certaines pages. Par exemple un article avec beaucoup de mot cles, beaucoups de documents, prend un certain temp a apparaitres sur toutes pages les mots cles.

    Mais au final je pense que le leger delai est moins important que le fait d’etre sur que le site n’ai pas de soucis en cas de pique de traffic et de robots aspirateurs recalcitrant.

    Je suis surpris de ne pas voir de message sur cette contrib. J’espere que d’autres sites a fort traffic s’y interesseront. Nous serions heureux de voir cette contrib utilise et ameliore par d’autres sites.

    Répondre à ce message

  • 10

    Bug avec l’affichage conditionnel d’un champ obligatoire.

    Bonjour.

    J’ignore si c’est lié à Formidable ou à Saisies mais la validation d’un formulaire ne fonctionne plus quand on a un champ obligatoire non affiché (donc non rempli) à cause d’un affichage conditionnel.

    Ça semble se faire sur tout type de champ (je l’ai vu sur des lignes de texte, radios, dates…). Mais, sur les checkbox, obligation + affichage conditionnel demandent carrément de cocher chaque case.

    Voir démo, avec ce YAML :

    id_formulaire: '106'
    identifiant: test_aff_si
    titre: 'Démo bug affichage conditionnel + champ obligatoire'
    descriptif: ''
    css: ''
    message_retour: ''
    saisies:
      - { options: { label: Choisis, explication: 'Fait apparaitre un champ obligatoire différent selon le choix', datas: "choix1|Noix\r\nchoix2|Fruit", obligatoire: on, nom: radio_1 }, identifiant: '@5c6293109cd5f', verifier: {  }, saisie: radio }
      - { options: { label: 'Choix de la noix', datas: "noix1|Noisette\r\nnoix2|Amande", choix_alternatif_label: 'Autre choix', afficher_si: '@radio_1@=="choix1"', obligatoire: on, nom: checkbox_1 }, identifiant: '@5c629355bf095', verifier: {  }, saisie: checkbox }
      - { options: { label: 'Choix du fruit', datas: "choix1|Myrtille\r\nchoix2|Framboise", choix_alternatif_label: 'Autre choix', afficher_si: '@radio_1@=="choix2"', obligatoire: on, nom: checkbox_2 }, identifiant: '@5c6293ee9757f', verifier: {  }, saisie: checkbox }
      - { options: { label: 'Affichage non conditionné', datas: "choix1|Polatouche\r\nchoix2|Tamia", choix_alternatif_label: 'Autre choix', obligatoire: on, nom: checkbox_3 }, identifiant: '@5c629530c97d0', verifier: {  }, saisie: checkbox }
    traitements: false
    public: non
    statut: publie
    date_creation: '2019-02-12 10:38:40'
    maj: '2019-02-12 10:44:49'
    apres: valeurs
    url_redirect: ''

    Arrivez-vous à reproduire ça ? Ou est-ce lié à ma config ?

    Merci d’avance et bonne journée.

    (SPIP 3.1.9, Formidable 3.34.9, Saisies pour formulaires 3.13.0)

    • c’est lié à HTML5. Je regarde ce qu’il en est.

    • Saisies 3.13.1 corrige cela. Il sera disponible en zip/par svp peu après midi.

    • Merci beaucoup ! Ça a déjà débloqué une bonne part de nos formulaires.

      Hélas, il reste un problème. Exemple :

      id_formulaire: '113'
      identifiant: complexe_ter
      titre: 'Démo complexe'
      descriptif: ''
      css: ''
      message_retour: ''
      saisies:
        - { options: { label: 'Je choisis', datas: "foo|Foo (bloquant)\r\nbar|Bar", obligatoire: on, nom: radio_12 }, identifiant: '@5b8fcae653a26', verifier: {  }, saisie: radio }
        - { options: { label: Foo, datas: "choix1|Choix 1\r\nchoix2|Choix 2", choix_alternatif_label: 'Autre choix', afficher_si: '@radio_12@=="foo"', obligatoire: on, nom: checkbox_1 }, identifiant: '@5b8fce27509ba', verifier: {  }, saisie: checkbox }
        - { options: { label: Identité, nom: fieldset_1 }, identifiant: '@575572e65e956', saisie: fieldset, saisies: [{ options: { label: Nom, type: text, size: '40', autocomplete: defaut, obligatoire: on, nom: input_2 }, identifiant: '@5755744a4049b', saisie: input }, { options: { label: 'Bar texte', type: text, afficher_si: '@radio_12@=="bar"', size: '40', autocomplete: defaut, obligatoire: on, nom: input_13 }, identifiant: '@5b8fd50fb6d07', verifier: {  }, saisie: input }, { options: { label: 'Foo date', heure_pas: '30', afficher_si: '@radio_12@=="foo"', obligatoire: on, nom: date_2 }, verifier: { type: date, options: { normaliser: datetime } }, identifiant: '@57557733db046', saisie: date }] }
        - { options: { label: 'Foo fieldset', afficher_si: '@radio_12@=="foo"', nom: fieldset_5 }, identifiant: '@575583dd03390', verifier: {  }, saisie: fieldset, saisies: [{ options: { label: Lapin ?, datas: "oui|Oui\r\nrepd|Réponse D", obligatoire: on, nom: radio_9 }, identifiant: '@5755862aa9f3a', verifier: {  }, saisie: radio }] }
      traitements: {  }
      public: non
      statut: publie
      date_creation: '2017-10-31 09:36:49'
      maj: '2019-02-12 14:38:18'
      apres: valeurs
      url_redirect: ''

      Le choix Foo fait apparaitre :
      -  un checkbox obligatoire
      -  un date obligatoire (dans un fieldset toujours affiché)
      -  un fieldset contenant un radio obligatoire.

      Si on choisit Bar, les champs date et radio liés à Foo bloquent la validation, mais pas le champ checkbox. Le problème disparait si on retire le champ radio du fieldset « Foo » (ou si on le remplace par un autre type de champ).

      Ça semble donc être lié à la présence d’un radio dans un fieldset à affichage conditionnel.

      Remarques complémentaires :
      -  Certains types de champs sont indiqués comme bloquants mais pas d’autres (voir pièce jointe).
      -  Un type de champ mis comme bloquant l’est aussi hors d’un fieldset (voir « Foo date » dans le haut de l’image jointe).

    • Oops… on ne voit pas bien l’image. La voici en lien.

      Merci d’avance. Je suis bien entendu à disposition s’il y a des questions.

    • Heu... avec l’exemple envoyé, je n’ai pas de problème. Mes radios ne bloquent rien... j’arrive à poster du moment que je remplis les champs affichés et marqués comme obligatoire...

    • Étrange.

      J’ai vidé les caches navigateur et Spip (y compris ./tmp/cache) et j’ai réimporté mon exemple ci-dessus.

      Si je coche Bar et remplis les champs nécessaires, le formulaire ne se valide pas. (Sous Firefox, si je coche ensuite Foo, je vois que ce sont les champs date et radio qui bloquent : ils sont encadrés de rouge.)

      J’ai essayé avec un Spip 3.2.3, pareil. Avec Chromium, pareil. :-/

    • ok, je sais. Il y a un problème au niveau du compresseur js interne. Comme pour les debug je le désactive, je voyais pas le problème. Je tente de corriger.

    • Bon,

      ce n’était pas lié à la compression js, mais j’ignore pourquoi je ne reproduisait pas chez moi.
      Enfin, j’ai fini par reproduire. La version 3.13.3 résoud normalement ce problème.

    • Merci beaucoup, ça semble fonctionner au poil. Mes collègues vont être contentes. :-)

      Belle journée. 🌞

    • tant mieux. N’hésite pas à signaler si problème similaire.

    Répondre à ce message

Un message, un commentaire ?

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document