2A02:2788:228:93D:61FE:834C:8847:7515

apostrophe

Cher 2A02:2788:228:93D:61FE:834C:8847:7515 (!...)
Quel est l'intérêt de remplacer le modèle {{'}} qui est fait pour précisément « afficher une apostrophe dactylographique juste avant un texte en italique ou en gras » (cf. la doc) par une apostrophe typographique, qui n'est utilisée nulle part ailleurs dans cet article ? Où est la cohérence ?
-- jilucorg → ✉ 24 janvier 2022 à 20:08 (CET)

Cher jilucorg,

Si tu veux, « par soucis de cohérence » (et de correction orthotypographique rigoureuse), je veux bien me charger de placer l’apostrophe typographique partout dans l’article en question…

L’usage du modèle {{'}} est réellement triste… il alourdit inutilement le code sans apporter aucun gain par rapport à directement encoder proprement l’apostrophe typographique qui est recommandée par les instances en charge d’UNICODE. Faut-il réellement encore en 2022 se limiter à l’usage qui avait été imposé à l’époque de l’ASCII ?

Bien cordialement, 2A02:2788:228:93D:61FE:834C:8847:7515 (discuter) 24 janvier 2022 à 21:09 (CET)

C'est prêcher un convaincu ! Personnellement, hors de WP, j'utilise systématiquement l'apostrophe typographique, j'ai même remappé mon clavier principal pour l'obtenir directement à la place de l'autre. Ce débat est récurrent ici (un marronnier), mais ce que j'ai pu en retenir en retenir c'est 1) jamais d'a. typo dans les titres d'articles et de paragraphes – sinon il faut faire des redirections car les recherches n'aboutissent pas –, et 2) cohérence à l'intérieur d'un même article.
Bien d'accord que c'est pénible, mais je vois difficilement comment unifier la chose au profit de l'a. typo, ce que perso je souhaiterais : la plupart des gens ne savent même pas que ça existe...
Bien cordialement itou, -- jilucorg → ✉ 24 janvier 2022 à 23:17 (CET)

Tiens, je viens de corriger un lien rouge : Apprentis d’Auteuil → correction : Apprentis d'Auteuil
-- jilucorg → ✉ 25 janvier 2022 à 19:41 (CET)

C’est super ! Merci
À mon humble avis, et sauf cas d’exception, l’a. dactylo (ainsi que les guillemets droits) ne devrai(en)t plus être utilisée(s) que pour le codage informatique (langage de programmation et autre usages apparentés, tels que les doubles et triples a. dactylo utilisées dans le code wiki pour l’italique et la mise en gras) ; la persistance de confusion (liée à la très grande polysémie de l’a. dactylo, dont l’usage il y plus de trente ans avant l’arrivée d’UNICODE n’avait presque pas d’alternative en informatique) est cause de mille et une misère comme par exemple l’apparition de « \' » dans certains textes lorsqu’un informaticien s’est trompé dans l’écriture d’une chaîne de caractères, ou à l’inverse l’absence d’apo. là où il en fallait une, voire même de nombreuses heures perdues dans du débogage… etc. De nos jours, pratiquement plus rien ne justifie de maintenir l’usage de cette a. dactylo si polysémique… nous avons ’ ′ et quelques autres symboles similaires, chacun dédiés à des usages spécifiques… C’est un peu comme si on voulait nous forcer à utiliser des abaques pour faire de la comptabilité… ou un TELEX à l’époque de l’internet haut-débit !
Cordialement, 2A02:2788:228:93D:209E:FD1D:F81E:45F5 (discuter) 26 janvier 2022 à 01:10 (CET)

Bien d'accord avec tout ça (en informatique notamment), mais je ne vois pas comment on pourrait en sortir, déjà il faudrait que Microsoft change la façon d'obtenir ’`‘' etc. directement (pas en tapant des Alt+1234 !) dans une session Win, comme sous Nunux avec les 4 niveaux ; et puis pour la rétrocompatibilité avec les milliards de lignes de code... Pour l'anecdote, concernant le fax, j'ai un fils qui bosse à Paris à la PJ (BRB) au nouveau 36, donc pas au fin fond de la cambrousse ni dans un service de dernier ordre : ils transmettent *toutes* leurs procédures aux proc' par fax, c'est une obligation, faut du papier (et d'ailleurs leurs procédures c'est une horreur à faire, avec des bécanes complètement pourries et un logiciel atroce qui leur fait perdre un temps énorme) !
-- jilucorg → ✉ 26 janvier 2022 à 09:20 (CET)

Microsoft n’est pas le seul intervenant problématique dans cette histoire… l’attachement viscéral aux configurations AZERTY/QWERTY — qui rappelons-le ont été inventés dans le but d’éviter que les tiges des Remington de nos arrières grand-mères se bloquent lorsqu’elles tapaient trop vite — est un autre élément très important.
À noter au crédit de M$ : ils proposent depuis de très nombreuses années un outil gratuit de reconfiguration et personnalisation de la configuration du clavier : Microsoft Keyboard Layout Creator (MSKLC). Et quand on y songe, si les Japonais et Chinois sont parvenus à imaginer des systèmes permettant d’utiliser un clavier comportant un nombre très limité de touches en comparaison au nombre invraisemblable d’idéogrammes, il n’y a aucune raison qui empêche qu’on ne puisse le faire pour des langues latines ! Quant à l’aspect des « recherches », le problème étant purement logiciel, il suffit d’adopter la façon de faire de Firefox par exemple qui propose de cocher des cases : « Respecter la casse » et « Respecter les accents et diacritiques », et pouf l’argument du « on n’arrive pas à trouver le texte recherché à cause de… » s’effondre lui aussi (certes l’option ne permet pas encore de trouver « cœur » avec « coeur » et inversement, mais à terme il faudra qu’ils se bougent un peu pour également gérer toutes les ligatures œ, æ, ij (voire d’autres dans certaines langues) ; j’espère en tout cas que les logiciels permettent déjà une recherche « avancée » pour les alphabets latins étendus usités dans certaines langues d’Europe de l’Est et pour le vietnamien par exemple). 2A02:2788:228:93D:B9F5:94CF:6DFA:7D95 (discuter) 26 janvier 2022 à 15:39 (CET)