Wikisource:Scriptorium/Septembre 2010

Questions
Choix éditoriaux Contenu des livres, mise en page, typographie, etc.	Questions techniques Utilisation de Wikisource, de la syntaxe d'édition, de l'interface.	Questions légales Droits d'auteurs sur les livres et questions juridiques.	Questions sur les Glyphes & caractères Codage et représentation des glyphes et caractères.	Scriptorium (Mois en cours, Archives, discussion générale en anglais) Pour laisser un message qui ne concerne pas les cas cités.
Communauté : Forum des nouveaux - Annonces - Projets - Actualités - Newsletter technique - Pages à supprimer

Lancer une nouvelle discussion Aller à la fin de la page

Septembre 2010

Adresse de la Société des amis des noirs, à l'assemblée nationale

Bonsoir, Je voudrais être sûre de l'inexistence de "Adresse de la Société des amis des noirs, à l'assemblée nationale, à toutes les villes de commerce, à toutes les manufactures, aux colonies, à toutes les sociétés des amis de la constitution" sur Wikisource. La recherche sur Wikisource me réserve des surprise souvent. Sur Google. N'est pas présentement consultable sur Gallica. Merci. --Ambre Troizat (d) 1 septembre 2010 à 20:10 (UTC)

Rien trouvé en recherche sur le titre, ou un morceau de texte (ne contenant pas d'apostrophe courbe...) Sapcal22 (d) 1 septembre 2010 à 20:32 (UTC)

Gallica  : c’est ce que tu cherches ? --Zyephyrus (d) 1 septembre 2010 à 22:39 (UTC)

Exact. Bien joué ! Merci à vous deux. --Ambre Troizat (d) 17 septembre 2010 à 21:47 (UTC)

Une liste des scans que nous cherchons

Nous avons tous, entre GoogleLivres aux États-Unis, Internet Archive, les diverses revues, etc., des "trucs" pour trouver un livre auxquels celui qui cherche le livre en question n'aurait peut-être pas pensé, ou pas accès. Je propose donc de transformer la page Wikisource:Demandes de scans à la BNF (puisque la BnF a, semble-t-il, préféré ne pas en tenir compte et n'a pas pensé que nous ferions peut-être plus vite un travail sur des textes qui nous plaisent en particulier) en une page où chacun pourrait mentionner les ouvrages ou textes dont il cherche les scans, librement et de manière non limitée. Cela ferait partie, je crois, de l'entraide de Wikisource. Enmerkar (d) 1 septembre 2010 à 21:43 (UTC)

Nous avons Wikisource:Textes demandés. Yann (d) 2 septembre 2010 à 13:20 (UTC)

Cette page des textes demandés n'est guère utilisée, et s'adresse plutôt aux lecteurs. Bref, que ceux qui le veulent mentionnent les scans qu'ils ne trouvent pas sur Wikisource:Demandes de scans à la BNF ; en s'y mettant à plusieurs, on aura plus de chances de mettre la main dessus. Enmerkar (d) 2 septembre 2010 à 22:16 (UTC)

Livres validés (déplacé depuis Discussion utilisateur:Zyephyrus)

Suite à la demande de Zaran ci-dessus, je me demande si j'ai bien fait d'ajouter certains livres à la liste des livres validés ? peut-être l'opération doit-elle être effectuée par un administrateur pour des raisons que j'ignore ? si c'est le cas, je t'indiquerai quels sont les livres que j’ai ajoutés à la liste. Cordialement, --Acélan (d) 31 août 2010 à 06:55 (UTC)

Yann a déprotégé il y a dix-huit mois la page des textes validés, laissant les contributeurs libres de décider de ce qu’ils validaient ; j’ai continué à valider ce qu’on me demandait de valider, mais le nombre de livres validables s’accroît et cela devient trop lourd ; Enmerkar parle depuis longtemps de sélectionner certains contributeurs de confiance à qui on donnerait des droits spéciaux ; Thomas a proposé à plusieurs reprises de supprimer ces validations et de ne conserver que les indicateurs du mode page ; de mon point de vue chacune de ces méthodes est bonne en soi dans une atmosphère de confiance réciproque, mais aucune d’entre elles n’est sans inconvénients si elle est appliquée à l’exclusion des autres. Ai-je oublié quelqu’un ? On en est là. Ton avis ? --Zyephyrus (d) 31 août 2010 à 08:20 (UTC)

Je serais plutôt de l’avis de Thomas : il suffit de cliquer sur la catégorie pour avoir la liste des textes validés, donc la liste fait double emploi, à mon avis. Je ne comprends pas ce que tu m'écris à propos de la suggestion d'Enmerkar ; en l'occurrence, que ne peuvent pas faire les contributeurs lambda ? --Acélan (d) 31 août 2010 à 11:25 (UTC)

Si on avait suivi la suggestion d’Enmerkar (à ce que j’ai cru comprendre, il voudra bien corriger si je déforme le sens de ses paroles), on donnerait un statut de « validateurs » à certains contributeurs choisis. Je crois me souvenir de n’avoir pas été la seule personne à ne pas avoir été d’accord avec cette proposition, qui réintroduit des inégalités parmi les contributeurs (et forcément de l’arbitraire), alors que les outils de Thomas avaient été me semble-t-il très soigneusement conçus pour éviter cela. Actuellement, je ne crois pas que personne ait validé des textes en y mettant ni de la mauvaise foi ni une volonté de vandalisme, et les contributeurs se sont montrés trop timides plutôt que pas assez à mon avis. --Zyephyrus (d) 1 septembre 2010 à 07:52 (UTC)

Je n’avais pas conscience que le processus de validation s’était ouvert à tous les utilisateurs, c’est pourquoi je continuais à te demander de temps en temps de valider des livres. Je suis d’accord avec Acélan, si cette page n’est pas protégée, elle fait double emploi avec la catégorie Textes validés . Ou alors elle pourrait servir à mettre en avant certains livres, mais pour cela il y a déjà la page Wikisource:Documents remarquables. Dans tous les cas, il faudrait modifier cette page Wikisource:Validation des textes. Cela ajoute encore un chose à reprendre dans l’aide de Wikisource. Zaran (d) 1 septembre 2010 à 08:39 (UTC)

Un dernier point à propos de la validation. Il est écrit en tête de la page Wikisource:Documents validés, que les textes de cette liste sont semi-protégés, c'est à dire non modifiables par des utilisateurs anonymes. Cependant ce n'est pas le cas de tous les textes de la liste. J'ai fait un essai : Les Misérables TI L1 est effectivement protégé, mais par exemple Je m’accuse… ne l'est pas. Il faudrait donc une réflexion sur la validation des textes autour de ces deux questions :

• qui peut marquer un texte comme validé ? (actuellement tout le monde, je pense que c'est bien)
• quelles doit être le statut d'un texte validé ? semi-protégé ? (pour l'instant ce statut ne semble pas clairement établi)

Zaran (d) 1 septembre 2010 à 08:47 (UTC)

Seriez-vous d’accord pour mettre cette discussion sur le scriptorium ? --Zyephyrus (d) 1 septembre 2010 à 09:10 (UTC)

Oui, bien entendu. Zaran (d) 1 septembre 2010 à 09:17 (UTC)

Idem. Les questions de Zaran sont intéressantes ; il serait souhaitable que les textes validés soient automatiquement "semi-protégés", si c'est possible.--Acélan (d) 2 septembre 2010 à 13:02 (UTC)

Question technique : pour semi-protéger un livre terminé, peut-on semi-protéger la page Texte entier de l’espace principal transclusions comprises ? Ou est-ce que ce n’est pas possible ? --Zyephyrus (d) 2 septembre 2010 à 13:26 (UTC)

Il y a la protection avec l'option "en cascade". Ça fonctionne partout sur Wikipédia, je ne vois pas pourquoi elle ne marcherait pas ici (attention cela a pour effet d'appliquer le niveau de protection à toutes les transclusions, modèle génériques inclus, et ce n'est pas sûr qu'on veuille semi-protéger par l'effet de la cascade des modèles qui sont protégés intégralement). Ceci dit, je ne suis pas favorable à la protection totale, vu le peu de nombre d'administrateurs capables de suivre les demandes de déprotection ou les problèmes (même si la demande est faite ici) : même sur Wikipédia les délais sont très longs, ici ce serait sans doute pire (et risquerait de tomber dans les limbes des archives de mois passés). Et puis on n'a pas le même niveau de vandalisme ici, Wikisource n'attire pas non plus les spammeurs, vu le peu de mise en évidence de leurs liens qui ici se repérerait tout de suite comme des intrus. Et puis notre sujet n'est pas polémique, on ne se bat pas sur des formulations ou le contenu puisque ici la totalité est nécessairement sourcée et cette source est sans ambiguité réelle de choix et dans le domaine public. — Verdy_p (d) 15 novembre 2010 à 01:58 (UTC)

Lettrines

Le problème de la trop grande diversité des modèles de lettrines a été soulevé en Août. Après avoir un peu étudié le problème, voici ce qui ressort :

• le premier modèle est historiquement {{Lettrine}}. Celui-ci est très mauvais pour plusieurs raisons :
  • comme expliqué par Thomas, il brise la continuité du texte : la lettrine n’est pas considérée comme attachée à ce qui suit. Ainsi, si le premier mot du paragraphe est Bonjour où la lettre B est une lettrine, la recherche du mot Bonjour (dans le navigateur ou dans un moteur de recherche) ne donnera aucun résultat.
  • les options de mise en forme sont réduites : il est par exemple impossible de choisir le nombre de lignes que devra occupé la lettrine.
• pour remédier à ces problèmes, le modèle {{Lettrine/2}} a été créé. Il me semble assez bon, et surtout, il es entièrement compatible avec le modèle {{Lettrine}}. Cela signifie qu’il faudrait simplement renommer le modèle {{Lettrine/2}} en {{Lettrine}} (et remplacer toutes les occurences du second modèle dans les pages où il est inclu, environ 500 pages). Je ne comprends pas pourquoi ceci n’avait pas été fait à l’époque de la création de {{Lettrine/2}}. Existe-t-il un problème que j’ignore avec ce modèle ?
• le modèle {{Lettrine2}} est défini à partir de {{Lettrine/2}} et ne présente pas énormément d’intérêt. On peut toutefois le garder pour des raisons de commodités. De plus, il est utilisé sur un nombre assez réduit de pages.
• le modèle {{Lettrine/I}} sert à afficher une image contenant la lettrine (dans le cas de lettrines très travaillées). Il ne présente pour moi aucun intérêt : autant inclure l’image avec l’option left pour la faire flotter à gauche. Par ailleurs, ce modèle n’est utilisé actuellement que sur 3 pages.

Parallélement à cela, j’ai commencé à travailler sur modèle Utilisateur:Zaran/lettrine. Celui-ci est compatible avec {{Lettrine}} et {{Lettrine/2}}. Il est assez proche de {{Lettrine/2}}, mais avec un réglage un peu plus fin de la taille et de la position des caractères. Ce modèle est encore susceptible de progresser, j’attends des remarques à ce sujet. Vous pouvez trouver une comparaison des deux modèles ici.

Ce que je préconise donc : le remplacement de {{Lettrine}} par {{Lettrine/2}} ou Utilisateur:Zaran/lettrine et la suppression de {{Lettrine/I}}. Zaran (d) 2 septembre 2010 à 15:45 (UTC)

Si je lis bien la documentation de {{Lettrine/I}}, ça ne revient pas à faire la même chose que de rajouter une image flottante, puisque la lettre incluse forme quand même un tout dans le texte (et on évite ainsi la disparition de l'initiale dans les moteurs de recherche). Pmx (d) 2 septembre 2010 à 21:24 (UTC)

Si on en croit la documentation oui, mais si tu regardes en détail, tu verras que la seule chose qui est faite en ce sens est l’utilisation du paramètre alt pour l’image. Ceci permet, comme c’est expliqué, d’avoir le texte complet lorsque l’on sélectionne l’image puis le texte. Cependant :

1. on peut utiliser le paramètre alt sans ce modèle
2. je n’ai pas l’impression que les moteurs de recherche considèrent une image (avec un attribut alt) suivi de lettres comme formant un seul mot. Je n’ai pas trouvé de façon sémantiquement cohérente d’obtenir ceci.

Quid des autres modèles ? Zaran (d) 2 septembre 2010 à 21:30 (UTC)

Je suis à 1000% pour la fusion et l’amélioration de tous ces modèles sous le nom {{Lettrine}}. La diversité ne peut que créer des problèmes.

Cdlt, VIGNERON * ^discut. 8 septembre 2010 à 10:03 (UTC)

Pages inversés dans djvu

J'ai commencé à passer Bas les cœurs ! en mode pages, mais j'ai un problème avec le chapitre 6 ou les pages 65-66 du djvu sont positionnées après la 68. Le cas s'est-il déjà présenté ? Doit-on modifier le djvu lui même pour remettre les pages dans l'ordre (pour l'instant je ne sais pas le faire) ou les réordonner dans la page Wikisource elle-même ? --Bgeslin (d) 3 septembre 2010 à 13:07 (UTC)

Cela se produit de temps en temps : pages inversées, pages doublées, pages venant d'un autre livre. Tant que ce n’est pas des pages manquantes, cela se règle assez facilement. Il faut réparer le fichier djvu lui-même. Sous linux, avec djvm -d (pour supprimer des pages) et djvm -i pour en insérer, c’est assez facile. Sous windows je ne sais pas. Si tu veux je peux réparer ce djvu. Zaran (d) 3 septembre 2010 à 13:21 (UTC)

Fait , j’étais lancé, je n’ai pas pu résister. . Zaran (d) 3 septembre 2010 à 13:31 (UTC)

Merci bien (j'y retourne...) --Bgeslin (d) 3 septembre 2010 à 14:25 (UTC)

Pages manquantes dans djvu

Bonjour
Je profite du sujet ci-dessus pour demander, justement, ce qu'on peut faire quand il manque des pages dans un fichier djvu. J'ai rencontré le cas il y a peu, j'ai laissé tomber pour passer temporairement à autre chose, mais j'aimerais bien pouvoir y revenir un de ces jours. Dans le tome I des œuvres de Diderot, il manque les pages 176 et 177 (en violet) ; à la place figurent les pages 178 et 179, qu'on trouve également là où elles devraient se trouver. Je précise que je n'ai jamais manipulé de fichier djvu… Cordialement, --Acélan (d) 3 septembre 2010 à 13:55 (UTC)

La manipulation technique pour ajouter les pages manquantes est, en elle-même très simple, et similaire à celle indiquée plus haut pour intervertir des pages… quand on dispose des pages manquantes. La difficulté est de trouver une autre source pour les pages manquantes. Parfois, entre Gallica, Internet Archive, et Google Books, on arrive à trouver la même édition que l’édition fautive, ce qui permet d’en extraire les pages manquantes. À part ça, je ne vois pas trop ce que l’on peut faire d’autre. Zaran (d) 4 septembre 2010 à 13:11 (UTC)

Fait --Maltaper (d) 4 septembre 2010 à 13:58 (UTC)

Merci, mais je ne les vois pas ; les pages 178 et 179 sont toujours en double et maintenant, tout est décalé à partir de la page 110 (fichier djvu 178) ; donc maintenant, il manque les pages 108 et 109 (djvu 176 et 177) et les pages 176 et 177. Et c'est peut-être très simple, mais je ne vois pas comment faire pour réparer tout cela, surtout que je ne travaille pas avec Linux. --Acélan (d) 4 septembre 2010 à 20:24 (UTC)

Je l’ai corrigé --Maltaper (d) 5 septembre 2010 à 00:15 (UTC)

Merci beaucoup, Maltaper ! curieusement, les anciennes pages s'affichent toujours, mais quand on est en modification, on voit bien les pages 176 et 177. --Acélan (d) 5 septembre 2010 à 06:53 (UTC)

Même après avoir rechargé ta page ? --Zyephyrus (d) 5 septembre 2010 à 07:35 (UTC)

Oui ; même en changeant de navigateur... --Acélan (d) 5 septembre 2010 à 08:48 (UTC)

Tu as essayé aussi de purger la page, le livre, le fichier…? Si tout cela échoue, il arrive souvent que le bogue se répare tout seul en quelques jours (du moins pour mes yeux profanes cela a l’air de se réparer tout seul). D’autres wikisourciens trouveront sans doute mieux ?  :) --Zyephyrus (d) 5 septembre 2010 à 09:03 (UTC)

On verra bien. De toute façon, le principal est que les pages sont bien là et que la correction redevient possible. --Acélan (d) 5 septembre 2010 à 09:37 (UTC)

Robert Carmille Biographie absente sur WP

Bonjour,
L'onglet Biographie est lié à une adresse de WP qui n'existe pas. La recherche proposée par WP conduit à la biographie de René Carmille, dont les dates de naissance et de décès ne correspondent pas (1886-1945 pour René au lieu de 1921-2008 pour le "sujet"). Mon ami Gougueulle propose la solution : Robert était le fils de René, ce que confirment les premières lignes du texte "Des apparences à la réalité..." cité dans l'artik.
De même, les deux liens "Citations" et "Fac-similés" conduisent vers des pages vides. Ne sachant pas rectifier, je livre ces détails à l'avisée communauté.
Cependant, distinguer les liens ad hoc de ceux en cul de sac (cf liens rouges de WP) me paraîtrait utile. Qu'en pensez-vous ?
Hop ! Kikuyu3 (d) 4 septembre 2010 à 11:37 (UTC) PS : newbie, ici, si c'est un marronnier, oups !

Quand cela concerne Wikipédia, il faut les mettre à jour. JackPotte (d) 4 septembre 2010 à 12:07 (UTC)

@JackPotte : +0,5, c’est aussi à nous de faire quelque chose de propre.

Robert Carmille : né en 1921, mort en 2008. A priori, je dirais qu’il n’a rien à faire sur la Wikisource. Apparemment, il y a une autorisation OTRS... (je vais demander une vérification, j’ai un gros doute !). Même avec l’autorisation, ce brave homme ne semble pas avoir fait grand’chose et surtout être en dessous du seuil d'admissibilité pour WP.

Sinon, inutile de sortir Google, à la toute fin de Des apparences à la réalité : le "fichier juif". Rapport de la commission présidée par René Rémond au Premier ministre : Mise au point par Robert Carmille, il est écrit : c’est René CARMILLE. Son fils Robert CARMILLE.

Je vais lancer une discussion plus bas sur le modèle titre qui serait à revoir complètement.

Cdlt, VIGNERON * ^discut. 8 septembre 2010 à 10:00 (UTC)

Guirlande de validations  : où en sommes-nous ?

Textes en cours^[1] et textes validés : barrés (ordre alphabétique)

1. Britannicus
2. Comme quoi Napoléon n'a jamais existé
3. De l’assujettissement des femmes
4. Des bouveries
5. Faust
6. Jane Eyre, tome 2
7. Jane Eyre, tome 1
8. La Chasse aux lions
9. La Femme pauvre
10. Le Peuple de la mer
11. Les Aventures de Huck Finn
12. Les Misérables, tome 3
13. Les Misérables, tome 2
14. Les Pêcheurs de perles
15. Lettres sur le commerce des grains
16. L’Ami Commun, Tome 1
17. L’Ami Commun, Tome 2
18. Mémoires de Louise Michel
19. Poèmes saturniens
20. Rip Van Winkle
21. Traité sur la tolérance
22. Le Petit Pierre

Avis ? Remarques ? --Zyephyrus (d) 6 septembre 2010 à 14:32 (UTC)

Ça fait déjà un certain nombre de livres validés. Je propose de finir de valider les livres en cours et de repartir en octobre sur un nouveau « projet du mois » (qui devrait peut-être être renommer en projet du trimestre vu le temps de maintien de la Guirlande ). Zaran (d) 6 septembre 2010 à 21:24 (UTC)

Un autre livre où il ne reste qu'une page à valider : Livre:Jean-François Champollion - Lettre à M. Dacier relative à l'alphabet des hiéroglyphes phonétiques.djvu Tpt (d) 8 septembre 2010 à 06:29 (UTC)

Fait --Zyephyrus (d) 8 septembre 2010 à 08:41 (UTC)

---

1. J’ai retiré un texte (Til l’espiègle) qui n’avait pas de contributeurs pour l’instant ; à remettre plus tard.

Saut de ligne dans la table des matières avec modèle {{table}}

Bonjour,

Comment éviter le saut de ligne entre les lignes de la table des matières, voir ici ? De quoi est-ce que cela dépend ? J’ai essayé de remplacer {{table}} par {{table}}, cela n’a rien changé. Pourtant ici le formatage obtenu avec le même modèle semble correct. Qui peut nous éclairer ? --Zyephyrus (d) 7 septembre 2010 à 07:03 (UTC)

Tu as encadré la table par la balise poem. Elle considère chaque retour à la ligne comme un <*br />, d'après mon expérience. Plus le retour à la ligne qui semble inclue dans le modèle {{table}}, ça donne un saut de ligne. Aristoi (d) 7 septembre 2010 à 07:30 (UTC)

Merci, Aristoi. Corrigé ! (J’ai ajouté un <div style="margin:8%;" >...</div> pour aligner les bords de ce qui avait la balise poem et de ce qui ne l’avait plus.)

Les wikisourciens effarouchés par les questions techniques ou les nouveaux qui ont eu du mal à suivre peuvent oublier tout cela ! Il faudrait maintenant repérer les numéros de pages des fac-similés correspondant aux différents textes déjà présents sur Wikisource. Appel aux wikisourciens qui savent feuilleter des livres et trouver des pages. C’est plus facile quand il y a une table des matières (généralement à la fin du livre, parfois au début) ; dans certains cas on est obligé de feuilleter tout le livre quand le sommaire est insuffisant, ou inexistant, ou faux... Ceux qui adorent ce genre de travail (c’est mon cas) vont pouvoir beaucoup s’amuser  :) --Zyephyrus (d) 7 septembre 2010 à 07:57 (UTC)

Pour les wikisourciens désireux de comprendre l’aspect technique, voici un schéma détaillant l’emploi du modèle {{table}} ou du modèle {{table}}. Ces deux modèles s’emploient de la même façon. N’hésitez pas à poser des questions. --Zyephyrus (d) 7 septembre 2010 à 08:44 (UTC)

Exemples de table des matières utilisant ce modèle {{table}} dans :

• Page:Le Fondement de la morale.djvu/196 (notez comment un numéro de section vide mais qui doit occuper la place pour déplacer le titre est passé sous la forme"&nbsp;", car sinon, le titre s'aligne à gauche sur les numéros de sections). — Verdy_p (d) 17 septembre 2010 à 13:11 (UTC)
• Page:Voltaire - Œuvres_complètes Garnier tome17.djvu/615 et pages suivantes : formatage avancé (noter les ajustements de l'interlignage et de l'indentation) — Verdy_p (d) 18 septembre 2010 à 12:41 (UTC)

Exemples: Le Coran (Traduction de Savary), 1821

• Page:Le Coran (Traduction de Savary, vol. 1), 1821.pdf/435 ou
• Page:Le Coran (Traduction de Savary, vol. 2), 1821.pdf/423 et suivantes.

Noter aussi comment dans la page d'index on peut aussi modifier la numérotation dans la liste des pages :

• Livre:Le Coran (Traduction de Savary, vol. 1), 1821.pdf ou
• Livre:Le Coran (Traduction de Savary, vol. 2), 1821.pdf

Les liens sont encore colorés (bleu ou rouge), et affichent l'état d'avancement (je réglera ça plus tard, en utilisant un modèle plutôt que la syntaxe simplifiée du wikilien).

Note : j'ai mis en place la structure générale, il y a des chapitres à continuer (tous les entêtes de chapitres/sourates sont présents), s'il y a des volontaires pour la saisie (l'OCR de Wikisource ne fonctionne plus...).

Je vais trouver une solution pour les références internes au document lui-même, en créant des modèles plus tard pour faciliter la correction de ces notes et leur rendu correct dans le document, aussi bien en mode page que dans le texte complet. Je sais comment faire mais je reporte ça à plus tard. — Verdy_p (d) 8 septembre 2010 à 13:18 (UTC)

Note je ne suis pas musulman, mais je considère que le Coran à lire en français d'une source réputée est un élément culturel essentiel à connaître, même pour des non-croyants, agnostiques, ou croyants d'autres religions. En disposer d'une copie fidèle est important pour ne pas raconter n'importe quoi, et en se basant sur une source fiable et reconnue depuis plus de 200 ans. Je ne me permettrai pas de modifier le texte tel qu'il est, et je fais en sorte de respecter la graphie originale (par exemple « les croyans » et non « les croyants » dans l’orthographe actuelle, ce qui ne gène pas la lecture et ne demande aucune modernisation poru que ce soit parfaitement lisible et compréhensible). C'est aussi pour ça qu'il fallait mentionner l’année précise de publication de cette réédition. La première publication imprimée de 1783 (par son auteur lui-même) est bien plus difficile à mettre en forme, et n'apporterait pas grand chose de plus (même s'il est possible que celle de 1821 ait déjà modifié quelques mots ou graphies). D'autre part seul le deuxième volume est disponible actuellement dans l'édition de 1783. Le manuscrit original (non imprimé) est en fait encore antérieur (vers 1756 il me semble), l'autre manuscrit étant perdu ou dans une bibliothèque non référencée, ou dans les mains d'un collectionneur privé qui ne l'a pas mis en ligne.

J'ai repris le travail qui avait été commencé en 2006, puis laissé de côté, pour le mettre en mode page. Certains chapitres sont déjà complets et à valider.

Je trouve dommage que la BnF n'ait même pas un seul exemplaire de l'édition de 1783, ni même de celle de 1821 (dont il existe des scans propres, ici ceux numérisés par Google depuis la Bibliothèque de Monaco) dans ses catalogues : on les trouve dans les collections de bibliothèques européennes (Monaco, Belgique, Suisse, Suède, Royaume-Uni...) et américaines. — Verdy_p (d) 8 septembre 2010 à 17:08 (UTC)

{{Table}} et {{Table2}} unifiés

Notes:

• {{Table}} ou {{Table2}} sont maintenant totalement équivalents et unifiés (le second redirige vers le premier). En effet la seule différence entre les deux était que {{Table2}} incluait la possibilité d'avoir une zone réservée (et paramétrable) en marge droite pour les numéros de page, cette zone étant par défaut de seulement 10 pixels auparavant dans {{Table}}, et donc presque toujours insuffisante. Maintenant {{Table}} utilise une marge par défaut de 0 pixels au lieu de 10, mais admet le paramètre "largeurp" utilisé déjà dans {{Table2}} pour réserver en marge droite l'espace des numéros de page à ne pas utiliser pour les titres.
• De plus, il n'utilise plus le tableau (qui dans certains cas provoquait une coupure en bas de certains caractères comme "p", "j", "q") mais des "div" simples (les numéros de section et de pages sont des flottants normaux), et le code est maintenant accessible sans difficulté aux lecteurs brailles par une disposition logique du texte. J'ai aussi corrigé divers bogues d'alignement, et veillé aussi à ce que le code HTML ou CSS généré soit le plus simple possible (pour faciliter le travail des indexeurs du web), par une optimisation conditionnelle en fonction de ce qu'on a réellement à afficher.
• Le code est commenté pour plus de clarté. J'ai testé ça sur IE6, IE7, IE8, IE9 beta, Firefox, Safari, Chrome, et Opera (sous Windows et Linux), et il est conforme avec CSS1, CSS2, CSS3, HTML4, HTML5 et XHTML. Je n'ai pas testé sur MacOSX mais ça devrait être bon vu le nombre de combinaisons testées (s'il y a un problème merci de me le dire avant de tout réverter). — Verdy_p (d) 12 septembre 2010 à 23:35 (UTC)

J'ai réglé les problèmes sur les vieilles versions de Firefox (2.0, 3.0 et 3.6), et certains autres problèmes sur IE6 et IE/Mac (j'ai trouvé un émulateur pour MacOSX). Cette fois ce sont 35 versions (!!) de navigateurs que j'ai testées, y compris des navigateurs pour smartphone (Nokia, Ericson, Sagem : certains modèls dont j'ai pu trouver des émulateurs sur le Web) et WebTV (par exemple téléviseurs Philips HDTV, qui utilise un moteur Opera en version embedded). Mais je n'ai pas testé l'iPhone (ça doit fonctionner à priori comme Safari pour Mac, que j'ai testé). Testé aussi pour la compatibilité WAI (accessibilité aux lecteurs d'écran), et pour ceux qui ont des tailles de police agrandies.

Un dernier problème que je vais régler : les largeurs indiquées pour les numéros de section (largeurs=) et de page (largeurp=) sont:

• actuellement en « pixels logiques » uniquement (px, qui correspond en fait plutôt à environ 2 minutes d'arc angulaire de vision à la distance normale d’observation du support concerné, plutôt qu’à une dimension physique, sachant que les unités « métriques » mm, cm, 'in, pt, sont elles aussi « logiques » et calées sur les supports la plupart du temps à 96 pixels logiques par pouce logique, soit 192 minutes d’arc par pouce logique ou 7,6 minutes d’arc par millimètre logique, les unités métriques devenant absolules uniquement sur un support imprimé de sorte que les pixels imprimés ne correspondent en fait jamais aux pixels logiques, comme cela se produit maintenant aussi pour les écrans haute définition dont les pixels physiques sont bien plus petits que des 2 mintues d'arc angulaire),
• et non en cadratins (em) (hauteur du corps de la police, celle-ci étant par défaut définie selon le média mais voisine de 12pt logique (mais MediaWiki réduit cette taille par défaut avec "font-size:x-small" qui généralement donne 87% de cette taille, et le navigateur peut imposer un agrandissement des polices, ce qui modifie les tailles en em ou en en, mais pas celles indiquées en unités métriques logiques ou pourcentage).

Je vais ajouter un paramètre permettant de changer cette unité, afin de permettre l'affichage correct avec des polices agrandies pour les déficients visuels (et non le zoom du navigateur qui agrandit toutes les unités y compris les pixels), car cela ne touche pas aux dimensions en pixels, et ces largeurs deviennent incorrectes si les polices ne sont pas réglées à 100% dans le navigateur. Des largeurs en em rendront l'affichage moins aléatoire et moins dépendant des polices utilisées (peut-être faudrait-il un second modèle, ou bien corriger tous les index existants qui utilisent "largeurp" et "largeurs" implicitement en pixels ?). — Verdy_p (d) 17 septembre 2010 à 13:24 (UTC)

On peut regretter que CSS ne dispose pas d'unités métriques absolues, ni d'unités visuelles angulaires absolues (en degrés/minutes/secondes, plutôt qu'en pixel logique qui ne correspond à rien de très précis !), ni de possibilité de régler la distance absolue d'observation (pour traduire les unités angulaires en unités métriques absolues) ; CSS se base en effet sur la résolution du support (en pixels logiques par unité métrique logique, donc en arc angulaire) et non sa définition (en pixels physiques par unité métrique absolue, par exemple en dpi). De nombreux navigateurs confondent toutes ces unités (et on explique alors les différences de rendu des dimensions, d'un système à l'autre).

Note: les unités visuelles devraient être des angles solides (en stéradians, car cela correspond à la distribution spaciale de l'énergie lumineuse perçue par les cellules rétiniennes) et non des angles d'arc (en radians en degrés), mais si on se base sur un cône d'observation, il suffit de mesurer l'angule d'ouverture du secteur d'intersection du cône avec un plan passant par l'axe de ce cône : il n'y a pas d'ambiguité (tant que l'objet observé n'est pas panoramique car alors tout est faussé et le modèle de vision est modifié largement par le fai que l’œil une définition beaucoup moins grande quand on s'éloigne de l'axe d'observation dans la zone de sensibilité de la macula (qui couvre un angle ne pouvant guère dépasser 30 à 40 degrés) : on en déduit qu'il existe une résolution maximale au delà de laquelle l’oeil ne perçoit plus rien (sauf en se rapprochant et sacrifiant l'observation d'une partie du document hors de la macula, non focalisée et donc floue), et donc qu'il existe une résolution maximale et un nombre maximum de caractères qu'on peut mettre dans une ligne pour que ces caractères soient clairement lisibles sans fatigue.

Ensuite les angles sont assez petits pour être assimilables à leur sinus, ce qui traduit simplement les angles en longueur mesurée perpendiculairement à l'axe d'ovservation, mais cela influence malgré tout les dimensions maximales des supports et le confort de lecture ; sinon on doit déplacer l'axe d'observation mais surtout refocaliser l'oeil à des distances variables, ce qui provoque la fatigue de lecture sur des supports trop larges, et explique pourquoi on préfère nettement lire des textes présentés en colonnes pas trop larges, en juxtaposant les colonnes si besoin : plus que le déplacement de l'axe de l'oeil par les puissants muscles autour de l'œil, c'est la focalisation par l'iris qui est très fatigante (on ne peut donc pas lire longtemps des supports trop larges) : un écran large n'est pas destiné à permettre d'afficher des lignes plus longues mais à, soit présenter des colonnes de texte multiples, soit à offrir une vision panoramique hors de la macula (mais sans nécessairement que cette zone soit focalisée).

Pour un confort de lecture, les lignes ne devraient jamais excéder 35em (maquette 1), les maquettes 2 et 3 sont carrément illisibles et fatigantes sur un écran large, qu'il vaudrait mieux pouvoir faire pivoter verticalement (comme les feuilles de papier et les livres dont la largeur idéale des pages correspond à la distance normale d'observation, à environ 70cm, et donne une largeur voisine de 18 cm pour le texte).

Un texte trop large sera impossible à lire pour quelqu'un atteint de presbytie (même corrigée partiellement pour la vision rapprochée) car il a perdu sa capacité à focaliser sans arrêt à des distances différentes d'un bout à l'autre de la ligne. La presbytie étant très fréquente (et débutant en fait ses effets dès l'age de 20 ans chez pratiquement tout le monde pour devenir handicappante vers 40-50 ans), il faut en tenir compte, sinon nos textes ne seront tout bonnement pas lus, car trop inconfortables.

Je recommande nettement la maquette 1 pour le confort de lecture, qui est aussi celle la plus proche des livres imprimés (après des siècles de constatations, scientifiquement justifiées, par les éditeurs qui voulaient vendre leurs livres afin qu'ils soient confortables à lire), et tout support qui n'accepterait pas la maquette 1 (35em de large) sera impropre à la lecture.

Si vous réduisez la taille des polices, il faut aussi vous assurer que la colonne de texte ne dépassera jamais 35em de large, quitte à augmenter les marges ; on peut réduire en revanche les colonnes jusqu'à environ 16em minimum (sachant que les colonnes de textes doivent aussi être séparées d'au moins 2em dans la même taille de police), en dessous c'est aussi fatiguant car on a de trop nombreux retours à la ligne (et cette fois ce sont les muscles autour de l'oeil qui fatiguent, et la justification des lignes rend celles-ci difficiles à identifier et suivre horizontalement) : en conséquence, jamais plus de 2 colonnes de texte dans une page, sauf si ce sont de simples listes de mots ou de nombres qu'on lit en fait plus verticalement qu'horizontalement, et qui ne doivent jamais être justifiées dans ce cas (jamais de justification en dessous de 16em) !. — Verdy_p (d) 18 septembre 2010 à 16:01 (UTC)

Où sont les livres ?

C'est une question idiote de grand débutant : existe-t-il dans Wikisource un endroit où sont stockés les livres "terminés", prêts à être téléchargés en PDF ? --Seymour (d) 7 septembre 2010 à 15:22 (UTC)

Les pdf ne fonctionnent malheureusement pas sur Wikisource pour l’instant. La Déclaration des droits de l’homme rend une page blanche …

Nous pouvons par contre imprimer facilement un « Texte entier » en mode texte. grâce à l’option « Version imprimable » du menu à gauche de l’écran. Tu peux nous demander de composer pour toi un document entier si la version Texte entier ne figure pas encore dans la boîte titre de l’œuvre, il est possible de le faire rapidement. --Zyephyrus (d) 7 septembre 2010 à 16:39 (UTC)

La catégorie:Livres terminés, ou bien, un peu plus large, la liste des Documents validés, te donnent les textes dont la conformité à l’édition de référence a été garantie par (au moins) deux contributeurs. --Zyephyrus (d) 7 septembre 2010 à 18:09 (UTC)

On peut parfaitement obtenir une version imprimable du livre entièrement en HTML, et à partir de là générer un PDF (ou un XPS sous Windows) en sélectionnant un pilote d'impression générant un tel fichier à la demande.

Ça marche très bien, et en tout cas ne nécessite pas le générateur de PDF (largement bogué et inutile) de Wikimedia.

Il est même possible de générer la mise en page complète du livre entier. Par exemple :

Rapport de 1990 sur les rectifications orthographiques/Complet

Qui est la version mise en page prête à l'impression et paginée du texte, qui respecte même la pagination d’origine. Cependant, comme ce document a été généré pour ressembler à la publication originale (moyennant de petites imperfections très mineures sur la mise en page, dépendante du navigateur utilisé et des polices installées), et que le PDF original lui-même n'est pas libre dans sa version numérique (alors que son contenu l'est selon le droit français applicable au contenu du document, voir sa page de discussion) il n'utilise pas le mode page, mais une simulation (la comparaison doit se faire en externe en téléchargeant le PDF d'origine, et on peut comparer le PDF imprimé avec le document numérisé ici sur WikiSource et imprimé avec le navigateur). Le même livre étant aussi consultable page par page, ou en version linéaire pour une consultation à l'écran sans pagination :

Rapport de 1990 sur les rectifications orthographiques

J'avais poussé assez loin la simulation des pages pour offrir une vision la plus exacte possible du contenu, mais effectivement cela demandait un effort supplémentaire pour traduire la mise en page et la mise en forme du texte (par exemple pour l'affichage en deux colonnes, certaines tables en deux colonnes étant coupées de façon optionnelle lors de la présentation paginée).

Cela reste une démonstration de ce qu’il est possible de faire, sans utiliser le générateur bogué (et totalement inutilisable) de PDF de Wikisource. La voie des versions directement imprimables est à mon avis la meilleure à suivre, ce générateur de PDF ferait mieux d'être supprimé. On a accès à la version imprimable directement dans la « Boîte à outils ».

Ce serait bien de veiller dans tous les livres à ce que leur rendu dans le mode imprimable fonctionne de la façon attendue, ou que ces livres proposent une version imprimable dans une sous-page dérivée, si certaines mises en forme plus avancées sont nécessaires.

— Verdy_p (d) 8 septembre 2010 à 09:27 (UTC)

La question de Seymour porte sur les PDF, pas sur les versions imprimables. Évidemment, à partir d’une version imprimable on peut en faire un PDF mais ce n’est pas à la portée de la majorité des lecteurs (dont moi-même).

@Verdy_p : tu as fait un sacré travail sur le Rapport de 1990 mais il est malheureusement inutilisable.

Il est utilisable pour ce qu'il est : c'est bien une numérisation immédiatement exploitable. Je pense que tu veux dire que cela ne peut pas être un modèle réutilisable pour d'autres livres. S'il est fait ainsi c'est pour assurer d'une part de son exactitude, et sa vérifiabilité (mise en forme comparable avec l’original), mais aussi parce qu'il n'était pas possible d'importer le PDF (le PDF est une numérisation non libre de droits, alors que son contenu l'est légalement, et que leurs auteurs ont voula la dissémination du document). Face aux erreurs de transcriptions qu'il y avait avant, cette version a entièrement corrigé les différences avec le texte original.

Il est totalement utilisable, navigable (oui il y a des liens entre toutes les sections et sur tous les termes qui renvoient au Wiktionnaire, lisible directement à l'écran, imprimable à l'identique, exportable, même si certaines choses pourraient être reprises dans des modèles génériques utiles à d'autres livres... — Verdy_p (d) 8 septembre 2010 à 12:47 (UTC)

Il me semble donc que c’est une fausse bonne idée.

Je ne dit pas qu'on doit tout faire comme cela. Mais la précision nécessaire à ce document a rendu ce travail nécessaire, afin que le document serve effectivement de source fiable non altérée ne serait-ce que d'une seule lettre ou d'un seul accent. Tout pouvait être reproduit, c'est ce que j'ai fait. — Verdy_p (d) 8 septembre 2010 à 12:47 (UTC)

Ce qu'il faut retenir, c'est qu'on doit travailler à améliorer la version imprimable. On laissera le générateur PDF de côté pour qu’il produise le résultat attendu, car pour l'instant il ignore des éléments qui sont bien destinés à être imprimés tels qu'indiqué dans le code HTML, et il étend à tord tous les liens en cassant absolument tout. Ce générateur de PDF ne doit pas servir à guider ce qu'on doit ou peut faire, à cause de ses trop nombreux bogues, car tout ce qu'on ferait pour s'adapter à lui ne serait de toute façon pas stable non plus quand il sera corrigé (s'il l'est un jour...). Il existe des outils pour générer des PDF, mais le plus simple (fourni avec Windows maintenant) est d'imprimer vers un document XPS. D'autres pilotes d'impression existent pour imprimer en PDF, ou d'autres formats. Dans tous les cas c'est la version imprimable qui servira à générer un document exporté, alors que la version pour lecture linéaire à l'écran produira des coupures de page maladaptées, et une mise en forme générale souvent incorrecte, comme c'est le cas souvent quand on imprime des pages web qui ne prévoient aucune pagination. parmi les choses indésirables dans la version imprimable : le sommaire automatique Wikimedia (utile seulement pour la consultation à l'écran), une bonne partie des liens de navigation sur le site, et la première page le titre de l'article, et en dernière page les infos sur Wikisource lui-même. Pour résoudre ça, on cache le sommaire dans une section avec la classe "noprint", on force un saut de page juste avant le texte et juste après, afin de pouvoir choisir de ne pas imprimer la première et la dernière page (merci pour les économies de papier...). Ces astuces sont présentes dans la version paginée prête à imprimer. Il est cependant dommage qu'on ne puisse pas demander au navigateur de ne pas rajouter ses propres entêtes et pieds de page dans des documents mis en forme, et de ne pas ajouter des marges supplémentaires au delà de ce qui est nécessaire (les marges ajoutées par le navigateur ne devrait pas dépasser 17 mm, même si elles sont laissées blanches, et s'il ajoute des entêtes, il doit les placer dans ces marges uniquement ; certains navigateurs sont gourmands et prennent de la place sur le papier, mais certains navigateurs ne permettent pas non plus de régler ces ajouts, par exemple Firefox ou Chrome qui ne possèdent toujours pas d'aperçu avant impression ni aucun moyen de modifier ces entêtes et pieds de page ajoutés, même s'ils respectent des marges non excessives ; personnellement j'imprime les docs sous IE qui permet de supprimer ces ajouts dans les marges). — Verdy_p (d) 8 septembre 2010 à 12:58 (UTC)

Ceci dit, on est tous d’accord, le générateur de PDF est une catastrophe qui bien souvent ne génère rien du tout et qui oublie des contributeurs si il génère quelque chose (la génération se fait uniquement quand il n’y a pas la balise pages, alors que cette balise devrait être toujours utilisée ou presque). Mais ta solution ne me semble in fine pas forcément meilleures (en d’autres termes : vaut-il mieux un outil utilisable mais à ne pas utiliser ou bien un outil inutilisable mais à utiliser ? je pencherais plutôt pour le premier qui me semble être un moindre mal).

Dans l’idéal, dans la barre de gauche, je pense qu’il faudrait plutôt un lien exporter ce document et proposer différents formats (PDF, ePUB, etc.) et différentes options/styles comme texte modernisé ou texte original, pagination optimisée ou pagination originale, etc (laisser les coquilles dans le Rapport de 1990 me choque un peu, ne pas avoir la possibilité de choisir de les imprimer ou non me choque encore plus). Je suis aussi optimiste, tout se règle avec le temps (il me semble que des développeurs se penche en ce moment même sur ce générateur).

Cdlt, VIGNERON * ^discut. 8 septembre 2010 à 10:19 (UTC)

Les coquilles sont laissées car c'est conforme à l'original. J'ai préféré insérer une note pour les signaler, plutôt que de risquer d'insérer une inexactitude ou une interprétation personnelle ou fausse. Au lecteur de juger avec les quelques notes présentes, mais il n'était pas question de les corriger ne serait-ce que d'une virgule, dans ce qui est un document de référence fréquemment cité. S'il apparaît de la part d'un site officiel une correction corrigeant ces coquilles, elles seront corrigées ici, mais pas avant. — Verdy_p (d) 8 septembre 2010 à 12:47 (UTC)

Pour reprendre tes points sans couper la lecture :

1. tu m'a compris, je parle bien du fait que ton exemple n’en soit pas un, car il est trop particulier pour servir de modèle. Accessoirement, je parle aussi du fait que je ne sais pas faire un PDF à partir de la version imprimable et que je ne suis probablement pas le seul (du coup pour nous, malheureusement, la seule solution pour avoir une PDF est le générateur).

Il y a plein de pilotes d'impression dispos (même libres) qui génèrent un fichier PDF. Ça s'utilise comme une imprimante, sauf qu'au lieu d'aller vers une imprimante, au moment d'imprimer tu auras un dialogue de sélection du fichier cible. Pareil sous Windows avec le générateur XPS (format propriétaire de Microsoft, concurrent du PDF d'Adobe) ou le format ePUB (encore très confidentiel et pas stable en fait, la plupart des ePUB que j'ai chargés, même depuis GoogleBooks ne fonctionnaient tout bonnement pas, chaque fois ils supposait une version spécifique d'une visionneuse non précisée...).

Bref je ne recommanderai pas le format ePUB pour le moment (il y a encore besoin de nombreux développements des outils tiers), mais seulement les formats PDF (à lire avec Adobe Reader ou tout autre visionneuse de PDF, y compris celle intégrée dans Google Chrome) et XPS (à lire avec la visionneuse Microsoft XPS, fournie avec Windows 7 et installable gratuitement pour XP et Vista).

Prend une version imprimable, imprime avec le navigateur, en sélectionnant cette pseudo-imprimante installée. Tu obtiens le fichier qui tu peux alors archiver et visionner séparément. Et là ça marche parfaitement, sans aucun des bogues de l'actuel générateur de PDF utilisé par une extension mal finie pour Mediawiki. — Verdy_p (d) 8 septembre 2010 à 16:57 (UTC)

2. comme tu le sous-entend toi-même ce rapport est assez particulier.

3. on peut aussi laisser les coquilles *et* les enlevés. Tu parles de rester conforme à l’original mais pourtant tu introduis des notes (ce que je considère comme une altération, et une altération assez perturbante puisque le rapport contient déjà un note).

Ces altérations sont clairement distinguées du texte, ne serait-ce que par leur couleur, et leur emplacement. Et le texte a ses notes qui sont incluses dans la pagination et la mise en forme originale (d'ailleurs ces appels de notes mêmes sont invisibles sur le document imprimé, il n'y a donc aucune altération, on peut lire ces notes ou ne pas les lire).

Fallait-il aussi supprimer les liens internes ? Pourtant ces liens sont normalement invisibles. — Verdy_p (d) 8 septembre 2010 à 16:57 (UTC)

Il me semble plus intéressant d’utiliser le modèle {{Corr}} et de pouvoir choisir entre afficher ou non la correction (avec par défaut, le texte non corrigé évidemment).

Je ne connaissais pas ce modèle à l'époque où j'avais fait cette version, et tous les appels de note ne sont pas que des coquilles. Par exemple les orthographes en "oe" et non "œ" sont semble-t-il volontaires, et je ne voulais pas les corriger, mais signaler l'absence de ligature à laquelle un lecteur (ou un correcteur) aurait pu s'attendre, faute de voir à côté le document original. Les notes sont là pour justement ne PAS corriger le texte tel qu'il est. — Verdy_p (d) 8 septembre 2010 à 16:57 (UTC)

Si un site officiel fait une correction, corriger brutalement le texte me semble aussi une mauvaise idée car on perd de l’information. Là encore, le modèle {{erratum}} est là pour ça.

Pourquoi pas, mais le document ayant été lu et relu par énormément de monde depuis 20 ans, je doute sincèrement que c'était réellement des coquilles... et donc je n'attends la publication d'aucun erratum, mais seulement une éventuelle réédition. Son origine (l’imprimerie nationale l’ayant composé ayant une très bonne réputation pour produire des documents exempts d'erreurs, et publiant rapidement de tels errata si jamais ça se produit, surtout quand il s'agissait ici d'un texte officiel qui fait l'objet de recommandations dans diverses administrations qui en font un usage réglementaire à force quasi-obligatoire, ne serait-ce que dans l’Education nationale pour assister les professeurs afin qu'ils ne sanctionnent pas les auteurs de ce qu'il considèrent encore comme des « fautes » alors que ce sont des graphies officiellement admises). — Verdy_p (d) 8 septembre 2010 à 16:57 (UTC)

Cdlt, VIGNERON * ^discut. 8 septembre 2010 à 13:19 (UTC)

{{Interprojet}}

Bonjour, le modèle interprojet affiche sur le menu de droite un lien qui n'est pas adapté au style vector comme sur La Légende dorée, si quelqu'un pouvait se charger de mettre à jour common.js… Tpt (d) 9 septembre 2010 à 04:52 (UTC)

Menu de droite ? Le lien interprojet s’affiche à gauche normalement, sous le style vector comme sous les autres, et n’est pas destiné à mordre sur l’espace du texte ; je n’ai pas bien compris ce que tu as voulu dire, peux-tu préciser ? --Zyephyrus (d) 9 septembre 2010 à 07:22 (UTC)

Sur mon Firefox 3.6.8 le modèle fonctionne exactement pareil sous monobook et vector. JackPotte (d) 9 septembre 2010 à 13:38 (UTC)

Pourtant sous le même firefox Ubuntu et Windows ainsi que chrome le lien s’affiche par rapport aux autre beaucoup plus gros et avec une puce. Tpt (d) 9 septembre 2010 à 19:27 (UTC)

Je confirme que chez moi aussi (XP, Firefox 3.6.9) le "Wikipedia" est plus gros et a une puce. Aristoi (d) 9 septembre 2010 à 20:35 (UTC)

Fausse manœuvre

En enlevant les pages publicitaires sur les Raymond Roussel pour obtenir des premières pages de titres , j'ai décalé toutes les pages. Je n'y ai pas pensé à temps .

Solution 1 : Rajouter des pages blanches à la place de celles que j'ai enlevées ?

Solution 2 : Refaire un nouveau « match and split » par dessus l'ancien ? Cela risque-t-il de casser quelque chose ?

Ou voyez-vous un autre moyen de corriger le décalage créé sur les index La Doublure , La Vue et Chiquenaude  ? Merci, wikisourciens expérimentés, de votre aide. --Zyephyrus (d) 10 septembre 2010 à 09:51 (UTC)

Le problème des pages blanches au début d'un livre m’a toujours interpellé. D’après Vigneron, elles présentent un réel intérêt pour les bibliothécaires, pour avoir par exemple des informations sur l’histoire de l’édition. Donc je pense qu’il ne faut pas les enlever … surtout quand les pages suivantes ont déjà été crées. De plus les pages d’index permettent de choisir la page de titre à afficher, ce n’ai que pour commons que cela pose un problème. Dans le cas présent, pourquoi ne pas simplement restaurer la version précédente sur commons ? Il y a aussi la possibilité d’ajouter des pages blanches au début. Je peux le faire si tu le souhaites. La solution match & split me semble mauvaise car il faudra recorriger à la main les erreurs d’appariement (il y a toujours quelques imprécisions). Une dernière solution aurait été de renommer toutes les pages du livre. J’ai cru voir sur le scriptorium que cela avait été activé pour les administrateurs. Zaran (d) 10 septembre 2010 à 11:45 (UTC)

Merci beaucoup, Zaran, de tes réponses. Je les reformule à ma manière pour m’assurer que je les ai bien comprises, et précise ce qui n’est pas encore tout à fait clair pour moi.

Nous pouvons d’une part remettre des pages blanches et en mettre deux de plus pour remplacer la jaquette publicitaire de Google du fichier initial, (voir historique).

Il faut garder les pages ajoutées en tête par Google Books (lisez la page en français pour vous en convaincre !) qui ne sont pas publicitaires mais requises légalement si Google Books a effectué cette numérisation. ::: C'est une question de droit, et d'ailleurs le contenu de ces pages l'indique clairement. De même qu'on n'a pas le droit d'ôter les filigranes Google dans les pages numérisées. En revanche cela veut dire que les fichiers PDF produits par Google ne sont pas importables sur Commons (restriction: utilisation on commerciale) mais ici c'est possible dans le but de produire la couche texte en mode page, sachant que ce sera finalement uniquement cette couche texte qui sera utilisée et publiée (le fichier PDF pouvant ensuite être effacé plus tard une fois la couche texte finalisée (et qui ne contiendra plus rien de ce qu'a produit Google, autre que le contenu du texte libre lui-même. Ce ne sont pas des pages de pub. — Verdy_p (d) 12 septembre 2010 à 22:47 (UTC)

Bref: ton fichier importé sur Commons sans ces pages est illégal (de même que tout fichier dérivé de type .djvu créé à partir de celui-ci). Même si le livre lui-même est dans le domaine public, le fichier numérisé ne l’est pas et est bien protégé par une restriction de licence non libre (utilisation non commerciale). Ce qu'on fait ici sur Wikisource ce n'est pas créer des PDF ou des .djvu mais bien créer des couches texte entièrement libres indépendantes de ces fichiers numérisés ! Et le fichier avec ces pages est légal, mais soumis à une licence restrictive (usage non commercial), donc pas éligible non plus sur Commons. — Verdy_p (d) 12 septembre 2010 à 22:50 (UTC)

Personnellement je préconise de ne charger aucun livre de Google Books sur Commons ni aucun .djvu dérivé mais uniquement ici (avec mention de la licence commerciale de Google, comme c'est requis), le temps de faire la couche texte en mode page, puis masquer ce fichier ici pour qu'il ne soit plus distribué, les visiteurs n'ayant alors plus que la couche texte. Créer un .djvu à partir du PDF est un abus de licence, Google pourrait demander à supprimer TOUS ces fichiers illégaux de Commons, mais comprendrait qu'on les importe ici temporairement le temps de faire la couche texte, à la seule condition qu'on n'altère pas les pages de licence ni les filigranes, comme c'est demandé par Google lui-même, car ce serait légal et conforme à sa licence. bien sûr on n'a pas vocation à faire la publicité de Google, mais tant qu'on a besoin de ces fichiers pour faire les couches texte indépendantes de ces fichiers, c'est admissible.

Il n’y a aucune raison de supprimer des pages des PDF de Google (qui sont de bonne qualité) ou les renuméroter. Ce n'est pas nécessaire pour produire le livre en couche texte, et pour utiliser le mode page qui est le seul endroit où on aurait ces fichiers, le but étant de créer les couches texte et de les promouvoir à la place des fichiers PDF. vous perdez votre temps à créer des .djvu, en plus de vous placer dans l'illégalité, et d'abuser des règles de Commons (qui n'accepte QUE des fichiers libres pour tous et sans restriction commerciale). Ici en revanche, on peut faire entorse temporairement le temps de faire les couches texte, ensuite on peut supprimer ces fichiers ou placer un lien vers le fichier détenu et distribué par Google (mais ce ne sera plus nécessaire). Ne chargez sur Commons que les numérisations de livres du domaine public soit faites par vous mêmes à partir d'un exemplaire dont vous disposez, soit numérisés par des tiers qui ne placent pas de restriction commerciale sur ces fichiers. — Verdy_p (d) 12 septembre 2010 à 23:02 (UTC)

Il me semble d’ailleurs que la première de ces deux pages ajoutées pourrait être une reproduction de la page de titre, ce qui permettrait de savoir immédiatement, sans avoir à l’ouvrir ni à se reporter à la documentation, ce qu’est le fichier image, au lieu que tous les livres restent impossibles à distinguer les uns des autres ; nous aurions donc 45 pages commençant par la page de titre, au lieu de 40 pages actuellement, pour l’exemple ci-dessus ; ce serait une première solution qui pourrait être satisfaisante.

Match et split étant écartés, il resterait d’autre part une deuxième solution : si un administrateur renommait toutes les pages du livre actuel, ce qui serait en effet possible, la numérotation des pages texte à transclure pourrait-elle ne pas être décalée par rapport à celle des images ? Que faudrait-il faire pour cela ? --Zyephyrus (d) 10 septembre 2010 à 12:24 (UTC)

La solution 1, largement plus simple en pratique et plus correcte dans l'esprit. Il ne faut retirer de pages blanches (pour les bibliothécaires, les bibliophiles et tout ceux qui travaillent sur des livres ou même la SIB). Il est prévu pour les fichiers multipages (DJVU, PDF, TIFF) de pouvoir choisir quelle page afficher, donc inutile aussi de forcer le titre sur la première page. Cdlt, VIGNERON * ^discut. 10 septembre 2010 à 14:25 (UTC)

C’est prévu aussi sur Commons ? --Zyephyrus (d) 10 septembre 2010 à 14:29 (UTC)

C’est même prévu d’abord pour Commons (ça bouge beaucoup du côté de Commons en ce moment). Cdlt, VIGNERON * ^discut. 10 septembre 2010 à 14:47 (UTC)

Je suis assez d’accord avec Vigneron, faut-il que j’ajoute des pages blanches ? Sinon Zyephyrus, je ne suis pas sûr de comprendre ta dernière question. Si les pages était renommées, il faudrait également changer en conséquence, sur toutes les pages où elles sont transcluses, les champs from et to de la balise <pages/>. Dans le cas présent, cela ne représente que quelques pages (chacun des livres est transclus en une fois), mais je ne sais pas si c’est ce que tu voulais dire. Zaran (d) 10 septembre 2010 à 20:53 (UTC)

Précision: de nombreux livres chapitrés ont leurs pages transclues en plusieurs parties, et dans ce cas il faut modifier les différents chapitres. De plus si on remplace un fichier par un autre qui a échangé des pages, il faudra renommer/ échanger les pages dont les couches texte ont été déjà créées dans l'espace "Page:", et revérifier les liens vers elles. Faites au plus simple: la numérotation des pages dans l'espace "page:" n'a pas à être identique à celle du livre, elle peut aussi être dans le désordre, ce n'est pas trop génant, puisque ces pages sont éditées indépendamment les unes des autres, et qu'on peur faire la page d'index quand même dans le bon ordre sans modifier le fichier, et en présentant la numérotation originale des pages du livre à la place des numéros de page du fichier. Noter aussi que la page d'index ne sert que pour le fichier lui-même: si un livre est numérisé en plusieurs fichiers, il faudra plusieurs pages d'index dans l'espace "livre:". En général on a plusieurs pages d'index si on a plusieurs tomes, et je suggère que les noms de fichiers soient nommés d'une façon qui permet de les trouver dans le bon ordre (et chaque page d'index a un champ pour insérer les liens vers les différents volumes/fichiers d'une même publication). — Verdy_p (d) 12 septembre 2010 à 23:18 (UTC)

Bonjour, Non, il ne faut pas garder les pubs de Google (ou autres, j’ai vu des fichiers de la BNF avec la même chose). C'est inutile, et ce texte est certainement soumis à un copyright. Les scans dans le domaine public partout (pas seulement aux Etats-Unis), doivent être mis sur Commons, pas sur Wikisource, quelque soit leur provenance. Yann (d) 14 septembre 2010 à 13:35 (UTC)

Ce n'est pas "inutile", c'est nécessaire pour la légalité de la chose. Le texte de ces pages est très clair à ce sujet, les ignorer c'est une violation manifeste de copyright et de la licence Google Books (qui n'est pas une licence libre). Ces textes Google Books n'ont pas leur place sur Commons (violation des règles strictes de Commons).

Bref tu te trompes lourdement. Tu les as lues ces pages de Google ? Manifestement non. Oui, il y a de la pub pour Google Books (on n'est pas obligé de pointer les pages directement dessus dans nos index) ici, mais surtout ce sont des pages de licence. Qu'on aime ou non ces pages, on n'a pas le choix autre que celui de les garder (le fichier sera donc ici uniquement le temps de faire la couche texte, ensuite on pourra supprimer ces fichiers pour éviter l'effet publicitaire).

TOUS LES FICHIERS .djvu qui ont été créés à partir des scans téléchargés depuis GoogleBooks, en supprimant ces pages (certains même en supprimant les filigranes GoogleBooks en bas de page) sont totalement illégaux.

Tu invoques la loi américaine avec raison (les serveurs sont aux USA), mais tu veux faire usage du "fair use" qui n'est pas adéquat ici puisque le "fair use" nécessite toute de même de citer la source explicitement). Les textes seuls sont dans le domaine public (je veux dire les originaux), mais 'pas les numérisations de ces textes. A ce sujet l'Union européenne mène une enquête en ce moment à ce sujet et connait déjà le problème posé par Google Books (qui ajoute de plein droit et légalement, un copyright sur les fichiers numériques, alors que les textes eux-mêmes sont du domaine public).

Si on veut des scans entièrement libres, il faut disposer du livre original et faire les scans soi-même et les publier soi-même sous licence libre. Les PDF de GooglBooks ne sont pas' libres, et sont soumis au copyright (là dessus seulement je suis d'accord avec toi, mais cela ne concerne pas que les pages initiales de GoogleBooks mais la totalité des pages du document, puisque c'est le format numérique du fichier lui-même qui est protégé, car c'est un travail supplémentaire indépendant du contenu de domaien public, qui autorise l'application d'un copyright ; on est dans le même cas que pour les bases de données contenant des éléments de domaine public, ou que n'importe quel texte soumis à copyright, qui contient pourtant des mots d'une langue de domaine public; ce qui est soumis au copyright c'est ce travail supplémentaire qui n'est pas l'oeuvre originale de domaine public). On doit retenir ici la définition du domaine public américain (qui toutefois respecte aussi les restrictions applicable aux domaines publics des autres pays membres du WIPO, c'est à dire la plupart des pays du monde, qui émettent déjà des ISBN, des ISSN, du droit d'auteur protégé, des brevets, des oeuvres littéraires, musicales ou artistiques ; même la Corée du Nord a adhéré au WIPO, il n'y a guère que des pays sans gouvernement pour ne pas être membre, par exemple la Somalie, ou les pays en transition, la République de Chine et la Palestine ayant adhéré à titre exceptionnel dans un régime transitoire... qui dure, alors que le Tibet ou la Sahara occidental, bien que toujours reconnus internationalement comme entités, n'ont pas de gouvernement reconnu ; d'autres entités sont reconnues exceptionnellement mais pas dans tous les pays: Chypre du Nord, l'Abkhazie, la Transnistrie, le Kosovo ; et pour eux il faut se baser sur leur reconnaissance officielle ou non par les USA afin de savoir qui définit et protège son domaine public). — Verdy_p (d) 17 septembre 2010 à 15:20 (UTC)

class="text alineanegatif"

J'essaie d'obtenir l'effet décrit. Apparemment ça marche quand on l'utilise dans une page de mode page, mais l'effet disparait dans le document obtenu par transclusion de ces pages. Voir Essai sur l’inégalité des races humaines/Table et les deux premières pages appelées. Sur un cas qui m'intéresse, le Modèle:ThéâtreDébut et ThéâtreFin ne fonctionne plus, sauf lors du premier affichage quand on modifie. En prévisualisation ou en affichage normal, pas d'effet. Voir Mémoires historiques/Index. Il y a une explication, ou je me fais des idées ? --Wuyouyuan - discuter 10 septembre 2010 à 14:21 (UTC)

L’effet décrit ? Tu souhaites avoir les classes : text *et* alineanegatif ? J’ai retiré la classe text qui me semble inutile mais cela ne change rien (bizarre).

A la lecture de MediaWiki:Common.css alineanegatif ne semble pas dépendre du namespace (étrange).

Mais bon, je suis pas vraiment un spécialiste du css, il y en a un dans le coin ? Cdlt, VIGNERON * ^discut. 10 septembre 2010 à 14:33 (UTC)

Cela vient du fait que parmi les deux sélecteurs suivants, le premier est prioritaire:

• #text p { text-indent:2em; margin: 0.2em 0;} (dans Common.css: sélectionne par id="text", mais s'applique à TOUS LES paragraphes inclus dans la totalité de la page, puisque l'élément id=text" est généré dans la page automatiquement, à tous les niveaux...)
• .alineanegatif p { text-indent:-2em; margin-left:2em; } (sélectionne par class="alineanegatif", mais s'applique à tous les paragraphes dans un élément de cette classe)

Une classe est toujours MOINS prioritaire qu'un ID. C'est une TRES mauvaise idée d'appliquer un style global sur un élément avec un ID qui contient tout le reste car ça empêche d'utiliser une classe... Bref, entre les deux définitions de text-indent ici, la première sépplique car elle est plus sélective.

Cet alinéa indenté forcé m'emmerde réllement, de même que le fait qu'il impose aussi des marges verticales aux paragraphes (ce qui est carrément stupide: soit on indente un paragraphe et on n'ajoute aucune marge, soit on met des marges, mais jamais les deux en même temps).

Bref, la première règle CSS est en trop, ou est trop sélective, ou ne limite pas sa portée aux seuls paragraphes de premier niveau dans l'élément #text.

Tout sélecteur contenant un "#" ne doit jamais être suivi d'un autre sélecteur d'élement combiné par une espace (qui signifie tout élément inclu dedans à tout niveau. Si on met un "#", il faut absolument limiter la portée avec un combinateur autre que l'espace.

le fichier "main.css" est donc bogué.

D'ailleurs je ne voit pas l'intérêt pour lui de faire:

• #text p { text-indent:2em; margin: 0.2em 0; }

A la limite on peut faire (avec un combinateur ">" plus restrictif que l'espace):

• #text > p { text-indent:2em; margin: 0.2em 0; }

Mais il est nettement préférable de faire:

• .alineapositif p { text-indent:2em; margin:0; } (texte indenté positivement), ou
• .alineanegatif p { text-indent:-2em; margin:0; margin-left:2em; } (texte indenté négativement), ou
• .text p { text-indent:0; margin: 0.2em 0; } (texte non indenté avec marges de séparation de paragraphe, comme sur Wikipédia)

Ce qui permet ensuite de changer de classe dans un div...

Note l'élément <div id="text">... </div> est ajouté spécifiquement ici que Wikisource, après le titre de page dans bodyContent, mais uniquement dans l'espace de nom principal (pas dans l'espace "page:"). Visiblement il a été fait pour gérer l'affichage des numéros de page en marge (lors de la consultation du texte entier) qui est tout aussi bogué: ces numéros de page devraient être flottants à gauche (positionnés dans la marge du div relatif conteneur) et non dans un div séparé, avec un code javascript très compliqué: qui d'aiilleurs bogue complètement aussi dans Wikisource anglais (car en plus son CSS a oublié de mettre l'attribut "position:relative au div conteneur...

Cet élément ajouté est totalement inutile. On pouvait se passer totalement du javascript pour générer les numéros de page dans l'affichage du texte intégral, le javascript n'étant là alors que pour les cacher ou les afficher avec une seule règle de style à basculer.

Je peux en faire une démonstration facilement. — Verdy_p (d) 12 septembre 2010 à 01:08 (UTC)

La section à corriger dans Common.css est la suivante:

* éléments du modèle DébutTexte */
#text-wrap {
 margin-left:3em; 
 position:relative;
}
#text-container {
 width:100%;
}
#text {
 text-align:justify;
 width:36em;
 margin:0px auto;
}
#text p {
  text-indent: 2em;
}
#text pre {
  background-color: #ffffff;
  font-family: sans-serif;
  line-height: 150%;
  border: 0px;
  padding-left: 2em;
  margin: 0;
  white-space: pre;
}

TOUS ces sélecteurs sont beaucoup trop larges. Et l'élément <div id="text"> est inséré par le javascript bogué lorsque qu'on affiche une page de l'espace principal. Ce javascript est tout aussi inutile et dangereux, il casse les pages en introduisant les sélecteurs ci-dessus à la totalité du contenu de la page et à tous les niveaux. Chez moi j'ai écrasé les fonctions javascript correspondantes dans mon thème monobook pour qu'elles ne fassent rien, et l'effet indésirable disparait complètement (du moins tant que personne ne génère dans les pages un div ayant cet ID très sélectif mais combiné de façon pas assez sélective)

Et le Javascript fautif est http://wikisource.org/w/index.php?title=MediaWiki:PageNumbers.js&action=raw&ctype=text/javascript (c'est lui qui casse les pages de façon totalement inutile en déplaçant du contenu dans le div ajouté : c'est un javascript global de wikisource.org et non local au projet francophone...)

On peut le désactiver en écrasant dans son monobook.js la fonction suivante:

function init_page_layout() {}

Mais alors il n'y a plus de numéro de page... Je vais travailler chez moi à un autre script moins bogué pour remplacer cette fonction.

— Verdy_p (d) 12 septembre 2010 à 01:28 (UTC)

Je n'ai pas trouvé de façon simple de désactiver le script: parfois ça marche, parfois non, car le script s'exécute dans un ordre indéfini (selon l'ordre et les temps de téléchargement). En revanche, j'ai trouvé un moyen de faire en sorte que le script ne touche pas à la page de façon destructive:

<div style="position:relative"><div id="text-wrap"></div><div class="text">

...
</div>

Un div vide avec l'id "text-wrap" est inséré, ce qui suffit à désactiver le déplacement du contenu qui suit dans la class "text". Le tout est dans un div de position relative afin que les numéros de page (insérés dans "text-wrap" soient correctement positionnés). L'ennui est qu'il n'est alors plus possible de gérer plusieurs maquettes, un ennui bien mineur ici. Grce au div vide "text-wrap", il n'y a plus ajout d'un div conteneur avec l'id="text".

et les alinéas négatifs marchent alors. Le code est dans Essai sur l’inégalité des races humaines/Table. — Verdy_p (d) 12 septembre 2010 à 09:04 (UTC)

Noter qu'on a toujours le style suivant par défaut dans le "main.css" global de MediaWiki (dans le thème "monobook" sur bits.wikimedia.org/skins-1.5, ou dans le thème "chick" ou le thème "vector"):

p {
    margin: .4em 0 .5em 0;
    line-height: 1.5em;
}

Autrement dit il sépare les paragraphes de marges, mais ne les indente pas. Pourtant, ici on a défini des alinéas indentés dans Common.css seulement ainsi:

.text p {
  text-indent: 2em;
}
.alineanegatif p {
  text-indent: -2em;
}
.indentation { // ne fonctionne pas... car pas assez sélectif
  text-indent: 2em;
}

Ici on change l'indentation mais on a oublié d'annuler les marges qui deviennent indésirables dans un text indenté. Ces derniers devraient remettre les marges des paragraphes à zéro.

Méfiance avec le combinateur "espace" entre selécteur de classe ".text" et sélecteur d'élément "p" ! Sa portée est très grande... — Verdy_p (d) 12 septembre 2010 à 09:22 (UTC)

On peut mettre les marges à zero avec la classe "poem", malheureusement elle est définie ainsi dans "Commons.css":

.poem p { 
    margin-top: 0em ! important; 
    margin-bottom: 0em ! important; 
    text-indent: 0em !important;
}

L'indicateur "!important" est réellement en trop : il empêche toute altération non seulement des marges (à zéro), mais en plus de l'indentation (à zéro). Une feuille CSS ne devrait jamais mentionner "!important" (inutile ici), autrement que par un autre style "!important" réservé aux utilisateurs... — Verdy_p (d) 12 septembre 2010 à 09:31 (UTC)

Je ne suis pas assez compétent pour comprendre ce qui précède, mais cela renforce mes soupçons sur l'expression de la transclusion de masse

<pages index="Jaurès - Action socialiste I.djvu" from=9 to=13 /> (ou une autre).

J'ai l'impression qu'elle force des instructions de mise en page qui s'exercent ensuite. Voir les différentes versions de Action socialiste où j'ai essayé de mettre un sommaire dans un espace plus large que le petit texte transclus placé au-dessus. Après de multiples essais, il a fallu revenir à l'appel des pages du texte une par une. Et le phénomène d'une mise en page différente en premier affichage pour corriger, et en prévisualisation ensuite, peut être mis en évidence sur cette version, entre autres. Certes, modifier risque de faire s'effondrer pas mal de mises en page basées là-dessus. --Wuyouyuan - discuter 12 septembre 2010 à 14:22 (UTC)

Non, la transclusion de masse fonctionne très bien et n'est pas responsable de ces bogues. Le problème vient entièrement du Javascript bogué "MediaWiki:PageNumbers.js", et de sa feuille de style boguée inclue dans "Common.css" (pas assez sélective pour "#text p") qu'il ajoute aux pages HTML pour que le navigateur vienne les modifier. Si on transclut les pages une par une, on aura exactement les mêmes bogues. La transclusion de masse reste à conseiller (surtout si on transclut plus d'une dizaine de pages).

Ce cadre est une transclusion

Source : Discussion utilisateur:Ambre Troizat

Tentative de texte juxtalinéaire

Je viens de créer un document bilingue breton-français avec le breton à gauche et le français à droite , en transclusion, chacune des deux colonnes étant une section d'une page du même :Livre. Les moines de l'Ile-Verte Pour les bretonnants: c'est le faux qui a mystifié les érudits et même F. M. Luzel pendant des années. C'est à peu près ça, sauf que les deux colonnes sont décalées en hauteur d'une fraction d'interligne, celle de droite un peu plus basse. C'est sûrement dû à une subtilité de bas niveau qui m'a échappé. Si quelqu'un peut m'aider à trouver. --Wuyouyuan - discuter 13 septembre 2010 à 05:31 (UTC)

Résolu par un valign="top".

Il semble que l'inclusion de la section étiquetée préserve le saut de ligne présent à la fin de la ligne <section end=""> dans une des colonnes, alors que ce saut de ligne est absent à la fin de la seconde puisqu'il est éliminé et suivi automatiquement d'un noinclude pour le pied de page du mode page.

L'astuce est alors d'utiliser valign="top" dans ton tableau à deux colonnes.

Mais pourquoi n'insères tu pas un tableau similaire dans le code du mode page ? tu aurais un aperçu correct aussi dans le mode page (si le code de ce tableau ne doit pas être transclu dans le texte complet, car le tableau se prolonge sur plusieurs pages, tu peux placer ce code supplémentaire du tableau dans une section "noinclude".) — Verdy_p (d) 13 septembre 2010 à 07:43 (UTC)

Le problème vient en fait d'un autre bogue (désolé pour toi ThomasV, c'est bien ton code qui pose problème à tout le monde et pas qu'ici!) du code Javascript qui modifie les pages HTML générées : dans la première colonne il modifie la balise <td> pour y mettre un attribut style="position: relative;", mais pas dans la seconde cellule pour la colonne de droite. Puis il génère des balises supplémentaires pour placer les numéros de page en marge toutes dans la première cellule, mais pas dans la seconde... Et dans le code qu'il génère, il ajoute un saut de ligne parasite en fin de première cellule.

Tu peux voir la ligne supplémentaire que le javascript génère en bas de première colonne, simplement en sélectionnant une portion de texte entre la première colonne et la seconde colonne : on voit très bien alors cette ligne en bas, sous le tableau... Cette ligne n'a rien à faire là dans les pages. Si on désactive javascript, la page ne sera pas modifiée, et sera correcte.

Ce javascript bogué (celui en charge d'afficher les numéros de page en marge et de générer les maquettes ou layouts commence un peu à m'énerver (et il énerve maintenant aussi les utilisateurs du WikiSource anglais dont les pages sont carrément cassées à cause d'attributs de style oubliés ou qu'il enlève carrément (par exemple il enlève dans les pages des classes nécessaires au rendu, et déplace le code HTML de façon incorrecte, de façon en fait totalement inutile et très dangereuse, en ajoutant du HTML superflu; en plus son code CSS est carrément erroné). — Verdy_p (d) 13 septembre 2010 à 07:58 (UTC)

@verdy : quand un script comporte des erreurs, la meilleure chose à faire est de les signaler, de tender de les comprendre et de proposer de les corriger.

Justement c'est bien ici (le Scriptorium) l'endroit le plus approprié pour en discuter (puisque le script lui-même n'a pas de page de référence facilement accessible ou stable). Si je le dis ici, c'est pour signaler l'anomalie à un endroit où on a une chance que l'auteur du script passe voir ce qui se passe, et pour tenter de l'expliquer et le corriger (ou bien pour contourner le problème si ça peut se faire facilement). — Verdy_p (d) 17 septembre 2010 à 17:03 (UTC)

Note: cela affecte aussi les présentations utilisant classe="deuxcolonnes" (les numéros de page ne sont pas non plus là où ils devraient, il faudrait placer les numéros de page en vis-à-vis de chaque colonne, dans sa marge qui devrait être au minimum de 3.5em en taille normale (en fait plus dans la taille réduite à 80% des numéros de page, ce qui fait que les numéros de page disposent de 3.5/0.8=4.375em, sachant que chaque chiffre fait environ 0.6em de large et les crochets 0.4em chacun, et laisse la place pour 5 chiffres, presque 6) ; idéalement on devrait aussi pouvoir régler la taille des marges afin d'assurer assez de place pour les numéros de page (qui ne sont pas toujours des numéros mais parfois un nom de page non numérotée — plus ou moins abrégé — comme "Introduction", "Avertissement", "Table des matières", "Index", "Sommaire", "Présentation", "Préface", "Remerciements", "Table des illustrations", "Post-scriptum", "Errata", "Appendice", "Annexes", "Références", "Notes bibliographiques", "Bibliographie", etc...). — Verdy_p (d) 17 septembre 2010 à 17:14 (UTC)

@wuyouyuan : pour afficher du texte juxtalinéaire, il convient d’utiliser l’extension DoubleWiki, pas de dupliquer le texte sur plusieurs wikis.

ThomasV (d) 13 septembre 2010 à 08:39 (UTC)

Pas d'angoisse: le texte de Les moines de l'Ile Verte est tout entier dans le wiki français, et n'existe pas ailleurs (pour l'instant) donc les dogmes ne sont pas atteints (l'esprit, je ne dis pas). Aussi bien, la transclusion d'une page contenant le modèle:Iwpage aboutit à un échec. Le texte de l'autre wiki n'apparait pas sur le document, alors qu'il s'affiche sur la page appelée. Voir plus haut. --Wuyouyuan - discuter 13 septembre 2010 à 09:31 (UTC)

Je plussoie Thomas. Le texte en breton ne devrait pas être ici mais plutôt sur la Wikimammenn (qui est en pleine recherche de textes bretons comme tu le sais) ainsi Doublewiki qui est précisément conçu pour répondre à ton besoin serait utilisable.

Iwpage n’est pas vraiment parfaite mais c'est le modèle à utiliser et améliorer (surtout que des transclusions interprojets sont prévus par les devs Mediawiki ce qui résoudrait les bugs actuels).

Cdlt, VIGNERON * ^discut. 13 septembre 2010 à 10:10 (UTC)

Certes, le breton est mieux sur le WS breton (et avec des gens qui manient le breton moins mal que moi). J'ai quand même donné déja ( les Soniou Breiz-Izel sont en attente de bonnes volontés ). Je réclame seulement le droit de m'amuser un peu, et de faire des démonstrations. Après, on aligne ou on généralise. Et dès que iwpage fonctionnera, je serai un grand supporter. --Wuyouyuan - discuter 13 septembre 2010 à 11:58 (UTC)

Ok.

S'il y avait le texte entier, on verrait que l’ouvrage est en français (c'est un recueil documenté), et contient de nombreux passages en latin (que j'ai corrigé dans le mode page), et si le texte extrait ici est effectivement en breton il l'est avec sa traduction en français à côté (puisque l'ouvrage est en français).

On voit très bien la fin du passage en latin dans la première page importée (avec entre parenthèses et italique à la fin "Archives des Côtes-du-Nord", bel et bien en français tout à fait moderne, ces archives n'existant sous ce nom que depuis la seconde guerre mondiale, et renommée seulement très récemment depuis le changement de nom du département), juste au dessus du texte bilingue breton-français. L'ouvrage original étant principalement en français, il a sa place ici... (mais quid du reste de l’ouvrage ?).

Note que l'ouvrage original lui-même devait réduire un peu les polices, je l'ai fait aussi dans le mode page, et ça tient exactement dans le même espace.

Par sécurité, selon les polices utilisées, j'ai aligné les paragraphes dans un tableau en séparant les cellules, ce qui fonctionne alors parfaitement avec des polices agrandies dans le navigateur, en maintenant les alignements qui sont effectivement volontaires dans l'original qui procède à ces alignements aussi dans une présentation en tableau (même si les filets de délimitation sont invisibles). Sans cela, même avec des ruptures de ligne forcées, on n'atteindrait pas l'objectif, et on aurait une présentation affreuse et illisible en visualisant la page avec des polices agrandies à 150%, ou sur un écran peu large (smartphone). La réduction de police ici fonctionne dans les marges imposées de la colonne de texte de la "maquette 1" (mais la "maquette 3" fonctionne mieux sur les smartphones à écran étroit car elle n'impose pas alors les barres de défilement horizontal en forçant une largeur minimale de "35em" qu'ils ne peuvent pas afficher avec les polices sélectionnées par défaut).

Le texte est effectivement voulu bilingue. (L'ordre "logique" de lecture semble bouleversé, mais le tableau maintient sa logique de lecture en colonnes ET en lignes, on lit donc le tableau dans les deux sens, même si on préfère la lecture verticale ; mais le HTML ne permet pas de modifier l'ordre de remplissage et ne possède pas de notion de "règle de tabulation verticale" permettant de tabuler une unique colonne de texte par rapport à cette règle avant de passer à la colonne suivante, et n'offre QUE les tables pour le faire (avec un remplissage d'abord dans le sens horizontal). — Verdy_p (d) 18 septembre 2010 à 13:47 (UTC)

Je sais et je t’en remercie (tu es un des 5 contributeurs de la Wikimammenn \o/).

Que tu testes, que tu t’amuses, ok, cela m’arrive souvent aussi. Par contre, là tu refais quelque chose qui existe déjà. Il vaudrait mieux essayer d’améliorer ce qui existe plutôt que de se disperser.

Là on a un peu un cercle vicieux : si personne n’utilise iwpage, cela motive pas non plus les developpeurs pour l’améliorer. Pour info, quel est ton problème avec iwpage ? (si tu n'indique pas de problème, personne ne viendra la corriger ; là encore cercle vicieux). JeanFred me dit que la transclusion interprojet serait déjà dans le trunk du svn de mediawiki mais que cela prendra encore quelques mois pour que la validation/activation soit faite. Donc wait and see. En attendant, j’utilise assez abondamment ce modèle et je vous engage à faire de même.

Cdlt, VIGNERON * ^discut. 13 septembre 2010 à 13:29 (UTC)

Faisons assaut de vertu. J'ai créé environ 300 pages qui contiennent Iwpage. Mon problème, c'est que je ne peux toujours pas créer des documents interwiki lisibles par le lecteur moyen (le fac-simile avec page de texte en regard est pour le lecteur initié). Mais tu es au courant de la déception de ceux qui créent les documents bilingues du Barzaz Breiz dans le WS breton. --Wuyouyuan - discuter 13 septembre 2010 à 13:51 (UTC)

En y revenant, je vois un bug (ou incompréhension de ma part) sur Iwpage dans une page: quand le texte du wiki lointain contient une note, elle ne survit pas au transfert, ou plutôt elle n'a pas de quoi s'afficher. Voir Page:Luzel - Gwerziou Breiz-Izel vol 1 1868.djvu/442 ou Page:Luzel - Gwerziou Breiz-Izel vol 1 1868.djvu/468.--Wuyouyuan - discuter 14 septembre 2010 à 00:09 (UTC)

Quelques remarques :

1. les notes sont solidaires du texte, elles ne devraient pas en être séparées (ceci dit, je t’accordes que dans le cas présent, cela fait bizarre).

2. pour moi, le mode page n’est pas un mode de lecture (lecteurs initiés ou pas) mais un mode d’édition. Il faut éviter de trop détourner les outils existant (si ils ne sont pas conçus pour, ils est normal qu’ils ne soient pas optimisés pour) ; il vaut mieux utiliser ce qui fonctionne déjà et sinon attendre la stabilisation d’outils comme http://toolserver.org/~magnus/book2scroll/ (potentiellement intégrés directement dans Wikisource dans le futur).

3. qu’appelles-tu des "des documents interwiki lisibles" ?

4. Pourquoi veux-tu absolument transclure pour faire des juxtalinéaires alors que DoubleWiki est justement exactement là pour ça et qu’elle le fait toute seule automatiquement ? (probablement que ta réponse sera liée à ma question précédente).

Digression : du coup, il me vient une question sous forme de paradoxe sorite, à partir de combien de caractères, mots, phrases, doit-on séparer le texte étranger ? Il est bien évident que si un livre francophone de 50 000 mots contient un seul mot en latin, on ne va pas ouvrir un livre sur la Vicifons. Mais à partir de quand cela devient-il pertinent ? 10 % du texte ? 30 % ? (en imaginant -probablement à tort- que ce ne soit qu’une question de quantité)

Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 12:50 (UTC)

Quelques précisions :

• pour ceux qui ne sont pas au courant, DoubleWiki est une extension de MediaWiki qui sert à afficher un texte bilingue. Exemple ici.
• Cette extension fonctionne mal pour le moment, et il est difficile de lui faire aligner correctement le texte avec sa traduction. Pour cette raison, je l’ai complètement réécrite il y a un mois. Le jour où nous aurons droit à une mise à jour, il sera donc peut-être possible d’aligner correctement le texte et sa traduction.
• Toute autre méthode (tableau fait à la main en dupliquant le texte d’un autre wiki, utilisation de iwpage en mode texte) est déconseillée. En particulier, le modèle iwpage ne sera pas amélioré afin de permettre un affichage bilingue. De plus, il ne faut pas utiliser le modèle Page à l’intérieur d’un tableau. Si vous êtes trop impatients pour attendre la prochaine mise à jour du code, ayez au moins l’intelligence de transclure les pages sans utiliser le modèle Page.

ThomasV (d) 14 septembre 2010 à 13:21 (UTC)

• DoubleWiki est mal adapté ici, puisqu'on a un texte bilingue dans l'original, et non deux ouvrages séparés dans des éditions différentes. DoubleWiki est fait pour afficher deux ouvrage monolingues côte-à-côte pour montrer leurs différences. Ces deux ouvrages ont des auteurs différents, chacun devant être idnetifiable. Ce n'est pas le cas ici. L'exempel que tu donnes pour Doublewiki est correct, on voit enttement les différences introduites par le traducteur anglophone, au delà de la seule présentation puisque les ouvrages ont des présentations très différentes).
• Mais ici on a un seul ouvrage, dans une présentaiton unifiée qui DOIT aligner son texte comem cela était voulu par le traducteur qui ne s'est pas contenté de citer le texte breton, mais a tenté de le traduire fidèlement pour ce qu'il signifie (strophe par strophe, plutôt que vers par vers, ce qui se voit dans la présentation qu'il a adoptée ou chaque strophe est traduite dans un paragraphe indenté qui n'est plus un poème). DoubleWiki sert plutôt pour les traductions isolées qui ne font plus référence au texte original (le traducteur a alors pris bien plus de liberté, souvent en restructurant le texte de façon assez conséquente, bref en en faisant plutôt une adaptation plus qu'une traduction assez littérale...).
• L'exemple que tu cites n'est plus du tout le même texte (et la version du wiki anglais devrait même avoir un titre différent pour cette traduction et mentionnant clairement le nom du traducteur, sachant que d'autres traductions ou adaptations en anglais peuvent exister en concurrence !) Ca explique pourquoi DoubleWiki "marche mal", en fait il ne permet pas de sélectionner correctement la traduction à comparer avec l'original (on a l'exemple avec les multiples traductions du Coran: on ne peut pas faire de correspondance unique avec la version arabe, mais la version arabe peut être en correspondance avec la page de sommaire des traductions disponibles en français, les relations n'étant pas symétriques (un pour un), mais asymétriques (un pour N). On a parfois aussi plusieurs versions du même texte dans la même langue (rééditions, parfois par le même auteur!), et alors des relations N pour N. DoubleWiki ne peut pas marcher s'il ne permet pas de sélectionner les paires à utiliser et se contente de chercher des titres exactement équivalents (et qui n'ont pas à l'être !) — Verdy_p (d) 18 septembre 2010 à 14:07 (UTC)
• En fait DoubleWiki est plus un outil à utiliser pour les traducteurs d'articles (mais Google propose un outil bien meilleur permettant de traduire un article Wikipédia d'une langue dans une autre de façon assistée et qui fonctionne de façon merveilleuse, avec une démo en vidéo sur la traduction de l'article Wikipéida des grandes pyramides égyptiennes de l'anglais vers le chinois...). DoubleWiki n'a pas vocation à présenter des textes bilingues, seulement de les comparer et s'il doit être amélioré, c'est ne permettant de sélectionner les versions de chaque côté parmi celles proposées dans les Interwiki, voire en navigant d'un seul côté, dans un menu affiché dans une langue offrant plusieurs traductions. Deux frames devraient faire l'affaire, si DoubleWiki ne parvient pas à gérer les liens du bon côté... — Verdy_p (d) 18 septembre 2010 à 14:13 (UTC)

Dates dans marge

Bonjour,

j'ai commencé à travailler sur les Mémoires de Victor Alfieri, d’Asti : dans le livre original les années sont inscrites dans la marge en regard du texte, comment fait on pour rendre cela sur wikisource ? (cf. Mémoires de Victor Alfieri, d’Asti/Première époque - Enfance). Merci d'avance--Bgeslin (d) 13 septembre 2010 à 14:49 (UTC)

il faut créer un modèle spécial adapté aux maquettes. Je vais m’en occuper; désolé pour le contretemps, j’étais absent 2 semaines. ThomasV (d) 13 septembre 2010 à 14:52 (UTC)

J’utilise ceci pour Sévigné :

En haut de page :

{{Notes latérales début|33|5}}

et dans la page :

<noinclude><span style=text-align:center; text-indent:0px;>{{Note latérale gauche|———<br />1675|4|1}}</span></noinclude>

Il reste à mettre {{Notes latérales fin}} à la fin de la section. --Zyephyrus (d) 13 septembre 2010 à 17:20 (UTC)

Certes, mais le résultat pour le lecteur n'est pas convaincant. Dans le document Lettre du 28 août 1675 (Sévigné) la note marginale a disparu. --Wuyouyuan - discuter 14 septembre 2010 à 00:12 (UTC)

Tu donnes ici un excellent exemple des problèmes de présentation visuelle des textes, Wuyouyuan. En effet, qui a écrit cette date en marge, et pour quoi faire ? Dans le même ordre d’idées, qui a coupé certains mots par des césures, et pourquoi avons-nous décidé de ne pas reproduire les césures de mots ? (cette question avait été chaudement débattue sur le scriptorium). Aucune décision n’a encore été prise sur la présentation des lettres de Madame de Sévigné ; mais dans les choix éditoriaux, je propose personnellement de conserver les dates des marges entre balises no-include pour ne pas les inclure, et de placer par contre l’information qu’elles apportent à des endroits pertinents par rapport aux nouveaux supports où on trouvera le texte. C’est dans cette optique que je proposais comme titre des pages que nous publions dans l’espace Principal, une lettre après l’autre, la date de la lettre, plutôt qu’un numéro d’ordre qui n’appartiendrait qu’à une édition particulière. Je ne sais pas si j’ai réussi à expliquer clairement ce que je veux dire ? --Zyephyrus (d) 14 septembre 2010 à 08:54 (UTC)

Je suis en train de rendre les modèles "Note latérale droite/gauche" compatibles avec les maquettes. En effet, il faut pouvoir afficher les notes latérales lorsqu’il n’y a pas de marge (par exemple avec la maquette 2). C’est pour cette raison que j’ai enlevé les noinclude autout des notes dans les lettres de Mme de Sévigné; ça n’a rien d’une décision éditoriale. ThomasV (d) 14 septembre 2010 à 09:19 (UTC)

Bon, j’ai à peu près fini d’adapter les modèles "note latérale" aux maquettes. Il reste sans doute des détails à régler, mais l’essentiel y est. Voici une démonstration de ce qu’il est désormais possible de faire : Introduction à l’étude de la paléontologie stratigraphique/Tome 1/Chapitre II

• Maquette 1: les notes s’affichent à droite et à gauche du texte.

  Ont-elles besoin d'être aussi à l'étroit dans cette maquette ? Cette maquette offre des marges très confortables... — Verdy_p (d) 18 septembre 2010 à 13:00 (UTC)

je les ai élargies le 17, et ton message date du 18. [1]. Est-ce que tu suggères de les élargir encore plus, ou bien avais-tu fait cette remarque en te basant sur la version précédente ? ThomasV (d) 19 septembre 2010 à 08:39 (UTC)

• Maquette 2: les notes sont affichées avec le texte, dans des boîtes flottantes, puisqu’il n’y a pas de marges. elles flottent à droite ou à gauche.

  Ces boites flottantes, puisqu'elles s'insèrent et décalent le texte, doivent elles-mêmes avoir des marges, clairement manquantes ici (je dirais 0.5em du côté intérieur du texte, et peut-être 0.3em en bas pour ne pas trop coller en bas à la suite du paragraphe qu'elles annotent, si l'interlignage du texte principal est plus réduit que 1.5em).

  Note que l'interlignage des notes devrait être "line-height:normal" et non "line-height:1.5em", sinon soit il est clairement excessif, soit il provoque des superposition selon la police utilisée; c'est particulièrement vrai pour tout texte dont la taille a été réduite ; note: l'interlignage "normal" dépend de la police il est en général voisin de 1.2em à 1.35em, certaines polices demandent 1.4em, notamment les polices les plus enrichies à cause de la hauteur de leur jambage ; l'interlignage par défaut "1.5em" de Mediwiki est toujours excessif là où il devrait utiliser "normal", mais c'est un ajustement fait pour pouvoir "caser" les exposants ou indices sans que l'interlignage soit agrandi automatiquement; il faut se méfier de l'interligange "1.2" qui est suffisant seulement si le texte est à fond transparent et n'a pas d'exposants ni indices, mais tronque par superposition le bas des caractères de la ligne précédente, si le texte est à fond coloré par coloration du "span" de texte et non du bloc conteneur "div"/"p"/"li"/"td"/etc.).

  Faut-il qu'elles aient un fond gris ? une bordure noire ou grise suffirait, mais aucune raison de changer la couleur de fond (le fond gris nuit à la lisibilité) — Verdy_p (d) 18 septembre 2010 à 12:58 (UTC)

ok, j’ai ajouté des marges, supprimé le fond gris, et utilisé un interlignage normal. ThomasV (d) 19 septembre 2010 à 08:39 (UTC)

• Maquette 3: les notes sont toutes dans la marge de droite.

  Même chose concernant le fond (hormis les marges non nécessaires ici), mais la bordure pointillée est à éviter. L'apparence devrait être similaire à la maquette 1 (il n'est peut-être même pas utile d'avoir une bordure. Mais dans cette maquette, il devient impossible de distinguer les notes à gauche et à droite, espérons qu'il n'y ait pas de collision quand il y a des notes de chaque côté au même niveau. Bizarrement ces notes sont placées un peu trop haut par rapport au paragraphe qu'elles annotent, elles sont placées à côté de la fin du paragraphe précédent. — Verdy_p (d) 18 septembre 2010 à 12:58 (UTC)

ok pour le fond. Pour la bordure en pointillés, même remarque que plus haut : elle avait déja été enlevée au moment où tu as posté ton message, ce qui me fait conclure que ton javascript n’était pas à jour. Autre remarque : Peux-tu, à l’avenir, éviter d’insérer tes commentaires au milieu des contributions des autres ? Ca rend la lecture difficile. Nous pourrions demander l’installation de LiquidThreads afin d’éviter ce genre de problème.ThomasV (d) 19 septembre 2010 à 08:39 (UTC)

Ceci m’amène à poser une question : voulons-nous vraiment afficher des notes latérales à droite et à gauche sur une même page ? il me semble que le choix du côté où on affiche la note dépend de la parité de la page (reliure, contrainte physique imposée par le support), et que toutes les notes devraient être du même côté en mode texte. il n’y a pas de distinction logique entre ces notes.

ThomasV (d) 14 septembre 2010 à 12:14 (UTC)

La distribution des notes à droite et à gauche du texte selon les pages paires et impaires du livre me paraît être un non-sens dans l’espace principal, où je mettrais quant à moi toutes ce notes d’un seul côté. Par contre, je crois qu’il faut prévoir les cas de notes des deux côtés de la colonne de texte, où ces deux côtés ont une fonction à ne pas négliger. Je n’en trouve pas d’exemple tout de suite mais il me semble avoir déjà rencontré cela sur Wikisource. --Zyephyrus (d) 14 septembre 2010 à 13:19 (UTC)

Pour info : le modèle {{manchette gauche}} est redirigé sur le modèle {{note latérale gauche}}, et le modèle {{manchette droite}} est redirigé sur le modèle {{note latérale droite}}, on peut donc utiliser indifféremment « manchette » ou « note latérale ». --Zyephyrus (d) 14 septembre 2010 à 14:03 (UTC)

Cela fonctionne plutôt bien (cf. Mémoires de Victor Alfieri, d’Asti/Première époque - Enfance). Merci. J'ai placé les années en marge à droite et gris afin que ça n'alourdisse pas le texte à la lecture à l'écran... --Bgeslin (d) 14 septembre 2010 à 15:37 (UTC)

Puisque nous sommes 2 pour et zero contre, j’ai modifié l’affichage des notes dans la maquette 1 : elles sont maintenant toutes à droite du texte. ThomasV (d) 15 septembre 2010 à 14:02 (UTC)

Bonsoir, la discussion est intéressante et d’actualité pour moi. J’ai essayé ce modèle qui rend bien en mode page mais qui a des défauts dans une transclusion, en effet j’ai deux notes latérales de deux pages différentes qui se chevauchent (l’une étant à la fin d’une page et l’autre au début de la suivante). Par exemple voir Essai sur l’entendement humain/Avertissement entre les pages xiii et xiv. Autre point est-ce que quelqu’un sait si ce modèle est compatible avec les générateurs de pdf (quel en est le rendu dans le texte final) ? --Walpole (d) 15 septembre 2010 à 20:08 (UTC)

ah oui, en effet, je n’avais pas pensé à ça. La solution la plus simple serait de revenir à l’affichage de part et d’autre. On peut aussi déplacer les notes dans le texte, ou programmer une détection des chevauchement (mais là c’est compliqué).

pour ce qui est des pdf, le rendu final devrait dépendre de common.css. mais il faudra attendre que l’extension collection soit réparée pour en être sûr.

ThomasV (d) 15 septembre 2010 à 20:31 (UTC)

J’ai décelé un autre type de chevauchement au sein d’une même page, l’auteur avait volontairement reporté sa seconde note latérale pour la positionner en dessous de la première. Voir l’exemple ci contre sur la Page:Locke - Essai sur l’entendement humain.djvu/38. Cordialement--Walpole (d) 16 septembre 2010 à 13:37 (UTC)

ce n’est pas gérable par la maquette. J’ai utilisé le même stratagème que l’éditeur du livre. ThomasV (d) 17 septembre 2010 à 09:50 (UTC)

C’est une usine à gaz, la mise en page des notes latérales, du mode page, n’est pas forcément compatible avec celle du texte (transclusion). Pour le même passage en texte Essai sur l’entendement humain/Préface au niveau de la page xxvii, les notes se chevauchent.--Walpole (d) 17 septembre 2010 à 21:00 (UTC)

Les moines de l'Ile-Verte sont à l'étroit

Encore moi et mon document à deux colonnes juxtalinéaires. Ce matin, en essayant de recopier le contenu de ma page de brouillon dans l'espace principal, j'ai constaté que l'espace disponible du document à créer Les Moines de l’Ile-Verte était rétréci à la largeur habituelle du <div class="text">. Evidemment, ma construction à deux colonnes, qui est légèrement plus large (60% de la pleine page), a du mal à s'afficher, même en retirant le <div style="margin . . . N'importe quel texte s'aligne sur les marges mystérieusement imposées. Après expérimentation, je constate que la mystérieuse instruction de mise en page est cachée dans {{Page| . . ., et qu'elle agit sur tout le document, et donc recadre un texte quelconque placé au dessus, qui, quand il est seul sur le document, s'étale sur 100% de la largeur. Encore quelque chose qui m'échappe. --Wuyouyuan - discuter 14 septembre 2010 à 01:09 (UTC)

oui, en effet. un peu de patience… ThomasV (d) 14 septembre 2010 à 04:05 (UTC)

J'ai trouvé une solution pas trop compliquée, mais elle utilise un tableau pour montrer la traduction française en vis-à-vis du texte breton original.

De plus, le texte original réduisait déjà les polices, cette réduction est aussi en place dans le mode page comme dans le texte complet, et s'affiche correctement, quelle que soit la police effectivement utilisée dans le navigateur.

Il reste qu'on a un problème pour le cas des livres avec des pages en vis-à-vis (une page dans une langue, l'autre à côté dans une autre):

• il faudrait avoir un moyen de créer une page dans un espace de nommage spécial contenant une liste de liens wikis vers des d'articles qui seraient alors affichés dans cet espace spécial "Comparer:" avec une interface permettant de sélectionner la présentation (côte-à-côte, défilant, l'un sous l'autre, défilants séparément, ou linéaire avec toutes les versions successivement, ou une seule version) et de sélectionner les textes à afficher dans chaque cadre. Un exemple de présentation existe (regardez le Kit Google Translate qui a une telle interface qui facilite le travail des traducteurs, et donne une démonstration de la traduction d'une page Wikipédia anglophone sur les pyramides égyptiennes vers la page Wikipédia en chinois). — Verdy_p (d) 19 septembre 2010 à 03:15 (UTC)
• De plus, pour faciliter la synchronisation des défilements (avec l'aide d'un javascript) on pourrait insérer dans les textes à comparer des marques invisibles de synchronisation verticale (à priori seulement entre les blocs, paragraphes, titres, ou dans des cellules de tables : donc de simples "<div class="vtab" title="nom ou symbole du point de synchronisation" />" suffiraient au javascript, probablement par un modèle pour en faciliter le suivi ou la gestion du code généré par exemple "{{vtab|nom du point de synchro}}", surtout si ce code doit être compatible entre plusieurs wikisources et correspondre au javascript qui utilise ces points de synchro).
• Cela mériterait le développement d'une extension à utiliser dans un espace de nommage spécifique (car l'espace principal ne doit pas avoir de barres de défilement au milieu des pages, car ce n'est pas accessible ni pratique pour la lecture, et impossible à imprimer.). Le contenu des pages de l'espace "Comparer:" serait uniquement une liste de liens wikis vers les articles (éventuellement interwikis...), sans aucun autre formatage, l'extension se chargeant de charger les pages sélectionnées et de les mettre en forme selon le mode d'affichage souhaité.
• La liste de pages à comparer pourrait comprendre plus de 2 textes (voire même un seul si un des textes n'est plus ou pas encore accessible) : l'extension permettrait de sélectionner les textes à mettre dans chaque cadre, et par défaut afficherait les deux premiers textes de la liste si le mode d'affichage par défaut est d'afficher les pages en vis-à-vis ou l'une sous-autre, mais on peut aussi imaginer que par défaut, tous les textes listés sont transclus successivement et affichés les uns sous les autres, sans aucun défilement de cadres séparés, ni besoin de synchronisation...
• Les liens interwikis ne suffisent pas : on ne peut pas référencer plusieurs versions de façon claire dans la même langue (y compris pour le français uniquement : adaptations/traductions différentes, éditions différentes... Ces liens sont plutôt destinés à référencer une page unique dans une langue (même si dans une langue tierce, on accède à une page d'homonymie ou une simple liste de sélection entre plusieurs textes disponibles sur ce wiki, voire une catégorie).
• L'autre possibilité (si on ne veut pas d'un espace de nommage séparé), c'est de développer une balise wiki spécifique qu'on place en bas du texte affiché dans l'espae principal, en contenant cette liste de liens: le javascript détecte le code (invisible) généré par cette balise et offre un menu permettant de comparer le texte affiché avec un ou plusieurs autres textes sélectionnés et listés dans cette balise sous un forme comme:

<otherversions>
* [[lien wiki vers un autre texte|titre à afficher]]
* [[lien wiki vers un deuxième texte|titre à afficher]]
</otherversions>

• Le code HTML généré par cette balise serait une simple liste à puce HTML (non ordonnée), rendue invisible par le javascript s'il est chargé et actif, sinon affichée par défaut dans une portlet de la barre latérale de navigation (par du code CSS), sinon affiché normalement si CSS est aussi désactivé (pour compatibilité WAI avec les lecteurs d'écran). Le javascript permettrait d'afficher le menu de présentation des textes.
• Le javascript pourrait même permettre, quand les textes référencés sont en vis-à-vis ou l'un sous l'autre, de permettre l'édition dans l'un ou l'autre cadre, et faciliterait le travail des traducteurs. Ce serait utile aussi à Wikipédia pour éviter de jongler sans arrêt entre les onglets ou les fenêtres (je reprends l'idée du kit Google Translate): dans chaque cadre, l'utilisateur est connecté sur le wiki correspondant (merci aux comptes Wiki globaux unifiés !) mais l'interface de chaque wiki est simplifiée : on n'incluerait pas la barre latérale ou les onglets de chaque wiki, juste le corps principal de chaque page, en mettant éventuellement en bas de chaque cadre défilant les éléments de navigation de chaque page (les parties hors du corps principal) dans une forme simplifiée comparable au thème basique.
• Que pensez-vous de l'idée ? — Verdy_p (d) 19 septembre 2010 à 03:15 (UTC)

ça ressemble furieusement à DoubleWiki. Note que dans la version actuelle (pas encore activée), la synchronisation verticale à l’aide de div invisibles a été abandonnée, au profit d’une balise qui contient une liste de phrases à aligner. ThomasV (d) 19 septembre 2010 à 09:43 (UTC)

Modèle:Auteur

Bonjour,

Depuis plus d’un an maintenant, Faager (d · c · b) a proposé un nouveau Modèle:Auteur : Utilisateur:Faager/Modèle:Auteur. La discussion n’a pas bougé depuis sur Discussion modèle:Auteur. Y a-t-il des questions, commentaires, oppositions à mettre le nouveau modèle en place ? Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 10:06 (UTC) <pre> {{Utilisateur:Faager/Modèle:Auteur |nom_c=Victor Hugo |nom_fam=Hugo Victor |initiale=H |date_naiss=1802 |date_dec=1885 |image=Victor Hugo.jpg |description=poète et écrivain français}} </pre> {{Utilisateur:Faager/Modèle:Auteur |nom_c=Victor Hugo |nom_fam=Hugo Victor |initiale=H |date_naiss=1802 |date_dec=1885 |image=Victor Hugo.jpg |description=poète et écrivain français}}

Le modèle Auteur tel qu’il est actuellement : Auteur:Victor Hugo

[[Image:Victor Hugo.jpg|80px|right|Portrait de Victor Hugo]]
{{Auteur|Victor Hugo|Hugo Victor|H|poète et écrivain français (1802–1885)}}

Portrait de Victor Hugo

{{Auteur|Victor Hugo|Hugo Victor|H|poète et écrivain français (1802–1885)}}

— Le message qui précède, non signé, a été déposé par Zyephyrus (discuter), le le 14 septembre 2010 à 12:18 (modifié par VIGNERON * ^discut. pour être plus parlant)

[Je me permets de préciser que plusieurs contributeurs différents, dont Vigneron lui-même, ayant modifié mon commentaire non signé, ce n’est pas à moi qu’il faut l’attribuer…--Zyephyrus (d) 17 septembre 2010 à 13:38 (UTC)]

pour les présenter de façon neutre il faudrait utiliser la même photo. à part ça, je préfère la disposition actuelle, elle me semble plus lisible. ThomasV (d) 14 septembre 2010 à 12:28 (UTC)

Fait , merci. J’ai aussi ajouté le code correspondant (y compris les catégories pour avoir le même rendu).

L’intérêt du nouveau modère est surtout sa structure et pas sa présentation. Si la majorité des wikisourciers veulent conserver exactement la même mise en forme, c’est tout à fait possible.

Ce n’est pas cela qui compte. Ce qui compte, c’est d’arrêter d’utiliser un modèle minimaliste qui nous oblige à doublonner des informations inutilement.

Le changement de mise en forme est juste là pour profiter du changement de modèle et est donc parfaitement optionnel.

Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 13:00 (UTC)

Je suis pour la modification de structure, il est plus facile de comprendre le comportement d'un modèle lorsque les paramètres sont nommés. Par contre, au niveau de la mise en forme, je préfère la version actuelle que celle proposée. Je suis cependant complètement pour l’ajout de l'image dans le bandeau et l'idée des icônes pour les liens externes me paraissait intéressante. Aristoi (d) 14 septembre 2010 à 13:19 (UTC)

Avez-vous comme moi un message en rouge à propos de la clé de tri défectueuse ? --Zyephyrus (d) 14 septembre 2010 à 13:12 (UTC)

Tout le monde a ce message qui apparait sur toutes les pages MediaWiki contenant deux clés de tri. Il y a deux modèles donc deux clés donc le message, c’est normal.

Je suis en train de modifier l’apparence pour éviter de vous perturber, on pourra toujours en rediscuter plus tard.

Sur la structure, j’ai juste une question : "nom_c" et "nom_fam" ou bien "nom" et "prénom" ? Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 14:34 (UTC)

• ok pour le changement avec l’apparence actuelle ;
• pour le nom et prénom, je pense qu’il vaut mieux un seul champ : sinon on aura du mal avec certains auteurs
• "médias" me semble maladroit : on s’attend à trouver une revue de presse.
• à propos, ce modèle permet-il de ne pas afficher de lien vers les autres projets, si l’auteur n’y a pas de page ?

ThomasV (d) 14 septembre 2010 à 14:49 (UTC)

• ok pour ton ok (si quelqu’un voit une différence entre les deux modèles, merci de le signaler)
• on a forcément au moins deux paramètres : un pour l’affichage, un pour le defaultsort ; donc soit nom_c/nom_fam qui correspond plus à la logique du modèle, soit nom/prénom qui est plus parlant pour le contributeur lambda. Pour les cas qui pose problème, tu penses à quoi ? On peut peut-être ajouter un troisième paramètre... (et puis, il y aura toujours des cas particuliers -eg. Henri IV - on ne peut pas toujours traiter toutes les exceptions. La BNF prend "Henri IV" comme clé de tri. Je fais fouiller côté BnF pour voir si il y a quelque chose à en retirer)
• bof, tu mettrais quoi comme nom ? Pour info, commons:Accueil utilise le terme média -sans s par contre- qui correspond le mieux au contenu. Éventuellement, on pourrait mettre "documents"... (mais pas convaincu, quelqu’un a une meilleure idée ?)
• j’y ai réfléchi mais je ne vois pas de solution simple (sauf à ajouter un paramètre pour chacun des projets... ce qui me semble trop lourd)

Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 16:04 (UTC)

"nom/prénom" ne s’applique pas à tous les auteurs. De plus, si le paramètre utilisé comme clé est appelée "clé", au moins les utilisateurs savent comment il est utilisé : c’est ce genre de chose qui aide le contributeur lambda.

à la place de "média", je mettrais peut-être "fichiers multimédia"

pour les paramètres en plus, on peut faire tourner un robot qui vérifie régulièrement l’existence des pages sur les autres projets; il y a régulièrement des contributeurs qui se proposent pour faire marcher un robot, donnons leur quelque chose à faire.

ThomasV (d) 14 septembre 2010 à 16:18 (UTC)

Ok, donc on partirait sur "nom" et "clé" plutôt que "nom_c" et "nom_fam", cela convient à tout le monde ?

"fichiers multimédia" est un peu trop long par rapport aux autres termes mais pourquoi pas.

Euh, pourquoi pas un bot effectivement (par contre là, je vois mois comment faire techniquement ; je passe la main sur cette partie).

Cdlt, VIGNERON * ^discut. 15 septembre 2010 à 07:19 (UTC)

Je trouve que « Fichiers multimédia », outre sa longueur, ne recouvre pas les fichiers sonores (un seul média), donc ne convient pas trop non plus sur le sens. Est-ce que « Autres médias » serait plus compréhensible ? --Zyephyrus (d) 15 septembre 2010 à 08:14 (UTC)

Je suis pour l’utilisation du nouveau modèle. En ce qui concerne les détails, je pense que le mieux est d’avoir un champ "nom" (ce qui recouvre tous les cas de figures) et un champ "clé". Pourquoi pas "Autre documents" pour le dernier champ ? Enfin, le lien vers les Fac-similés est légèrement plus gros que les suivants, est-ce volontaire ? Zaran (d) 15 septembre 2010 à 15:44 (UTC)

Ok, on semble donc bien parti vers "nom"/"clé".

Et si on mettait tout simplement le nom des projets ? Wikipédia, Wikiquote, Wikisource ?

Non, la taille du lien "fac-similé" est une erreur, je corrige (il y aussi un léger décalage en haut, non ?).

Cdlt, VIGNERON * ^discut. 16 septembre 2010 à 09:53 (UTC)

Rappel : si je me souviens bien, il y avait aussi consensus pour mettre une reproduction de la signature de l’auteur sur sa page auteur. --Zyephyrus (d) 17 septembre 2010 à 13:42 (UTC)

Bonjour, je suis pour la modification du modèle, les champs sont une avancée importante. Je n'ose plus faire de proposition de peur de bloquer un concensus... un an de plus :-) mais plus tard je proposerai sans doute jour_naiss, mois_naiss alors annee_naiss me parait plus adapté que date_naiss, pour faire des éphémérides / anniversaires comme sur d'autres projets. Sapcal22 (d) 17 septembre 2010 à 17:53 (UTC)

@Zyephyrus : j’avais oublié, je peux rajouter le champs mais où place-t-on l’image ?

@Sapcal22 : bonne idée. L’avantage énorme de cette nouvelle version est que les champs sont nommées, on peut donc en ajouter plus facilement au fur et et à mesure, faire travailler des bots dessus, etc.

Je pense que l’on peut maintenant passer à la phase de remplacement, des oppositions ? Cdlt, VIGNERON * ^discut. 19 septembre 2010 à 17:29 (UTC)

Oui, en effet, le modèle est très bien mais je serai plutôt pour apporter la modification proposée par Sapcal (je suis prêt à mettre en place les éphémérides). Tpt (d) 19 septembre 2010 à 18:59 (UTC)

Oui, il est vraiment temps de passer à un modèle avec des paramètres nommés. Yann (d) 20 septembre 2010 à 09:58 (UTC)

Typo et présentation

Bonjour, je suis toujours sur le journal d'un écrivain de Dostoïevski et j'ai quelques soucis :

• Comment mettre les apostrophes courbes
• Comment transformer les points de suspension

Comment reproduire le rappel du titre avec le numéro de page en haut de cette même page comme il à été mis sur la retranscription voir ici : Page:Dostoïevski - Journal d’un ecrivain.djvu/99, or je voulais bêtement faire un copier coller de cette ajout pour la page suivante mais les données n'apparaissent pas. Où sont-elles svp ? et est-ce finalement utile puisque quand le texte est mis en continu ces rappels de titre et les numéros de page n'apparaissent plus. Merci --Le ciel est par dessus le toit (d) 14 septembre 2010 à 12:09 (UTC)

Dans tes préférences, il y a un gadget : Caractères spéciaux automatiques (accents, apostrophes) qui permet de faire tout cela (apostrophes typographiques -et non courbes-, point de suspension, s long, ligatures orthographiques, etc.).

Pour faire le remplacement dans les textes existants, il y a les expressions régulières (regexp) aussi dans la barre d’outils .

Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 12:20 (UTC)

si personne n’est contre, on peut aussi déplacer ce gadget vers common.js : ça l’activera pour tout le monde ThomasV (d) 14 septembre 2010 à 12:27 (UTC)

 Neutre En préliminaire, j’ai une petite question, as-tu une idée du ralentissement occasionné par ce gadget ? Sinon comme condition sine qua none, je pense qu’il faut faire une page d’explications sur ce gadget dont le comportement est parfois contre-intuitif. Globalement, je suis plutôt pour.

Sinon un détail mais ce gadget ne fonctionnant pas sous IE7 (et probablement d’autres navigateurs), il est abusif de dire qu’il sera activé pour tout le monde

Cdlt, VIGNERON * ^discut. 14 septembre 2010 à 13:05 (UTC)

Pour le rappel de titre en haut de page, le code est dans la partie "En-tête" du mode page, accessible grâce au bouton [+] de la barre d’outils. Sur cette page est utilisé le modèle {{numérotation}}, on peut aussi utiliser le modèle {{nr}} plus basique. Aristoi (d) 14 septembre 2010 à 13:14 (UTC)

Mise en forme de texte sur deux colonnes

Bonjour
J'ai un souci avec la mise en forme de cette page et des suivantes. Le texte se présente sur deux colonnes après le 2e paragraphe de la page, et intégralement sur deux colonnes sur les pages suivantes. J'ai voulu utiliser la classe <div class="text deuxcolonnes"> ; c'est à peu près convenable en mode page, mais le colonnage saute en partie en mode texte (j'ai fait la transclusion pour montrer ce que ça donnait).
Un problème analogue se posera quelques chapitres plus loin.
Merci d'avance à qui voudra bien me dépanner. --Acélan (d) 15 septembre 2010 à 12:55 (UTC)

c’est corrigé (il faut utiliser des noinclude), à ceci près que tu utilises poem sur une page et pas la suivante. ThomasV (d) 16 septembre 2010 à 10:46 (UTC)

Merci ! (pour les balises différentes d'une page à l’autre, c'était pour des essais, j’ai homogénéisé le tout). --Acélan (d) 16 septembre 2010 à 18:48 (UTC)

Les noinclude ne sont pas nécessaires: il suffit de placer le code qui ne doit pas être inclus dans la transition de page dans la partie pied de page ou entête de page.

En revanche je me deamnde pourquoi l'entête de page, lorsqu'il est visualisé en mode page, est sauvegardé avec 3 retours chariot. Il ne devrait strictement rien y avoir, ou bien ces 3 retours chariot devraient être remplacés par "<div />" à la fin de l'en-tête (sans aucun retour chariot après), afin de ne pas décaler l'entête du reste de la page dans la section principale de l'éditeur. Ce div vide suffit à éviter l'indentation par défaut du premier paragraphe dans la section principale, puisqu'elle va être affichée juste après ce div sans retour chariot, et suffit à provoquer la rupture verticale entre l’entête et la suite qui doit être immédiatement dessous et non continuer à droite de l’en-tête de page).

Exemple avec les trois retours chariots (ajouté automatiquement par l’éditeur mais uniquement à la fin de l'en-tête)

(Ce texte est dans l'en-tête de page.)

ce paragraphe dans la section principale poursuit celui de la page précédente et n'est pas indenté.

Ceci est un autre paragraphe.

Ceci est un autre paragraphe.(Ce texte est dans le pied de page.)

Exemple avec un div vide

(Ce texte est dans l'en-tête de page.)

ce paragraphe dans la section principale poursuit celui de la page précédente et n'est pas indenté.

Ceci est un autre paragraphe.

Ceci est un autre paragraphe.

(Ce texte est dans le pied de page.)

Note: pour éviter qu'un div vide soit éliminé par MediaWiki, il doit avoir des attributs (MediaWiki purge automatiquement les balises "div" ou "span" sans contenu ni attributs, après y avoir aussi compressé puis déplacé en dehors du contenu les blancs au début et à la fin de celui-ci).

Ici j'ai utilisé <div class="page-start" /> et <div class="page-end" />, dans la syntaxe abrégée XML/XHTML mais que MediaWiki convertit en syntaxe non abrégée compatible SGML/HTML (tout en restant compatible XML) Ces classes pourraient être utilisées dans les personnalisations CSS/Javascript des thèmes utilisateurs pour présenter ces entêtes et pieds de page, par exemple en incluant un filet horizontal ou une marge verticale pour ceux qui le souhaitent encore. — Verdy_p (d) 17 septembre 2010 à 14:20 (UTC)

Bref :

• remplacer les trois retours chariot ajoutés à la fin de l'en-tête par le div vide (qu'on repère par sa classe lors de l'entrée en édition) ;
• et pour le pied de page, insérer un seul retour chariot (pour terminer le paragraphe en cours, afin qu'il soit terminé et détecté comme paragraphe par MediaWiki, et qu'il s'indente correctement) suivi du div vide (qu'on repère aussi par sa classe lors de l'entrée en édition) avant le reste du pied de page.

noter que le pied de page actuellement peut s'afficher à la suite du dernier paragraphe non terminé en bas de page, et accollé à celui-ci (il manque une séparation du pied de page, dans l'affichage de la page complète avec entête et pied de page). — Verdy_p (d) 17 septembre 2010 à 16:06 (UTC)

ce n’est pas si simple de remplacer les retours chariot ; nous avons maintenant plus de 10^6 pages formatées ainsi. de plus, je ne vois pas trop le bénéfice à tirer d’une telle opération. ThomasV (d) 19 septembre 2010 à 11:05 (UTC)

Tirets fantômes

En faisant un copier/coller, par exemple du chapitre 1 de Mémoires_de_Victor_Alfieri,_d’Asti/Seconde_époque_-_Adolescence vers OpenOffice (avec l'option "Trame de fond de champs" activée) je me suis aperçu qu'il y avait des tirets de césures invisibles à l'écran sur wikisource (mode page ou texte) qui étaient présents dans le texte. Ces tirets correspondent à la césure du texte tel qu'il est présenté dans le djvu. C'est la première fois que je remarque cela. Quelqu'un sait-il à quoi cela correspond et comment les effacer dans wikisource, ou au moins les y rendre visible pour le faire manuellement ? --Bgeslin (d) 15 septembre 2010 à 19:26 (UTC)

À mon avis, le problème vient de la présence du caractère SOFT HYPHEN (U+00AD) qui n'apparaît qu'aux coupures de lignes. Il doit y avoir moyen de le remplacer en faisant de la recherche plein texte avec copier-coller dudit caractère. Pmx (d) 15 septembre 2010 à 21:39 (UTC)

Dans certains cas, il faut des tirets fantômes dans le Wikisource, quand un mot est trèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèèès long, car en mode page (comme aussi dans l'original du livre scanné, ou dans la "maquette 1" contrainte en largeur), il sortirait des marges. Dans ce cas on place ce tiret là où il est dans l'original scanné, et on a aussi un affichage correct en mode page comme ne mode texte complet (dans la maquette1). Ce tiret de coupure conditionnelle apparaîtra (comme il apparaît aussi dans l'original), mais disparaîtra automatiquement dans la maquette 3 (si l'écran est assez large pour afficher le mot entier).

D'autres raisons peuvent justifier l'insertion de ces tirets invisibles, pour des raisons esthétiques lors de la justification totale (mais à chaque fois ce sera dans un mot plus long que la moyenne ou trop long pour s'afficher en entier dans une colonne de texte étroite.

Ces tirets ne sont pas gênants pour l’indexation du texte (ce sont en fait des caractères de contrôle, et non caractères graphiques ou orthographiques), et je pense qu’il n’est même pas utile de les filtrer (sauf si on on a abusé à trop d'endroit). On ne doit les trouver que dans des mots exceptionnellement longs (plus d'une quinzaine de caractères, le mot recouvrant au moins la moité de la ligne dans la page scannée) afin d'éviter une espace beaucoup trop long avant ou après sur la même ligne justifiée.

Si le paragraphe n'est pas justifié dans la colonne de texte, on ne placera le tiret conditionnel que si le mot tout seul peut déborder de la colonne.

Ces tirets devraient ne pas être invisibles en mode édition (utiliser la syntaxe ­ pour voir là où ils sont). — Verdy_p (d) 17 septembre 2010 à 16:20 (UTC)

J'ai vu le cas où les tirets de coupure conditionnelle étaient absolument nécessaire : un des personnages ne s'y exprime que sur un ton monocorde et sans jamais faire la moindre pause entre les mots (ce qui rendait ses propos difficiles à comprendre). L’auteur a volontairement supprimé TOUTES les espaces entre les mots, mais pour que le texte tienne dans la colonne de texte, il était nécessaire d'admettre des coupures de ligne conditionnelles. Dans ce cas on place des tirets conditionnels là où il y aurait du y avoir des espaces (si le personnage s'était exprimé normalement). D'ailleurs le livre original affiche bel et bien un tiret de coupure en choisissant de la faire entre deux mots plutôt qu'à n'importe quelle autre position (l'éditeur a utilisé la justification totale des paragraphes, en ajustant aussi l'interlettrage pour que la colonne s'aligne quand même, alors qu'il n'y a aucune espace dans la ligne).

En HTML, on n'a pas de support de la justification totale automatique, permettant de modifier automatiquement l'interlettrage afin d'éviter des espaces disgracieuses entre les mots et de régulariser les colonnes de texte, et aussi afin de faciliter la lecture pour que les lignes restent bien visibles et identifiables à l'œil ; pour cela il faudrait qu'on ait une propriété CSS permettant d’indiquer la largeur maximale ou minimale (en em) des espaces entre mots avant de modifier (positivement ou négativement) l'interlettrage pour répartir et équilibrer partout sur la ligne le reste des espaces entre tous les glyphes ou espaces séparateurs de mots). Classiquement les éditeurs utilisent des espaces entre mots en les justifiant entre 0.3em minimum à 2em chacun (parfois moins dans des colonnes de texte très étroites comme les colonnes de petites annonces, ou des annuaires, index et longues listes de termes) ; l’idéal étant de 0.5em en présentation non justifiée : ceci évite aussi d'avoir à rendre des césures (si on peut compacter légèrement les lignes pour faire tenir le mot entier), la valeur minimale dépend aussi des polices utilisées (mais en général, les polices incluent dans chaque glyphe un interlettrage de 0.2em réparti moitié-moitié de chaque côté du glyphe, ce qui fait qu'on peut rapprocher les lettres au maximum de -0.1em pour compacter les lignes).

Les éditeurs aujourd'hui utilisent une autre approche: des polices légèrement compressibles horizontalement, ce qui déforme un peu les glyphes mais respecte leur interlettrage naturel et évite des collisions.

Ce n'est possible qu'avec les polices numériques d'aujourd'hui mais ce n'était pas possible au temps du plomb, où les glyphes permettait l'ajustement de l'interlettrage car ils n'incluaient AUCUN espacement à droite ou à gauche de l'œil métallique, l'interlettrage étant réalisé lors de la justification de la ligne par un peigne à dents pyramidales qu'on faisait glisser entre les glyphes en frappant le peigne au maillet, avant de bloquer la ligne composée et justifiée par un serrage vertical à vis des deux mâchoires horizontales tenant les glyphes solidaires (puis de retirer le peigne pour composer la ligne suivante); de la même façon les lignes pouvait être justifiées verticalement en les plaçant dans un cadre de composition d'une colonne, avec aussi un peigne vertical glissé dans le cadre de chaque côté de la colonne avant de bloquer par des vis les deux mâchoires verticales tenant les lignes de texte solidaires). Les colonnes ainsi bloquées pouvait alors être placées dans le cadre de page... Ces peignes étaient faits avec des dents pyramidales dans un métal très dur (pas en plomb ! mais souvent en tungstène pour éviter leur usure en glissant le long des glyphes qui cependant avait des bords adoucis pour ne pas entailler les dents des peignes) coulissant le long d'un rail graissé (la partie la plus large de chaque dent étant le long du rail). Ce procédé permettait des justifications totales très précises et très esthétiques, plaisantes à lire (et on n'a toujours pas l'équivalent en HTML aujourd'hui). — Verdy_p (d) 17 septembre 2010 à 16:55 (UTC)

@Verdy: si tu apprenais à résumer ta pensée en 2 lignes, il y aurait plus de monde pour lire ce que tu écris. ThomasV (d) 17 septembre 2010 à 17:00 (UTC)

Thomas, je te prie d'éviter de faire des commentaires potentiellement blessants, d'autant plus quand ils sont largement hors sujet. Je t'en remercie par avance. Faager (d) 17 septembre 2010 à 19:29 (UTC)

toutes mes excuses ; mon but n’était pas de blesser qui que ce soit. ThomasV (d) 17 septembre 2010 à 20:16 (UTC)

Proclamation du 10 mai 1802 (Guadeloupe)

Le bandeau Tsss… est actuellement aposé sur Proclamation du 10 mai 1802 (Guadeloupe). Des pdf du texte sont maintenant disponibles ici et sur Gallica. Peut-être attendre un peu avant de créer les djvu. D'autant plus qu'il y a 4 volumes. Il est toujours plus facile de saisir les textes longs en mode page. Est-il possible de créer un djvu pour ces quelques pages ? Merci. --Ambre Troizat (d) 17 septembre 2010 à 21:44 (UTC)

statistiques

Depuis aujourd’hui, un tiers (33.4%) de nos textes sont en mode page. Félicitations à tous ceux qui participent à cette aventure!

Parmi les 66% de pages restantes, il n’y a pas que des textes "nus" : une partie des pages ne sont pas destinées à passer en mode page (page d’accueil, pages d’homonymie, listes, etc). Afin de produire des statistiques plus fiables, j’ai créé la catégorie catégorie:SansTransclusion (le nom n’est pas terrible, mais ce n’est pas grave, c’est une catégorie cachée). Cette catégorie est destinée à recenser les pages qui ne sont pas supposés passer en mode Page, et doivent être décomptées des statistiques. ThomasV (d) 18 septembre 2010 à 21:48 (UTC)

Note : ce chiffre de 33% indique le nombre de pages passées en mode page, mais ne tient pas compte de la longueur des textes. Si on pondère par le nombre de caractères, nous avons environs 858Mo de texte en mode page, et 954Mo de textes nus. ThomasV (d) 20 septembre 2010 à 12:16 (UTC)

Notez aussi que nous avons actuellement 480000 pages dans l’espace Page. En faisant une simple règle de trois, nous pouvons voir que l’ensemble de nos textes représenterait, une fois passé en mode page, environ 1 million de pages. ThomasV (d) 20 septembre 2010 à 13:58 (UTC)

Un javascript à modifier

Bonjour, les liens vers les autres projets dans le menu de droite apparaissent sous le skin Vector dans Firefox 3 avec des puces comme dans le skin monobook (un exemple : Utilisateur:Faager/Modèle:Auteur). Si un administrateur pouvait corriger le problème… Merci d’avance, Tpt (d) 19 septembre 2010 à 18:47 (UTC)

Je n’ai toujours pas compris de quoi il s’agit. Avec Firefox et sous Vector je n’ai jusqu’ici rien vu de particulier. --Zyephyrus (d) 20 septembre 2010 à 13:28 (UTC)

Inactualités littéraires

Bonsoir,

Il me semble que le contenu de Wikisource pourrait être mis encore un peu plus en valeur par l’ajout d’une rubrique « Actualités et événements » en page d’accueil (qui visiblement a beaucoup d’espace libre). Les germanophones ont une rubrique « Anniversaires », mais je pense à quelque chose de plus large. Par exemple, nous avons les critiques littéraires d’Anatole France qui étaient publiées dans le Temps, chaque samedi semble-t-il ; une telle rubrique pourrait reprendre ces articles à 100 ou 120 ans de distance, en suivant les jours de l’année. Des articles de journaux ou de revues pourraient dans cette idée être mentionnés, ainsi que la publication d’œuvres il y a 100, 150, 194, etc. ans. Imaginons par exemple ce genre d’inactualités avec le cas de La Terre de Zola ; la publication de cette œuvre a donné lieu à un article de France et à un célèbre article dans le Figaro du 18 août 1887. Cette rubrique pourrait reproduire ainsi l’actualité littéraire d’une autre époque. En outre, dans les domaines de l’histoire, de la politique, des arts, etc., le formidable travail d’édition de Zoé sur la Revue des Deux Mondes fournit une matière considérable qu’il ne serait pas inintéressant de mettre en valeur. Marc (d) 19 septembre 2010 à 22:01 (UTC)

Très bonne idée, mais boulot redoutable, parce qu'il n'y a rien de plus difficile à connaître que la date d'un vieux texte. Jusque très récemment personne ne se souciait de les dater à la parution. Les articles du recueil d'Anatole France sont repris sans date (ou au moins je n'ai pas trouvé dans le livre), etc,. Un exemple: j'ai pensé aux premières représentations de pièces classiques. La base César reflète surtout des incertitudes; on ne va pas souvent au delà de l'année. Trouvé: il y a 250 ans, le 3 septembre, Tancrède de Voltaire; pas de chance, nos n'avons pas encore le texte. On peut commencer en exploitant la Chronologie de la littérature de Wikipédia. Trouvé: il y a 150 ans Max Havelaar, roman. Mais nous n'avons pas non plus le texte (Google l'a). --Wuyouyuan - discuter 20 septembre 2010 à 04:06 (UTC) Max Haavelar ! Déja trois contributeurs et des pages validées ! Quand on a besoin de bonnes volontés, il suffit d'en parler ici. --Wuyouyuan - discuter 21 septembre 2010 à 03:40 (UTC)

Oui, les pages chronologiques de Wikipédia sont un très bon point de départ. On trouve par exemple, en 1892, la publication en feuilleton du Château des Carpathes. Dans la rubrique que je propose, l’idée serait de signaler le début de ce feuilleton ; et en signalant d’autres actualités à côté de cela, on obtiendrait une présentation contextualisée des textes de Wikisource, alors que jusqu’à présent, le lecteur aborde Wikisource par les index ou les thèmes, et les catégories années sont loin d’être représentatives des textes disponibles. En revanche, je me demande si une telle rubrique ne risque pas de devenir un peu un gros fouillis. En tout cas, c’est encourageant de voir qu’il y des contributeurs pour le roman Max Haavelar. Marc (d) 21 septembre 2010 à 12:02 (UTC)

Dans le cas d’Anatole France, ses articles peuvent être retrouvés assez facilement dans le Temps sur Gallica. Ensuite, on peut adopter une base mensuelle pour certains textes ; et tous les textes ne datent pas de plus de 200 ans. Comme j’ai parlé aussi d’articles de revues présentant l’actualité littéraire, politique, sociale, etc., d’une époque, il me semble que la date est inscrite dessus (Revue des Deux Mondes, chroniques littéraires de divers journaux). Mais il semble de toute façon que cette idée n’intéresse personne. Marc (d) 20 septembre 2010 à 13:08 (UTC)

Si, cette idée me paraît très intéressante ; mais je ne pense pas pouvoir m’en charger, ou en tout cas pas de façon régulière. Si nous le faisons à plusieurs, je contribuerai de temps en temps avec plaisir. --Zyephyrus (d) 20 septembre 2010 à 13:25 (UTC)

De toute façon, pour que cela fonctionne, il faudrait qu’une telle rubrique soit alimentée de temps à autre par les contributeurs au même titre que la rubrique Nouveautés. Par exemple, en travaillant à l’édition d’un auteur ou en faisant tout autre travail d’édition sur Wikisource, tu vois qu’il y a des textes qui ont été publiés en septembre. Dans mon cas, tel texte de Nietzsche ou des articles sur lui publiés tel jour ou tel mois. Cela peut inciter à éditer de nouveaux textes sur Wikisource pour faire une sorte de dossier (comme l’exemple du livre de Zola), mais des textes déjà là seraient à utiliser, ce qui permettrait, comme je le disais, de les mettre un peu plus en valeur et de proposer une présentation plus vivante de Wikisource comme bibliothèque. Le plus difficile ne me semble pas de remplir cette rubrique, car il y a déjà beaucoup de textes sur Wikisource qui peuvent servir, mais de savoir comment l’organiser en évitant que cela devienne chaotique. Marc (d) 20 septembre 2010 à 14:14 (UTC)

c'est intéressant, mais je n'ai malheureusement pas de textes à proposer pour ce projet. J'ai bien essayé récemment la mise en ligne d'un article de presse (attentat du 9 décembre 1893 contre la Chambre des députés organisé par Auguste Vaillant). Mais ça prend beaucoup de temps puisque le scan n'est pas de bonne qualité (Gallica dispose d'une version plus lisible en ligne) et l'on s'éloigne des actualités littéraires. Pyb (d) 21 septembre 2010 à 07:26 (UTC)

Cela ne se restreint pas forcement à la littérature ; tous les textes, historiques, juridiques, politiques, économiques, etc., pourraient être utilisés. Pour les articles de presse, je me suis fait la même réflexion que toi sur la difficulté d’en éditer certains en trouvant dans un numéro de 1918 du Figaro un article qui évoque Nietzsche d’une manière qui est intéressante pour l’histoire de la réception des idées. Mais la qualité des images est en effet mauvaise. Marc (d) 21 septembre 2010 à 12:02 (UTC)

Validations

Bonjour,

J’ai remarqué que le nombre de validations décroît : [2]. Pourrait-on essayer de garder au moins une légère croissance, et éventuellement de fixer un objectif ? (100 pages validées par jour ?). Yann (d) 20 septembre 2010 à 10:03 (UTC)

Qui peut nous construire un joli petit modèle que les contributeurs s’ils le désirent pourraient afficher sur leur page utilisateur et qui se mettrait à jour automatiquement : « Aujourd’hui [ou : cette semaine] j’ai validé n pages » ? (Cela n’empêcherait pas de valider sans compter, soit un nombre de pages réduit mais c’est toujours utile, même une unique page est utile ; soit parce que « quand on aime on ne compte pas », soit pour toute autre raison. Je trouve pour ma part qu’avec le jeu des mille pages nous nous étions bien amusés. --Zyephyrus (d) 20 septembre 2010 à 10:34 (UTC)

Il faudrait avoir des "données corrigées en fonction des variations saisonnières" ; le mois d'août est normalement plus creux que les autres mois. Avec les stats de septembre, on verra si les stats se confirment. --Acélan (d) 20 septembre 2010 à 11:32 (UTC)

@Zephyrus: un tel modèle ne serait pas très simple à programmer, car la base de donnée ne possède pas de table pour stocker l’état de validation des pages; il faudrait consulter le contenu des pages pour y avoir accès, et ce contenu n’est pas sur le toolserver. On pourrait aussi utiliser les commentaires laissés lors de l’édition mais c’est peu fiable. à part ça si tu veux refaire un jeu des 1000 pages je suis partant. ThomasV (d) 20 septembre 2010 à 11:51 (UTC)

On ne peut pas relever ce qui appartient à la fois à « Contributions de l’utilisateur XX » et à la catégorie « Pages validées » ? Ce n’est pas combinable ? --Zyephyrus (d) 20 septembre 2010 à 12:30 (UTC)

non, ça ne te dirait pas si tu as validé une page ou bien modifié une page qui était validée avant, ou bien modifié une page alors qu’elle n’était pas encore validée, mais qui a été validée par la suite par quelqu’un d’autre que toi ThomasV (d) 20 septembre 2010 à 12:45 (UTC)

Pour les étudiants, enseignants & co, c’est la rentrée. C’est un moment de l’année où il y a plein de paperasses administratives à faire, quelques repères à reprendre. Ceux qui ont des enfants doivent également s’occuper de leur rentrée.

Bref, rien que de plus normal. De fait, que des contributeurs se fixent des objectifs personnels, ok (c’est mon cas), mais des objectifs globaux ça sert à quoi ?

Sloonz (d) 20 septembre 2010 à 15:31 (UTC)

Levée de fond. Besoin de votre imagination

Bonsoir

Dans quelques semaines, la levée de fond annuelle de Wikipedia (et des autres projets wikimedia) va commencer. Cette année, il sera apparemment possible d'assez bien localiser le texte par projet et par pays. Si vous avez des idées de slogans sympa (y compris à consonnance locale), merci d'aller les ajouter ici et d'en profiter pour commenter les propositions déjà postées. Ca ne vous prendra que quelques minutes. Merci ! Anthere (d) 22 septembre 2010 à 21:38 (UTC)

Wikisourciens, des idées ? Exercice annuel habituel : composer une phrase qui puisse résumer ce qu’est Wikisource et ce que nous demandons de soutenir.

Tous les livres du monde parvenant à tous. Soutenez Wikisource.

Une bibliothèque complète servie à toutes les tables. Soutenez Wikisource.

C’est tout ce qui me vient à l’idée pour l’instant, pouvez-vous l’améliorer ? D’autres propositions ? --Zyephyrus (d) 23 septembre 2010 à 16:37 (UTC)

Ok sur l’esprit de tes propositions mais pas forcément sur la forme (trop familier ?). Je ne suis pas contre tes propositions mais je dirais plutôt :

Tous les livres du monde disponible pour tous. Soutenez Wikisource.

Une bibliothèque complète accessible via Internet. Soutenez Wikisource.

Cdlt, VIGNERON * ^discut. 24 septembre 2010 à 13:22 (UTC)

J’ai ajouté ces deux dernières phrases sur Méta et indiqué qu’elles étaient proposées par Vigneron. --Zyephyrus (d) 8 octobre 2010 à 22:25 (UTC)

Catégorie:Auteurs-Courant littéraire

Il faut renommer les catégories sous Catégorie:Auteurs-Courant littéraire vers Auteurs-xxx. --Maltaper (d) 23 septembre 2010 à 05:20 (UTC)

Bonjour,

Oui, je pensais le faire avec un robot et j’ai d’ailleurs une méthode pour conserver les historiques. Marc (d) 23 septembre 2010 à 14:25 (UTC)

C’est fait. Marc (d) 24 septembre 2010 à 10:48 (UTC)

Fac-similés

J’ai presque tout le temps le message suivant en cliquant sur le lien Fac-similés des pages auteur :

Une erreur de syntaxe de la requête dans la base de données est survenue. Ceci peut indiquer un bogue dans le logiciel. La dernière requête traitée par la base de données était :

(Requête SQL cachée)

depuis la fonction « ». La base de données a renvoyé l’erreur « 1054 : Unknown column 'false' in 'where clause' (10.0.6.27) ».

Marc (d) 23 septembre 2010 à 14:25 (UTC)

Je reçois aussi souvent ce message et ai supposé (sans preuves) qu’il se produisait seulement en cas d’absence de fac-similés correspondant à la requête ; est-ce le cas ? --Zyephyrus (d) 23 septembre 2010 à 16:41 (UTC)

oui. le bug se produit aussi si une page d’index a été créée récemment, et qu’elle n’est pas encore répertoriée par le moteur de recherche. ThomasV (d) 23 septembre 2010 à 17:12 (UTC)

On ne pourrais pas modifier le message d’erreur ? genre « il n’y a pas encore de fac-similés pour cet auteur ? » Cdlt, VIGNERON * ^discut. 24 septembre 2010 à 13:18 (UTC)

Version complète vs fac—similés

Bonjour, je commence juste à corriger et je ne veux pas me tromper. Voici mon souci : j’ai commencé à m’occuper des textes de George Sand en version fac-similé. Pour Livre:Sand - Le Marquis de Villemer.djvu, il y avait les images et l'OCR. Il a fallu corriger et, avec l'aide de Utilisateur:Zyephyrus (j'en profite pour le remercier pour sa mise à l'étrier plus qu'efficace), tout s'est normalement passé. Je voudrais passer à Livre:Sand - La mare au diable.djvu mais je me suis aperçu que La Mare au Diable en version complète et validée existe ! ! ! De plus, la version fac—similé ne possède pas d’OCR. La question est donc de savoir :

1/ faut-il faire la version fac—similés (je crois comprendre que l’idée est d’avoir, autant que possible, une version vérifiable avec le mode image) ?

2/ si oui, peut-on partir du texte complet (simple copier/coller puis correction) et la nouvelle version fac—similé va-t-elle remplacer la précédente ?

Merci d’éclairer ma lanterne. Toto256 (d) 24 septembre 2010 à 16 : 48 (UTC)

Bonjour,

Il manque les informations bibliographiques pour le texte sur Wikisource. Tu devrais donc à mon avis commencer par le comparer avec le fac—similé, et, si cela correspond, utiliser ce texte pour le mode page et le recorriger de cette manière (comme il n’y a pas d’édition de référence, il est de toute manière impossible de le valider en l’état). Et si tu connais les différentes éditions de ce texte (s’il y en a), tu pourrais aussi envisager d’utiliser un fichier de meilleure qualité avec OCR comme celui-ci (et en profiter pour corriger les deux erreurs de typographie dans le titre). Marc (d) 24 septembre 2010 à 17 : 03 (UTC)

Effectivement, il vaut mieux partir du fac—similé dont on connaît l’édition et la source Gallica. Par contre, pour la typographie du titre, je pense que Zephyrus a raison Discussion:La_Mare_au_Diable, George Sand utilise La Mare au Diable dans sa notice Page:Sand_-_La_Mare_au_Diable.djvu/6. Il faudrait donc changer toutes les pages du fac—similé ??? Et ça je ne sais définitivement pas faire… Toto256 (d) 24 septembre 2010 à 17:27 (UTC)

Il faut demander sur Commons le renommage du fichier. Il y a un modèle pour faire cette demande, c’est plutôt rapide je crois. De cette manière, tant que tu n’as pas commencé l’édition du livre, il ne sera pas nécessaire de renommer les pages. Marc (d) 24 septembre 2010 à 17:36 (UTC)

On pourrait aussi ajouter un paragraphe « Demande de renommages » sur la page des requêtes, est-ce que cela ne permettrait pas de regrouper et suivre plus facilement le renommage sur Commons et le renommage sur Wikisource en même temps ? Pyb, Vigneron, Yann et moi (ordre alphabétique pas chronologique) sommes administrateurs là-bas et ici et pourrions faire le tout ensemble. Des idées plus pratiques ? Autres propositions ? Des inconvénients auxquels on n’aurait pas pensé ? Où mettre un lien vers la page des requêtes pour qu’elle soit retrouvée facilement ? --Zyephyrus (d) 24 septembre 2010 à 18:59 (UTC)

Merci pour le renommage (j'ai cru avoir tout cassé, ouf …) : on va pouvoir se mettre au travail. Par ailleurs, effectivement, le besoin de renommage existe : j'ai bien peur de devoir faire une demande pour Le Parfum de la dame en noir qui me semble plutôt devoir être Le Parfum de la Dame en noir voir Page:Leroux_-_Le_Parfum_de_la_dame_en_noir.djvu/39 mais là il y a tout à refaire… Toto256 (d) 24 septembre 2010 à 22:37 (UTC)

Bonjour, pour le nommage des fichiers on a des règles qui sont identiques pour tous les livres (permet d'éviter les doublons). Mais ce sont des règles assez complexes (voir ici et ici). Et cette majuscule de la Dame en noir n'est pas forcément pertinente dans le nommage du fichier ou du texte, je ne vois pas d'exception pouvant s'appliquer au cas. Par contre dans le texte lui-même, on conserve en général tel quel (peut-être voulu par l'éditeur ou mieux l'auteur). Sapcal22 (d) 25 septembre 2010 à 23:02 (UTC)

OCR

Bonjour,

Ma question est simple, mais je n'ai pas trouvé sa réponse sur les autres pages... Pourquoi mon bouton OCR a disparu, alors qu'il est bien activé dans les gadgets ? Merci, Bertille

Peux-tu préciser sur quelle page il a disparu, est-ce toutes les pages, qu’elles soient sans texte ou avec texte ? --Zyephyrus (d) 24 septembre 2010 à 18:24 (UTC)

J'ai le même problème avec les "nouvelles fonctionnalités" (et avant, avec la version bêta) ; quand je désactive les nouvelles fonctionnalités, je récupère l'OCR - et je perds plein d'autres boutons de mise en forme. Et c'est sur toutes les pages. --Acélan (d) 24 septembre 2010 à 18:47 (UTC)

Acélan : ce n’est sans doute pas le même problème, car tu parles du fait que tous les boutons de l’ancien habillage n’ont pas encore migré vers le nouvel habillage qui par contre en apporte de nouveaux de son côté, d’où des adaptations un peu tâtonnantes pour l’instant pour nous tous. Bertille : était-ce pour toi comme pour Acélan ? --Zyephyrus (d) 24 septembre 2010 à 20:55 (UTC)

Oui, j'ai désactivé les nouvelles fonctionnalités pour l'instant pour retrouver mon bouton. Merci ! --Bertille

Interwiki

Ce contributeur a placé un certain nombre de liens dans les pages. Ce type d’interwiki ne semble pas fonctionner, mais on ne peut pas non plus mettre des liens dans un espace réservé aux textes. Que faire ? Marc (d) 24 septembre 2010 à 19:38 (UTC)

À la place de {{Wikipédia|Michel Strogoff (roman)}}, employer {{interprojet|nolink|w=Michel Strogoff (roman)}}, qui affichera le lien dans le menu de gauche (voir Trousse à outils (déployer Modèles, 1ère série). Pour l’instant les modèles de la trousse à outils sont en vrac dans l’ordre où ils ont été déposés, en attendant que quelqu’un en structure la liste…. --Zyephyrus (d) 24 septembre 2010 à 20:46 (UTC)

En fait, je pensais à des interwiki en bas de page, comme ici : « Ô triste, triste était mon âme ». Marc (d) 24 septembre 2010 à 21:03 (UTC)

C'est embêtant de ne pouvoir utiliser le même système que pour les autres langues quand cela se situe sur oldwikisource'... ou alors c'est un préfixe que l'on a pas trouvé ? Un argument de plus pour une langue qui voudrait se créer son propre wiki Sapcal22 (d) 25 septembre 2010 à 23:07 (UTC)

George, Alexandre Dumas

Bonjour. J'essaie de rendre George un peu plus lisible. Que dois-je faire du code wiki " [merged small][ocr errors]" ? que je trouve, me semble-t-il, en fin de chapitre. Dois-je laisser ou retirer ? Merci des réponses. --Ambre Troizat (d) 24 septembre 2010 à 20:01 (UTC)

Bonjour, il faut le supprimer, ce qui semble être fait. Le texte doit être le plus proche possible de l'original Sapcal22 (d) 24 septembre 2010 à 22:06 (UTC)

OCR

Le bouton OCR apparait fugitivement puis disparait sous le bouton gras... j'ai essayé d'être plus rapide sans succès. Est-ce propre à ma config (Firefox 3.5.13 sur Mandriva) ou d'autres ont ce problème ? Sapcal22 (d) 25 septembre 2010 à 10:59 (UTC)

Sous l’habillage vector ? --Zyephyrus (d) 25 septembre 2010 à 12:26 (UTC)

Merci Zephyrus, ton message + celui du dessus que je n'avais pas vu, m'ont permis de trouver un mode ou celà fonctionne. A priori je ne touche pas aux préférences pour rester comme l'utilisateur novice... là en l'occurence ce n'est pas le fameux vector mais Activer la barre d’outils améliorée ou une de ses voisines qui cachait ocr Sapcal22 (d) 25 septembre 2010 à 22:00 (UTC)

catégories mode page

j’ai caché les catégories d’avancement dans l’espace page, car cet affichage n’est pas utile (présence du bandeau) ThomasV (d) 25 septembre 2010 à 21:42 (UTC)

Autre traduction HS

Le modèle autre version qui servait à faire un lien direct avec d'autres traductions du même texte, mais d'un traducteur différent ne fonctionne plus {{AutreVersion|Orgueil et Préjugé|Autre traduction}}. Il était par exemple pour Orgueil et Préjugé sous autre langue pour donner les deux autres traductions existantes du texte. Sapcal22 (d) 25 septembre 2010 à 22:53 (UTC)

Pour moi, cela fonctionne. Marc (d) 25 septembre 2010 à 23:19 (UTC)

Lettrines (suite)

Bonjour, j'ai un souci avec les modèles de Lettrine. Je m'explique (voir exemple La_Mare_au_Diable/02 associé à la page Page:Sand_-_La_Mare_au_Diable.djvu/15).

Si j'utilise le modèle {{Lettrine}}, alors un retour à la ligne apparaît à la cassure de la page physique.

Inversement, si j'utilise le modèle {{Lettrine2}} (plus esthétique par ailleurs car il évite l'indentation de la lettre qui suit), cette fois-ci je n'ai plus aucun retour à la ligne donc plus de paragraphe !!!

Merci de vos conseils Toto256 (d) 26 septembre 2010 à 09:42 (UTC)

Pour information, la moins mauvaise solution que j'ai trouvée pour le moment est d'utiliser {{Lettrine2}} et de fermer explicitement le paragraphe par un </p>. Cela fonctionne que la fin de paragraphe soit dans la même page ou dans une page suivante. Toto256 (d) 27 septembre 2010 à 17:13 (UTC)

Merci, Toto256, d’avoir trouvé une solution ! Nous en prenons bonne note. --Zyephyrus (d) 27 septembre 2010 à 17:20 (UTC)

Désolé pour le dérangement

Je ne comprends pas pourquoi entre la page 101 et 102 ici http://fr.wikisource.org/wiki/Journal_d%E2%80%99un_%C3%A9crivain/1873/VII, il y a un retour à la ligne, Merci pour votre aide --Le ciel est par dessus le toit (d) 27 septembre 2010 à 10:04 (UTC)

un <br /> superflu. Marc (d) 27 septembre 2010 à 10:15 (UTC)

merci--Le ciel est par dessus le toit (d) 27 septembre 2010 à 10:42 (UTC)

Huet - Étude sur les différentes écoles de violon.djvu

J'ai importé la première image dans l'ouvrage Huet - Étude sur les différentes écoles de violon.djvu, sur lequel je fais les premières corrections manuelles, page 60. J'ai utilisé l'icône galery. Pouvez-vous me dire si j'utilise la bonne méthode ? J'avais uploadé l'image en format tiff plutôt que jpeg. Cela a-t-il une importance capitale ? Merci de vos réponses --Ambre Troizat (d) 27 septembre 2010 à 21:50 (UTC)

Je l’ai remis en 450 pixels, pour le rapprocher des dimensions du fac-similé ; tu peux essayer d’autres dimensions si tu préfères, en modifiant le chiffre devant px dans le lien qui appelle l’image (Mediawiki comprend et affiche indifféremment les trois mots image, file ou fichier — anciennement image, puis file en anglais, traduit par fichier en français ; les dimensions se mettent le plus souvent en px pour pixels ; en dernier on met ce qui doit s’afficher en alternatif ou dans une infobulle). --Zyephyrus (d) 28 septembre 2010 à 08:28 (UTC)

Merci Zyephyrus, je vais expérimenter tout ça. --Ambre Troizat (d) 29 septembre 2010 à 19:20 (UTC)

Comment je bidouille, me trompe et m'énerve dans mon coin ou les preuves de mon incompétence

Ça parait toujours facile comme ça, le métier de copiste, mais bon comme dirait ma boulangère : « rien n'est facile dans la vie, ma bonne dame ». Oui elle dit toujours ma bonne dame, même si son interlocuteur est un bon monsieur, cela me ferait davantage sourire si elle me disait mon bon homme, mais ça elle ne le dit pas. (peut-être que son boulanger d'homme n'est-il pas bon, mais comme diraient certains comiques, troupiers ou pas, : « cela ne nous regarde pas. »)

Pour revenir à notre sujet. Je recopie ou corrige les textes à partir des Djvu, rien de très compliqué jusque là, mais là où ça se complique c'est quand je veux obtenir quelques chose comme ça : Journal_d’un_écrivain/1873/V alors que la page sur le Djvu est comme ça : Page:Dostoïevski_-_Journal_d’un_ecrivain.djvu/72. Comment fait-on donc pour que les quelques phrases n'apparaissent pas au dessus du titre : V BOBOK après transformation. J'ai essayé par moi même par des copier-coller de la syntaxe mais je me suis souvent planté et quand j'ai cru trouver une solution, elle appartenait, à ce que certains mystiques apparenteraient à un miracle.

Dans mes bidouilles, j'ai rajouté le texte : II MON PARADOXE qui figure sur le Djvu Page:Dostoïevski_-_Journal_d’un_ecrivain.djvu/240 à la fin de cette page là : La_Mort_de_George_Sand alors qu'il n'a rien à faire sur cette dernière.

Ô généreux contributeurs, quelqu'un pourrait-il m'expliquer la logique pour obtenir le résultat escompté et me préparer quelques pages du texte sur lequel je m'acharne Livre:Dostoïevski_-_Journal_d’un_ecrivain.djvu, afin que je puisse me reposer quelques instants des troubles que cette incompréhension génère sur ma santé morale.

En attendant, je courre chez ma boulangère m'acheter un croissant que je savourerai en pensant bien à vous.

Merci --Le ciel est par dessus le toit (d) 28 septembre 2010 à 09:03 (UTC)

Bonjour, je te conseille, si ce n'est déjà fait, la lecture de Aide:Transclusion, en particulier la première question des FAQ.

Le principe est donc de préciser le nom de la section étiquetée à conserver en début et/ou en fin de transclusion en utilisant les attributs fromsection et tosection.

Pour que cela fonctionne, ces sections étiquetées doivent être définies dans les pages qui sont en début/fin de transclusion (voir le point 1 sur Aide:Labeled_Section_Transclusion)

Ex : Dans Page:Dostoïevski_-_Journal_d’un_ecrivain.djvu/72, 2 sections étiquetées sont définies (ch4 et ch5). Pour n'avoir que le contenu de la section ch5 au début de Journal_d’un_écrivain/1873/V, le champ fromsection est défini à ch5.

Concernant La_Mort_de_George_Sand, il suffit de reproduire le même schéma en créant une section étiquetée correspondant au chapitre 1 (ex : ch1) sur Page:Dostoïevski_-_Journal_d’un_ecrivain.djvu/240 et d'indiquer le nom de cette section dans l'attribut tosection sur La Mort de George Sand.

Chocodup (d) 28 septembre 2010 à 13:16 (UTC)

modèle 1er

Pour écrire 1^er j'ai trouvé deux modèles :

• {{1er}} qui donne 1^er
• et 1{{er}} qui donne 1^er

Dans mon navigateur 1^er (modèle {{1er}}) apparait souligné (je ne sais pas si c'est le cas pour tous le monde)

C'est le cas pour tout le monde car la feuille de style CSS par défaut de MediaWiki produit ce soulignement pointillé par une décoration du texte, sauf si votre navigateur est configuré pour ignorer totalement le CSS émis par le site web, ou si vous visualisez le site en mode texte seul, ou via certaines passerelles (pour téléphone mobile par exemple, ces passerelles éliminant tout le CSS émis), y compris les mises en exposant assez souvent (et les gras, italiques, soulignements, couleurs, images, etc...). — Verdy_p (d) 2 octobre 2010 à 00:59 (UTC)

et n'est pas toujours copier-collable lorsqu'on le sélectionne à l'écran (le copier/coller fonctionne vers un éditeur de texte mais pas vers un traitement de texte où 1^er est éliminé de la phrase qui le contient). La cause : la balise abbr qu'utilise le modèle pour afficher premier lorsque l'on passe la souris dessus. Comment se comporte cette balise chez vous ? (j'aime bien faire des copier/coller sans perdre de mots en route, et ne suis pas trop emballé par un multiplication possible de mots soulignés dans les textes de wikisource, donc je serais plutôt défavorable à l'utilisation telle-quelle de cette balise dans le corps des textes, mais je vois que ce modèle existe depuis un petit moment...) --Bgeslin (d) 28 septembre 2010 à 17:47 (UTC)

Je préfère le deuxième. Je dois même avouer que je ne connaissais pas le premier, et au vu des pages liées au modèle, peu de monde le connait/l’utilise. Aristoi (d) 28 septembre 2010 à 19:48 (UTC)

peut-être qu'on pourrait les fusionner, par exemple en conservant le 2^e et la syntaxe du 1^er ThomasV (d) 28 septembre 2010 à 19:55 (UTC)

Ce qui me gène avec ces modèles, c'est que le er étant trop gros ou haut, il augmente l'interligne, ce qui est rarement le cas dans les fichiers source. De toute façon, deux c'est un de trop. Sapcal22 (d) 30 septembre 2010 à 21:29 (UTC)

Pas du tout ! Les exposants sont codés de façon qu'ils ne touchent pas à l'interlignage du texte qui les contient (ce qui n'est en revanche pas le cas des numéros de références). (L'interlignage par défaut du texte est 1.5em, l'exposant utilise un interlignage 1 (relatif à la taille du texte englobant) avec une taille de texte réduite à 83.3%) — Verdy_p (d) 2 octobre 2010 à 00:24 (UTC)

Fusionner me semble être une fausse bonne idée : 1. n’oubliez pas les autres abréviations en ^er comme I^er 2. pour des raisons d’accessibilité,

Quelle accessibilité ? Le texte doit être aussi accessible que l'original qui n'a pas pris soin de les expliquer. — Verdy_p (d) 2 octobre 2010 à 01:05 (UTC)

il faut utiliser la balise abbr.

NON ! NON ! NON ! C'est modifier le texte que de vouloir l'expliquer ! — Verdy_p (d) 2 octobre 2010 à 01:05 (UTC)

3. par contre, le comportement de cette balise peut (doit?) pouvoir être modifier ; étrangement {{Abréviation}} indique « ce modèle ne souligne pas l’abréviation ».

Il me semble donc que c’est plutôt un problème de rendu qu’il faut corriger sur le modèle {{abréviation}}.

Sapcal22 : la balise sup place l’élément trop haut (cf. la première ligne de cette section) mais pas les modèles normalement (chez moi, les deux exemples fonctionnent correctement).

Oui mais la balise sup du modèle {{e}} (qui est employé aussi dans les abréviations qui l'utilise y compris {{1er}}) n'est pas employée toute seule, elle a un style qui réduit l'interlignage en même temps que la taille (la réduction de taille suffisant à conserver un interlignage suffisant). — Verdy_p (d) 2 octobre 2010 à 00:24 (UTC)

Cdlt, VIGNERON * ^discut. 1 octobre 2010 à 15:37 (UTC)

Je confirme que je suis pas normale ... les 3 sont pareils, c'est bien ce que je voulais dire. Mais c'est un détail. Sapcal22 (d) 1 octobre 2010 à 16:59 (UTC)

Je suis d'accord que le soulignement imposé des abbréviations avec l'élément "abbr" dans un texte (div class="text") est un problème qui doit pouvoir se résoudre facilement dans la feuille de style de Wikisource, en lui demandant de ne pas le faire (même si l'abbréviation le produit ailleurs), même si on peut conserver en revanche la spécification du curseur d'aide (cursor:help) qui n'est pas gênante pour la lecture:

.pagetext abbr, .text abbr {text-decoration: none;}

Cependant je ne vois aucune utilité à baliser dans un texte original les abréviations de l'auteur aussi usuelles que 1^er, et 1^er est aussi simple et efficace (et tous les exposants ne sont pas des abréviations).

Bref les autres abréviations comme M^gr seront aussi aisément produites sans "abbr" ainsi: M^gr, avc le modèle de base des exposants {{e}}. Demander ce balisage est une pollution inutile des textes originaux (et impose une interprétation absente du texte original ou implicite), et on ne le fait pas non plus pour les liens vers des sites web présents dans les textes ou leurs références originales. Je suis donc plutôt contre l'emploi de "abbr" (ce qui supprimera en même temps son effet de bord à l'affichage). Si l'auteur a ressenti le besoin d'expliquer ses abréviations, il l'aura fait littéralement dans son texte, pas la peine de le rajouter...

Bref c'est même le modèle {{abréviation}} tout entier (et les autres modèles qui l'utilisent) qu'il faudrait interdire dans les textes où il n'a pas sa place.

La seconde apparence demandant uniquement les exposants originaux sans noter qu'il s'agit d'une abréviation (ni l'expliquer dans une bulle d'aide) est nettement préférable: le modèle "{{1er}}" devrait être remplacé directement par "1{{er}}" (qui sétend lui-même en "1{{e|er}}")

Il n'y a qu'un seul cas où il serait bon de marquer certaines abréviations : celui où il est impossible de la rendre dans la forme originale (par exemple une ligature ou un signe impossible à coder en Unicode, HTML ou CSS actuellement). Dans ce cas, le soulignement servirait non pas à expliquer le sens de l'abréviation, mais à en afficher un rendu (il faudrait du javascript pour pouvoir afficher une image alternative sur la zone marquée).

Vouloir expliquer une abréviation, c'est introduire une interprétation (éventuellement fausse !) du texte original, et c'est totalement inutile pour les abréviations usuelles (que l'auteur n'a pas eu besoin non plus d'expliquer), et pour les autres, le texte original contiendra une définition de cette notation inhabituelle (et il sera aussi inutile de répéter cette interprétation sous une autre forme dans une balise "abbr").

— Verdy_p (d) 2 octobre 2010 à 00:24 (UTC)

La Nuit des rois

J'ai essayé de mettre la nuit des rois dans Wikisources. Je n'y connais rien. Quelqu'un peut-il regarder ou faire des remarques.

Merci --Berichard (d) 28 septembre 2010 à 20:31 (UTC)

Bonsoir,

Cela me semble très bien mis en page. Je crois qu’il existe un modèle pour le nom des personnages ; peut-être des contributeurs qui s’occupent particulièrement de l’édition de pièces de théâtre pourraient-ils dire si des modèles de ce genre sont à utiliser ici. Marc (d) 29 septembre 2010 à 20:08 (UTC)

On peut utiliser les modèles de Wikisource:Éditer du théâtre si on le souhaite, bonne continuation Sapcal22 (d) 30 septembre 2010 à 21:26 (UTC)

Statistiques

Bonjour,

J’ai modifié légèrement les statistiques, afin de ne pas compter comme textes les pages d’Homonymie (définies sur Mediawiki:Disambiguationspage). Ceci explique pourquoi le nombre de textes dans Modèle:ALL TEXTS a diminué de 600, et pourquoi Modèle:PR PERCENT a augmenté de 0.40%.

ThomasV (d) 29 septembre 2010 à 09:17 (UTC)

simplifier la syntaxe LST

Les transclusions de sections en mode page sont compliquées, et semblent poser problème à beaucoup de monde. Une partie de cette difficulté tient à la syntaxe des balises de l’extension LST : les sections doivent être délimitées par des balises de début et de fin (sauf avec lsth, mais cette option, non activée ici, impose d’afficher les titres de section)

ces balises ont une syntaxe compliquée et inhabituelle:

<section begin=chapitre1/>
bla
bla
<section end=chapitre1/>

alors qu’un habitué des balises html s’attendrait plutôt à ceci :

<section name="chapitre1">
bla
bla
</section>

La raison de cette complication est que l’auteur de l’extension LST a voulu rendre possible la transclusion de sections qui se chevauchent. Cette possibilité est tout à fait inutile pour Wikisource, et c’est elle qui nous impose cette syntaxe compliquée.

Afin de simplifier ceci, j’ai écrit un gadget javascript qui remplace ces balises par un pseudo-titre de section (comme avec lsth):

##chapitre1##
bla
bla

Ces pseudo-titres sont reconvertis en balises lors de l’envoi de la page.

Exemple : Page:Diderot - Œuvres complètes, éd. Assézat, XIX.djvu/307 (comparez le wikitexte avec et sans le gadget).

Ce script permettrait de simplifier beaucoup la transclusion de sections en mode page.

Notez que ceci nous enlève la possibilité d’utiliser l’espace entre sections pour y mettre du texte à ne pas transclure. Par exemple, sur cette page, le titre en chiffres romains est intercalé entre deux sections : [3]. Le gadget a une action non neutre : il déplace le texte placé entre les sections, vers la section du haut.

Je pense cependant que ceci est un faux problème. En effet, exploiter un effet de bord de la LST pour ne pas transclure du texte me semble être une mauvaise habitude. Si un texte ne doit jamais être transclus, il est préférable de toujours le signaler par des balises noinclude (exemple ici): c’est standard, facile à comprendre, et de cette manière on est sûr que le texte ne sera pas transclus, que la page appelante utilise ou non des LST (et si un texte doit parfois être transclus, il vaut mieux le mettre dans une section étiquetée).

Je propose donc de promouvoir l’utilisation de ce gadget, et d’adopter pour convention de ne plus insérer de texte entre des sections étiquetées en mode page.

ThomasV (d) 1 octobre 2010 à 00:25 (UTC)

mise à jour : j’ai fait en sorte que le gadget ajoute tout seul les sections noinclude si il rencontre du texte entre les sections. il n’y a donc plus besoin de vérifier ceci. ThomasV (d) 1 octobre 2010 à 08:35 (UTC)

Bonjour, le problème avec la méthode employée dans l'(exemple) c'est que cela fait disparaitre le numéro de chapitre correspondant de la page texte entier. --Bgeslin (d) 1 octobre 2010 à 09:14 (UTC)

en effet. si le numéro de chapitre est à transclure, il faut le mettre dans une section, quite à en créer une troisième. du coup je me demande si c’est une bonne chose que le script ajoute des "noinclude". ThomasV (d) 1 octobre 2010 à 10:29 (UTC)

c’est bon, j’ai modifié le gadget; au lieu d’ajouter des "noinclude" il ajoute une section supplémentaire. elle porte le nom de la section qui la précède suivi de "_bis" ThomasV (d) 1 octobre 2010 à 10:45 (UTC)

On a l'exemple sur Wikisource anglophone où on a un étiquetage des sections et sous-sections (imbriquées), notamment pour la comparaisons des textes bibliques.

C'est vrai que la syntaxe est un peu inhabituelle (celle des balises de fermeture), mais l'inclusion mutuelle a aussi son utilité, d'autant plus que la délimitation des sections et sous-sections s'étend sur plusieurs pages (et de plus n'est pas non plus strictement hiérarchique, le balisage relevant d'axs d'analyse différents (parfois orthogonaux) du texte (par exemple par langue, ou par auteur dans un ouvrage à plusieurs auteurs, ou par chapitre, ou selon différentes numérotations en vigueur des chapitres, afin de produire des lectures dans des ordres différents, ce qui est fréquent dans les textes bibliques).

La numérotation des versets est aussi orthogonale, puisque selon les traditions, on peut avoir des numérotations distinctes (versets fusionnés ou non) pour exactement le même texte par le même auteur (ou traducteur) et la même édition de l'ouvrage (je m'en suis aperçu dans une des traductions du Coran) !!!

Donc avant de passer un bot pour tout supprimer (travail qui risque de casser les numérotations et transclusions de pages), merci de considérer qu'on peut avoir une syntaxe simplifiée, mais qu'en cas de problème, la syntaxe longue sera notre seul recours (d'autant plus que ces balises ont aussi un effet sur les sauts de lignes inclus ou non dans la transclusion de la section, ce qui serait facilement cassé et fausserait les numérotations de paragraphes, ou risquerait d'ajouter des paragraphes vides).

Je veux bien qu'on ait une syntaxe simplifiée, à condition que vous ne décidiez pas d'interdire la syntaxe LST actuelle qui a son utilité et sa spécificité. — Verdy_p (d) 2 octobre 2010 à 00:15 (UTC)

personne n’a parlé d’interdire la syntaxe actuelle, ni de faire passer un robot ; il s’agit uniquement d’activer un script qui simplifie la rédaction des pages et évite des erreurs. De plus, ce script se désactive tout seul sur toute page qui comporte de l’inclusion mutuelle, donc on ne perd absolument rien. ThomasV (d) 5 octobre 2010 à 15:03 (UTC)

Mise à jour : après une période de test, le script est activé par défaut. il reste possible de le désactiver en ajoutant "self.proofreadpage_raw_lst=true;" dans vos préférences.

Notez que les parties du texte qui ne sont pas dans une section sont précédées par une ligne contenant "####" (exemple)

ThomasV (d) 19 octobre 2010 à 20:19 (UTC)

J’ai peur de comprendre la mise à jour. J’espère qu’aucun script n’a été activé par défaut sur mon compte. Si le but était de simplifier la vie des personnes qui ont du mal à comprendre la syntaxe des sections, j’ai du mal à comprendre que l’on suppose facile à comprendre comment se ferait l’ajout de "self.proofreadpage_raw_lst=true;" dans les préférences. Il me semble qu’un principe de base serait d’éviter de modifier automatiquement les préférences. Par ailleurs, je trouve que la syntaxe des sections est évidente. Il m’a suffit de voir un exemple et de le reproduire pour avoir un résultat qui me satisfaisait. Je voudrais continuer ainsi sans avoir à modifier, je ne sais comment, mes préférences. Loïc Mottier (d) 20 octobre 2010 à 13:01 (UTC)

j’ai créé un gadget pour faciliter le réglage des préférences. ceux qui ne souhaitent pas utiliser la nouvelle syntaxe peuvent donc cocher l’option "ancienne syntaxe pour les transclusions de sections dans l'espace Page" dans leurs préférences (section gadgets) ThomasV (d) 20 octobre 2010 à 12:33 (UTC)

Merci. C’est plus clair ainsi. Loïc Mottier (d) 20 octobre 2010 à 13:01 (UTC)