Wikisource:Colorer les langues

Idées et projets

Vous êtes ici : accueil >Projets >Colorer les langues

    Légende des icônes : état d’avancement des projets et des portails
   00%.svg   En projet     25%.png   Commencé     50%.png   En cours     75%.png   Avancé     Relu et corrigé   Terminé  







Projet n° 38 – Colorer les langues

Enrichir et assouplir les modèles de formatage des citations en langues autres que le français.

Pourquoi ?Modifier

Transclusion

Source : Discussion utilisateur:VIGNERON/Archive_1#langues de couleur

quand on cherche / consulte un tel dico avec l'intention de trouver les info de telle ou telle rubrique sur une de ces langues, tu n'imagines pas combien on gagne en confort et en rapidité de consultation.


LiensModifier

Transclusion

Source : Wikisource:Scriptorium/Juillet_2007#Modèle lang


Transclusion

Source : Wikisource:Scriptorium/Juillet_2009#Des couleurs et des langues


PropositionModifier

Acer11 propose ceci : Dans mon idée il faudrait préciser {{lang|en|vert|hello}} ou {{lang|en|#0AA545|hello}} (ex. fantaisiste).

DiscussionModifier

Ce projet a été intitulé Colorer les langues par Zyephyrus (d · c) mais selon moi cela pourrait aller plus loin et concerner toute la gestion des langues (la couleur mais aussi la police, et la taille d’écriture). Qu’en pensez-vous ?

Modèles existants :

Dans les feuilles de style :

VIGNERON * discut. 24 juillet 2009 à 15:06 (UTC)

Le b (blocages) du modèle {{User}} judicieusement choisi pour faire remarquer que Zyephyrus a déjà été bloqué (et qui plus est par soi-même), pour ceux qui se demanderaient pourquoi Vigneron introduit ici ce modèle ;-) . Pour revenir aux choses sérieuses, il me semble que la proposition d'Acer11 serait nettement plus maniable que cette liste hétéroclite. Y a-t-il d'autres avis ? En fait la question me paraît être celle qu'Acer11 a posée : peut-on construire un tel modèle ? Je louche vers diverses personnes, en particulier Philippe ou Faager (mais pas seulement eux). Autre question : verrais-tu un inconvénient, Vigneron, à déplacer cette discussion sur la page du projet, pour ne pas avoir à suivre deux pages en même temps ? --Zyephyrus 24 juillet 2009 à 13:10 (UTC)
À propos des blocages (j'utilise aussi le modèle {{u}} sans mauvaise intention), il existe maintenant {{u'}} qui semblera moins agressif. Faager 24 juillet 2009 à 13:55 (UTC)
Désolé, j’utilise User tellement couramment que je n’y fais même plus attention (on peut aussi mettre block=non). En fait, le b apparait même si on n’a pas été bloqué, exemple : VIGNERON (d · c · b).
Pour moi, les modèles {{he}} (hébreu), {{Sa}} (sanscrit), et {{polytonique}} devrait clairement disparaître au profit de lang (qui devrait gérer la taille et la police). La feuille de style devrait être étendue à toute les langues (et pas que grc, el, et he).
Par contre, je ne sais pas si on doit gérer en même temps la couleur et la langue et si oui comment.
Aucune objection à déplacer cette conversation (c’est mon premier projet, je n’osais pas intervenir directement sur la page principale).Cdlt, VIGNERON * discut. 24 juillet 2009 à 15:06 (UTC)
Heu, attention, Philippe m'a fait {{he}} pour ce travail épisodique, j'en suis très content et j'aurai du mal à m'en passer, la lisibilité est devenue agréable ! --Acer11 24 juillet 2009 à 15:16 (UTC)
Tu peux avoir exactement le même rendu avec lang (c'est d'ailleurs mon but). Cdlt, VIGNERON * discut.
Je comprends d'autant plus ta réaction qu'ayant maintenant l'habitude du modèle {{polytonique}} cela me plairait assez en fin de compte de le conserver aussi :) --Zyephyrus 24 juillet 2009 à 16:24 (UTC)
Il faut évidemment conserver ces modèles mais comme redirections vers {{lang}}. Cdlt, VIGNERON * discut. 25 juillet 2009 à 17:40 (UTC)
Puisque j'ai l'honneur d'être cité comme pouvant construire un tel modèle, je dois vous décevoir : je ne pense pas pouvoir, tout seul, réussir faire ce que vous demandez, à moins d'être guidé exactement dans ce qu'il faut implémenter, car je n'ai idée ni d'alphabets non latins, ni des besoins exacts qu'ont ceux qui les utilisent. Ce que je sais (à peu près) faire, c'est implémenter concrètement des conditions (du type #if, #ifeq, #switch, #expr et cie). Donc, je pense qu'il vaut mieux s'adresser en priorité à un spécialiste des langues en cause. Je pense que Philippe s'y connaît mieux que moi en tout cas. Faager 25 juillet 2009 à 00:01 (UTC)
Philippe, tu es là ? Il y aurait aussi Kipmaster qui connaît plusieurs langues et sait bien programmer ; et tout autre contributeur compétent même partiellement sur la question ne doit surtout pas hésiter à participer à ce projet s'il en a envie ! --Zyephyrus 25 juillet 2009 à 07:58 (UTC)

En fait, je vois deux parties dans ce projet :

  1. la partie technique (je suis assez compétent mais j’aurais besoin d’aide, Lgd pourrait nous aider, cela ne passe pas des des parsers mais plutôt par des classes et la feuille de style)
  2. une partie « décisionnelle ».

Avant de modifier le code de la feuille de style (et potentiellement de faire des bêtises comme ce que j’ai indiqué à François), il faut définir ce que l’on veut précisément. Quelle langue est concerné par quelle(s) modification(s). Par ordre de priorité, je vois:

  • agrandir la taille des écritures peu visibles (hébreu, chinois, japonais, arabe, tibétain, hindis, etc. à 1.25 ou 1.5 em à définir précisément),
  • utiliser des polices de caractères spécifiques pour certaines langues (pour les grecs ancien grc et moderne el, ce qui est déjà en place dans la feuille de style mais qui pourrait être amélioré/étendu),
  • la question des couleurs (où je n’ai aucun avis particulier).

Tout cela doit se faire à partir du modèle {{lang}} uniquement (évitons de multiplier inutilement les modèles, les anciens modèles doivent être conserver pour des raisons de compatibilité/habitude, par contre, on peut envisager de créer un modèle pour chaque langue pour simplifier en tant que redirection, par exemple {{sanskrit|blabla}} serait une redirection vers {{lang|sa|blabla}}, cela éviterait aux utilisateurs d’avoir à connaître les codes langes ISO 639) et est géré par les feuilles des style (reste à déterminer laquelle : la globale : commons.css, celle par apparence : Mediawiki:monobook.css, ou bien par celle personnelle de chaque utilisateur : ma page/monobook.css).

Il faudrait aussi prendre des exemples sur différents usages pour voir comment adapter cela correctement. Cdlt, VIGNERON * discut. 25 juillet 2009 à 17:40 (UTC)

Si je puis me permettre (puisque Vigneron m'avait demandé un coup de main): vous avez deux choses bien différentes à gérer:
  • la métadonnée signalant la langue, sans effet sur l'affichage, via un modèle {{lang}} qui se contente de baliser pour donner la bonne valeur de code de langue à l'attribut HTML concerné
  • d'éventuelles mises en formes de ces contenus, qui peuvent varier selon la langue (couleur, police, taille etc.)
Pour bien gérer cela, et conserver également une syntaxe peut-être plus simple pour les contributeurs, vous avez besoin:
  • d'un modèle {{lang}} qui ne fait que créer la métadonnée (attribut lang="...")
  • d'une série de modèles {{sanskrit}}, {{grec ancien}}, etc. qui font appel au modèle {{lang}} et qui se chargent des mises en formes particulières. Pour les langues n'ayant pas besoin d'une mise en forme spécifique autre qu'une mise en couleur commune, un modèle générique {{langue}} sera utile.
De cette manière, vous gardez la possibilité de bien gérer séparément mise en forme et métadonnées et vous disposez de modèles évitant aux contributeurs d'avoir à connaître les codes de langue.
Cordialement, --Lgd 26 juillet 2009 à 05:25 (UTC)
Moi cela me convient. Des objections ? On y va ?
Vu que l’on a deux étapes indépendantes, on peut déjà commencer par la modèle {{lang}} (et corriger les css). Cdlt, VIGNERON * discut. 14 août 2009 à 09:07 (UTC)
Oui oui, ça me va moi aussi, merci Vigneron de relancer, allons-y pour :
  • le modèle {{lang}}
  • En attendant de diversifier il pourrait y avoir aussi le modèle générique {{langue}} pour les langues n'ayant pas besoin d'une mise en forme spécifique autre qu'une mise en couleur commune, comme propose Lgd.
Ceci dit vivement la diversification pour le grec ancien et l'hébreu. --Acer11 14 août 2009 à 17:54 (UTC)

Quelle(s) couleur(s)Modifier

Le projet avance mais on n’a pas défini quelle(s) couleur(s) utiliser !

Les couleurs déjà prises sont le noir (#000000), le blanc (#ffffff), les bleus #002bb8 (lien interne) #5a3696 (lien interne visité), #3366bb (lien externe), les rouges #cc2200 (lien rouge), #a55858 lien rouge visité).

Il reste donc de nombreuses couleurs disponibles (16 777 209 pour être exacte). Il semblerait que les verts soient déjà utilisé dans certains monobooks, il reste donc les bruns, les gris, les violets, les oranges, etc.

Le brun ou le gris me semble la meilleure solution (les violets sont trop proches des bleus ou des rouges, les oranges souvent trop clair pour respecter les normes de contrastes).

Je propose donc un brun comme #804000 (ratio de 7,9) ou le gris foncé #656565 (ratio supérieur à 5 selon Colour Contrast Analyser, un gris plus clair ne serait plus accessible). Cdlt, VIGNERON * discut. 15 août 2009 à 09:46 (UTC)

Les deux me paraissent intéressantes, j'aurais tendance à privilégier le gris pour le modèle général, à la fois facile à voir quand on le cherche et discret sur l'ensemble d'une page. --Acer11 16 août 2009 à 06:55 (UTC)

Je pense que ce n'est pas une bonne idée. Les couleurs sont déjà utilisées par MediaWiki pour indiquer des liens. Quelqu'un qui a l'habitude de Mediawiki, en voyant du texte de couleur, va penser qu'il s'agit d'un lien et peut etre essayer de passer sa souris dessus. De plus, il reste peu de couleurs disponibles (lien nouveau, visité, inexistant, inexistant visité = 4 couleurs déjà prises, sans compter les 'stub' ). bref, il ne reste que le vert, en supposant que l'utilisateur n'ait pas changé ses préférences. (et encore, le vert est abondamment utilisé par Zephyrus un peu partout) ThomasV 14 août 2009 à 09:18 (UTC)

En utilisant les classes, on peut moduler les rendus. Le rendu dépend donc uniquement de ce que l’on décide. Personnellement, je serais plutôt partisans de ne rien colorer par défaut, et de créer une case « colorer les langues » dans l’onglet Apparence Spécial:Préférences. Par contre, la taille devra être activé pour tous (case coché par défaut, décochable évidemment).
Sinon, il reste encore pas mal de couleurs (gris, brun, violet, jaune, etc. on devrait pouvoir en trouver parmi les 16 777 216 couleurs disponibles). Quelle sont exactement les couleurs déjà employées ? En analysant les pages, je dirais #002bb8 (lien interne) #5a3696 (lien interne visité), #3366bb (lien externe), #cc2200 (lien rouge), #a55858 (lien rouge visité) est-ce bien cela ? y en a-t-il d’autres ? (évidemment, je ne parle pas de ceux qui ont modifié leur monobook, leur css, voire leur navigateur)
On peut aussi envisager autre chose que de simplement colorer le texte : le souligner avec des tirets par exemple, le surligner, etc.
Respecter le choix des utilisateurs est selon moi, un point essentiel et ce n’est nullement incompatible. Cdlt, VIGNERON * discut. 14 août 2009 à 15:14 (UTC)
Avoir du texte coloré en pleine page, c'est différentier des éléments dont la lecture se trouve ainsi facilitée : l'indication d'une lien, éventuellement, mais pas seulement. Dans un dico comme le Trévoux, pouvoir identifier les mots en langues étrangères à la couleur est un vrai bonus pour la consultation. --Acer11 14 août 2009 à 18:16 (UTC)
Évidemment, c’est un bonus, mais il ne faut pas le faire n’importe comment (sinon, le bonus devient un malus). Au-delà de la colorisation, la balise HTML lang (introduite par le modèle lang et qui ne colore rien) est reconnu par les lecteurs d’écrans et donc facilite l’accès pour les aveugles (point important aussi). Cdlt, VIGNERON * discut. 15 août 2009 à 09:18 (UTC)
Je me permets d'afficher cette discussion sur la page du projet. --Zyephyrus 16 août 2009 à 07:14 (UTC)

Quelle(s) taille(s)Modifier

Le projet avance mais on n’a pas défini quelle(s) taille(s) utiliser ! (echo)

Il faudrait définir précisément quelle taille appliquer à quelle écriture. En gros, je crois que la plupart des écritures non-latines ou presque sont concernées :

  • arabe : العربية, et persan : فارسی
  • berbère (tifinagh) : ⵜⴰⵎⴰⵣⵉⵖⵜ
  • chinois (sinogrammes, Hanzi) : 漢語;中文
  • coréen (Hangul) : 한국말
  • japonais : 日本語 (Kanji), とうきょう (Hiragana), チーズ (Katakana)
  • cyrillique (biélorusse, bulgare, macédonien, roumain ancien, russe, ruthène, serbe, ukrainien, vieux slave) : кириллица
  • hébreu : עִבְרִית
  • grec : Ἀρχαία Ἑλληνική (ancien) et Νεοελληνική (moderne)
  • gotique : 𐌷𐌰𐌿𐌱𐌹𐌳𐌰𐍃𐌴𐌹𐌳𐍉 (rare, nécessite souvent d’installer une police d’écriture)
  • Écriture de l’Inde : देवनागरी Devanâgarî (pour le sanskrit, hindî, le népalais, le marâthî, etc.), বাংলা Bengalî, ગુજરાતી Gujarâtî, தமிழ் Tamoul, తెలుగు Télougou, ਗੁਰਮੁਖੀ ਲਿਪੀ Gurmukhî (pour le panjâbî), (etc. ?)
  • khmer : ភាសាខ្មែរ
  • laotien : ພາສາລາວ
  • thaï : ภาษาไทย
  • tibétain : བོད་སྐད་ (rendu mal géré -entre autres- par Firefox)
  • futhark et autres runes : ᚠᚢᚦᚨᚱᚲ
  • inuktitut : ᐃᓄᒃᑎᑐᑦ
  • cherokee : ᏣᎳᎩ ᏫᎩᏇᏗᏯ

Ceci dit, vue que certaines langues utilisent plusieurs systèmes d’écritures, cela complique la chose (il faut préciser he pour de l’hébreu en hébreu et he-Latn pour la transcription de l’hébreu). Cdlt, VIGNERON * discut. 15 août 2009 à 09:46 (UTC)

Pour l'hébreu, la taille du modèle {{he}} me convient très bien et pour l'esthétique et pour la lisibilité.
Pour le grec, faire au moins l'équivalent du rendu par un <big>, ce qui peut être proposé comme une norme en attendant avis plus précis selon les langues. --Acer11 16 août 2009 à 07:00 (UTC)
Actuellement, {{he}} augmente de 150 %. Cela me semble peut-être un peu beaucoup mais cela me va bien. Pour visualisation : 150 % : עִבְרִית ; 125 % (c’est-à-dire l’équivalent d’un big) : עִבְרִית. Le rendu diffère selon les ordinateurs, mais chez moi (Mozilla Firefox et Opera), en 150 % on dirait que le texte est en gras (ce qui peut gêner la lecture, surtout si on rajoute une couleur !).
ronntudju, j'veux pas pinailler, je ne vois pas ce pb de "gras" mais ça me suffit avec 125% seulement. --Acer11
 
Ce que je vois sur mon écran (avec Opera mais le rendu est similaire sur Firefox) sour Windows XP.
J’ai fait une copie d’écran pour te montrer, ce n’est pas très esthétique (par curiosité, qu’utilise-tu comme navigateur/système ?). 125 % me semble un bon compromis et surtout cela correspond à un big (donc cela sera mieux esthétiquement, si on veut mettre du texte en big à côté). Cdlt, VIGNERON * discut. 17 août 2009 à 19:12 (UTC)
C'est curieux, je n'ai pas ce rendu avec un XP banal et le dernier FF (3.5.2), mais je ne sais pas faire une image de ce que je vois. Ailleurs j'ai aussi un linux (debian) avec Iceweasel, dans mon souvenir c'est pareil que WP + FF. Je vérifierais. --Acer11 18 août 2009 à 06:07 (UTC)
Pour le grec, autant le grec ancien grc mérite un agrandissement (avec tout les esprits et autres diacritiques), autant cela me parait moins nécessaire pour le grec moderne el.
Chui OK là-dessus. --Acer11
La taille est de toute façon assez subjective (moi qui ai l’habitude de lire du chinois, je n’aurais pas besoin d’en augmenter la taille, mais cela ne concerne que moi et comme je le disais le rendu dépend aussi du navigateur et du système installé par chacun) et il faudra plusieurs essais avant de trouver les bonnes tailles. Cdlt, VIGNERON * discut. 16 août 2009 à 08:01 (UTC)
Je ne suis pas convaincu de l’intérêt d’augmenter le taille de l’écriture hébraïque. En effet, la taille standard est la même que celle de Wikisource en hébreu et pour moi, ça reste lisible (cf. ici). Le problème est que, quand on augmente la taille des caractères, les diacritiques ne semblent pas suivre et le rendu n'est pas terrible du tout, en tout cas sous Firefox et Opera. Pour reprendre l’exemple ci-dessus, je ne vois pas le hidiq sous le ע initial quand est utilisé le modèle {{he}}. Pymouss |Parlons-en| 16 août 2009 à 09:22 (UTC)
grmmmblblbl, 'faut penser aux copains qui ont des difficultés, ou à ceux dont une langue dans un autre alphabet n'est pas une lecture bien rodée, fluente... C'est quand même tellement plus facile quand c'est agrandi ! sans parler de l'esthétique (je reconnais que c'est secondaire). Pour les psaumes en hébreu, j'ai vu des étudiants qui se décourageaient "remis en selles" simplement en agrandissant les textes. --Acer11
+1, il faut penser au plus grand nombre, les lecteurs d’hébreu (et même globalement de langue étrangère) ne font pas partie « du plus grand nombre ». Il me semble donc logique d’agrandir (mais pas trop non plus, sinon les conséquences font plus de mal que de bien).
Pour le hiriq, il me semble plus visible en 125 % qu’en 100 % (par contre, à 150 % il est confondu avec la jambe du ayin initial donc invisible). La wikipédia en Hong-Kongais est aussi en 100 % [1] mais franchement, c’est illisible (même pour moi, qui me débrouille en chinois classique). PS : Acer, si le 125 % ne te suffit pas, tu peux toujours faire crtl + +.
Je n'ai pas ce pb, mais OK pour 125%, comme déjà dit. --Acer11 18 août 2009 à 06:07 (UTC)
Globalement, je propose donc de mettre en 125 % toute les langues non-latines sauf pour le cyrillique et le grec moderne (et ancien ?) en 100 % (hiragana et katakana pourrait aussi être en 100 % mais le code langue est le même que pour les kanji). D’autres suggestions ? Cdlt, VIGNERON * discut. 17 août 2009 à 19:12 (UTC)
OK avec le grec ancien en 125%. --Acer11 18 août 2009 à 06:07 (UTC)
100% est OK pour le cherokee, dont les glyphes et leur métrique sont plus ou moins calqués sur le latin et le cyrillique. Même chose pour les tifinagh ou le syllabaire canadien autochtone, dont les structures graphiques sont légères et très lisibles.
Un agrandissement s'étudie au cas par cas, écriture par écriture, mais pas par une règle par défaut.
Concernant l'hébreu ou l'arabe, l'agrandissement dépend de selon qu'on utilise un jeu enrichi de diacritiques ou non (il est préférable d'agrandir l'arabe coranique ou l'hébreu biblique afin d'expliciter les lectures vocaliques et interprétation, ainsi que les intonations ou cantillations, par les diacritiques qui sont difficiles autrement à distinguer).
Mais la seule vraie façon de procéder est d'utiliser "font-size-adjust:" (surtout pas "font-size:" ! Le résultat est horrible, entre autres, sur le thaï, le tibétain, et même le chinois dont les sinogrammes servant de base pour la taille de corps n'ont pas du tout la métrique des caractères latins inclus dans les mêmes polices, mais qui nécessitent tout de même un agrandissement à cause de la complexité graphique, ceci n'étant pas nécessaire au même degré pour le coréen moderne écrit en Hangul, presque toujours sans sinogrammes "Hanja").
Voir aussi comment Windows règle le problème dans les "font-aliasing" définis pour les polices virtuelles destinées à l'internationalisation des dialogues et de l'UI. Des ajustements de taille sont bel et bien définis police par police en fonction de la police d'origine, et du jeu de caractères (essentiellement l'écriture) ciblé dans la police définie en alias...
J'ai déjà fait des suggestions d'ajustement de tailles, qui fonctionnent sur bon nombre d'écritures dans ma feuille de style personnelle (chargée depuis mon monobook.css ou vector.css local, qui référencent un fichier "polices.css" unique sur mon compte utilisateur de Wikipédia, ce fichier étant partagé alors sur tous les projets Wikimedia et même d'autres projets hors de Wikimedia). — Verdy_p (d) 14 septembre 2011 à 17:41 (UTC)

Quelle(s) police(s)Modifier

Il y a aussi le choix de la police qui peut être fait via le CSS. Là part contre, je suis complètement inculte, en plus, je crois me souvenir que forcer le rendu avec une police spécifique c’est Mal.

Actuellement, le modèle {{polytonique}} propose plusieurs polices (je suppose que le navigateur utilise la première police sauf si elle n’est pas disponible, et ainsi de suite avec les suivantes). Cdlt, VIGNERON * discut. 16 août 2009 à 08:12 (UTC)

Ces polices mentionnées dans le modèle devraient ne plus être là. La classe ou la langue indiquée suffisent. Pour le reste, les polices peuvent aller dans la feuille de style CSS... — Verdy_p (d) 14 septembre 2011 à 18:59 (UTC)

Suivi du projetModifier