BoyWiki:Agora/Demandes traitées

Interventions traitées

Notes en bulles

Une chose qui serait très utile pour la lecture des articles : une fonction faisant apparaître le texte d'une note dans une bulle (sur fond légèrement jaune) quand le curseur est placé sur l'appel de note.

Je n'ai vu cette fonction sur aucun wiki jusqu'à présent, mais je sais que c'est techniquement possible (ça existe sur d'autres sites). Il y a l'équivalent dans Word.

Caprineus 24 décembre 2008 à 12:09 (GMT)

On peut simuler un effet approché (et imparfait) en utilisant cette syntaxe lors de la création de la note:
<span title="texte de la bulle"><ref>texte de la note</ref></span>
Par exemple:

Ses deux accroche-cœurs se cambraient sur ses tempes : on eût dit des scorpions. Et sa robe de soie était ouverte et ample. Il est comme un diamant, qui réveille les cœurs, excite le désir. Si un jour il t’invite, n’hésite pas, car tout est facile avec lui et son esprit habite le beau corps lumineux qui se fond avec lui, comme un nuage au vent. Imaginerait-on que, quelque part, existe un autre être vivant dont la beauté puisse être comme sa réplique ?

Le problème c'est que ça ne fonctionne pas avec le modèle Citation bloc pour une raison qui m'échappe, mais ça marche si on fait appel distinctement aux modèles début citation et fin citation. Si quelqu'un a une idée ?

Pinocchio 24 janvier 2009 à 22:22 (GMT)

A vrai dire, c'est un bon début : cette bulle, bien que sommaire, est tout à fait pratique et lisible.

Le principal problème, c'est qu'il faut écrire deux fois le texte de la note, ce que la plupart des rédacteurs ne feront pas (je connais des participants de longue date à LG qui ne savent même pas, ni ne veulent savoir, comment utiliser un <b> ou un <i> !). Ne serait-il pas possible d'intégrer une fois pour toutes la fonction span dans le ref, et que le texte ne soit saisi qu'une seule fois ?

Autre chose : si je laisse le curseur immobile sur l'appel de note, la bulle disparaît au bout de quelques secondes – ce qui n'est guère commode pour lire une note un peu longue. Serait-il possible de faire un réglage pour que la note reste affichée indéfiniment, tant que le curseur est positionné sur l'appel de note ?

Enfin (mais c'est juste la cerise sur le gâteau, donc pas absolument nécessaire), ce serait bien que cette bulle puisse afficher des gras et des italiques. Je n'ai pas testé (et n'ai pas le temps de le faire, car on doit venir me chercher d'une minute à l'autre...), mais je sais que c'est rarement le cas.

Caprineus 25 janvier 2009 à 14:14 (GMT)

C'était juste une idée pas trop compliquée pour répondre partiellement au problème. Mais cette solution est peu configurable : il faut bien voir que <span> n'est pas destiné à faire des bulles ! Il utilise seulement une fonctionnalité du navigateur : c'est lui qui décide d'afficher une bulle, tout comme il le fait également pour un lien externe. Il n'y a donc aucun attribut du code qui configurerait cette bulle (gras, italique, délai d'affichage, etc...). Il est peut-être possible de créer un modèle refbasdepage qui intègrerait l'ensemble du code et permettrait de ne saisir qu'une fois le texte (quoique, avoir une note complète en bas de page et succincte en bulle ça peut être vu comme un avantage !), mais c'est probablement tout. Il est sûrement possible de faire mieux mais avec une autre solution plus complexe (javascript)...

Pinocchio 25 janvier 2009 à 17:08 (GMT)

Voici deux morceaux de code relevés sur une page internet qui fait apparaître une bulle explicative (avec image intégrée !) lorsque le curseur s'arrête sur certains mots (le texte a été modifié, mais pas le code, bien sûr) :

<style type="text/css">
.infobulle{
width:350px;
position: absolute;
visibility : hidden;
border: 1px solid Black;
padding: 10px;
color : white ;
font-family: Arial;
font-size: 12px;
background-color: #5F0F0E;
text-align:justify;
}
</style>

<link href="styles/styles.css" rel="stylesheet" type="text/css">

<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt">Ceci est un texte à propos des <a href='#' class='texte' onMouseOver='montre("<img height=\"145\" alt=\"garçon.jpg\" hspace=\"0\" src=\"/galerie_images/garçon.jpg\" width=\"190\" align=\"baseline\" border=\"0\" /><p>Un garçon est un être humain non adulte de sexe masculin.</p><p>Le garçon est un être sexué.</p>")' onMouseOut='cache()'><i style='text-decoration:none;color:#5F0F0E'>garçons</i></a> de toute sorte. Les garçons sont souvent aimés et éduqués par des <a href='#' class='texte' onMouseOver='montre("<img height=\"130\" alt=\"homme.jpg\" hspace=\"0\" src=\"/galerie_images/homme.jpg\" width=\"190\" align=\"baseline\" border=\"0\" /><br />Un homme qui aime les garçons est généralement appelé pédéraste. ")' onMouseOut='cache()'><i style='text-decoration:none;color:#5F0F0E'>hommes</i></a> : ils peuvent ainsi prendre modèle sur leurs aînés. </p><p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt" /><p>De nombreuses sociétés ont favorisé ce type de rapports.</p><p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt" /><p>Mais d'autres interdisent toute forme d'éducation amoureuse.</p>

Est-ce que ça peut t'aider à élaborer des "notes en bulles" ?

Caprineus 26 janvier 2009 à 12:56 (GMT)

Fonction en cours de test. Comme d'habitude les pré-tests n'ont été effectués que pour Firefox 3 et IE 7.

(Un exemple de page truffée de notes pour les essais : Ramoneurs_savoyards)

Vos remarques svp ? - Pinocchio 10 février 2009 à 12:10 (GMT)

Ah ! que ceci est bel et bon ! Et je suis surpris de la vitesse d'apparition des bulles.

Côté graphisme, on peut éventuellement pinailler sur quelques points. Par exemple :

• Il est étrange que les italiques apparaissent en brun. Certes, ça souligne les titres, mais en même temps ça évoque les "liens rouges" des wikis, alors qu'il n'y en a pas. Je serais donc plutôt favorable à les remettre en noir (d'autant qu'il y a parfois de vrais liens rouges, qui doivent alors apparaître distinctement – comme dans les notes 48, 55, 56, 57 de l'article Ramoneurs_savoyards).
• Pour ma part, j'arrive à lire les notes en bulle, mais on peut craindre qu'un lecteur presbyte ait vraiment des difficultés, car les caractères sont très petits. Le mieux serait sans doute de les mettre de la même taille, ou presque, que dans les notes visibles en bas de page.
• A mon goût, la couleur du fond des bulles est trop sombre. Elle devrait être juste un peu plus sombre que le fond de la page.
• Il faudrait peut-être prendre exemple sur les bulles qui apparaissent brièvement quand on pointe sur un lien, de manière à avoir un filet sombre tout autour de la bulle, ainsi qu'une ombre qui la fasse ressortir sur la page. (Peut-être qu'un filet jaune foncé serait plus esthétique qu'un filet noir.)

Par ailleurs, j'ai constaté un étrange mini-bug : dans la note 6 de la page 2000, les mots Le Matin sont en italique. Or dans la bulle ils apparaissent en caractères droits. Comme ce sont les premiers mots, peut-on supposer que le code de l'italique ne fonctionne pas dans les bulles en début de note ?

Pour information : je lis BoyWiki avec Mozilla 1.7.12, affichage 1024 × 768, sous Windows XP SP3.

Caprineus 11 février 2009 à 01:36 (GMT)

À la page du 1^er avril, j'ai créé 5 notes avec de nombreuses mises en forme, pour tester le bon fonctionnement des bulles pendant la phase de mise au point.

Apparemment, tout fonctionne correctement (y compris l'écriture arabe, qui est souvent problématique) – sauf les mises en forme en début de note : que ce soit en italique, en gras ou en petites capitales, la mise en forme n'est visible dans les bulles que si elle ne s'applique pas au premier mot. Étrange !

Une suggestion sur un autre point : apparemment, la hauteur minimale des bulles est fixée à environ 4 lignes de texte. Ce qui n'est pas très esthétique quand il n'y a que quelques mots, l'essentiel de la bulle étant vide. Serait-il possible de ramener la hauteur minimale à une ligne de texte ?

Caprineus 11 février 2009 à 11:39 (GMT)

Merci pour les tests ! J'ai corrigé les erreurs et modifié le style, sauf pour l'ombrage qui n'est pas supporté d'une manière simple et standard actuellement.

Pinocchio 11 février 2009 à 23:19 (GMT)

Après avoir testé sur la page du 1^er avril, j'allais dire que tout était maintenant parfait... quand j'ai voulu, par acquis de conscience, tester aussi les Ramoneurs savoyards. Et là, problème(s) !

La bulle de la note 1 affiche, avant le texte, toutes les variantes de l'appel de note : ^{1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9}. Il me semble que ce n'était pas le cas avant. Et c'est aussi laid qu'inutile.

De plus, la note n'est pas affichée entièrement. Il en va de même pour les notes 2, 3, 8, 20, 25, 27, 30, 35, 36, 37, 40, 41, 42, 52, 54, 55.

En gros, les notes qui s'affichent incomplètement semblent être les plus longues. Cependant, ça n'a rien de systématique : les notes 39 et 49 s'affichent tout entières sur 5 lignes, alors que la note 40, dont le texte est pourtant un peu plus court, n'affiche même pas la moitié d'une ligne ! Idem pour la 51, correctement affichée sur 6 lignes, et la 50, plus courte mais très incomplète.

Un nouveau ramonage du code serait sans doute opportun...

Caprineus 12 février 2009 à 14:46 (GMT)

Eh oui, dans la précipitation j'ai oublié le cas des indices multiples tel qu'on trouve dans le ^[1] des petits ramoneurs, désolé… Je suppose que le texte, mal encadré de balises html, qui en résultait était la raison des pertes de contenu. Enfin je suppose parce que pour Firefox ou IE je n'ai pas constaté ces bouts de texte absents, mais les navigateurs sont plus ou moins tolérants envers les erreurs html, ce qui peut expliquer la différence.

Et à présent, c'est mieux ?

Pinocchio 12 février 2009 à 19:36 (GMT)

Oui ! Je viens de visionner à nouveau toutes les notes des petits ramoneurs, et maintenant les bulles s'affichent correctement (de même que dans les tests du 1er avril). Comme quoi Mozilla est certes moins évolué que Firefox ou IE, mais il est quand même bien utile pour détecter d'éventuelles failles.

Vraiment, ces notes en bulle représentent une grande avancée dans le confort du lecteur, et l'on peut être étonné que Wikipédia n'y ait jamais pensé. Ou alors c'est qu'ils n'ont pas d'informaticiens à la hauteur... (je veux dire : à la hauteur de celui de BoyWiki :-) Je ne serais pas étonné qu'un jour ou l'autre on nous copie... En tout cas, merci encore pour ces perfectionnements.

(Tiens ! Au bout d'une dizaine d'indentations successives, BoyWiki semble fatigué d'alterner les couleurs...)

Caprineus 12 février 2009 à 21:27 (GMT)

Content que ça fonctionne enfin ! Mais il doit bien rester quelques cas imprévus…

Ce n'est pas forcément une indication d'une moindre évolution de Mozilla que de le voir refuser d'interpréter ce qui est mal écrit, il est simplement plus strict.

Chez Wikipédia il existe en option des bulles beaucoup plus sophistiquées, tu devrais essayer dans ton compte (il faut un compte) d'activer 'popups' dans 'Préférences/Gadgets' pour voir : c'est surprenant. Mais je trouve vite lassant ces bulles qui surgissent à profusion sur tout les liens : trop c'est trop. Et surtout il existe en option des modules aux fonctions comparables qui peuvent être installés dans les navigateurs (par exemple CoolPreviews chez Firefox) et qui font aussi bien, alors…

J'ai ajouté deux niveaux d'indentations de plus : étrange, sur le Bistrot ils sont moins bavards que nous ?

Pinocchio 12 février 2009 à 22:24 (GMT)

Agora : fond alterné jaune clair - jaune foncé

L'utilisation de l'Agora serait beaucoup plus facile si les réponses à un message apparaissaient sur des fonds jaune clair et jaune foncé alternés (comme sur le Bistro de Wikipédia). Loustic a découvert que cette fonction est liée à l'activation d'un script Java hébergé dans http://upload.wikimedia.org (l'adresse n'est pas accessible en direct, ce serveur doit héberger tous les applets Java nécessaires à Wikipédia).

Ce serait bien d'introduire cette fonction sur l'Agora (tout en se méfiant du Java, qui semble être une porte ouverte aux vandales). Caprineus 22 décembre 2008 à 17:04 (GMT)

Fonction en cours de test. Les critiques sont attendues, je sais qu'il reste des bugs, j'essaierai d'y palier (dans la mesure de mes moyens). Tous ne peuvent pas être corrigés, il nous faudra suivre quelques règles simples lors de l'usage des indentations (caractère :), par exemple les lignes vides entre paragraphes d'un même commentaire devraient commencer par un :, ou encore ne pas utiliser ce caractère : en dehors des indentations de dialogues.

Les pré-tests n'ont été effectués que pour Firefox 3 et IE 7. Merci de signaler les possibles disfonctionnements si vous utilisez d'autres navigateurs.

Pinocchio 30 janvier 2009 à 17:33 (GMT)

Ah, ben c'est beaucoup plus clair et plus joli comme ça ! Merci de t'être vaillamment battu contre des lignes de code dont la moindre m'aurait fait fuir...

La seule petite critique que je pourrais faire, c'est que les deux couleurs du fond ne sont pas assez différentes (la plus sombre pourrait sans inconvénient être assombrie encore un chouia). Le mieux serait peut-être de prendre les teintes du Bistro de Wikipédia : elles y sont en usage depuis longtemps, à la satisfaction des usagers.

Concernant le navigateur : j'utilise Mozilla 1.7.12, et apparemment tout marche bien.

Caprineus 31 janvier 2009 à 14:58 (GMT)

Tu mentionnes comme un "bug" le fait que « les lignes vides entre paragraphes d'un même commentaire devraient commencer par un : ». Mais c'est le cas aussi sur le Bistro : ce n'est donc pas un bug, mais cela relève du fonctionnement logique de l'indentation.

Quant à « ne pas utiliser ce caractère : en dehors des indentations de dialogues », je ne comprends pas bien ce que tu veux dire. J'ai mis plusieurs : dans mon texte, et ils passent très bien.

Tout petit bug sans importance : en prévisualisation, les bordures horizontales n'apparaissent pas, et les paragraphes ne sont pas espacés automatiquement. Est-ce grave, docteur ?

Autre chose enfin : penses-tu que les changements que tu as faits puissent affaiblir la sécurité ? (Loustic émettait des craintes par rapport aux applets Java.)

Caprineus 31 janvier 2009 à 15:14 (GMT)

Le bleu a été foncé un peu, pas trop, il risque de masquer les liens qui sont aussi en bleu.

C'est vrai, sur Wikipédia aussi les lignes vides entrainent une rupture de style. Si il est une seule règle à suivre c'est celle de ne pas faire de ligne vide. Si on veut absolument un saut de ligne (sachant qu'un simple changement de paragraphe applique déjà un interligne) il suffit de commencer la ligne vide par des : , ou encore d'insérer un <br> à la fin de la ligne précédente.

Je voulais dire que si on utilise le caractère : pour introduire un retrait supplémentaire dans un même commentaire (hors indentation des dialogues), bien sûr ça fonctionnera, mais les lignes ainsi traitées apparaitront colorisées. Il vaut mieux utiliser dans ce cas les listes à puces qui introduisent également un retrait. N'existe-t-il pas un simple caractère tabulation dans la syntaxe wiki ?

Au sujet de la sécurité : c'est une vaste question ! Je n'ai fait qu'ajouter quelques lignes de code (javascript et non pas java) à celui que tu utilisais déjà peut-être sans le savoir (insérer du gras en cliquant le bouton Bold c'est du code). Par principe l'exécution de ce code s'effectue côté navigateur, après le chargement de la page (qui le contient), dans une sorte de carcan sécurité imposé : par exemple il lui est impossible d'accéder à un fichier local. Bien entendu on est pas à l'abri d'un bug. La sécurité implique aussi la confiance que l'on place dans un site, c'est à dire dans le code provenant de ce site. En principe ce code est lisible par tous, il se situe dans les pages MediaWiki:Common.js ou MediaWiki:Monobook.js (pour l'environnement Monobook).

Pinocchio 1 février 2009 à 00:38 (GMT)

Merci pour le boulot Pinocchio. Pour un début, c'est prometteur. Il y a toujours "one more bug", ce n'est pas ce qui m'inquiète le plus tant qu'il y a quelqu'un capable de retoucher le code. Le plus important reste la remontée d'information, il faut être conscient qu'un bug n'est jamais la faute du créateur de code (qui ne peut pas tester toutes les fonctions et toutes les configurations machine) mais de l'utilisateur qui tombe dessus et ne le rapporte pas.

Rassuré de voir que tout ça peut être réalisé en .js, c'est embarqué au chargement de la page et il reste donc la possibilité pour les parano qui le souhaitent de bloquer leur exécution sur leur propre machine si besoin, en utilisant par exemple NoJava sur Firefox.

Je rajoute une petite explication sur le mode d'emploi pour formaliser l'utilisation des indentations dans les textes postés sur l'Agora.

Mon seul dernier questionnement concerne la protection de ce genre de pages de code. Pour le moment, je n'imagine pas quelqu'un, en dehors de Pinocchio, s'essayant à modifier le code. Mais il y aura potentiellement de plus en plus de posteurs ayant, ou se sentant, des compétences d'éditeur de javascript et qui auront, avec le niveau d'administrateur, la possibilité de le faire. Il me semble que le simple fait d'avoir ce droit est une garantie suffisante que le contributeur ne changera pas le code sans savoir exactement ce qu'il fait. Votre avis ?

Hormis ce point, je pense qu'on peut considérer le problème traité et qu'on peut le basculer dans la page des interventions traitées. La suite de ses évolutions fera partie de sa vie normale dans le cadre d'un Wiki.

--Loustic 1 février 2009 à 11:27 (GMT)

Bah, c'est surtout très inspiré de Wikipédia, ce sont eux qui ont créé à partir de rien !

Et merci pour le mode d'emploi, je me demandais comment et où formaliser la syntaxe minimale. A propos de la page Agora principale que tu as modifiée, sais-tu si les trois lignes ":<br>" qui se trouvent en bas de la page servent à quelque chose ou qui les a insérées ? Elles introduisent une coloration parasite difficile à empêcher. Est-il possible de retirer les ":" devant les <br> ?

Il me semble nécessaire que les pages de code restent modifiables au moins par tout les admins, ne serait-ce que pour désactiver une fonction qui empêcherait le fonctionnement normal ou la lisibilité du site. Et puis un code peut souvent être amélioré, allégé, aéré par d'autres, au pire il est toujours possible de restaurer une version antérieure, comme pour toutes les pages du wiki.

Pinocchio 1 février 2009 à 13:23 (GMT)

Il me semble (pas sûr quand même...) que c'est moi qui avais mis les trois ":<br>" au bas de la page de l'Agora (pour créer un écart suffisant avec le reste du texte). Je viens de supprimer les : et apparemment tout est bien.

Concernant les droits de toucher au code, il y aurait une réflexion assez vaste à mener sur les "niveaux" de droits. Un "administrateur" devrait être quelqu'un qui administre, à ne pas confondre avec un "technicien" (qui peut toucher au code), ni avec un "gardien" (qui surveille le wiki, peut bloquer des pages ou des contributeurs), etc. Actuellement les choses sont un peu confuses...

Je n'y ai pas réfléchi plus que ça, mais le sujet mérite assurément d'être approfondi.

Caprineus 1 février 2009 à 21:40 (GMT)

Caractères spéciaux

Sur toutes les pages de création-modification de Wikipédia, on trouve, sous la fenêtre de composition, un choix très vaste de caractères spéciaux (codes wiki, API, grec, cyrillique, maths, etc.). Il suffit de cliquer pour les insérer. Ce serait pratique d'avoir la même chose sur BoyWiki.

Caprineus 22 décembre 2008 à 19:29 (GMT)

Juste une première étape : l'ajout de boutons dans la barre d'outils pour les insertions et caractères les plus souvent utilisés. C'est une proposition. L'inconvénient est que des caractères se trouvent mélangés avec des styles…

Bien entendu les icônes des boutons devront être remplacées. Ce qui entraîne une question : qui a le droit de télécharger de nouvelles images et comment on procède ? Et une autre : a-t-on le droit de copier les icônes de Wikipédia, la licence libre s'applique t-elle aussi aux icônes ?

Pinocchio 2 février 2009 à 15:44 (GMT)

Ouais !!! On va bientôt pouvoir écrire directement en grec et en russe...

Après test des nouveaux boutons, juste deux (toutes petites) remarques :

• On pourrait éventuellement économiser un bouton en remplaçant Guillemets ouverts et Guillemets fermés par Guillemets, qui encadreraient automatiquement le texte sélectionné.
• En raison du sens "instinctif" de lecture de gauche à droite (et du plus petit au plus grand), il serait logique que le bouton du Tiret semi-cadratin soit à gauche du Tiret cadratin.

Quant à l'ordre des boutons, je suppose que c'est modifiable. On y verra plus clair une fois les icônes mises en place.

Pour répondre à ta première question : si l'image que tu veux charger existe sur le net, mets une demande sur l'Agora en indiquant l'adresse de l'image – un administrateur spécialisé se chargera du boulot.

En ce qui concerne les droits sur les icônes, j'ai trouvé ces trois pages :

MediaWiki edit toolbar

Protected toolbar buttons

Category:ButtonToolbar

En cliquant sur une icône, ça t'amène à sa page, où se trouve la mention des droits. Il semble qu'à peu près tout soit libre, sous réserve peut-être d'en indiquer la source sur notre page de la même icône.

Caprineus 2 février 2009 à 22:20 (GMT)

Merci pour les infos. J'ai corrigé les remarques. Si tu vois d'autres boutons à ajouter… Je réserve pour plus tard les fonctions 'insérer un tableau' et 'chercher/remplacer', si elles sont nécessaires (et si elles fonctionnent...)

Pinocchio 3 février 2009 à 13:56 (GMT)

La suite : le menu des caractères spéciaux. Plutôt que le placer sous le texte, comme on le trouve habituellement, j'ai essayé de l'insérer au dessus, sous la barre d'outils. Il me semble que c'est plus pratique ainsi au lieu de jongler avec l'ascenseur pour accéder successivement à la barre d'outils et aux caractères spéciaux : je sais pas pour vous mais chez moi la page d'édition de Wikipédia dépasse la hauteur d'écran. Pour la même raison (accéder à la totalité de l'espace d'édition sans dépasser la hauteur d'écran) j'ai simplifié le champs de caractères spéciaux et limité sa hauteur. Vos avis svp ?

Par ailleurs les nouvelles icônes de la barre d'outils semblent refuser de s'afficher sur IE : simple problème de configuration ?

Pinocchio 4 février 2009 à 23:40 (GMT)

Bravo pour cette avancée technique, on pourait même penser que c'est mieux que sur Wikipédia ! Peut-être ce va être eux qui nous copieront un jour ? Mais il me semble qu'il manque le Œ et œ (faut le trouver dans phonétique française !) qui sont très utiles. D'autre part, je ne comprends pas pourquoi tu mets cela sous la rubrique Latin pourquoi pas une rubrique carractères spéciaux de base (trouver un nom plus court) qui comporterait tous ceux les plus utilisés, comme la liste de Wikipédia, avec des trucs comme ''<ref>'' etc... et qui s'afficherait par défaut. Ceux des autres langues sont quand même d'une fréquence d'utilisation bien moindre. Clipeus Virtutis 5 février 2009 à 12:36 (GMT)

Merci pour tes remarques. Effectivement j'en ai oublié ! J'ai ajouté 'Français' en rubrique par défaut pour les caractères communément utilisés. Sinon les fonctions et balises wiki sont réunies dans la barre d'outils au-dessus (<ref> c'est le bouton 'Référence'), il m'a semblé plus pratique de séparer les caractères spéciaux des attributs du langage wiki. - Pinocchio 5 février 2009 à 15:57 (GMT)

Félicitations et merci à Pinocchio pour ces listes de caractères. En effet, les disposer avant la fenêtre de composition est une très bonne idée !

Quelques remarques en vrac :

• À ma connaissance, les caractères Ĉ ĉ Ĝ ĝ Ĥ ĥ Ĵ ĵ Ŝ ŝ ne sont utilisés qu’en espéranto : on peut donc les enlever de la liste Autres Latin pour les laisser uniquement dans la liste Espéranto.
• A propos : il me semble que cette juxtaposition d’un pluriel et d’un singulier m’écorcherait moins l’œil sous la forme Autres (Latin)...
• Dans la liste Autres (Latin), donc, on peut ajouter :
  Ā ā Ă ă Đ đ Ē ē Ĕ ĕ Ī ī Ĭ ĭ İ ı Ł ł Ō ō Ŏ ŏ Ø ø Ş ş Ū ū Ŭ ŭ (mais il y en a d’autres).
• Je suggère de créer une liste Arabe (transcription) :
  ’ ‘ ° Å å Ā ā ã à á ä ą Đ đ Ḍ ḍ Ğ ğ Ġ ġ Ħ ħ Ḥ ḥ Ī ī ĩ ì í ł Ø ø Š š Ṣ ṣ Ŧ ŧ Ṭ ṭ ẗ Ū ū ũ ù ú ẃ ý Ẓ ẓ
• En revanche, la liste actuelle Arabe est inutile, car il est impossible d’écrire de l’arabe en l’utilisant (j’ai essayé). En effet, chaque lettre arabe possède 4 formes différentes (isolée, initiale, médiane, finale), qui doivent être gérées automatiquement par le logiciel de traitement de texte – ce que bien sûr BoyWiki ne sait pas faire (en bref, je tape un ع mais c’est le logiciel qui décide, selon sa place dans le mot et les lettres qui l’entourent, si cette lettre prend la forme ع ou عـ ou ـعـ ou ـع). De plus, il faudrait ajouter à la liste de nombreux signes accessoires (comme les voyelles courtes, la ponctuation...), ainsi que d’autres lettres employées dans les formes dialectales de l’arabe. Ce serait un vrai casse-tête, alors que Word ou OpenOffice, par exemple, sont tout à fait capables d’écrire en arabe des textes qu’il suffit ensuite d’importer dans le wiki.
• La liste Phonétique française pourrait avantageusement être remplacée par Phonétique (ou API, pour Alphabet phonétique international), de façon à y intégrer les signes utilisés pour d’autres langues. En effet, sur un site francophone, on aura plutôt l’occasion d’utiliser l’API pour indiquer la prononciation d’autres langues que celle du français – que la plupart des lecteurs connaissent déjà.
• La liste Grec sera surtout utilisée pour écrire du grec ancien. Il faudrait donc y faire figurer les voyelles minuscules et majuscules avec toutes les sortes d’accents. On devrait pouvoir trouver ça sur Wikipédia, non ?
• Une liste Symboles serait-elle utile ? Avec par exemple :
  ª © ℅ € № ® ™ º ¹ ² ³ ⁿ † ‡ • ¼ ½ ¾ ⅛ ⅜ ⅝ ⅞ “ ” „ ‰ ‹ › ‼ ± × ÷ ≈ ≠ ≤ ≥ □ ▪ ▫ ◊ ● ◦
• Enfin, concernant la barre d’outils : ce serait bien de faire apparaître dans la bulle du bouton Espace insécable le texte suivant :
  Espace insécable : inutile avec : ; ! ? « » (mettre une espace simple)
  En effet, le logiciel gère automatiquement l’affichage correct de ces signes de ponctuation en fin de ligne, même sans espace insécable.

Caprineus 5 février 2009 à 23:04 (GMT)

Merci pour toutes ces précisions dont j'ai essayé de tenir compte. Il reste une difficulté due à la profusion de signes grecs (trouvés sur Wikipédia), si on veut conserver l'avantage d'une barre des caractères spéciaux de faible hauteur et donc d'une page d'édition tenant dans la hauteur d'écran. En ce sens je propose une solution, mais qui me semble imparfaite, dont j'imagine qu'elle est peu pratique à l'usage... Qu'en penses-tu ? - Pinocchio 6 février 2009 à 18:18 (GMT)

J'en suis estomaqué ! :-) C'est pour le coup que Wikipédia va vouloir copier BoyWiki (comme on est gentils, on les laissera faire – à condition qu'ils n'oublient pas la mention d'origine...)

Rien à critiquer donc, et ta disposition pour gérer les lettres grecques semble en effet la plus pratique. Juste une remarque : les voyelles courtes et longues, que tu as mises avec les esprits rudes, ne seraient-elles pas mieux placées sur la liste (sans esprit) ? De plus, ça rééquilibrerait un peu la longueur des listes.

Pour la transcription de l'arabe, je m'aperçois que j'ai oublié de mettre les majuscules suivantes, qui peuvent être utiles : À Á Í Ì. Pourrais-tu les insérer avant les minuscules correspondantes ?

Dans cette même liste pour l'arabe, on pourrait ajouter Ċ ċ Ż ż, qui sont utilisés en maltais (le seul dialecte arabe qui s'écrive toujours en caractères latins).

Par ailleurs, je ne retrouve pas les deux apostrophes inclinées ’ ‘ que j'avais indiquées en tête de liste. Est-ce un oubli, ou une impossibilité ?

Quant à compléter la phonétique, à vrai dire rien ne presse, et il sera toujours temps de s'y mettre si le besoin s'en fait sentir. De toute façon ça risque de nécessiter une liste assez longue, qu'il faudra peut-être scinder.

Ce qui est particulièrement réjouissant, outre le côté pratique de telles améliorations, c'est que l'aspect culturel de BoyWiki en est conforté : au moins, on ne pourra pas nous confondre avec des sites d'érotisme primaire, des forums d'échanges illégaux (ou de discussions oiseuses), ou des revues aguicheuses. Ça fait plaisir !

Caprineus 6 février 2009 à 21:07 (GMT)

Merci mais il reste des bugs, l'alignement des caractères est mauvais pour IE, en plus des icônes qui peinent à s'afficher...

Derniers oublis ajoutés. - Pinocchio 6 février 2009 à 23:20 (GMT)

Tableaux

Ajout d'un bouton dans la barre d'outils d'édition en vue de tester un assistant à la création de tableaux simples. Évidemment, les nombreux paramètres dédiés aux tableaux ne sont pas tous applicables à travers une interface simplifiée. En particulier la fusion de cellules me semble difficile à synthétiser. Le but est de fournir une aide pour les cas courants. Il est bien sûr possible de définir (et ajouter) d'autres styles. Est-ce une solution souhaitable ? Proposable pour d'autres modèles complexes ? Vos avis svp ? (Comme d'habitude testé seulement pour Firefox 3 et IE 7) Pinocchio 17 février 2009 à 21:29 (GMT)

Affichons le résultat, pour voir :

Titre_col_1	Titre_col_2	Titre_col_3
Cellule_c1_r1	Cellule_c2_r1	Cellule_c3_r1
Cellule_c1_r2	Cellule_c2_r2	Cellule_c3_r2
Cellule_c1_r3	Cellule_c2_r3	Cellule_c3_r3
Cellule_c1_r4	Cellule_c2_r4 (plus large)	Cellule_c3_r4
Cellule_c1_r5	Cellule_c2_r5	Cellule_c3_r5

Ça paraît en effet très pratique !

• Concernant les bordures : serait-il possible d'avoir le choix entre : sans bordure, avec bordure simple (comme actuellement), avec bordure double (plus joli) ?
• Largeur du tableau : actuellement, le tableau s'adapte au contenu. Dans certains cas, il pourrait être utile d'imposer la largeur du tableau (en pourcentage). Est-ce possible ?
  L'idéal serait même de pouvoir imposer la largeur de chaque colonne séparément. Mais là, c'est peut-être demander la lune...

Un cas particulier que j'aimerais tester : un tableau de deux colonnes de largeurs réglables, sans bordure (ou juste celle séparant les deux colonnes). L'intérêt serait de faire figurer en vis-à-vis un texte original et sa traduction. Il pourrait y avoir une seule ligne (texte unique long) ou plusieurs (pour un recueil de poèmes, par exemple).

Ça demanderait sans doute un modèle particulier (gestion de la bordure, de la largeur des colonnes, de l'écartement des deux textes...).

Cette idée m'en donne une autre : pourquoi ne pas avoir un tableau spécial "textes littéraires", qui dans sa forme la plus simple n'aurait qu'une seule cellule ? On pourrait alors lui donner par défaut des caractéristiques différentes du texte habituel : fonte, taille des caractères, couleur du fond, gestion des paragraphes, largeur du texte, etc. Bref, un peu ce que je suggérais dans la section Modèle de texte cité (plus haut sur la même page).

Caprineus 17 février 2009 à 23:30 (GMT)

La possibilité d'imposer une largeur au tableau a été ajoutée. Le réglage pour chaque colonne est plus difficile à prévoir ne sachant pas à l'avance combien de colonnes seront souhaitées. Par défaut l'espace disponible (ou imposé) est partagé entre les colonnes en fonction de leur contenu.

Ajouté aussi deux styles plus particulièrement adaptés aux textes pour essayer de répondre à ta demande. L'un sans bordure, l'autre avec juste un bord par colonne en forme de liseré. L'utilité semble réduite à un faible nombre de colonnes, deux tout au plus. Mais le second me parait utilisable dans le cas que tu proposes d'un texte en vis-à-vis avec une traduction. Les deux versions du texte peuvent être recalées si nécessaire (le même texte n'a pas forcément la même longueur dans deux langues différentes) pour maintenir le vis-à-vis en changeant de ligne dans le tableau. Le type et la taille des caractères n'ont pas été fixés dans le tableau, ni la couleur, ils peuvent être définis par un modèle externe (un div avec un style) dans lequel est inséré le tableau, ou un modèle interne à chaque cellule du tableau.

Quant au modèle de texte cité, je ne suis pas sûr qu'un tableau soit le plus adapté : un tableau d'une seule cellule perd les avantages du tableau mais en conserve les inconvénients. Il me semble que pour du texte les solutions classiques à base de paragraphes permettent plus de souplesse (hauteur de ligne, retrait en début de ligne). Enfin le tableau reste quand même une solution, son avantage étant de ne pas multiplier les solutions. À suivre…

Pinocchio 18 février 2009 à 21:33 (GMT)

(J'ai créé un titre Tableaux, parce que cette partie devient vraiment longue...)

Pour que tout le monde voie ce que ça donne, voici les 4 modèles de tableau avec 2 colonnes et 3 lignes :

Wikitable

Cellule_c1_r1	Cellule_c2_r1
Cellule_c1_r2	Cellule_c2_r2
Cellule_c1_r3	Cellule_c2_r3

Alterné

Cellule_c1_r1	Cellule_c2_r1
Cellule_c1_r2	Cellule_c2_r2
Cellule_c1_r3	Cellule_c2_r3

Sans bordure

12. In Naeuolum Mentula cum doleat puero, tibi, Naeuole, culus, non sum diuinus, sed scio quid facias.	12. Contre Nevolus Si la queue de ton garçon lui fait mal, et qu'à toi, Nevolus, c'est le cul, je ne suis pas devin, mais je sais ce que tu fais.
20. De aquila portante Iouem Dic mihi, quem portas, uolucrum regina ? « Tonantem ». Nulla manu quare fulmina gestat ? « Amat ». Quo calet igne deus ? « Pueri ». Cur mitis aperto respicis ore Iouem ? « De Ganymede loquor ».	20. Sur un aigle portant Jupiter Dis-moi, qui portes-tu, roi des oiseaux ? « Celui qui tonne ». Pourquoi sa main ne lance-t-elle pas d'éclair ? « Il aime ». Pour qui brûle le dieu ? « Pour un garçon ». Pourquoi, le bec ouvert, te tournes-tu vers Jupiter ? « Je lui parle de Ganymède ».
Cellule_c1_r3	Cellule_c2_r3

Bordure gauche

Twelve and a half	Douze ans et demi
Boy, twelve and a half. Comes up to my shoulder. Comes up to my. Comes. Dazzling gossamer waves caress his ears, his sweet korallion ears, boy arms circle my waist, wrist watch cold against me. He comes to my shoulder. Gracile waist ; hipless hips. Precious candied lips. His mouth breathes open. For long seconds no breath comes out. Comes then in tiny gasps. Comes. His cyan eyes half shut, a flaxen lash so glossy licks my chest. Boy, twelve and a half sings in the College chapel. Mozart makes him stiff. Makes him quiver in the stalls. The choirmen gaze on him with the look : they know. This is true, he tells me so. I kiss. I kiss the bloomy curve of his honey gold neck.	Garçon de douze ans et demi. Remonte vers mon épaule. Remonte vers mon… Remonte. D’éblouissantes vagues arachnéennes caressent ses oreilles, ses douces oreilles corallines, bras garçonniers encerclant ma taille, bracelet-montre froid contre moi. Il remonte vers mon épaule. Taille gracile, hanches déhanchées. Lèvres précieuses et luisantes. Sa bouche respire, ouverte. Longues secondes où ne s’en échappe aucun souffle. Puis s’échappe en tout petits halètements. S’échappe. Ses yeux de cyan à demi clos, cils de lin brillant qui effleurent ma poitrine. Garçon de douze ans et demi qui chante dans la chapelle du collège. Mozart le fait bander — lui donne des frissons dans les stalles. Les choristes, à cette vue, fixent sur lui leur regard : ils savent. C’est vrai, il me l’a dit. J’embrasse. J’embrasse la courbe épanouie de son cou de miel doré.
Cellule_c1_r3	Cellule_c2_r3

Le choix entre les divers types de tableaux est intéressant. Ne pourrait-on avoir aussi le double liseré autour des cellules ?

Pour afficher deux textes en vis-à-vis, ce n'est pas encore vraiment au point. Il faudrait sans doute avoir un modèle de tableau spécial pour cet usage, et qui présenterait les caractéristiques suivantes :

• Nombre de colonnes limité à 2 (donc pas de choix sur ce point).
• Possibilité (mais pas obligation) d'imposer la largeur des colonnes (par exemple, 45 % + 55 %).
• Aucune bordure, sauf éventuellement un liseré séparant les deux colonnes (la bordure bleue à gauche du texte de gauche, dans "Bordure gauche", n'est pas vraiment utile).
• Largeur totale = 100 % de la page (inutile de donner un autre choix).
• Eviter d'avoir une marge trop importante à droite ou à gauche du tableau (comme c'est le cas maintenant pour le "Sans bordure").
• En revanche, la marge intérieure (entre les deux textes) doit être suffisante pour bien les séparer visuellement.
• Enfin, ce serait bien de pouvoir justifier à gauche et à droite les deux textes.

Actuellement, et avec les textes que j'ai essayés, le résultat est à peu près correct si la fenêtre est en pleine largeur, mais ça se gâte si on affiche une barre latérale.

Caprineus 19 février 2009 à 22:28 (GMT)

Difficile de servir avec précision des cas divers spécifiques avec une solution générique. On peut donc distinguer deux types de problème (et de solution !) : d'une part, c'était le point de départ, l'assistant à la création de tableaux, pour les cas simples, et de l'autre une demande spécifique de mise en page qui peut se résoudre avec un modèle approprié.

Création donc des modèles {{Citation bilingue}} et {{Citation courte}}, le second par souci d'harmonisation du style. J'ai conservé en option le liseré bleu (j'aime bien !), les colonnes du modèle bilingue sont justifiées, ce qui même sans liseré aide à la séparation visuelle, et la possibilité d'aligner la première colonne à droite a été ajoutée.

Pinocchio 21 février 2009 à 18:51 (GMT)

Merci pour toutes ces améliorations ! Je viens de faire quelques essais (avec visualisation des résultats) sur la page {{Citation bilingue}}.

• Je n'ai pas trouvé le moyen d'enchaîner plusieurs textes avec un titre différent pour chacun (textes latins) : seul le second titre apparaît. Est-ce une impossibilité du modèle, ou moi qui n'ai pas su mettre les éléments dans le bon ordre ? J'ai pourtant essayé plusieurs possibilités. (J'ai laissé tout tel quel, pour que tu puisses voir ce qui ne fonctionne pas.)
• On voit bien, avec les vers latins, que dans ce cas-là le principal problème est celui de la longueur des lignes. Il y a beaucoup de vers coupés – ce qui n'est pas très joli (et c'est encore pire si l'on affiche à l'écran une barre latérale). Je serais donc d'avis de supprimer les marges droite et gauche, ou du moins de les réduire fortement.
• (Pour garder la possibilité du liseré : ne serait-il pas possible de conserver les marges à peu près telles qu'elles sont quand il y a un liseré, mais que le texte occupe tout l'espace quand le liseré est absent ?)
• Certes, les marges supplémentaires droite et gauche signalent visuellement la présence d'une citation. Une alternative existe pourtant : pas de marge, mais des caractères différents, du type sérif (avec éventuellement un fond ivoire). Ce qui serait cohérent avec la proposition que j'avais faite précédemment, de créer un format particulier pour tous les textes reproduits, comme par exemple l'intégrale du roman L’Élu (actuellement, seul le chapitre VI est en sérif, à titre d'exemple).
• Pour revenir à la question des marges et à celle de l'équilibre entre texte et traduction (qui peuvent n'avoir pas la même longueur) : ne serait-il pas possible de prévoir dans le modèle {{Citation bilingue}} une fonction du type |%cit (pourcentage citation) et |%tra (pourcentage traduction) ?
  |%cit=40|%tra=60, par exemple, permettrait d'occuper tout la largeur, tout en ayant une traduction une fois et demi plus large que la citation. En revanche, |%cit=35|%tra=55 laisserait 10 % de marges, soit 5 % de chaque côté. Chaque contributeur pourrait ainsi adapter ces pourcentages à la présentation désirée.

Caprineus 22 février 2009 à 12:42 (GMT)

Juste pour voir, je viens d'employer le modèle {{Citation bilingue}} avec une poésie arabe d'Abû Nuwâs. Dans l'ensemble, le résultat est très acceptable (à condition de penser à faire la justification à droite). Ça confirme quand même :

• qu'il vaudrait mieux avoir systématiquement du sérif pour les citations (l'arabe en sans sérif, c'est pas bô !)
• que ce serait bien de pouvoir gérer la largeur des deux colonnes.

Caprineus 22 février 2009 à 13:44 (GMT)

• Enchaîner plusieurs textes avec des titres différent, c'est pas prévu. Ce que j'appelle blocs c'est plusieurs parties éventuelles d'un même texte.
• Les marges ont été un peu réduites mais il y a peu à gagner de ce côté là.
• Ajout d'une option %cit=n (la seconde colonne s'ajuste pour occuper l'espace restant) : c'est en effet l'idée la plus efficace.
• La police de caractères a été changée pour Times New Roman",Times,serif; (par ordre de préférence selon support par les navigateurs) et la taille ajustée.

Pinocchio 23 février 2009 à 13:17 (GMT)

Merci pour ces derniers progrès (oui, je sais, je suis casse-pieds – c'est mon côté perfectionniste...). Il me semble que maintenant tout est bien pour les citations bilingues (tu pourras déjà en voir une en oeuvre à l'article Uraniens). Si d'autres aménagements sont souhaitables, nous verrons cela à l'usage.

Grâce aux pourcentages, j'ai pu affiner le rapport des colonnes dans la citation anglaise, et ainsi faire mieux coïncider les textes.

Dans l'exemple en arabe de la page {{Citation bilingue}}, j'ai grossi l'écriture arabe avec <big></big>, ce qui est préférable par rapport aux caractères latins voisins. Il faudra un jour se pencher sur le rendu de l'écriture arabe, sans doute avec un modèle dédié.

Quant à la fonte latine utilisée dans les citations et traductions de la même page, je suis un peu surpris. En effet, si l'on compare avec le texte de la page L’Élu – Chapitre VI, on constate une nette différence de largeur des caractères, alors que c'est censé être du Times New Roman dans les deux cas : les caractères de L’Élu sont proportionnellement plus larges (voir en particulier la forme des o). Y a-t-il une explication à cette différence ?

(Ceci dit, dans le cas des citations bilingues, cette "étroitisation" des caractères est plutôt un bien, car elle permet de mettre plus de texte sur des lignes plutôt courtes. Mais dans une citation longue et sur une seule colonne, comme dans le cas des chapitres de L’Élu, ce ne serait pas agréable pour lire.)

Caprineus 23 février 2009 à 15:45 (GMT)

Oui j'ai remarqué aussi : c'est probablement un effet de la taille affectée au caractères dans ce modèle, les caractères changent non seulement de hauteur mais aussi de forme quand on fait varier le pourcentage de la taille. On peut imaginer qu'une taille exprimée en % ne tombe pas sur un nombre de points exact de la fonte. Pour le modèle Citation longue ils seront plus gros.

On peut éventuellement réduire d'un pixel le liseré qui est peut-être un peu voyant ? Ou diluer la couleur ?

Pinocchio 23 février 2009 à 16:46 (GMT)

La réduction d'un pixel pour le liseré me semble en effet une bonne chose.

Quant à la couleur... Ce serait bien d'avoir une signalétique commune à tous les textes cités – c'est-à-dire : aux citations (simples ou bilingues) dans le cours d'un article, aux citations sur une page spéciale (comme Les Passions schismatiques (extraits)), aux textes longs (en vers comme sur la page A Boy’s absence, ou en prose comme les chapitres de L’Élu), qu'ils soient intégraux ou partiels.

Cette signalétique comporterait le type de fonte (sérif), ainsi qu'une couleur de fond très légèrement plus sombre que le fond général (l'ivoire des chapitres de L’Élu est bien, à la fois sobre, visible, et évoquant un vieux parchemin...). On pourrait y ajouter des marges légèrement plus grandes que pour le texte normal, et éventuellement une gestion des paragraphes faisant plus "imprimé" (pas d'espace entre les paragraphes, mais un retrait de première ligne).

C'est en fonction de cette signalétique commune, une fois définie, qu'on pourra choisir la meilleure couleur pour le liseré optionnel. Il n'est peut-être pas absolument nécessaire de rester dans les tons bleus. Pourquoi pas un jaune assez soutenu, tirant plus sur le rouge que sur le vert (vieil or, peut-être) ?

Caprineus 24 février 2009 à 00:14 (GMT)

Liseré réduit et fonte uniformisée.

À propos de la couleur et de la signalétique commune, oui, c'est pourquoi j'ai choisi un bleu pour le liseré : c'est un pastel dans les mêmes tons qui a été proposé pour le modèle {{Réf Livre}} qui est en rapport avec les citations. Mais on peut en changer. Le cas de la citation longue (extrait ou texte complet) peut être différent, il ne subit pas les mêmes contraintes pour se signaler puisqu'il n'apparaitra probablement pas dans le cours d'un article, il est lui-même l'article, sa seul contrainte est la lisibilité, sa lecture à l'écran peut être longue.

Pinocchio 24 février 2009 à 13:26 (GMT)