Recherche avancée

Sur d’autres sites (5690)

• Anomalie #2974 : changement de langue par défaut du site change langue des articles

  25 avril 2013, par Suske -

  Pour faire avancer le schmilblick, résultat de ma quête découverte dans le code de SPIP (merci à l’équipe spéciale pour sa précieuse collaboration) : en résumé, je confirme.

  http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/configurer_langue.php#L56 appelle caculer_langue_rubriques après validation de la sélection (http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/rubriques.php#L365) et là, on a :

   sql_updateq("spip_rubriques", array("lang" => $GLOBALS[’meta’][’langue_site’], "langue_choisie" => ’non’), "id_parent=0 AND langue_choisie != ’oui’") ;
  

  Les rubriques racine avec langue_choisie=’non’ ont "lang" modifié avec la valeur qui vient d’être sélectionnée comme "Langue principale du site".

  C’est utile/nécessaire dans le cas d’un site sans gestion du multilinguisme au niveau des rubriques (si on décide que le site en javanais devient brusquement un site en russe par exemple) mais dans ce cas-ci cela entraîne le basculement d’un secteur linguistique vers une autre langue.

  Cela provient du fait que dans le cas du multilinguisme par secteur (meta "multi_secteurs"=’oui’) la langue principale du site n’est pas indiquée "lang_choisie"=’oui’ car la langue est la langue par défaut. Du coup il me semble qu’on pourrait mettre cette valeur en base sur la ou les rubriques racines au moment de la validation du choix de langues pour les rubriques racines uniquement.

  J’ai testé

  sql_updateq("spip_rubriques", array("langue_choisie" => ’oui’), "id_parent=0 AND langue_choisie != ’oui’") ;
  

  à la ligne http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/configurer_multilinguisme.php#L38

  Par ailleur, dans le cas où l’utilisateur crée ou déplace ensuite une autre rubrique en langue principale du site à la racine, le problème revient. Donc cette seule intervention, si elle est valable, n’est pas suffisante. Comme calculer_langue_rubriques est appelé dans ces cas de figure, j’ai ajouté en début de fonction :

      // si secteurs de langue fixer lang_choisie à oui pour la racine - à non pour les autres
      if (lire_meta(’multi_secteurs’)=="oui") 
  
          sql_updateq("spip_rubriques", array("langue_choisie" => ’oui’), "id_parent=0 AND langue_choisie != ’oui’") ;
  
          sql_updateq("spip_rubriques", array("langue_choisie" => ’non’), "id_parent != 0 AND langue_choisie = ’oui’") ;
  
      
  
  
  

  Cela fait le boulot et je n’ai pas vu de conséquence négative jusqu’ici mais cette gestion est suffisemment complexe pour que je me contente de rapporter ça ici pour voir ;-).

• Revision 68533 : Et meeeeerde je voulais pas commiter ma modif de DATE pour dans le commit ...

  21 décembre 2012, par rastapopoulos@… — Log

  Et meeeeerde je voulais pas commiter ma modif de DATE pour dans le commit précédent [68532] !
  DONC je change pour cette modif un numéro fonctionnel.
  Et donc c’est quoi :
  La saisie "date" sait gérer "horaire=oui" en option.
  Si on ne le met pas, ça fait la même chose qu’avant.
  Si on met cette option, alors ça génère *deux* input, un pour la date, un pour l’heure, et ça enregistre le tout dans la *même* variable, mais en tableau.
  Par exemple si nom=debut, ça va donner debut[date] et debut[heure].
  Ça c’est pour la *sortie*.
  En *entrée* la saisie sait prendre :
   soit une date au format SPIP j/m/a
   soit une date SQL, avec heure ou pas
   soit un tableau avec les deux clés "date" et "heure" au format SQL
  À venir : la vérification "date" qui gère aussi le tableau date/heure si détecté et qui normalise donc avec la bonne heure choisie par le même champ de formulaire.

• Revision 68541 : La vérification "date" sait maintenant gérer automatiquement les ...

  21 décembre 2012, par rastapopoulos@… — Log

  La vérification "date" sait maintenant gérer automatiquement les heures-minutes si la valeur est un tableau avec deux clés "date" et "heure". Dans ce cas, et seulement dans ce cas, alors le script vérifie en plus le format de l’heure (on accepte 00:00 mais aussi 00h00 ou 00h00m) ainsi que la cohérence des nombres. Si tout est bon, alors l’heure trouvée est utilisée dans la normalisation SQL.
  Au passage, les numéros de version c’est vraiment n’importe quoi depuis le début sur ce plugin (toujours en "1" au niveau du fonctionnel, malgré tous les commits d’ajouts et non pas de debug). Donc on le met en 1.0.0 et on changera désormais comme il faut !