[spip-dev] A tester : SPIP 1.7.2 pr1

Salut,

vous pouvez télécharger SPIP 1.7.2pr1, qui devrait déboucher très rapidement
(après la traduction des dernières chaînes en attente) sur la version 1.7.2
"officielle".

                  http://www.spip.net/spip-dev/devel/

(Les utilisateurs du spip_loader devront attendre la version "officielle").

Attention, la version 1.7.2 sera probablement la dernière de la série 1.7,
ce qui signifie que les bugs qu'elle contiendra ne seront pas corrigés
avant assez longtemps -- du moins dans les versions "stables". Il est donc
crucial que celle-ci soit bien testée, sur beaucoup de plate-formes,
et dans toutes ses possibilités, notamment à l'installation.

Par rapport à la 1.7.1, cette version apporte :

* une amélioration de la fabrication automatique des vignettes, avec
  la capacité d'utiliser aussi bien la librairie imagemagick (en ligne
  de commande ou via le module php-imagick) que la librairie GD.

* de nouvelles possibilités dans la gestion de sites multilingues :

  - tous les textes (titre ou contenu d'un document ou d'un mot-clé,
    nom d'un auteur, etc.) peuvent être transformés en objets
    multilingues, et donc s'afficher différemment selon le contexte
    linguistique dans lequel ils sont appelés.

    L'outil de base est le « bloc multi », qui s'écrit par exemple :
    <multi>Irak [en]Iraq</multi>. Si ce bloc multi est donné comme
    titre de mot-clé, il s'affichera sous la forme "Iraq" s'il est
    lié à un article en anglais, et sous la forme "Irak" dans les
    autres cas.
    
    Note : la première version donnée (ici la version française du mot)
    sert de valeur par défaut, pour les langues non prévues dans le bloc
    multi. Si le mot est associé à un article en chinois, il s'affichera
    donc en français.

    Un bloc multi peut s'étaler sur plusieurs lignes, ce qui permet de faire
    des descriptifs multilingues.

  - les blocs multi fonctionnent aussi dans les squelettes

  - il est désormais possible de gérer le multilinguisme en fonction de la
    langue du visiteur, sans recourir à une structure compliquée de sélection
    de langue.
    
    + les pages que l'on veut gérer de cette manière (par exemple, une page
      "articles récents en /français/chinois/") doivent être annoncées, dans
      le fichier php3 du couple php3/html, avec l'option $multilang=true;

      Cette option indique au cache de SPIP qu'il doit gérer un cache séparé
      pour chaque langue, et choisit une langue par défaut (celle du
      navigateur, prise soit dans les réglages du navigateur, soit, après
      sélection d'une langue dans un menu de langue, dans le cookie
      spip_lang déposé par SPIP).

    + deux balises permettent de créer les menus de langue correspondants :
      #FORMULAIRE_LANG, qui propose un menu donnant accès à toutes les
      langues utilisées dans le site public, et #FORMULAIRE_LANG_ECRIRE, qui
      donne accès à toutes les langues utilisées dans les fichiers de langue
      de SPIP (cas des formulaires, et notamment du formulaire de connexion
      à l'espace privé)

* Correction de divers bugs, notamment :

  - (introduit dans la 1.7.1) : l'affichage des puces ne
    respectait plus les sauts de paragraphes
  - modifier le descriptif d'un document
  - les mélanges des formes <:chaine:> et <INCLURE()>
  - effacement de titre sur nouvel article

-- Fil

- Le champ "selected" de la drop-box du #FORMULAIRE_LANG reste à "français" même sur une page en anglais

- C'est bien forml qui sert à définir l'aspect visuel de la boite ?

- Je met la page sommaire dans quelle boucle pour qu'elle tienne compte de la langue choisie par le visiteur ?

Les squelettes standards n'ont pas le #FORMULAIRE_LANG.

Petite réponse groupée :slight_smile:

@ Nicolas Krebs <nicolas1.krebs2@netcourrier.com> :

Concernant la nouvelle technique de textes multilingues,
une syntaxe pour donner la liste des traductions entièrement en xml serait
(je passe sur les namespace)

<list>
<item>texte par défaut</item>
<item lang="fr" >texte en français</item>
<item lang="en" >texte en anglais</item>
</list>

http://groups.google.com/groups?selm=40750e9c$0$26446$626a14ce@news.free.fr

C'est toujours le même problème : taper du XML à la main, ça n'eest pas très
pratique ; d'où le choix de raccourcis intuitifs et faciles à entrer. S'il
faut exporter les blocs multi vers d'autres bases en suivant tel ou tel
standard, ça reste facile.

> Je ne veux pas organiser ça plus "sérieusement", sinon on va finir comme à
> l'usine, avec contremaîtres, bilans chiffrés, et coups de schlague.

Guillaume Duval, « "Les PME, c'est l'avenir" : une illusion qui a la vie
dure », Alternatives economiques, n°224, avril 2004, page 11, dernier
paragraphe

Explicite ?

Je me trompe peut-ête, mais pour moi, sqlite est une base de données SQL
(utilisable avec PHP) comme les autres, et augmenter le nombre de bases de
données SQL consisterait simplement à faire une version de SPIP avec
mysql, postgresql, sqlite, et pourquoi pas oracle (
http://www.spip.net/threadspip2014-3512.html ), dans un premier temps.

Il y a une différence fondamentale avec SQLite : il n'y a pas à
configurer d'accès à une base de données. Par ailleurs ce sera le standard
de BDD de php5, si j'ai bien lu. De ce point de vue, c'est plus intéressant
que Oracle. Mais je n'ai rien contre Oracle, à part ses origines (CIA)...

Je ne sais pas si la génération de #FORMULAIRE_LANG
(dans ecrire/inc_lang.php3 lignes 394 à 469)
contient l'erreur critiquée dans
Pan sur les doigts | Openweb.eu.org,

Oui, effectivement.

mais je vous conseille de supprimer « <noscript> » et « </noscript> ».

Là il faudrait argumenter. Et je ne vois pas le rapport avec la remarque
précédente.

@ Minh Ha Duong <haduong@centre-cired.fr> :

- Le champ "selected" de la drop-box du #FORMULAIRE_LANG reste à
"français" même sur une page en anglais

Ce menu est là pour que l'utilisateur choisisse sa langue sur une page
*multilingue* ; donc le mettre sur une page "en anglais" est un contresens.

- C'est bien forml qui sert à définir l'aspect visuel de la boite ?

Aucune idée de ce qu'il faut mettre ; Arno* ?

- Je met la page sommaire dans quelle boucle pour qu'elle tienne compte de
la langue choisie par le visiteur ?

Pour faire une page multilingue, tu indiques
        $multilang=true;
dans le fichier .php3

et tu utilises le critère {lang} dans les boucles.

Les squelettes standards n'ont pas le #FORMULAIRE_LANG.

Non, car ils ne comportent pas une seule page dont le contenu change en
fonction de la langue du visiteur (à l'exception de la page de login, qui
elle utilise #FORMULAIRE_LANG_ECRIRE).

Par contre (pas grand chose à voir) il faut que je retravaille
backend-dist.html pour qu'on puisse l'appeler via backend.php3?lang=xx

-- Fil

Hi

Je test la 1.7.2 pr1 en local et j'ai un truc bizarre:
Dans les auteurs, chaque fois que j'affiche la page des informations personnelles de n'importe quel auteur, j'ai toujours "George" comme signature et "george@diwanalarab.com" come e-mail. Pourtant la page "L'auteur" de l'auteur affiche bien le vrai auteur et son vrai e-mail.
C'est pas normal ca, je crois.

George

Fil wrote:

Je test la 1.7.2 pr1 en local et j'ai un truc bizarre:
Dans les auteurs, chaque fois que j'affiche la page des informations
personnelles de n'importe quel auteur, j'ai toujours "George" comme
signature et "george@diwanalarab.com" come e-mail. Pourtant la page
"L'auteur" de l'auteur affiche bien le vrai auteur et son vrai e-mail.
C'est pas normal ca, je crois.

Non, en effet c'est bizarre. Sur www.spip.net/ecrire/ ça fonctionne, donc ?

-- Fil

Fil wrote:

Je test la 1.7.2 pr1 en local et j'ai un truc bizarre:
Dans les auteurs, chaque fois que j'affiche la page des informations personnelles de n'importe quel auteur, j'ai toujours "George" comme signature et "george@diwanalarab.com" come e-mail. Pourtant la page "L'auteur" de l'auteur affiche bien le vrai auteur et son vrai e-mail.
C'est pas normal ca, je crois.
   
Non, en effet c'est bizarre. Sur www.spip.net/ecrire/ ça fonctionne, donc ?

Oui, surtout que dans la table spip_auteurs les informations sont justes. Est ce que ce serait une histoire de cookie?

George