Avant ma clé était : si_la_suppression_automatique_est_activee_les_articles_avec_le_statut_archive_seront_automatiquement_supprimes_des_que_la_date_d_archivage_est_depassee_du_nombre_de_jours_indiques
Après le passage de Salvatore elle est devenue : si_la_suppression_automatique_est_activee_les_articles_avec_le_statut_archive_seront_automatiquement_supprimes_des_que_la_date_d
Bug ou c’est une contrainte documentée que j’ai loupée ?
Ouais, bon, c’est dommage que ça bloque hein… mais j’ai envie de dire c’est un peu abusé comme « clé », et pas spécialement légitime. On n’est pas dans des fichiers de langue comme on voit parfois ailleurs où la clé c’est la chaine de la langue par défaut à traduire. Chez SPIP on n’attend vraiment des clés, des identifiants.
Beaucoup plus lisible en plus dans les utilisations dans les squelettes ensuite.
Clairement personne n’a pensé que quelqu’un utiliserait les clés de langue de la sorte aussi longues.
Ça n’a pas vraiment de sens : c’est censé être un code résumé / identifiant, qui ne change pas si le texte change peu à l’intérieur, et rend d’usage dans SPIP bien laborieux de ces clés par ailleurs !
On dirait que tu fais comme dans du gettext (fichiers .po) qui utilisent plus facilement le texte complet de la langue source comme « msgid » d’identifiant ; mais c’est pas non plus ce qui est fait ici, qui est un mixte des deux bien étrange ! Et SPIP ne sait pas gérer l’appel de traductions avec une chaine qui aurait pour clé un texte par ailleurs : c’est peut être pour cela que tu as remplacé par des soulignés etc… Mais ça rend l’ensemble très chaotique il me semble, non ? Ni l’un, ni l’autre…
Bah éventuellement on peut augmenter la taille du varchar, c’est pas sorcier… y a de la marge…
Mais, le veux t’on vraiment ? C’est effectivement une question !
Pour préciser pourquoi j’en suis arriver à faire des chaines de langues si longues, c’est surtout que j’en avais marre de toujours rechercher dans les fichiers de langue à quoi correspond tel ou tel chaine de langue pas du tout explicite.
Par exemple, vous savez à quoi correspondent les chaines de langues suivantes :
erreur
erreur_texte
forum_titre_erreur
pass_erreur
avis_erreur
info_erreur_systeme
info_erreur_systeme2
Et bien ça correspond à :
Erreur
erreur(s)
Erreur...
Erreur
Erreur : voir ci-dessous
Erreur système (errno @errsys@)
Le disque dur est peut-être plein, ou la base de données endommagée...
Je pourrais en citer d’autre avec les innombrables info_publie_1, info_publie_2, info_publie_01, info_propose_1, info_propose_2, info_propose_3, info_propose_4, info_propose_5…
Bref, du coup étant habitué à gettext avec des fichiers .po/.mo qui utilise la langue source comme msgid d’identifiant j’ai « réappliquer » ce concept aux fichiers de langue pour mes plugins SPIP avec 2 gros avantages pour moi :
Avec la chaine de langue je sais tout de suite quel texte sera affiché (du moins dans la langue fr)
Quand une chaine de langue n’est pas traduite, c’est son identifiant qui est affiché et du coup même sans traduction les auteurs (français) comprennent le texte et peuvent me remonter plus facilement le bug.
Ça m’évite les retours quand ça bug du type : Hey, j’ai le message info_image_process_titre / info_message_2 / info_propose_3… qui s’affiche, je comprend rien !
Merci @nicod, maintenant que c’est dans la doc, ça évitera peut-être à d’autres de se prendre les pieds dans le tapis ^^
Ensuite, il faudrait voir avec le core SPIP, car si l’idée est de rester avec des clés assez courtes de maximum 128 caractères, peut-être qu’un petit test avec le déclenchement d’une alerte lors de l’affichage d’une chaîne de langue avec un code trop long serait le bienvenu :
// dans `inc_traduire_dist()`
if ( strlen($code) > 128 ) {
trigger_error('Attention la clé de la chaine langue est très longue et non supportée par Salvatore', E_USER_WARNING);
spip_log('Attention la clé de la chaine langue est très longue et non supportée par Salvatore', _LOG_AVERTISSEMENT);
}
Mais bon, ça rajoute de la lourdeur pour, j’imagine, très peu de cas comme le mien ^^, donc dans la doc, c’est déjà bien !
Et mettre ce 128 dans une constante configurable ? Mais il me semble que c’est pas banal pour une constante de modifier le type d’un champ créé en BDD.
