User talk:Verdy p

Jump to navigation Jump to search

@Nemo There was absolutely no edit war on this message, I was pinged after fact (on another wiki!) I saw it later, I just made a single edit that Thibaut reverted instantly while I was using a normal review. Those that don't do any work acannot be criticized, I dod a lot, many things I do are validated, but unavoidably, there will be veruy few things that people disagree later. There is no valid cause for such measure: I've not refused to talk, I've particiapted when I was pinged, but Thibaut started to discuss it elsewhere and did not notify me first here and did not initiate any talk here. When we use the translate interface on one page or message group, each item is commited without seeing any notification; I did not do "massive" edit, but normal review with the existing interface. Who will want to work on this wiki if decisions are made elsewhere, and I did not damage anything. And this was absolutely not an edit war (only Thibaut warred instantly gasint my edit, and did not wait for any discussion or even a reply: I promptly replied as fast as I could, and withing the existing limits of this wiki and tools).

Visibly it's impossible to follow any discussion when decisions are made elsewhere and I'm not properly notified on the right place, and I get NO change at all to see that there's a disagreement. You take this decision hours later, even if I've not made any further changes after these late talks on another place.

Your LENGTHY block is not respectful of the HUGE work I've done and do (almost all validated). I get no time (not even a minute to react when things are decided elsewhere).

I appeal it, the normal procedures are not followed and you don't even seem to consider the technical limtiatiàon of this wiki (and visibly users on other external wikimedia wikis do not understand the intereactions bwetween Wikimedia and this wiki: I'm not "guilty" for technical limitation of these interactions and the lack of cooperation by Wikimedians (nor absence of desire to properly review what happens here with correct methods).

-Note: I cannot reply in LiquidThread below, so this is here. I could send you a mail. Verdy p (talk) 19:21, 6 January 2021 (UTC)

And I appeal again; the only user that complained used agresive tone, and did not want to discuss, and continued with his bad tone. I gave all explainations. That user changed his mind multiple times, did not read the relevant doc, did not want to discuss seriously the problem that was overlooked too rapidly. I've NOT disupted lot of people, but a very few users (that should be aware of the rules and of the documentation available and displayed prominently, rejected the arguments, choosing instead to NOPT solve the proble mthat affect all users of MediaWiki, adding even more to the confusion.

I've not abused any rule, but that user abused it at lerast by his very unpolite tone, disregarding all efforts made and even proposals I offered to him in the talk that he initiated himself. He even biased the presentation by reversing the facts in the complaints, saying "wrongly" that I had not read a doc (that the same user admitted to have not read, because he asked "which doc?" (even after I had pointed him to the place that he should have read). So I've been agressed, I've vreplied pollitely, but I'm sanctionned, and not the abuser (at least for his tone and agression, and the falsified presentation of facts. He also at one time accepted my presentation, then got elsewhere to complain without notifying me: a decision was made then by someone not looking the facts seriously, and disregarding the efforts I made to explain, exhibit the problem: I did not disrupt massively as stated. My change was fully in sync with existing doc and rules (and past decisions made since long collectively for Mediawiki).

The problem remains exclusively in Flow, which is not widely deployed (and not even enabled by default in Wikipedia). Is used the existing past decisions (and the "/qqq" doc made by Flow authors themselves that "hide" should be translated exactly like in the MediaWiki UI, and also visible in the UI of TWN in the "/qqq" page that lists the "identical" resources). I've not created these docs. Flow needs a fix, and a serious discussion, but disregarding the problem I discovered whi_le using the existing policies and documentation, and not taking any action agaisnt the complainer for his unpoliteness and biased presetnation of facts is simply unacceptable.

A single small contributor that decides for himself for an option that is used by ~5 users in, but that breaks the UI for millions users, can take over all past collective decisions (that I respected, and demontrated as being relevant).

Once again, some privileged admins (for very specific rights) want to own projects (that they don't really participate in), and that have made little efforts, other than imposing their view and rejecting any problem, using also agressive tone. Who will calm them? Who was refusing to discuss the problems? Not me. Where this blocking decision was made and justified? No where. Where was I given a chance to explain and present the facts (as they are known, some of them are presented later). I've used the correct chronology and did not bias them. It is once again a proven fact that we cannot discuss in Wikimedia about any relevant problems, if a few admins decide to ignore them and discard all relevant discussions (and lall past collective decisions) and not allow in fact anyone to contest or propose something else. I've not damaged anything for anyone. Flow has a problem, but I'm not the cause of it and now the problem is even worse in French and no one wants to fix it (even if it contradicts the documented goals). All past works and donated time from important contributors that took may cautions and used the best efforts, are simply voided by a few that don't merit their privilege that they don't own but are just a temporary trust granted by a much larger community (that is supposed to review these privileges but cannot discuss about these privileges when they are abused by the grantees).

-- Verdy p (talk) 14:05, 22 April 2021 (UTC)

@Jules*:: Non ta référence est incorrecte; ce que tu cites c'est ce qui a été fait pour Flow et uniquement lui (et jamais revu); Flow n'est PAS Mediawiki, c'est un addon récent, partiellement intégré sur quelques pages au gré des utilisateurs qui le souhaitent. Mediawiki n'inclut pas Flow.

Et je recommence parce que tu ne lis toujours pas: ce n'est PAS Mediawiki qui utilise "hide=masquer" depuis longtemps (et non pas "hide=cacher") dans son UI. Et il y a eu de nombreuses aurtes unifications auparavant pour "hide=masquer" changé en "hide=masquer", à de nombreuses reprises (y compris par VIGNERON et d'autres "admins") et partout c'était pour l'interface de navigation de MediaWiki, sans aucun privilège, qui n'impactait jamais les autres (sans modif dans la base de données, ou seulement dans les préférences personnelles de l'utilisateur seul, pour ce qui concerne par exemple les notifications qu'il a reçues et déjà lues, mais qu'il peut relire plus tard et toujorus rechercher et afficher).

L'interface UI de MediaWiki a bel et bien "hide=masquer" disponible pour tout le monde, depuis longtemps on le voit dans les notifications, les boites déroulantes (c'est intégré dans les composants Javascript de l'interface). Partout où "hide" dans cet usage pour tous avait été traduit de façon incohérente comme "cacher", cela a été corrigé. (Sauf dans l'extension Flow que finalement bien peu utilisent).

Maintenant au lieu de garder cela, Flow a ajouté deux actions d'administration "delete" (pour sysops) et "suppress" (pour "oversighters"/modérateurs). C'était source de confusion en anglais.

Lors de la traduction jamais relue en français la version pour "oversighters/modérateurs (5 personnes en tout sur Wikipé il a été mis "suppress=supprimer" (delete="supprimer" pour les sysops a été gardé et correctement traduit). Comme cela faisait doublon cela a ensuite été changé en "suppress=masquer", là encore nouveau doublon avec l'action pour tous "hide=masquer" pour tout le monde dans Mediawiki.

J'avais corrigé tout ça en remettant "hide=masquer" dans Flow (comme dans MediaWiki), en gardant "delete=supprimer" (là aussi comme dans Mediawiki), et réglant corerctemetn le doublon final sur "suppress" pour les "oversighters"/modérateurs (plusieurs propositions dans la discussion): il était possible d'utiliser "masquer" éventuellement mais pas tout seul: une précision était indispensable mais plus lisible et compréhensible que "(OS)" qui ne veut rien dire (la seule façon de le lire naturellement en anglais c'est comme l'abréviation de "operating system", ce qui ici n'a aucun sens: la précision "(OS)" n'en est donc pas une, elle n'est clairement pas suffisante pour comprendre ce que fait cette commande, à qui elle s'adresse et qui elle impacte, selon quelle règle.

Flow fait bande à part, uniquement en français, à cause d'un mélange initial jamais relu lors des premières traduction de ce greffon quand il était en chantier (et il n'est encore, Wikiemdia ne l'ayant pas intégré comme composant de base et continuant encore à utiliser les pages Wiki standard pour l'espace de discussion utilisateur et la plupart des pages de décision et communautaires).

Maintenant tu penses que ce que je dis est faux mais il est clair que tu ne veux pas lire ou comprendre, et même que tu veux me lire en faisant dire ce que je n'ai pas dit. J'ai essayé d'être clair, et tu as prétendu que je n'ai rien compris, mais tu as confondu les choses. Tu n'as pas non plus lu les docs de Flow indiquées dans "/qqq", c'était pourtant correctement guidé dans TWN.

Il reste que Flow a fait le choix malheureux du terme "suppress" en anglais pour l'action des "oversighters" et que cette action en anglais n'est pas claire non plus (pas facile de comprendre que ce n'est pas la même chose que "delete" pour l'action des sysops. Et pourtant, le rôle documenté des "oversighters" est bel et bien celui de modérateur (c'est explicite dans la doc de Flow... que donc tu n'as pas lue non plus avant de demander à l'administrer). Le terme "over-sight" est aussi ambigu (en clair c'est la même chose que "over-view", c'est une supervision (pas une simple relecture collaborative entre pairs, car il y a une forme d'autorité et ce n'est pas un droit pour tout le monde, et pire encore ceux qui l'ont peuvent même dissimuler leurs propres actions)

Ce n'est pas à utiliser n'importe comment, le risque étant la falsification et un abus d'autorité: exactement ce qui s'est produit ici contre moi, en utilisant en plus des arguments faux (marteler en sens inverse que c'et moi qui me trompe alors que j'ai bien fait référence à Mediawiki seul pour clairfier ce qui était spécifique à l'extension Flow qui n'a toujours pas été relu et approuvé comme partie de Mediawiki, meme s'il a été isntallé comme extension dans certains wikis dont mais uniquement pour certaines pages).

Il y a bien une gêne pour pas mal de monde, mais ce que j'ai fait minimisait la gêne: quelque chose doit changer et mon changement revenait aux choix initiaux de MediaWiki (pour tout le monde) et n'impactait alors que ~5 utilisateurs (autodésignés...) sur dont un s'est trompé initialement.

Et me bloquer ici pour ça, sans tenir compte de la quantité énorme de travail que j'ai fait ici (et que toi-même tu as utilisé sans t'en rendre compte, comme beaucoup, car justement c'était cohérent). Ce que j'ai fait n'est rien d'autre que de la relecture. Et je me suis appuyé déjà faits sur les choix passés depuis longtemps pour Mediawiki dans son UI de base (et certainement pas que pour, l'interface francophone de Mediawiki servant aussi à TOUS les autres wikis (quels que soient leur édition linguistique sur leur contenu, dans Wikiemdia mais partout ailleurs):

Il ne faut certainement pas que la wikipédie francophone impacte tous les autres wikis; c'est bien pour ça que Mediawiki est traduit ici et que cela doit se concerter à une plus large échelle. Il peut exister des décisions raisonnables faites sur la Wikipédie francophone (ou ailleurs) masi au final il faut que ce soit signéalé et référencé ici, parce que les autres projets ont aussi leur mot à dire et au moins tout le monde doit être au courant.

Cela n'a pas été fait et à la place une décision abusive est prise contre moi, en comité externe restreint, sans me laisser aucun moyen de me défendre, ou seulement m'écouter et pas déformer ce que j'ai dit. Et pire on me dénigre publiquement alors que je suis de ceux qui ont le plus aidé de monde ici et ailleurs. Et on vient ajouter en plus des trucs aussi faux: "impossible de discuter" avec moi... A-t-on seulement essayé ? J'ai répondu autant que possible et sans tarder, je n'ai pas fait la sourde oreille.

Et toi même tu avais même accepté ma traduction, avant de te rétracter depuis mon blocage, parce que tu as trouvé un soutien inattendu ailleurs (dans des discussions occultes sur certains canaux, où on m'a cité sans même me consulter ni aucun "ping" d'alerte et surtout aucune trace visible). Bref une décision biaisée, faussée car les évidences ne sont pas complètes et qu'il m'a été prêté des intentions et des actes qui n'étaient pas les miens. Une décision "'d'autruche la tête dans la terre" (qui feint de reconnaitre un problème bien réel dans Flow que j'ai décrit, et dont on pouvait discuter sans remettre en cause la traduction de MediaWiki qui fonctionnait avec des décisions collectives, comprises et bien appliquées: refuser de regarder pour ne pas voir la réalité, surtout si elle est plus compliquée que ce qu'on croit en première vue et qu'on n'a pas envie de réfléchir, et croire que cela réglera le problème ou le préviendra; le problème est toujours là!).

Flow reste à part, c'est encore un élément mineur, on me bloque pour ce qu'on vu une poignée d'utilisateurs francophones privilégiés, qui n'ont même pas bien lu les docs existantes et ont encore moins travaillé ici et discuté avec aussi peu de monde ici pour les aider comme je l'ai fait, sans compter mes heures, et qui en plus ont utilisé (un langage grossier en perdant leur calme et coupant court à tout). Qui ne voulait pas discuter ici? certainement pas moi. Mais celui qui a demandé ma sanction a fait tout ce qu'il a voulu sans comprendre et surtout en mentant par omission volontaire.

Note aussi que j'ai même voulu t'aider sur la page support (où tu changes encore une fois de pseudonyme...). Tu avais posé une question j'ai répondu, chercher à te guider (je ne t'ai rien imposé), mais aucune réponse. On se demande avec qui tu veux réellement discuter. Et je l'ai fait sans même relier à la question de la traduction de Flow. Visiblement tu n'es pas arrivé ici pour aider, juste te plaindre et chercher à nuire ce projet en attaquant un de ses plus gros contributeurs; mais tu n'as pas fait autant d'efforts et consacré autant de temps que j'en ai fait, tu as agi dans la précipitation et coupé court toi même à toute discussion (sans la solliciter et la suivre sérieusement, et en utilisant un langage grossier qui normalement aurait dû disqualifer tes propos; mais je n'ai pas tenu compte de cette attaque et cherché à rester courtois; au final je suis le seul sanctionné sévèrement mais toi tu as eu ce que tu voulais, tu n'a contribué à rien du tout, tu as menti par omission ou en déformant mes propos et ne ne voulant rien lire du tout, d'ailleurs tu as même avoué n'avoir pas lu les docs!)

En quoi suis-je "coupable". Et comment j'aurais pu réagir autrement ? J'ai essayé de suivre les règles du mieux que je pouvais (une erreur est possible pour tout le monde, même pour moi ou d'autres admins qui en font aussi, mais ça se corrige à condition de discuter correctement et il n'y a rien qui alors justifie un tel emportement comme tu l'as fait en maquillant la vérité).

Je maintiens donc mon appel ici contre cette décision. Et d'autres utilisateurs même de Wikipédia verront bien qu'il s'agit d'un abuis d'autorité et que la politique générale de concertation assied encore une fois quelques privilégiés qui biaisent toute forme de décision collective puisqu'ils peuvent utiliser des sanctions démesurer, et même user de menaces, mensonges ou insultes sans être sanctionné : les wikipédiens n'élisent pas les admins, ils en ont seulement peur et se taisent ou au final ils en partent et l'audience de Wikipédia ne fait que s'éroder et le site reçoit de plus en plus d'avis négatifs dans nombre d'autres médias: il n'est plus du tout ouvert comme il le devrait, il est même devenu plus fermé que Facebook (en dépit de sa modération automatique forte, mais au moins on sait dans quel sens elle agit, et lui au moins il n'exclut personne, sauf délit vraiment grave engageant sa responsabilité légale).

Le problème de Flow est toujours là, mais au vu de la sanction portée contre moi ici, personne n'osera plus s'y impliquer et cela restera du seul bon vouloir des 4 ou 5 utilisateurs de Wikipédia francophone qui d'une part ne participent pas ici, d'autre part ne font rien non plus dans le développement de Flow, enfin n'en ont pas lu les docs utiles, et n'ont jamais autorisé quiconque contester une traduction rapide jamais relue (même si c'est incohérent).

Verdy p (talk) 12:23, 25 April 2021 (UTC)


Thread titleRepliesLast modified
MediaWiki:Flow-history-action-suppress-post/fr1310:28, 23 April 2021
MediaWiki:Cargo-cargotables-hasreplacement/fr107:01, 21 April 2021
FreeCol:Model.monarch.action.declareWar.text/fr107:19, 14 April 2021
Template:Languagename807:54, 7 April 2021
Your changes to Convenient Discussions translations215:19, 25 March 2021
pagename009:55, 25 March 2021
The Inuka Team: We need your help.012:03, 15 March 2021
PLURAL & EOL116:45, 9 March 2021, 17 February 2021, 17 February 2021
Nouvelle guerre d'édition1315:35, 16 February 2021
Mass changes without consensus418:46, 6 January 2021
Wikimedia:Wikiedudashboard-timeline.block_type214:15, 31 December 2020
Es-tu sûr ? ;-)019:57, 29 December 2020
Vicuna:Uploadcheck-checks-running013:26, 29 December 2020
Mantis:S kb/fr015:12, 7 December 2020
Changements inutiles avec GENDER et PLURAL915:00, 12 August 2020
Thanks014:24, 12 August 2020
Espaces fines insécables entre les guillemets1020:58, 8 December 2019
Typographie dans les traductions114:58, 1 December 2019
First page
First page
Previous page
Previous page
Last page
Last page



Merci de m'indiquer en français compréhensible ce qu'est censé vouloir dire ce « (en relecture) » dans MediaWiki:Flow-history-action-suppress-post/fr.

Par ailleurs, concernant MediaWiki:Flow-moderation-confirm-hide-post/fr, je suis admin (et OS) sur Wikipédia en français, je suis quand même bien placé pour savoir qu'on parle de masquage (et masquer) quand il y a action admin (qu'il s'agisse de Flow ou non). « Cacher » n'a jamais été le terme utilisé pour décrire les actions admins. Merci de cesser de reverter et de rendre l'interface de Flow incompréhensible ! Vous aviez déjà annulé la modification correcte d'Arkanosis…

Jules78120 (talk) 13:09, 21 April 2021 (UTC)

Jules78120 (talk)13:09, 21 April 2021

Laissez tomber, ras-le-bol de tomber sur vous à chaque fois qu'il y a des éléments d'interface bancals. Je vais utiliser les bons termes en local directement sur WP-fr et m'éviterait vos modifications mal-avisées et hors-sol.

Jules78120 (talk)13:14, 21 April 2021

Non, OS est ambigu déjà en anglais et encore plus en français). et "afficher/masquer" est la norme déjà dans nombre de traductions de Mediawiki, modèles et modules.

Si maintenant il faut préciser un droit admin ce doit être plus explicite que le "(OS)". Tu contestais "quelles doc" alors que la doc était visible dès le début dans l'UI normale de TranslateWiki (la sous-page "/qqq" qui s'affiche par défaut et précise le tout).

Si tu viens contester ça c'est à revoir sur Wikipédia et Mediawiki qui font exactement le contraire de ce que tu dis... La précision est nécessaire (peut importe le verbe que tu préfères) mais elle doit être claire. c'est bien pour ça que même en anglais cela incluait la précision (qui au départ n'existait pas mais qui a justement été ajoutée en incluant aussi la doc nécessaire, que tu n'as toujours pas lue!)

Tu sembles te baser sur l'ancienne version ambigue (avant le changement nécessaire approuvé en anglais): ça te perturbe si tu utilise l'outil avec le droit admin mais cette perturbation est minimale et ne concerne que quelques admins qui doivent s'y faire et ne donne aucune gêne pour les autres (les milliards d'utilisateurs de Mediawiki, ou la centaine de millions en français, qu'ils aient des privilèges ou pas).

Et Flow doit aussi s'accorder avec le reste (ce n'est pas la seule interface de discussion): le "masquage" est aussi pour Mediawiki standard : notifications, boites de navigation déroulables dans les modèles courants et n'implique aucun privilège nécessaire.

Donc j'ai juste considéré l'usage en vigueur le plus courant, que tu voudrais changer unilatéralement sans en discuter avec les très nombreux autres (par millions ou plus si on inclue aussi les tas de wikis hors de Wikimedia) plus concernés que la microscopique poignée d'admins francophones de Flow (qui sert assez peu, car Flow a de grosses anomalies connues).

Verdy p (talk)13:21, 21 April 2021

De plus tu ne sais pas discuter, le ton grossier de tes commentaires en dit long...

J'ai été bien gentil de répondre (promptement) sans utiliser ton langage. Si tu avais fait autant d'effort sur Translatewiki que j'en ai ait depuis longtemps, en écoutant énormément de monde ce n'est pas surprenant que parfois quelqu'un contribuant épisodiquement soit surpris, mais qu'il refuse la discussion et s'emporte comme tu le fais n'est pas acceptable.

Va te plaindre si tu veux, mais au moins fais le honnètement avec une vraie discussion et pas juste une attaque personnelle. Je n'ai rien fait de "mal" et au contraire je soutiens bien plus de monde que tu crois. Il peut y avoir parfois des ratés, mais pas la peine de polémiquer car cela ne fait rien avancer pour personne.

Note bien que l'action d'interface utilisateur avec les boites déroulantes utilise depuis longtemps "afficher/masquer" (action inversible à tout moment, ne faisant aucune modification dans la base de données et ne demandant strictemen aucun privilège). Ce choix a été discuté depuis longtemps et a suivi dans Mediawiki lui-même. Cette interface existe aussi dans les discussions standards de Mediawiki (pages de discussion) avec des boites déroulantes (pour les discussion closes / archivées qui ne devraient plus être modifiées).

On a le même contexte implicite dans Flow: "masquer" ne devrait donc pas demander non plsu de privilège. Il en est de même pour le masquage des notifications (inversible aussi avec des cookies ou des préférences stockées de l'utilisateur).

"Cacher" pose plus de problème (il entre en conflit avec la notion de cache, c'est-à-dire de mémoire tampon, avec un usage technique, qui serait malgré tout approprié pour certaines actions administratives demandant un privilège, si "masquer" tout seul ne suffit pas pour distinguer la simple action personnelle dans l'UI de tout le monde).

Verdy p (talk)13:27, 21 April 2021

Oh, je conviens n'avoir aucune patience à votre endroit, puisque ce n'est pas la première fois que vous passez en force. Ici, vous privilégiez votre avis sur les termes à utiliser à... l'usage en place. Sauf que ce faisant, vous rendez une interface de Wikipédia inutilisable. Alors vraiment, vous me faites perdre mon temps. (Et la doc que vous citez ne soutient absolument pas ce que vous dites.) Que vous apportiez beaucoup à TranslateWiki (je ne le remets pas en question) n'enlève rien à vos passages en force.

Et vos discours sur l'interface... avec vos modifs les OS avaient deux liens "masquer", rendant l'interface incompréhensible. Quant au fait que « cette perturbation est minimale et ne concerne que quelques admins qui doivent s'y faire et ne donne aucune gêne pour les autres (les milliards d'utilisateurs de Mediawiki, ou la centaine de millions en français, qu'ils aient des privilèges ou pas) », c'est totalement illogique : par définition, seuls les admins et les OS voient les liens qui leur sont destinés, donc évidemment que ces liens doivent leur être compréhensibles ; on s'en fout totalement des millions d'utilisateurs non francophones ou non admins/OS puisqu'ils ne voient pas ces liens !

Jules78120 (talk)17:58, 21 April 2021


Voir mw:Help:Structured_Discussions/Glossary/fr (ping Trizek).

La traduction choisie sur Portal:Fr/MediaWiki#Glossaire global pour « suppress » est « masquer », « cacher » et « masquer » permet de différencier entre « hide » et « suppress », c’était comme ça pendant six ans, avant de tout changer, merci d’en discuter avant.


Thibaut (talk)17:47, 21 April 2021

il n'empêche que ça contredit tout ce qui a été fait ailleurs, Flow voulant créer une exception pour lui (alors qu'il n'est quasiment pas utilisé, et même obsolescent à cause de vieux problèmes peut-être insolubles et en tout cas non réglés). Flow n'est qu'un complément sur certaines pages, il ne remplace pas les discussions et la présentation de MediaWiki (qui n'en a pas besoin). Mediawiki utiliser masquer/afficher pour les actions normales de son interface y compris les discussions.

L'ambiguïté que tu relèves a été levée à l'inverse de ce qui est fait partout ailleurs dans MediaWiki : les actions administratives y sont même correctement identifiées comme telles, avec une précision de rappel indispensable pour les rares utilisateurs qui y ont accès. Ce choix fait pour Flow ne peut que causer des erreurs par surprise.

Je ne m'oppose pas au terme "masquer" pour l'usage administratif, juste que cet usage administratif DOIT correctement identifié comme tel, et que l'action normale (sans privilège) reste "masquer" (et jamais nulle part "cacher"!) pour les utilisateurs (privilégiés ou pas, identifiés/connectés ou pas) et que "masquer" est supposé être réversible, temporaire, et n'avoir aucune incidence sur l'utilisation par les autres utilisateurs (et le plus souvent elle est temporaire et n'induit aucune modification dans la base de données ou seulement dans les données personnelles de l'utilisateur, pas toujours dans la base de données du wiki, parfois dans un cookie de la session de l'utilisateur ou dans le stockage local de son navigateur). Utiliser à la fois "masquer" et "cacher" côte à côte ne résout rien, n'aide personne, et n'évitera aucune erreur d'interprétation par un admin (qui serait gênante ou inattendue pour tous les autres), mais en plus échanger l'usage non privilégié de ce terme ne peut pas clarifier.

C'est pour ça que j'insiste pour que l'indication qu'il s'agit bien d'une action administrative soit présente, par une précision (le terme "masquer" tout seul est très malvenu pour ce cas et ne convient QUE pour l'action interactive de n'importe quel utilisateur sans aucune conséquence pour les autres). Qu'est-ce qui t'empêche de préciser explicitement cette action administrative ? En quoi ça te gêne réellement (toi ou les quelques admins qui y auront accès et ne doivent pas faire de confusion, ce qui n'est certainement pas le cas pour la paire "cacher/masquer" sans autre précision)?

Que dire alors du reste de l'interface de Mediawiki où le choix entre "masquer" et "cacher" (deux traductions possibles pour la même action) date depuis bien plus longtemps encore dans Mediawiki et reste plus que jamais utilisée dans l'UI de Mediawiki et disponible pour tout le monde sans changer quoi que ce soit à la navigation par les autres?)

Flow ajoute ici une contradiction (absente dans la version anglaise où le terme d'usage administratif est bel et bien précisé explicitement, les actions de l'UI et de l'administration utilisant le même verbe "hide" dans les deux cas, seule celle de l'UI n'ayant pas de précision? Là c'est non seulement une exception de Flow, mais un truc franco-français mal réfléchi, qui ne peut QUE tromper et gêner pas mal de monde perturber par ce choix incohérent dans l'UI francophone mal traduite et mal relue par quelques personnes comme toi qui n'y ont pas réfléchi avant.

Et surtout qu'est-ce qui t'empêche de rester poli ici? Je ne suis pas passé en force puisque c'était l'usage établi (très fortement et depuis bien plus longtemps que Flow qui reste un chantier inabouti, et déjà programmé comme obsolescent, Wikimedia ne souhaitant pas poursuivre sur cette voie en développant et testant d'autres solutions)?

La page de "glossaire" que tu cites en plus ne preovient que d'une modif rapide par Trizek, cnore assez récente (en 2017), qui n'a jamais été relue ni discutée. Mediawiki est bien plus ancien. Ceci dit la terminologie en anglais n'aide pas tellement mais utilise "hide" pour l'action par tout le monde ("masquer" partout dans MediaWiki), delete (traduit partout comme "supprimer" dans Mediawiki, ainsi que dans Flow dans l'action administrative des sysops), mais aussi malheureusement suppress pour l'action des '"oversighters" (superviseurs ou modérateurs, traduits très maladroitement comme "masqueurs"), ce qui ne pouvait pas être traduit aussi comme "supprimer" mais n'aurait jamais dû être "masquer" déjà en 2017 selon le choix malheureux fait sans discussion ni relecture par Trizek qui a préféré (à tord à mon avis) contredire complètement la traduction de base de Mediawiki.

Ce "glossaire" francophone n'est pas mieux, et franchement Flow mérite d'être moins ambigu (même en anglais avec son choix malheureux de "suppress" qui est tout aussi ambigu avec "delete", puisque les "oversighters" peuvent aussi être des "sysops" et que l'effet n'est pas non plus exactement le même et correspond encore moins à sa traduction française qui a choisi de lever la manifeste ambiguïté sémantique issue de l'anglais en une autre ambiguïté cette fois avec une autre troisème option non ambiguë en anglais, et la seule disponible pout tout le monde et conforme à l'usage universel de l'UI de Mediawiki).

Bref Trizek a imposé son choix non relu, toi tu le suis tel quel. Mais cela n'a jamais été discuté (et cela contredit la doc "/qqq" du message concerné : je ne serai pas le seul à voir que c'est une erreur (au moins une incohérence), mais elle n'est pas trop vieille pour ne pas changer ce choix initial malheureux, que seule une poignée d'admins ou de modérateurs francophones comprendront.... peut-être..., au prix d'une confusion supplémentaire pour tous les autres qui vont se demander pourquoi on leur impose dans Flow un autre terme "cacher" et non "masquer" comme partout ailleurs): ce glossaire francophone fait mine de croire que Flow existe tout seul sans MediaWiki (ce qui n'est pas du tout le cas). Ces incohérences ne facilitent pas l'utilisation de MediaWiki qui devrait pouvoir s'utiliser presque sans documentation pour tous (aux admins et modérateurs de se documenter mieux, c'est leur devoir par rapport aux autres en vertu des privilèges qu'ils ont, mais pas de "droit", juste parce que les utilisateurs leur ont fait confiance à un instant donné mais jamais de façon inéluctable).

Si on veut utiliser un terme clair pour les oversighters (dont l'action est celle de la "modération", terme largement consacré sur le web et même jusque dans la loi française afférante, et qu'ont devrait traduire comme "modérateurs" et non "masqueurs de n'importe quoi"') c'est bien "moderate" en anglais (et non "suppress") et "modérer" en français !!! Et surtout garder alors "hide"="masquer" dans l'UI de Mediawiki pour les actions strictement personnelles des visiteurs qui n'impactent personne d'autres qu'eux-mêmes. Et revoir le glossaire francophone (et proposer la clarification aussi en anglais, où "suppress", "oversight" et "oversighters" sont tout aussi peu cohérents, peu compréhensibles, et intraduisibles tels quels... et qui posent d'autres difficultés et ambiguités avec d'autres extensions et droits associés, dont la relecture avant publication, le passage en revue par des pairs ou une concertation, la validation, selon différents processus, la relecture de fidélité pour Wikisource ou pour l'orthographe, ou encore l'approbation pour les extensions de prévalidation de contenus sur les très gros wikis qui ont des systèmes de versionnement comme en allemand ou russe avec une très grosse équipe qui passe en revue des tonnes de modifs en attente, bien que ces gros wikis contreviennent aux principes même de fonctionnement de Wikimedia et d'ouverture à "tout le monde peut contribuer", mais où presque personne n'en voit le résultat avant longtemps, que ce soit utile ou pas; de tel système n'existe pourtant pas dans les wikis anglophones ou multilingues).

Verdy p (talk)18:10, 21 April 2021

L’action des oversighters est celle de masquer (suppress) des informations personnelles… Pas de modérer. Ils masquent des diffs ou des messages qui deviennent inaccessibles à tout le monde, y compris aux admins.

Thibaut (talk)18:53, 21 April 2021

+1 Thibaut.

Et sinon, je crois que vous confondez plusieurs choses :

Jules78120 (talk)19:18, 21 April 2021

Non je n'ai pas confondu les 3 concepts, dont j'ai justement bien parlé.

En mot -à-mot et littéralement "to oversight", se traduit "übershichten" en allemand, "superviser" en français, on a bien les deux parties "over"/"über"/"super" pour traduire "au dessus"; et "sight/Sicht" c'est le regard, la vision, la vue, autrement dit l'apparence. Autrement dit on créer d'une part une hiérarchie basée sur les résultats apparents. Cette hiérarchie est loin de ce que veut Wikimedia car la "supervision" résultante est une fonction organisationnelle basée sur un donneur d'ordres et des exécutants qui n'ont pas leur mot à dire mais devraient recevoir en échange une compensation (dans le monde du travail : un salaire). Wikimedia c'est plutôt le mode de l'artisanat, chacun entreprend, et tente d'attirer les autres pour vendre des services tout en choisissant ce qu'on veut faire et conservant sa liberté de temps, mais cependant sans contrat dans Wikimedia autre que le respect de la liberté des autres.

Le terme pour "OS" (encore une abréviation ajoutant de l'ambiguïté) est très mauvais dans tous les cas, et associer "oversight(ers)" à leur action "suppress" est très étrange. Pourtant c'est bien un rôle de modération, qui consiste à interdire tout accès à une information à la majorité, c'est une action répressive, suite à un abus, ou une mesure de sauvegarde destinée à protéger et éviter les abus (par exemple protéger la vie privée légitime qui aurait fuitée, que l'auteur de la fuite ou la personne visée en soit responsable ou pas par un comportement ou une action volontaire ou un effet inattendu et mal compris car souvent mal expliqué au préalable, ou juste pour essayer ou par mégarde ou un problème technique, ou une attaque sur un système de sécurité qui aurait du fonctionner).

Les 2 dernières actions sont des actions administratives, ce ne sont jsute pas nécessairement les mêmes personnes (en fait les admins/sysops ont parfaitement la possibilité d'être "oversighters" et utiliser la même fonction pour un peu n'importe quoi, avec quelques restrictions comme les journaux d'accès au serveur qui eux ne sont accessibles que par des personnes sous contrat avec une clause forte de confidentialité, mais juste pour émettre un avis et vérifier par exemple l'identité des personnes, sans juger de ce qu'elles font ni pouvoir elles-mêmes appliquer les sanctions. Elles sont là juste pour répondre à des demandes de vérifications, ce que la plupart des admins ne peuvent pas faire (à l'exception des propriétaires de l'installation, qui de leur côté se sont engagés à ne pas le faire et déléguer cela à une équipe ayant des droits nettement plus restreints).

Ici tu sembles croire que j'ai pris en compte uniquement 2 actions, alors que j'en ai bien décrit 3.

Dans la version anglais on a une confusion sémantique entre les 2 dernières des 3 (toutes deux de nature "administrative" car demandant un privilège, mais pas la 1re ; maintenant en français on a une confusion entre la 1re et la 3e, mais pas la 2e! (dont les traductions dans Flow ont eu l'effet de casser la cohérence générale de "hide" dans la 1re option depuis des décennies, une cohérence cassée unilatéralement par la traduction expédiée par Trazik il y a 3 ans sur MediaWiki-wiki)

Pourquoi faire aussi compliqué, déjà en anglais ? Et pourquoi compliquer encore plus les choses en français ? Pourtant la cohérence d'une traduction est la première aide qu'on apporte à tout le monde qui peut alors apprendre sans s'y perdre et s'y tromper.

oversight = modérer me parait tout à fait approprié, d'autant que cela ne supprime en fait rien, et qu'en plus, contrairement à une traduction littérale du mauvais terme anglais "oversight" en "superviser" cela n'introduit pas une notion de hiérarchie avec un donneur d'ordre et tous les autres de simples exécutants (non payés, donc devenant des esclaves... ce n'est pas l'esprit de Wikimedia : une vraie supervision dans uen entreprise ou un commerce est un échange contractuel avec un équilibre raisonnable ou compensé, et pas de façon théorique mais de façon mesurable et précise).

Et la traduction de "hide" en "masquer" ne vient pas de moi et ne date pas de novembre dernier. Elle date de plusieurs décennies dans Mediawiki (et il y a eu pas mal de discussions à ce sujet déjà, pour justement l'unifier, dans toutes les langues, dont l'anglais et le français au moins). Je n'ai rien inventé. De même que la cohérence est un concept fort déjà discuté et demandé depuis longtemps.

L'incohérence c'est juste dans Flow, pas dans Mediawiki qui n'en a pas besoin lui-même (pas plus dans Wikipedia français où ce composant ne fait pas partie des bases sauf quelques pages où certains utilisateurts ont voulu l'utiliser, masi il ya d'autres systèmes (dont LiquidThread qui lui aussi a ses défauts).

"Hide"="Masquer" est juste un outil de navigation, au même titre que suivre un "lien" pour accéder aux détails au lieu de les inclure au complet et les répéter un peu partout (ou les "transclure" avec un modèle). Cela n'a jamais été une modification du contenu ou une action administrative. C'est un système structurant, qui n'a jamais pour but de masquer les choses mais au contraire enrichir de façon appropriée, à la demande et en toute liberté. pour tout le monde. Et pourtant cela a bien été casse justement en français (pas en anglais ou les autres langues, même avec Flow installé et utilisé).

Verdy p (talk)20:42, 21 April 2021
  Qu'est-ce que cette formulation (que je trouve boiteuse) ajoute ? Le « pour elle » me semble parfaitement inutile.

Urhixidur (talk)22:52, 20 April 2021

Je ne vois rien de "boiteux", et c'est conforme à l'original. Ceci dit ce n'est pas bien important.

Verdy p (talk)07:01, 21 April 2021

C’est le « nous » royal qui est utilisé, d’où la majuscule. Ça se voit bien dans l’original anglais.

Urhixidur (talk)20:05, 13 April 2021

OK, je n'ai pas vu ça en relecture, j'ai d'abord pensé à une faute de frappe

Verdy p (talk)07:19, 14 April 2021
Edited by another user.
Last edit: 15:11, 5 April 2021

Sérieusement ? « septentrionnal » n'est pas un mot français ! diff

Urhixidur (talk)14:28, 5 April 2021

"septentrional" l'est bien ! désolé pour cette faute de frappe dans le simple texte d'une discussion

Verdy p (talk)15:07, 5 April 2021

J'ai corrigé dans Template:Languagename cette faute de frappe sur "méridionnal"->"méridional" aussi. Bizarre que le correcteur orthographique ne la signale pas !

Ce modèle je suis le seul à le maintenir depuis plusieurs années, en suivant les demandes du support et classant les centaines de langues. Bizarre que tu t'y intéresses seulement maintenant. J'ai cumulé des tonnes de recherches et vérifications, mais une faute est toujours possible.

Je l'ai créé parce que les données CLDR sont très incomplètes (et ont été partiellement importées mais pas maintenues ensuite non plus depuis longtemps; et il fonctionne aussi indépendamment des mises à jours de MediaWiki qui ne les a pas toutes au complet, ce site prenant en charge aussi d'autres projets, et aussi des variantes non prises en charge par la version actuelle de MediaWiki utilisée ici dans son greffon "#language:" et ses données internes. Mediawiki n'est réellement suivi que pour les projets de Wikimédia et suit certaines règles internes non conformes à BCP 47; et ça fait des années que ça dure et que Wikimedia viole les standards et tarde à mettre à jour ses bases de données alors que les anomalies sont connues et signalées depuis des années; pendant longtemps Wikimedia n'avait pas de comité des langues et créait ses codes n'importe comment pour répondre trop vite aux premières demandes)

De plus BCP 47 a subi une mise à jour importante avec la publication de la norme ISO 639-3 et la révision de l'ancien catalogue IANA: longtemps il fallait des codes "inventés" et la classification posait de plus en plsu de problèmes résolus avec la RFC 4646 et la norme ISO 639-3, qui a également revu la classification des anciens volets ISO 639-1 et ISO 639-2 et les faire recoller à BCP 47, lequel a fait le ménage tout en maintenant la compatibilité ascendantes pour les traductions avec les codes terminologiques, et la compatibilité pour les classifications bibliographiques améliorées avec ISO 639-5. Mais avec ces révisions Wikimédia n'avait pas tellement de moyen d'être conforme avec ces changements survenus plus tard. Cette conformité progresse (elle est maintenant exigée sur Wikimédia pour les nouvelles langues prises en charge d'abord sur Incubator, mais les codes des wikis de projets approuvés depuis longtemps ne sont pas encore mis à jour et ça continue de polluer les projets, comme dans Wikidata et sur Commons et dans des tas de modèles et modules et des liens divers entre projets, et dans les noms de domaine utilisés).

Verdy p (talk)15:10, 5 April 2021

Pour résoudre la question de la casse des points cardinaux, où sont les sources BCP 47 et ISO 639 ? Prenant un premier code comme ajp, ici on a « arabe levantin du sud » tandis que la Wikipédie ( a « arabe (lévantin du Sud) » (« lévantin » est fautif). Même les noms anglais diffèrent. Wikidata a « arabe levantin méridional ». Comment ça se fait que ce soit encore un tel fouillis incohérent ?

Urhixidur (talk)15:47, 5 April 2021

Ces noms n'étaient PAS dans Wikidata quand je les ai mis, j'en ai cherché pas mal, Wikipédia et Wikidata en ont inventé aussi. On peut les corriger mais je n'ai rien fait massivement, ils ont été créés patiemment, un par un, mais des changements sont possibles (et "l'ortôgraphe" de ces nons n'est pas stable non plus selon les sources). l'ISO 649 et l'IANA ne contiennent que des noms anglais (et pas en synchronisation non plus), certains noms français sont dans ISO 15924.

J'ai fait pas mal de recherches, et si tu avais suivi ce modèle comme je l'ai fait pendant des années (sans que personne vienne critiquer le tout en dernière minute alors qu'il est là depuis longtemps) et tu t'y étais intéressé avant, on aurait pu discuter les ajouts un par un. Il y a certainement des mises à jour à faire, les choses évoluent, mais tant que personne ne les signale ou les remarque, tout va bien. Ce modèle a aidé énormément de monde ici depuis longtemps (et il n'est pas le seul, j'ai passé du temps à la classification qui avait été négligée pendant des années avant que je parvienne à terminer la liste des centaines de langues déjà référencées). J'ai suivi les discussions sur Support et les ajouts au fur et à mesure.

Maintenant que c'est complet (pour les langues déjà présentes sur les pages traduites et les pages utilisateurs), le gros du travail est fait et il ne reste que des corrections et des ajouts de temps en temps (de plus en plus rarement), ce qui n'est pas lourd à gérer et sans commune mesure avec le patient travail de construction et classement qui a permis à des tas de langues nouvelles de lancer leurs traductions (et sur les centaines de langues ajoutées depuis des années, personne n'a critiqué ce que j'avais indiqué, quelques uns (rares) ont corrigé leur langue native et là encore je n'ai rien trouvé à redire.

J'ai juste essayé d'être complet en français et anglais (car ce sont les deux langues principales de travail et de publication de l'ISO) et d'ajouter quelques autres noms dans les langues officielles locales des pays où ces langues sont parlées. Il y a toujours dans tous les cas un "fallback" sur la langue anglaise (avec "#language:" quand il fonctionne). De plus les variantes avec un code d'écriture sont prises en charge (les donnes ISO 15924 sont au complet et là aussi je les maintiens en français et anglais (noms officiels) et quelques autres langues (traductions proposées avec un lien, elles aussi modifiables dans leur modèle propre), ce qui donne des traductions acceptables pour la plupart des utilisateurs et en pratique.

Il n'y a pas d'équivalent ailleurs (ou bien ce wiki ne permet pas d'utiliser d'autres systèmes). J'ai fait du mieux possible avec les outils disponibles.

Comme tu le vois, même Wikimedia n'est pas cohérent entre les éditions de Wikipédia, Wikidata... tout bonnement car c'est hors du champ des normes actuelles: le seul effort de normalisation est dans CLDR, mais il progresse TRES lentement et ne répond toujours pas aux besoins. Si tu vois des anomalies, c'est peut-être Wikipédia ou Wikidata qui ont tord et doivent être corrigés et synchronisés (mais là il faut être patient car il y a beaucoup plus d'utilisateurs et beaucoup plus de monde à mettre d'accord et pas mal d'erreurs, ou pas forcément les mêmes sources utilisées, certains considérant une source plus pertinente qu'une autre, ou une source pouvant de devenir beaucoup moins plus tard, ou pouvant aussi être corrigée...)

De même les désaccords existent dans les traductions sur CLDR (il y a des tas de propositions qui n'ont pas encore passé l'étape de "vetting" et des tas de noms en état "beta" à prendre avec précaution). CLDR d'ailleurs ne prétend même pas devenir un standard, juste un état de l'art connu à un moment donné (et qui peut changer, rien n'y est définitif).

Donc tout est à corriger, partout, et on ne peut qu'essayer de chercher ce qui convient le mieux à un instant donné, "dans l'état de l'art" actuel. Ce n'est pas un problème nouveau, cela fait des décennies et pour la grande majorité des langues, il n'y a pas unicité des noms et des orthographes, juste des usages dont les proportions varient au cours du temps.

Concernant les points cardinaux en français ils n'ont pas de majuscule (juste des capitales contextuelles en début de titre, ou quand ils font partie intégrante du nom d'une entité territoriale administrative, ce qui n'est pas le cas des points cardinaux situant les variétés linguistiques dans un groupe de langues: le "sud" est juste relatif, et ne désigne pas un lieux clairement identifié, il peut aussi être le "nord" d'autres choses et d'autres langues dans un groupe de langues plus large; il ne doit donc pas prendre la majuscule, c'est l'orthographe française normale, mais la confusion est fréquente, calquée à tord sur l'anglais).

Verdy p (talk)16:19, 5 April 2021

tord -> tort

Pour la règle orthotypographique des points cardinaux, voir qui se résume à :

Cette règle [direction > minuscule ; lieu > majuscule] s’applique aux points cardinaux simples (nord, ouest…) ou composés (nord-ouest…), à leurs synonymes (septentrion, noroît, suroît…), aux termes équivalents (occident, orient, couchant, levant, ponant, midi…) ou assimilables (centre…) : le cap Nord, le pôle Nord, le pôle Sud ; la gare de l’Est, la gare du Nord ; le Grand Nord, l’hémisphère nord, l’hémisphère sud.

Donc quand on parle d’une langue d’un point cardinal, ça prend la majuscule (par ex. « zazaki du Sud »).

Urhixidur (talk)12:26, 6 April 2021

Your changes to Convenient Discussions translations

Hi. I see you've made a lot of changes like this: Why do you think they are needed (the "c:" prefix seems to work on wikis quite well, unlike on Translatewiki), and if they are, I should add this to the source, first of all; otherwise anyone might revert the changes on the basis of absence in the source.

Jack who built the house (talk)09:55, 25 March 2021

That's because the interwiki prefix c: is not universal across wikis, except those wikis hosted by Wikimedia. The Mw: prefix however is recognized on all wikis recognizing MediaWiki extensions (like yours), so MediaWiki wiki will correctly forward the link to Wikimedia Commons.

Also your extension is not installed and supported in any Wikimedia wiki. All it has is a description page on the MediaWiki wiki, plus your personal user page, for contacting you rather than document it.

If your extension is installed on Wikia, the interwiki starting by c: will go to Wikia Commons, not Wikimedia Commons, so the link will not reach the intended user page or its translations. If you really want to make sure that these links will go to your user pages on Wikimedia Commons, don't use wikilinks, use links by URL starting by https:...

Also I did not change a lot, most of these edits were on resources that were already "FUZZY" since long. This also means that most people don't know your extension and did not review these translations at all since long. They have then no specific reason to revert something that works now, but was never working before.

I don't know which wiki really uses this extension, but you seem to assume that they have the "c:" interwiki prefix enabled, and only going to Wikimedia Commons... As far as I know this "short" prefix is not part of the default installation package of Mediawiki and most wikiw will only enable "mw:" if they have installed any Mediawiki extension, normally documented in Mediwiki wiki (and not on Wikimedia Commons, which is definitely not the place for that, even if you can do that in your user pages, but for one-to-one talks refering to your own usage of Wikimedia wikis, but not elsewhere if it's not linked to something that works in Wikimedia wikis).

That's why I suggest to move these doc pages on MediaWiki wiki, as subpages of description page for your extension and not liked to your usage pages in Commons, which is unrelated to this "Convenient Discussion" project as it concerns all other activities that you could have on WM Commons (but maybe WM Commons is your "home" wiki for Wikimedia SUL).

Verdy p (talk)11:13, 25 March 2021

Thanks for the explanation. The reason it's currently hosted at Commons is that it's a user script/gadget (not an extension) that is guaranteed to work only on Wikimedia wikis. (If there is demand for use on third-party wikis, efforts can be made to make sure it is environment-independent, but currently there is no such guarantee.) So, the "c:" prefix seems to actually be universal in the scope that is currently intended.

Jack who built the house (talk)15:19, 25 March 2021

Dans les Template data de MediaWiki le pagename est un nom de page quelconque ce qui correspond a un type de données c'est pourquoi j'ai supprimé 'la' Nom de page . Pourquoi l'avoir enlevé ?

--Christian 🇫🇷 FR (talk) 09:55, 25 March 2021 (UTC)

Christian 🇫🇷 FR (talk)09:55, 25 March 2021

The Inuka Team: We need your help.

⧼Hello⧽ Verdy p,

Thank you so much for all the work you do. It is great to have you doing so much work to ensure that knowledge is available in French. Please, we will need your help in volunteering to translate the pages below to the French language:

Translating these pages will help educate more people about the Inuka team and their projects. Please, don't feel pressured to finish all the translation; it is okay to translate some of the pages and direct me to someone else who can help translate the other pages.

Thanks for the help!

UOzurumba (talk)12:03, 15 March 2021



La syntaxe de {{PLURAL}} est différente du mot magique {{PLURAL:}} de MediaWiki, il faut tout copier en entier (comme ici : [1][2][3]) sinon ça fonctionne mal.


Thibaut (talk)16:09, 9 March 2021

Désolé, je le savais mais je n'ai pas vu l'absence des ":"; mais j'ai bêtement suivi ce qui était quelques lignes au dessus ou en dessous, où cette factorisation était déjà là. Franchement je trouve que les outils qui utilisent cette syntaxe sur ce wiki, devraient gérer ça dans leurs script d'import; c'est lourd ici, alors que la défactorisation est facile à faire automatiquement (et qu'en plus le script peut même redécouper la syntaxe {{PLURAL}} en autant de sous-chaines, une par cas à traiter (ce qui lui fera alors dupliquer certaines chaines pour les cas manquants (identiques par défaut à un autre cas). C'est lourd pour pas mal de langues asiatiques aussi

Ce devrait être à l'outil qui va importer les traductions venant de ce wiki, de les convertir dans son format. Comem cela se fait aussi pour la traduction des .po/.pot compatibles Gettext mais utilisés dans des environnements sans Getttext

Et là je ne parle même pas des "placeholders" aux formats exotiques et des différents langages de balisage (Mediawiki aussi dans son dialecte pas réellement conforme à HTML). Tout ça c'est lourd pour les traducteurs qui doivent chaque fois se demander dans quel langue c'est réellement écrit et ce qu'on peut traduire, ou adapter en code ou pas. Il y a beaucoup de projets ici qui ont ces spécificités documentés nullepart (rien dans le /qqq, même poas de métadonnées non plus permettant une validation spécifique par ce wiki, par exemple les plaholders C/C++ ou Java)

C'est d'autant plus pénible cette absence, que la syntaxe non factorisée ne permet qu'un seul nombre (implicite), et aucune autre variation (genre). Pourtant on a bien dans le même outil certaines chaines qui ont plusieurs occurences de {{PLURAL}} dans la même chaîne à traduire. La syntaxe Mediawiki est la plus souple (même s'il lui manque les cas CLDR standards marqués par des étiquettes (zero, one, two, few, many), et qu'elle ajoute en revanche un truc inutile avec les cas de nombres exacts). Ces usages déviants de {{PLURAL}} au lieu de devraient être indiqués explicitement dans la sous-page de doc "/qqq". Si tu en voies où c'est nécessaire, merci de le mentionner dans ces "/qqq". C'est lourd quand on valide en passant d'un module à l'autre, et parfois quand ils sont mélangés avec différentes syntaxes sans un même outil, comme c'est le cas de ces modifs récentes pour L'EdlV !

Verdy p (talk)16:34, 9 March 2021

Ça donne :
French-based creole languages of France in the Atlantic Ocean
Portal:Gcf : créole guadeloupéen-martiniquais, kréyòl gwadloupéyen
Portal:Gcr : créole guyanais, kriyòl gwiyannen
Portal:Ht : créole haïtien, Kreyòl ayisyen
Portal:Kmw : komo (République démocratique du Congo), Komo (Democratic Republic of the Congo)
Or, si la Guadeloupe et la Guyane font bien partie de la France, ce n’est pas le cas de Haïti ni du Congo. L’expression "French-based creole languages in the Atlantic Ocean" me semble plus juste dans ce cas. Qu’est-ce qui te pousse à ajouter "of France"?

Urhixidur (talk)14:23, 31 December 2020


Urhixidur (talk)13:19, 3 January 2021

J'avais répondu déjà pourquoi répéter la question?

Verdy p (talk)16:12, 3 January 2021

Où est la réponse ? J'ai dû la rater.

Urhixidur (talk)13:56, 4 January 2021

Seudo est venu à la même conclusion que moi le 6 janvier. En date d'aujourd'hui, qui ne dit rien consent.

Urhixidur (talk)15:20, 17 February 2021

Je ne consens pas. Car l'extension revient à étendre la liste à des pays non francophones du tout. Hors le cas de l'haïtien est bien une langue **en France** par une communauté haïtienne dans les Antilles françaises.

Peut-être que "of France" devrait être of French-speaking countries. Les créoles sont difficilement classables.

Note aussi que le créole guadeloupéen est aussi appelé créole martiniquais et c'est quasiment le même créole dans toutes les Antilles et pourrait être juste "créole antillais" ou "créole franco-antillais" à l'exception de l'haïtien qui est un peu à part et des créoles états-uniens (ancienne Louisiane ou Nouvelle-France, et Maine) devenus très minoritaires sauf encore dans les actuels Etats de Louisiane et du Mississipi.

Verdy p (talk)15:57, 17 February 2021

Puisque ce message n'est pas documenté, comment fais-tu pour savoir qu'il aura un suffixe ?

Urhixidur (talk)15:22, 17 February 2021

C'est un message "patchwork" dont la suite est dans la ressource suivante (juste le point d'interrogation en anglais), entre les deux il y a un mot variable. Ce message est mal fichu (par exemple en allemand, une partie des mots va dans la seconde partie du message avant le point d'interrogation, ou dans les langues où le point d'interrogation est différent.

Ce genre de source de traduction est à éviter mais on fait ce qu'on peut.

Cela devrait être rappelé aux auteurs de MantisBT (qui aussi devraient mieux régler leur robot d'import car il écrase TOUTES les langues à chaque fois qu'il tourne en utilisant les ressources qu'il connait déjà dans son projet, mais ou oubliant d'importer d'abord les messages plus récents de et de les tester pour les intégrer. J'ai pu voir le massacre fait (via FuzzyBot) sur CodevTT qui remet des ressources "françaises" bourrées de fautes d'orthographe et de contresens venant à l'origine de vieux traducteurs automatiques.

MantisBT est typique d'un projet mal géré.

Verdy p (talk)15:48, 17 February 2021

Nouvelle guerre d'édition


Pourquoi encore repartir sur une guerre d'édition plutôt que de participer à la discussion pour trouver la meilleure traduction possible ?

Dans l'absolu, c'est déjà une mauvaise idée mais en l'occurrence si c'est pour faire une faute de traduction comme Special:Diff/9894655 c'est encore pire.

VIGNERON (talk)14:03, 16 February 2021

Et je vois que tu viens de remettre la traduction fausse ? Pourquoi ?

VIGNERON (talk)14:24, 16 February 2021

Guerre d'édition ??? Il me semble que c'est toi qui justement "invente" un mot français. "timeout" est traduit un peu partout avec le mot "délai" parfaitement français et bien compris (contrairement à timoute). Dans ce contexte, c'est pour éviter une erreur d'exécution de la requête qui a un délai d'exécution maximum, s'il est dépassé, ça produit une erreur. Le contexte est pas vraiment technique car c'est ici un générateur de requête simples avec un assistant destiné à être utilisé par le plus grand nombre, pas un obscur outil pour quelques développeurs. Donc là tu déclenches toi -même une guerre contre la francophonie en inventant une utilisation qui n'existe pas en français et annulant un français tout à fait correcte et adapté. Et je ne vois rien qui indique une annulation, j'ai juste modifié une relecture parmi d'autres je n'ai pas fait de "revert" volontaire.

Verdy p (talk)14:25, 16 February 2021
  1. regarde la discussion où je t'ai notifié (contrairement à toi qui modifie sans prévenir les principaux concernés)
  2. regarde le diff fourni (qui est une erreur flagrante indiqué dans la discussion)
  3. pour timeout/délai c'est un autre problème (lui aussi indiqué dans le discussion)
VIGNERON (talk)14:30, 16 February 2021
Edited by author.
Last edit: 14:42, 16 February 2021

De toute façon tu invoques toujours des termes polémiques, à placer le mot "guerre" à tout bout de champ au lieu de lancer une discussion. Il n'y a aucune "guerre". Ce n'est pas la peine de hausser le ton chaque fois que quelqu'un met quelquechose de différent en utilisant la simple "relecture" alors que c'est une fonction de base demandée à tout le monde. Franchement acucser quelqu'un de malveillance alors qu'il utilise ce qui est visible dans les outils standards. Si ça ne plait pas, lance une discussion, et il vaut mieux te plaindre des outils qui ne montrent pas les historiques et les commentaires pendant la relecture. On ne se rend jamais compte que ce qu'on relit peut être une annulation de ce qu'a fait quelqu'un d'autre. Il n'y a aucun malveillance, mais aucune alerte de l'outil pour savoir qui contacter.

Je ne sais pas quel outil tu utilises pour voir ça, mais ce n'est sans doute pas l'outil stantard. Et maintenant tu voudrais encore me bloquer ? Tu n'abuses pas de ton autorité pour interdire en fait l'utilisation de la relecture à quiconque viendrait l('utiliser sans savoir que c'est toi et qu'il a pu écrire autre chose (pourtant correct, tant qu'aucun problème n'est signalé et documenté de façon *visible* pour tout le monde et pas seulement par toi) ?

Verdy p (talk)14:31, 16 February 2021

Tu inverses les rôles, alors qu'une discussion où tu as été invité est en cours pour trouver les meilleures traductions, tu agis seul sans prévenir personne et pour ré-introduire une erreur déjà indiquée (ce qui n'est pas une relecture, pas une bonne relecture en tout cas). Alors, oui j'ai parlé à tort de guerre d'édition et je m'en excuse ; j'imagine que tu penses sincèrement aider et que tu ne te rends pas compte des dégâts que tu cause.

Bref, soyons constructif : pourquoi ne pas participer à la discussion en cours pour trouver la meilleure traduction ? Pour rappel, elle est ici : Thread:User_talk:Gomoko/Query_builder.

VIGNERON (talk)14:40, 16 February 2021

Une discussion qui n'est PAS mentionnée dans ce cas. Rien de visible dans l'outil de relecture. Et je n'ai eu aucune notification avant non plus. Je n'agis pas "tout seul", ce qui est fait dans l'outil de relecture est public. Ce n'est pas le cas de la discussion sur TA page qui n'est pas référencée ailleurs. On ne règle rien sur des discussions privées. De plus on ne voit aucune notification pendant qu'on utilise l'outil, on voit des centaines de chaines à relire et rien tant qu'on ne change pas de page (il peut s'écouler un temps considérable).

Verdy p (talk)14:43, 16 February 2021

Par rapport aux ajouts sur ton message précédent :

  • « Si ça ne plait pas, lance une discussion » c'est très exactement ce que j'ai fait *avant* tes modifications
  • « plaindre des outils » ce n'est peut-être pas assez mis en avant mais il n'est pourtant pas si difficile d'accéder à l'historique d'une traduction

Note que je ne t'accuse absolument pas de malveillance, je pointe juste une erreur de traduction et je m'interroge sur ton comportement que je trouve non-constructif.

VIGNERON (talk)14:47, 16 February 2021

Mass changes without consensus

Hello, I've not looked at the details but it looks like you're again edit warring with multiple users, apparently over the same thing you were blocked for last year. Please achieve consensus for mass changes or glossary and standard translations on Portal talk:fr or other relevant talk page before starting mass changes and mass reverts. At a minimum, provide explanations for your changes.

You could start from answering questions like Thread:Phabricator talk:phabricator-core-530f7f5b804131ff/fr/Travail / tâche. You might also want to get some uninvolved French speaker to comment on Thread:Portal talk:Fr/Espaces fines or summarise its outcome (if the discussion has run its course). I thought that issue had been resolved but maybe I misunderstood.

As you know, there aren't many ways to force people to discuss. I don't want to use blocks, but I may have to.

Nemo (talk)09:53, 6 December 2020

No I'm not "edit warring", I just use the interface to fix lot of typos spread in the same module; those were not validated at all by anyone. The translate interface offers no way to comment these validations, and in fact there are *so many* errors, There is no consistant talk space. What was told to me (and discussed) was severe bugs discussed in Phabricator, starring by date formats in this module. As well I've not seen any one except you complaiuning here, and you did not talk about this and did not translate anything in this module. So your reaction is surprizing. And Phabricator is far from being completely translated : it is the largest project untranslated in French. There are so much to do and I've done a lot there, carefully. The Phabricator project of course needs further testing, but it's not evident to do given that thje /qqq documentation is giving false hints and points to nowhere (most references to source code are wrong, these are not in the correct place, the links are broken (this is another issue that is also discussed in Phabricator itself). So this is an ongoing effort, I do my best according to the state of the project, and consistantly (because it then helps fixing the rest *if* and *when* there will be decisions, which havce still not occured or were not signaled to me or any one else in a place I know or can find easily. You are overreacting here, I've not done anything bad.

Verdy p (talk)12:24, 6 December 2020

Phabricator is no doubt a mess, because its maintainers care very little about i18n and refused to adopt any sensible development process. However, this has nothing to do with your decision to make changes without explanation, which make cooperation with other translators impossible.

The next time I see such a way of editing I'll apply a block.

Nemo (talk)20:54, 6 December 2020

I do my best and such block would be absuive, given that there's no such coordination visible. and I've corrected many things (including many typos, including orthographic and false-sense, and just used the tool manually; these are absolutely "massive" as you state). You are visibly using automation tools yourself and revert things blindly. I've not done anything that is abusive, and if there really exists some dicussions they should be pointed at by those starting them (the /qqq doc pages can be used for that). There's nothing I can see that would signal any problem. I was instructed in Phabricator tio make these changes and I have made them the normal way, patiently in a real review process (this module was never reviewed since the early "fast" translation, so there were real errors (causing troubles signaled in Phabricator, but denied there as the pPhabricator project does not care about problems in translations). So All must be tracked oin this wiki. I insist: if you want to apply some enforcemen,t or point to a discussion, you need to reference them in "/qqq" pages: this is is how this wiki works, but visibly you don't care and just use private background channels I'm not aware (and no body else can know them).

Translating Phabricator is a real long process, it is very complex, it requires testing that cannot be done directly on this wiki, we just detect the issue after facts, once they are imported in Phabricator. But I've made my best to be consistant.

For now these talks have NOT run (so you cannot speak of any existing "consensus"), because all this is still in a testing phase and we still need to see the result in Phabricator itself, after the import. But all these still require not jsut a single translation (all of them were made massively but not reviewed at all, and it was needed to pass these validation step, even if they require later fixes, where this would cause problems detected later. t that timle we can create a more formal analysis and reportt of the available options, and then take decisions. But I did not create any mess as I was consistant: this means that if someting needs to be changed, it will be easier to apply the changes consistantly using some search tools.

You then don't follow the normal rules, and just want to overuse your privilege to apply a "user block" ion this wiki for very unfair reasons, against an honnest user doing his best and definitely not abusing any right. I'm not a pirate or spammer of this wiki that I help maintain for many aspects (including in support talks). I don't say my opinion is definitive, but I explain it, and others can also give theirs. If there are disagreements, this can be discussed and eventually decided. But there was NO visible decision until now about this translation module which is still in alpha stage (even in French were it is one of the few most advanced languages, whereas most other languages have no support at all or are lagging very far behind).

Phabricator is definitely not translatable as easily as Mediawiki which has progressed since longer and has grown at musch lower rate. Phabricator was imported in TWN as a very large bulk project, and severe lack of documentation (most "/qqq" pages are misleading, they most often point to sources that are no longer there, it's hard to track where units are used).

Verdy p (talk)00:37, 7 December 2020

Seriously, edit warring on such a visible message without even a discussion? That just earned you a block, because you might have stopped in the hours since but clearly it will take you some time to become collaborative with your fellow translators again.

Nemo (talk)18:44, 6 January 2021


Re : Tu as terminé la traduction avec un point, alors que l'original anglais l'omet. L'original serait fautif ?

Urhixidur (talk)13:39, 29 December 2020

Il n'est pas fautif mais l'anglais est un peu trop permissif sur la ponctuation. Ce qui compte c'est le rendu final dans la page, et aussi de respecter la langue. Une phrase complète qui n'est pas un titre et qui n'est pas une simple expression nomale, prend un point en français même si en anglais c'est souvent oublié (les deux solutions étant égales par ailleurs dans cette langue, mais un peu choquante en français. Ca fait partie de la traduction que d'adapter aussi la ponctuation à la langue. Il y a bien d'autres endroit où cela aurait pu être fait. On peut toujours demander la correction aussi en anglais, ça ne change pas le sens. Cela n'apporte pas grand chose en anglais et je ne vois pas ce qui interdit de ponctuer correctement en français qu'il y ait un point ou pas en anglais. Et surtout il y a un manque de cohérence pour certains messages anglais que de voir certains avec des points et d'autres pas, ça ne doit pas empêcher de faire les choses correctement en français sans attendre un éventuel changement en anglais (par des programmeurs qui souvent tendent à vouloir tout abréger et à mettre des capitales impropres un peu partout (des capitales qu'on ne garde pas non plus en français)

Verdy p (talk)19:03, 29 December 2020

Où as-tu pu pêcher le contexte ? Existe-t-il un moyen de faire afficher le message avec son contexte afin de déterminer si une ponctuation est manquante ou pas ?

Urhixidur (talk)14:15, 31 December 2020

Es-tu sûr ? ;-) Sûr est bien correct en français, c'est la traduction usuelle de "sure". "Certain" n'est pas strictement incorrect mais fait "bizarre". Voulez-vous vraiment supprimer le compte %{username} ? Est plus long mais évite le parenthésage du genre et explicite le rôle de %{username}.

Trial (talk)19:00, 29 December 2020


Re : Garder le « pluriel d'origine » n'ajoute rien à la traduction, à mon avis. La vérification du téléversement peut comprendre de multiples étapes ou branches parallèles, l'usager s'en fout, c'est une boîte noire. Je pense que dans ce cas-ci la règle d'or (Utiliser le singulier plutôt que le pluriel autant que possible) s'applique. Qu'en penses-tu ?

Urhixidur (talk)13:26, 29 December 2020

Mantis:S kb/fr


Au sujet de l'annulation de la récente correction effectuée par User:Thibaut120094...

En réalité, son changement était tout à fait correct - il s'agit bien de KO et non pas de KiO (CF print_max_filesize() function)

Ceci étant, l'utilisation de KO dans ce contexte n'a pas de sens, et dans la prochaine version de Mantis (2.25.0) les KiO seront effectivement utilisés (voir PR 1714).

-- Damien, développeur MantisBT15:08, 7 December 2020

Changements inutiles avec GENDER et PLURAL


Quel est l’intérêt :

  1. de changer {{GENDER:$1|vous}} en {{GENDER:$1|}}vous
  2. et de changer {{PLURAL:$1|Message|Messages}} en Message{{PLURAL:$1||s}}

mis à part faire perdre du temps aux relecteurs ? À la limite, quand tu es l’auteur de la traduction, tu fais comme il te chante, mais s’il te plait ne fais pas de modifications inutiles, c’est anticollaboratif !

Pols12 (talk)18:59, 12 December 2019

Faire perdre quel temps ? Ces messages n'avaient jamais été relus avant et était à relire déjà et depuis longtemps. I' y a Deillers de messages jamais relus avdc toutes sortes de fautes, et la revue en masse est à faire. Autant faire court, ce qui est invariable peut être sorti pour justement montrer ce qui l'est clé un simple u. Terme est totalement invariable i' n'a pas besoin du tout d'être en paramètre, et l'appel de modèle requis peut rester sans paramètre et sera aussi invariable sur le serveur avec moins de cache et de memoire inutile

Verdy p (talk)17:12, 15 December 2019

Il n’y aura pas « moins de cache ni de mémoire inutile » parce que dans un cas comme dans l’autre il n’y a QU’UNE SEULE et unique version du message finale, la raison invoquée n’est donc pas une bonne raison.

Par contre en multipliant les versions dans l’historique, cela accumule des versions intermédiaires et donc au contraire, tu augmentes le besoin en capacité de stockage du serveur.

Quant au temps perdu, j’ignore ce que font les autres traducteurs, mais moi je relis systématiquement les modifications aux messages que j’ai traduit. Donc si, tes modifications complètement inutiles me font perdre du temps, et c’est très désagréable !

AJOUT : et puis ici, comment peux-tu croire que tu fais économiser de la mémoire ?

Pols12 (talk)16:02, 17 December 2019

je parle de l'analyse du message lui-même pour former la chaîne finale en faisant des substitutions conditionnelles. Les chaînes de paramètres vides n'entrainent pas d'allocation, elles sont directement supprimées du flux et traitées atomiquement. Et ici ce qui est constant dans toutes les variantes reste constant hors de l'expansion du modèle.

Verdy p (talk)17:30, 17 December 2019

Le gain de mémoire entre une chaine vide et une constante est sans doute quasiment nul. En tout cas, il n’est pas significatif pour avoir un gain de performance.

Les messages en anglais n’utilisent pas cette bidouille, ça devrait suffire comme argument…

Pols12 (talk)17:59, 17 December 2019

L'idéal serait même de supprimer le marqueur totalement, mais il faut une référence même vide dans l'état actuel (l'interface de ne permet pas encore de marquer des éléments comme facultatifs, il insite pour qu'on mette ces marqueurs de genre liés à une variable présente dans la version anglaise (même inutiles ou pas positionnés sur le bon mot avec lequel il devraient s'accorder selon une logique anglophone qui n'a pas cette logique), et refuse sinon d'en ajouter là il il faudrait (même si c'est "documenté", mais absent de l'original anglais). L'original n'est pas forcément le bon indicateur de ce qui doit être fait dans la traduction, on doit s'écarter des suggestions fausses.

Verdy p (talk)18:53, 17 December 2019

« L'original n'est pas forcément le bon indicateur de ce qui doit être fait dans la traduction »

Quand il s’agit de langue, non, en effet. Mais quand il s’agit d’une question technique, si. Mais apparemment tu ne veux pas l’entendre.

Pols12 (talk)16:12, 19 December 2019

Où est la "question technique" ?

Verdy p (talk)20:00, 19 December 2019

Économiser de la mémoire cache, c’est ce que je considère comme une question technique.

Pols12 (talk)20:03, 19 December 2019

Thank you for your help on the support page


Abijeet Patro (talk)14:24, 12 August 2020

Espaces fines insécables entre les guillemets


Le Lexique des règles typographiques en usage à l'Imprimerie nationale ([1]) et l'OQLF recommandent tous les deux l'usage de l'espace insécable (U+00A0) entre les guillemets et non l'espace fine insécable (U+202F).

C'est aussi le caractère utilisé par MediaWiki dans le rendu d'une page quand des espaces normales (U+0020) sont utilisées entre guillemets ([2]).

Je pense qu'il vaut mieux se conformer aux sources de référence et à l'usage (cf. MediaWiki).


Thibaut120094 (talk)11:53, 14 September 2019

Ces règles sont vieilles et dataient d'avant l'encodage tardif de la fine en Unicode.

La fine a toujours été en usage dans l'imprimerie et bien distincte de l'espace insécable, elle est largemetn dicumentée dans l'imprimerie comme étant de taille entre 1/4 et 1/6 de cadratin (et non 1/2 cadratin comme l'espace normale ou l'espace insécable NBSP) : en typographie anglaise c'est plutôt 1/6, et en typographie française c'est par tradition 1/5.

C'est très bien documenté et largement discuté dans Unicode, et cela a été longtemps réclamé. Avant la fine insécable, on devait utiliser un style CSS et la fine sécable mais qu'on devait éviter en texte brut à cause justement de l'absence de style.

J'ai longtemps travaillé dans la presse et l'édition pour des logiciels de gestion de contenu, la fine est hautement recommandée, et même imposée aux opérateurs qui saisissent les petites annonces et les journalistes dans absolument TOUS les quotiens, annuaires et guides de France (régionaux ou nationaux) de plein de maisons comme Hachette, Larousse, tous les quotidiens régionaux de France (y compris parisiens), Pages Jaunes qui étaient TOUS nos clients.

Le traitement automatique du texte pour le prétirage en pré-presse va même remplacer et mettre les fines (chez certains éditeurs), qui sont utilisées partout autour des ponctuations et comme séparateur de groupes de chiffres (dont les numéros de téléphone et pas que les annuaires mais aussi comme les guide type Gault&Millau, et la presse magazine, et même la presse spécialisée professionelle qui a aussi des éditeurs dont les groupes sont situés à Paris ou dans les Hauts-de-Seine).

La règle est bien connue et pas qu'en France car c'était demandé aussi par nos clients presse en Belgique, Suisse, Canada, Luxembourg, Liban, et pas qu'en zone francophone car on la trouve aussi en Espagne et Italie. Même au Royaume-Uni.

Franchement la méconnaissance... NBSP (U+00A0) n'est plus recommandé QUE comme repli au cas ou NNBSP (U+202F) ne peut pas être utilisé pour des raisons techniques (ce qui n'est plus justifié depuis, le caractère étant bien supporté par les moteurs de rendu (dont tous les moteurs pour l'édition) même si les polices de caractères utilisés n'ont pas ce caractère, car il est synthétisé et n'a besoin d'aucun glyphe: s'il est absent d'une police le moteur utilise lui-même la moitié de la métrique de l'espace, donc 1/4 de quadratin et c'est dans les clous acceptables; s'il est présent dans une police, sa métrique (entre 1/4 et 1/6 de cadratin) est utilisée (mais c'est rarement le cas sauf cas particulier de polices aux métriques très spéciales comme les polices décoratives ou destinées au titrage).

Verdy p (talk)12:28, 14 September 2019

Les sources que j'ai cité plus haut datent bien d'après l'encodage de l'espace fine dans Unicode.

Avez-vous des sources pour soutenir vos propos ?

Dans toutes les sources que j'ai pu consulter, l'espace fine insécable est uniquement recommandée devant le point-virgule, le point d’exclamation et le point d’interrogation.

« le caractère étant bien supporté par les moteurs de rendu »

Non, le caractère est malheureusement invisible sur Safari sur iOS (ce qui constitue une grande partie du lectorat sur Wikipédia).

Thibaut120094 (talk)12:47, 14 September 2019

De même l'OQLF indique clairement :

Ce tableau tient compte des limites des logiciels courants de traitement de texte, qui ne comportent pas l’espace fine (espace insécable réduite), à la différence des logiciels d’éditique et des logiciels professionnels de mise en pages.

Le tableau de l'OQLF est maintenant obsolète puisque les logiciels courants de traitement de texte comme aussi les navigateurs web comprennent et prennent en charge la fine. On revient aux règles de l'éditique qui sont applicables partout (sauf dans de très vieux contextes comme les anciens terminaux à police de chasse fixe uniquement, mais même eux font maintenant la substitution des espaces précis pour les remplacer par NBSP ou SPACE, ou des répétitions d'un de ces deux caractères si nécessaire : il n'est plus nécessaire que NNBSP soit présent dans les polices, et c'est le cas aussi dans les polices asiatiques: le moteur de rendu fait la prise en charge le plus adaptée de toutes les espaces codifiées et standardisées dans Unicode/ISO/CEI 10646, et c'est effectif maintenant depuis plus d'une décennie sur le web, et depuis toujours dans l'éditique professionnelle avant même l'apparition du web).

On donc des fines parfaitement supportées, on doit les utiliser. Il est juste regrettable que la fine ait tardé autant à être encodée dans Unicode/IEC 10646. D'aillurs la fine a toujorus existé aussi dans l'éditique anglophone, mais elle était jugée non nécessaire car traditionellement elle était un peu plus fine (1/6 cadratin) que la fine francophone (1/4 cadratin) et les polices de caractères de base avaient iuntégré une "approche" dans les signes de ponctuation: la fine a alors été supprimée dans les années 1960 pour les machines à écrire (de là vient aussi la convention anglophone des deux espaces après le point entre deux phrases d'un paragraphe, car l'éditique recommandait une espace plus importante en anglais (dont les mots sont plus courts et où il y a plus d'espaces séparateurs de mots qu'en français où la mise en page était plus lisible en anglais avec ce double espacement, mais pas nécessaire en français, allemand, néerlandais, italien, espagnol, portugais, grec, hébreu, arabe: ce double espacement en pratique ne persiste plus qu'aux USA, mais vient de la dactylographie qui s'y est développée plus vite qu'ailleurs et a résisté bien plus longtemps, mais où aussi l'éditique progressionnelle avait bien plsu de liberté de mise en page : la règle dactylographique est bannie depuis toujous au New York Times, mais encore imposée dans le Financial Times, et la presse magazine aux USA a toujours fait ce qu'elle voulait; pour les annuaires avant la libéralisation, AT&T n'utilisait pas du tout cette règle, mais d'autres éditeur d'annuaires et guides ont fait d'autre choix; chaque éditeur définissant ses propres règles de style; pour les journaux officiels américains au niveau fédéral ou de chaque Etat ou juridiction, il n' y a jamais eu les mêmes règles, chacun faisant ce qui lui plaisait et changeant d'avis selon les législatures, notamment au plan fédéral ou suivant les ministères, mais ça fait longtemps que ces journaux officiels sont diffusés par voie électronique vers leurs abonnés juristes, en forme ASCII uniquement sans aucune mise en page; pour les journaux officiels des villes et municipalités, il n'y avait jamais de règle, la typographie dépendant de l'éditeur privé choisi localement).

Verdy p (talk)12:58, 14 September 2019

L'OQLF indique plus loin : « Si l’on dispose de l’espace fine, il est conseillé de l’utiliser devant le point-virgule, le point d’exclamation et le point d’interrogation. », exactement ce qui est indiqué sur

Thibaut120094 (talk)13:03, 14 September 2019

Pas que là. Je sais de quoi je parle ayant justement travaillé avec à peu près tous les professionnels de l'édition en France (aussi au Canada), ils demandaient tous la même chose ; y compris avec les guillemets. La référence que tu donnes de l'OQLF est antérieure à l'encodage de la fine en Unicode, mais l'éditique a la fine utilisée depuis longtemps, représentée en SGML, et même avant l'HTML et le web et que finalement elle soit ajoutée à l'Unicode (quand un autre usage a été ajouté aussi pour les langues asiatiques, mais le comité Unicode ne voulait pas en entendre parler avant, jugeant que c'était inutile pour l'éditique qui utilisait SGML ou les langages et feuille de style pour la mise en forme, pour marquer les caractères "insécables", et donc en utilisant la fine sécable déjà codée. L'Unicode s'appuyait en fait sur l'absence d'usage dans les textes bruts (sans mise en forme), qui ont malheureusement hérité des mauvaises pratiques de l'ASCII et des anciens jeux de caractères. Unicode était plus timide à l'époque et avait un certain conservatisme, même poru des prtaiques qui n'étaient nécessaires que par les limitations des anciens systèmes dactylographiques, très largement développés pour les langues européennes. L'Unicode a eu de nombreuses demandes pendant des années pour l'ajout de NNBSP, et encore aujourd'hui ce caractère est mal connu (et même Microsoft dans Windows le "cache" dans son outil "Charmap" où il n'est accessible dans aucune catégorie, et n'apparait que si on choisit une police qui le mappe directement (rare et en fait inutile), et choisissant d'afficher "tous les caractères" en mode Unicode, et il faut le chercher alors à sa position U+202F. L'outil "Charmap" a de nombreux bogues de classification jamais corrigés depuis longtemps malgré tous les signalements. Avec ça il n'a pas facilité la vie de ceux qui voulaient l'utiliser. Il aura fallu que ce soient les moteurs de rendu qui le prennent en charge (puisqu'il a été informellement décidé qu'il était vain d'attendre qu'il soit "mappé" dans les polices alors que le comportement attendu était pourtant bien documenté. Les pratiques de l'éditique professionnelle n'ont jamais changé. Et même l'imprimerie nationale (avec qui on travaillait) nous demandait explicitement de traiter les NNBSP pour la mise en page et même de l'afficher explicitement sous forme balisée dans les outils de saisie: on utilisant une balise "[FINE]" entre crochets et en gras et rouge, traitée comme un seul caractère à la saisie, et ce "caractère" était saisi avec la simple touche [F2] du clavier PC. Et on peut facilement s'en convaincre: il suffit de regarder les rendus PDF générés par les textes publiés par l'Inprimerie nationale, et dans le JORF: les guillemets ont bien une fine à l'intérieur, et non une espace insécable (c'est encore plus visible avec la justification du texte puisque la fine n'est PAS justifiée et conserve sa taille, mais l'espace insécable l'est et peut s'élargir comme l'espace normale!)

Verdy p (talk)18:07, 14 September 2019

Personnellement, je m’en moque que l’espace soit fine ou non.

Par contre je ne trouve pas normal que le changement soit fait de manière massive alors qu’il n’y a pas consensus.

Et ça me fatigue de devoir relire des tas de modifications juste pour une espace qui perd un quart de pixel de large. Faire le changement au passage, quand il y a un autre changement à faire, d’accord. Mais ne faire que ce changement là, c’est faire perdre du temps en relecture à tous les traducteurs de

Pols12 (talk)00:47, 10 October 2019

Typographie dans les traductions

Boujour Verdy p,
Dans mes traductions françaises, je suis les préceptes de Wikipédia:Conventions typographiques. Mes traductions du 26 courant ont été modifiées par vous en incluant des apostrophes courbes et en retirant mes espaces insécables. Je ne suis pas spécialiste sur translatewiki, mais les traductions faites sur les projets WM suivent ces règles. Auriez-vous des informations dont je n'ai pas connaissance à ce sujet ? Cordialement.

Eihel (talk)11:20, 28 November 2019

Bonjour Eihel,

Les recommandations sont sur Portal:Fr/MediaWiki : il faut en effet utiliser l’apostrophe courbe.

Concernant les espaces insécables, Verdy_p et Thibaut120094 mènent une guerre stupide depuis quelques temps. Je crois qu’il va falloir chercher un maximum de contributeurs pour prendre une décision, parce que ça devient vraiment pénible…

Pour le reste, suivre les conventions typographiques de Wikipédia est une bonne chose, même si ce n’est pas toujours évident car on traduit souvent des bribes de messages, pas des articles, donc il y a peu de phrases…

AJOUT : Ça y est, en fait, la discussion est lancée sur Portal_talk:Fr#Espaces_fines_57010.

Pols12 (talk)14:27, 1 December 2019
First page
First page
Previous page
Previous page
Last page
Last page