Portal talk:Fr

From translatewiki.net
Jump to navigation Jump to search

Contents

Thread titleRepliesLast modified
watcher400:39, 28 January 2020
Espaces fines insécables ou espaces insécables entre les guilemets ?300:24, 28 January 2020
« Maison, douce maison »700:14, 4 January 2020
Espaces fines4414:49, 1 January 2020
yes yes yes ... oui oui oui 112:14, 19 December 2019
Megabyte: Mo ou bien MiB Mio MiO ? 606:52, 17 December 2019
Rectifications de 1990517:41, 8 December 2019
Comment traduire 'hunk' ?217:29, 8 December 2019
Traductions désuètes depuis la source en anglais015:12, 8 December 2019
De la traduction des genres en français2811:25, 5 August 2017
About MediaWiki:Wm-license-book-editor/fr518:59, 12 May 2016
Point à la fin des phrases216:50, 12 May 2016
Glossaire de traduction016:13, 12 December 2015
MediaWiki:Multimediaviewer-optin-pref/fr210:05, 17 May 2014
Adding a new variant to the French translation418:07, 18 November 2013
Apostrophes212:16, 7 July 2013
MediaWiki:Mobile-frontend-editor-license112:14, 7 July 2013
About MediaWiki:Postedit-confirmation/fr005:09, 5 November 2012
About MediaWiki:Notification-reverted-email-body/fr005:09, 5 November 2012
About MediaWiki:Viewcourseaction-summary-token/frTraduction de "Enrollment token"012:52, 13 June 2012
First page
First page
Previous page
Previous page
Last page
Last page

Le terme observateur me paraissait pertinent pour traduire watcher, mais récemment Verdy_p a préféré utiliser « suiveur » ([2]). Le terme était déjà présent sur Xtools.

Personnellement, quand je lis « observateur », je pense à un détective avec une paire de jumelle.
Quand je lis « suiveur », je pense à quelqu’un sans personnalité, qui fait comme les autres.

Pols12 (talk)00:51, 4 January 2020

C'est lié au verbe "suivre" (watch), c'est celui qui fait un suivi, pas celui qui simplement "observe".

On peut suivre quelqu'un (sa page de discussion ou ses modifs) sans pour autant être d'accord avec lui. L'analogie avec les jumelles ici est correcte. C'est bien pour un travail de détective et d'analyse, pas une simple observation alimentant une base ou un corpus traité en masse. C'est pour l'analyse détaillée "à la loupe" des modifs et actions de chacun ou des modifs d'une page.

Ceci dit, si on veut mettre "observateur", le lien avec l'action "suivre cette page" ou les listes de "pages suivies" risque d'être moins évident (et je vois mal utiliser "observer" quand c'est pour suivre les modifs d'une page d'image et pas simplement la regarder dans l'état, traduit plutôt par "aperçu" ou "voir en grand écran" ou "télécharger" selon le cas...). "Observer" est beaucoup plus vague et pas lié au reste de l'interface.

Verdy p (talk)17:29, 7 January 2020

D'accord avec Verdy_p, car avant ça (si j'ai bien compris), on a la phrase « Nombre de contributeurs ayant la page dans leur liste de suivi ». Donc il s'agit de la Liste de suivi que vous apercevez dans le menu en haut de cette page (si vous travaillez en français). Avoir un suivi sur les modifs d'une page, donc un suiveur, c'est ainsi que je le conçois. Suivre une page pour n'être qu'observateur, ça ne colle plus.

Eihel (talk)00:31, 28 January 2020
 

Utiliser le verbe « observer » ne me choquerait pas (ce n’est pas aussi passif que « regarder »), mais il est vrai que « suivre » est mieux.

C’est le terme de « suiveur » qui me gêne car il n’a pas du tout ce sens. À la limite le mot « veilleur » serait sans doute efficace, mais tout comme « observateur », on perd le lien avec « suivre ».

Tant pis, je consens à « suiveur », on va créer un nouveau sens à ce mot… =)

Pols12 (talk)17:42, 7 January 2020

Nouveau sens, je ne pense pas. Mais c'est un terme d'usage rare dans l'UI en comparaison du verbe "suivre" et de son participe "suivi" utilisé un peu partout. Et l'association du nom avec le verbe devrait être évidente. "Suiveur" est bien dérivé du verbe, c'est plutôt son usage "moderne" qui a ajouté une signification, sans remettre en cause le lemme initial basé sur le sens du verbe (dans tous ses modes de conjugaison, surtout l'infinitif et le participe passé où l'usage est clair, bien établi, bien compris). Le verbe "suivre" de toute façon est déjà polysémique (le participe présent "suivant" a plutôt un autre sens et ne devrait plus être utilisé que pour traduire "next"="prochain" et lié au nom "suite" lui aussi polysémique et en anglais "following" ou "series", avec une extension d'étendue de la partie au tout). Ce n'est pas toujours simple d'utiliser une langue humaine et assurer une cohérence terminologique dans un contexte logiciel; même le terme "follow" en anglais est polysémique, comme aussi "follower(s)". Du moment qu'on ne crée pas de confusion ou qu'en en évite, une terminologie cohérente incluant les racines et dérivés est cependant préférable, on n'écrit pas un roman ici, les messages à traduire sont trop courts pour avoir un contexte suffisant apportant la clarté nécessaire donc on doit parfois accepter de ne pas utiliser ce qui semblerait un meilleur terme dans un contexte moins technique.

Verdy p (talk)21:54, 8 January 2020
 
 

Espaces fines insécables ou espaces insécables entre les guilemets ?

Discussion ici.

(désolé pour la faute de frappe dans le titre, impossible de modifier, ça mouline dans le vide…)

Thibaut120094 (talk)12:36, 14 September 2019

Des avis extérieurs seraient les bienvenus.

Thibaut120094 (talk)14:52, 3 October 2019

Comme par ailleurs, mettre des espaces de largeur normale tant que les espaces fines insécables posent problème. Après on sera toujours à temps de se poser des questions ;-).

Trial (talk)12:07, 19 December 2019
 

Mon choix : nbsp. Différence visuelle minime (même en zoomant), habitude.

Eihel (talk)00:18, 28 January 2020
 

« Maison, douce maison »

Bonjour,

Je ne suis pas sûr que traduire littéralement une expression idiomatique soit une bonne idée.

Des propositions ? (contexte)

Thibaut (talk)17:21, 16 December 2019

Ce genre d'humour dans les sources à traduire devrait être évité. Mais pas d'indication claire de l'intention, et ce n'est idiomatique qu'en anglais et pas dans une autre langue où on la lit forcément littéralement. Et si on mettait dans MediaWiki une expression "quand les poules auront des dents", tous les autres seraient bien embêtés à la traduire, ce qui pourrait sembler sympathique dans une langue peut vite devenir offensant dans une autre, qu'on la traduise littéralement ou pas, et sinon cela ne veut rien dire et autant ne rien mettre du tout si ça n'a pas d'utilité réelle. Cet idiomatisme est vraiment une verrue plus gênante qu'autre chose.

"Foyer, doux foyer", ou "On n'est jamais aussi bien que chez soi"... C'est proche mais pas forcément équivalent.

"Home Sweet Home" ne se trouve en France que comme des marques commerciales (agences immobilières, magasins de déco...) et la laisser en français ne peut faire qu'évoquer autre chose qui n'a rien à faire là.

Verdy p (talk)22:59, 16 December 2019

C'est pas terrible mais ça semble être à la mode en ce moment.

Si j'ai bien compris le contexte, c'est le message de bienvenue après avoir terminé l'installation de Phabricator (ou l'ajout du logo ?).

Je propose de traduire « Home Sweet Home » par « Bienvenue » ou « Bienvenue sur votre nouvelle installation », des avis ?

Thibaut (talk)07:07, 17 December 2019

Si tu veux restez plus proche : Bienvenue chez vous ou Bienvenue à bord.

Mais je ne suis pas pour, c'est du phrasé qui ne nous(*) colle pas trop.

Je préfère simplement Bienvenue.

(*) Français, francophones

Trial (talk)15:48, 18 December 2019

De toute façon ce message n'apporte aucune information pertinente, il se veut juste "sympathique", il n'y a pas de raison de coller à cet idiome anglophone, plus à la forme bienveillante. Mais j'en vois déjà qui diront que ce n'est pas conforme à la source et voudront du mot-à-mot...

Verdy p (talk)16:13, 18 December 2019
 

Je préfère également « Bienvenue », c’est simple, sobre…

Ne rien mettre me va aussi, tant qu’on retire cette traduction littérale…

Thibaut (talk)16:29, 18 December 2019

Oui mais la simple "Bienvenue" est déjà souhaitée aux nouveaux arrivants qui s'inscrivent sur Phabricator. Là c'est pour leur indiquer qu'ils sont déjà contribué et qu'on les remercie du bon travail commencé sur Phabricator, et qu'on les invite à continuer maintenant qu'ils sont familiarisés et peuvent se sentir à l'aise maintenant, "comme chez eux", car ils ont lu et apparemment compris le guide de base sans être assisté pour tout, donc peuvent aller un peu plus vite (même s'ils auront encore à apprendre et se familiariser ensuite aux changements et nouveautés). Le "Bienvenue" pourrait aussi bien être éliminé puisqu'il n'ajoute rien. J'aime bien "Bienvenue chez vous" qui apporte de la bonne humeur et reprend une partie du sens initial idiomatique sans trop le déformer.

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

J’ai mis un « Bienvenue chez vous » qui est consensuellement mieux que la traduction littérale.

Si les développeurs se sont fait plaisir pour la VO, il faut qu’on s’amuse aussi dans la traduction. Un simple « bienvenue » me parait trop sobre, mais au fond, peu importe… =)

Pols12 (talk)00:14, 4 January 2020
 
 
 
 
 

Espaces fines

Edited by author.
Last edit: 20:50, 18 November 2019

Bonjour,

À la demande de Nemo_bis, j'ouvre une discussion ici.

Comme je l'ai indiqué ici, les espaces fines insécables (U+202F) posent problème sur les appareils sous iOS et sur Safari sous macOS où l'espace est tout simplement invisible.

Il me semble donc que pour le moment, pour des raisons de compatibilité, il faudrait plutôt utiliser des espaces insécables normales (U+00A0) à la place.

Des avis ? (Évitez de faire des pavés et pensez à aérer votre texte).

EDIT : Pour rappel, Safari est le deuxième navigateur en termes de parts de marché ([1]).

Ping Lyokoï, Jules78120, VIGNERON, Gomoko, Wladek92, Urhixidur et Verdy p.

Thibaut (talk)08:21, 13 November 2019

Je ne connais pas la norme ou ce qu'il faudrait faire, mais si un des caractères ne passe pas, il ne faut pas l'utiliser.

Lepticed (talk)08:28, 13 November 2019
 

Je répète mon opinion d’hier, puisqu’elle n’a probablement été consultée que par Thibaut (T60529) : une partie non négligeable des francophones n’insérant en général pas d’espace à ces endroits, les deux options proposées (1. Tout le monde a une espace mot insécable ; 2. la majorité a une espace fine insécable, mais une partie a une absence d’espace) me semblent aussi bonnes (ou mauvaises) l’une que l’autre.

J’ajoute que, à supposer que verdy_p surinterprète la très légère différence d’espacement (cf. discussion précédente), les développeurs de Safari auraient manifestement fait un choix délibéré (on s’attend dans le cas contraire à un caractère de remplacement, pas à un non-affichage). En ce cas, choisir l’espace mot insécable revient à contredire un choix que j’espère cohérent dans l’écosystème en question (et que je ne connais pas assez pour juger). L’intérêt pour ces utilisateurs de choisir l’option 1. me semble alors à tout le moins discutable.

— Ltrlg (discuter)14:15, 13 November 2019
 

If the narrow non-breaking space is used on iOS/non-supporting device, what will I see if I copy and paste the translation to plain text? "Abc : def"? Or "Abc: def"? Is that a potential problem?

WhatamIdoing (talk)18:43, 18 November 2019

On iOS, you'll get the string of characters "Abc : def" displayed as "Abc: def" ([1]) and yes the lack of space is a problem in French.

Thibaut (talk)20:46, 18 November 2019

If I understand this correctly, then:

  • If we say "Abc <nbsp>: def", and I copy it, and paste it into another document, then I will get "Abc : def" (which is good).
  • If we say "Abc <nnbsp>: def", and I copy it, and paste it into another document, then I will get "Abc: def" (which is not good, right?).

If I understand this all correctly, then I prefer the one that copies/pastes better. (I don't know whether others will think that is important, but it would be a little helpful to me.)

WhatamIdoing (talk)02:32, 19 November 2019

copy-pastes are NOT removing spaces even if they are nbsp or nnbsp. If this ever happens on a nay device this is a clear violation of standards and a sever bug that may occur on some old versions using incorrect or very antique Unicode databases or making false assumptions.

I've tested on MacOS 13 and 14, both NBSP and NNBSP are supported and work as expected. I've not seen any one silently removed or replaced by SPACE, or not rendered as empty (except in monospaced consoles where NNBSP **may** be invisible but still unbreakable, or consoles using legacy non-Unicode 8-bit charsets like MacRoman, where NBSP may be replaced by SPACE and NNBSP may be dropped)

If you use legacy apps that generate texts not saved in UTF-8 but in legacy charsets (MacRoman, ISO8859-1,Windows1252, CP850, US-ASCII, TISCII, VISCII, TIS620, HKCS, GBK, SJIS,...), the NNBSP may then be dropped and this is not a defect, but NBSP will be replaced by SPACE where needed if the legacy charset maps no NBSP: this is a conversion, not a transcoding, it may be lossy in that case when the legacy charset is not supporting the whole UCS


(note: GB18030 supports the whole UCS, so even if GBK did not, this should no longer occur with GB18030 which is UCS-compliant and can be used now as a conforming UTF even if GB18030 is not defined in the Unicode standard itself but by the PR Chinese standard; GB18030 is not part of the Unicode standard because it also allows other extensions or distinct duplicate encodings that are not mapped to any UCS position, but there's a& GB18030 subset that is bijectively liked to the UCS and this bijection is now warrantied to be stable even in the PR Chinese standard; GB18030 was even amended to explicitly say that these extensioçns are now deprecated adn their support is NOT mandary in any GB18030-conforming application; this means that any Unicode-conforming application is now GB18030 conforming and the reverse is true as well for all newer GB18030 applications that chose to no longer honor the legacy extensions which were part of the unamended GB18030; this also means that the PR Chinese government no longer needs to maintain its own encoding standard, all is done in the UCS directly, along with the work made in the IRG working group for the ideographic script subset in the UCS and coordinated with relevant national standard bodies in PR China, Taiwan, Singapore, North and South Korea, Vietnam, Japan, Thailand, Burma, Mongolia, Russia and other countries having officially recognized Chinese-speaking communities, or with international organizations needing support for modern Chinese, Korean and Japanese, or for educational bodies like linguistic departments of universities).

Verdy p (talk)17:28, 27 November 2019

Did you test this on iOS (i.e., on an iPhone or iPad)?

WhatamIdoing (talk)21:45, 27 November 2019
 

Thanks Verdy for engaging in the discussion. Please refrain from changing spaces while the discussion is ongoing and then abide by the consensus.

Nemo (talk)21:35, 2 December 2019
 
 
 
 

Oui pour le U+00A0 évidemment. U+202F est théoriquement meilleure du point de vue typographique (et encore) mais pose bien trop de problème.

VIGNERON (talk)21:24, 27 November 2019
 
Edited by author.
Last edit: 00:23, 29 November 2019

Bonjour à tout le monde,

On m'a invité a donner mon avis, alors j'ajoute mon « grain de sel » ← avec des espaces insécables. Pour moi, la réponse est simplissime. Tout d'abord, à la vue des participants à cette discussion, nous parlons tous de Wikimedia ← sans accent. C'est important, car TW accueille beaucoup de projets et tous appliquent leurs propres règles. Donc si on veut faire une traduction de Phab, de MW, de WD, etc. en français, il faut appliquer les règles locales. En occurrence, les règles locales sont celles de wikipedia:fr:Wikipédia:Conventions typographiques et elles sont indépendantes de toutes règles extérieures, quand bien même elles s'en inspirent. Si une traduction est proposée dans une autre langue, ce sont les règles locales dans cette langue qui s'appliquent. Pour rappel: il s'agit d'un espace insécable qu'il faut utiliser, soit U+00A0 en Unicode (nbsp). Maintenant, si vous parlez de traduire un projet extérieur à WM comme https://mifos.org/, je n'ai auncun avis.

Petit addenda, il faut utiliser aussi l'accentapostrophe droite et les guillemets en chevrons (guillemets français). Je croise trop souvent ces erreurs. Vos préférences ou avis ci-dessus doivent aussi changer les règles sur frwiki. Sans cela, vous n'avez pas d'autre choix, il me semble. Dites-moi si je fais fausse route ?

Eihel (talk)15:37, 28 November 2019

Note: "l'accent droit" n'existe pas (en tout cas nulle part en français).

Et sinon l'apostrophe ASCII n'est requise sur Wikipédia QUE dans les titres d'articles (qui ont leurs propres limites techniques y compris en terme de présentation et de capitalisation, et qui d'ailleurs n'admettent même aucune espace insécable, ni aucun tiret de soulignement ASCII et d'autres caractères ASCII réservés), pas dans les textes qui sont libres et doivent utiliser les formes typographiques normales.

Merci de ne pas confondre donc

  • les contraintes sur les titres d'article (même si on peut en changer l'apparence de façon très limitée, uniquement concernant la capitalisation de la première lettre et l'enrichissement par une mise en forme CSS ou des attributs ou balises HTML "inline" avec "DISPLAYTITLE:", toute autre modification des caractères étant proscrite et rendant DISPLAYTITLE nul et totalement ignoré, même lors de son inclusion par un modèle : ceci est signalé d'ailleurs par une bannière d'alerte dans l'éditeur Wiki en mode prévisualisation) et
  • celles sur le reste du contenu qui n'a de contrainte que sur les balises HTML autorisées (uniquement une partie de celles de HTML4, aucune de celles ajoutées dans HTML5) et sur les attributs interdits (scriptables ou de liens externes avec href="..." également scriptable) ou encore les URLs autorisées (seuls certains préfixes de schémas sont autorisés pour les liens externes, "file:" et "javascript:" sont interdits et filtrés par exemple, de même que les schémas de commande d'applications externes: ces liens ne peuvent être qu'affichés (pour une utilisation par un "copier-coller" manuel vers la barre d'adresse ou un outil externe, mais jamais actifs et cliquables directement dans le navigateur).

Dans le contenu, tout texte Unicode valide dans un élément HTML de texte (hors des balises elle-même, ou dans la valeur textuelle des attributs de balises autorisées) sera accepté (cela n'exclut que certains caractères de contrôle, et les caractères de contrôle des sauts de lignes sont unifiés: CR, LF, CR+LF, LS, PS, les autres sont éliminés ou invalides comme NUL), y compris en cas de tentative de contournement via des références numériques de caractère. C'est issu du standard HTML4 et maintenu en HTML5. De plus ce contenu textuel doit pouvoir être normalisé en forme NFC, NFD sans aucune conséquence sur l'affichage, mais aucun autre filtrage n'aura lieu (donc pas de normalisation NFKC ou NFKD qui se fait avec perte d'information). Les seuls caractères Unicode interdits sont les "non-caractères" (y compris les "surrogates" non appairés, non valides dans tous les codages UTF), et la plupart des contrôles C0 et C1 (hormi ceux des sauts de ligne, qui sont automatiquement unifiés, ou ceux de tabulation, qui sont traités comme des espaces simples dans la plupart des éléments HTML et unifiés et compactés en une seule espace, sauf dans des balises comme "pre" contenant du texte non balisé mais pré-mis en forme et ne dont aucun code wiki ne sera analysé, ou comme la balise "source" dont le contenu est analysé par un parseur spécial pour sa remise en forme automatique).

De fait les codages non-Unicode contenant des séquences d'échappement ne sont pas autorisés du tout, même en essayant d'utiliser une référence numérique pour des contrôles C0 comme ESC, ou DLE, ce qui inclut les codages asiatiques ou codages pour terminaux/consoles VT100 et dérivés et toute séquence destinée à gérer un tabulateur ou la position dynamique d'un curseur d'entrée de texte ou encore la délimiation de zones de saisie sur un écran de formulaire, ou la gestion d'une ligne d'état). Cela est compatible avec Unicode, mais pas avec HTML4 donc pas non plus en wiki (et même si le wiki génère ensuite du HTML5 qu'il refuse cependant d'accepter en entrée).

Tout le reste c'est du contenu binaire qui ne peut être mis que dans un "fichier" avec un des types MIME autorisés par Wikipédia ou Commons et dont le contenu sera vérifié par des outils automatiques (qui peuvent aussi éliminer des parties sensibles ou des fragments exécutables ou scriptables interdits, ces modifs automatiques notamment dans les PDF ou images/photos/vidéos et clips sonores étant permises par les licences requises : si ces modifs surviennent elles annuleront les empreintes numériques, mais pas les métadonnées d'auteur ou de licence).

Dernière précision : ces règles de wikipedia.fr concernent le contenu de fr.Wikipedia, et n'ont rien à voir avec la localisation de MediaWiki lui-même qui est indépendante de tout wiki. Il y a plein d'autres wikis basés sur MediaWiki qui utilisent l'interface française: ici on traduit l'interface, pas les contenus.

L'interface est destinée à être affichée directement, mais pas modifiée sur le wiki lui-même (même si certaines de ces traductions sont stockées dans la base de données, c'est dans un espace restreint inaccessible à quiconque hors des administrateurs qui peuvent y toujours y mettre autre chose que ce qui vient de MediaWiki, et empêcher l'écrasement en bloquant ces pages pour que l'import n'y touche pas (généralement cela se fait pour ajouter ou modifier des contenus destinés à expliquer la politique locale à fr.Wikipedia ou à donner des liens d'aide spécifique).

Sinon il y a les extensions de MediaWiki dont bon nombre ne sont même pas présentes sur fr.Wikipédia mais pourtant traduites en français car elles sont utilisées sur d'autres wikis (pas tous d'ailleurs sur les wikis de Wikimedia, ou sur des wikis très spécialisés et techniques ou fonctionnant en groupe fermé avec des besoins très spécifiques au groupe fermé et des règles de confidentialité ou contractuelles très différentes, ces wikis ne sont pas liés par l'identification SUL, les comptes utilisateurs sont totalement séparés, les règles applicables au contenu et même aux licences sont également très différentes et il peut y avoir des contenus sous licence propriétaire dans de tels environnement; les règles lingusitiques adoptées sur le profile fr.wikipedia public ne s'appliquent pas du tout à ces wikis public ou privés, et avoir des exigences linguistiques bien supérieures à ce à quoi se limite fr.Wikipedia). Bref fr.Wikipedia ne régit rien ici et ici on n'a pas besoin de ces approximations de contenus actuellement soutenues par fr.wikipedia.

D'ailleurs concernant les apostrophes tu t'es bel et bien trompé en lisant les recommandation de contenu fr.wikipedia un peu trop vite en diagonale.

Et note aussi que ces préconisations ne s'appliquent pas non plus à Wikidata, ni à Commons, ni encore à fr.wiktionary ou fr.wikisource qui utilisent pourtant les traductions faites ici et qui exigent une typographie bien plus précise et soignée (qui à terme doit aussi orienter ce à quoi devrait aboutir aussi les contenus de Wikipedia (et ne me dit pas que le Wiktionnaire, Wikisource ou Wikidata sont des projets mineurs dont tout le monde se fout (sachant aussi que Wikidata a des utilisations de plus en plus nombreuses hors de Wikimedia, y compris dans des applis officielles et scientifiques, et qu'il sert aussi à orienter largement ce vers quoi tend Wikipedia sans être contraint non plus par les exigences de la Wikipédie anglophone; d'ailleurs Wikidata n'utilise pas les restrictions sur les titres de pages qui n'y sont que des identifiants numériques, le reste étant traduit dans des libellés et descriptions indépendants et entièrement multilingue, supportant toutes les écritures et nombre de variantes dialectales ou orrthographiques; de même Wikidata ne tient pas compte des limites des codes interlangues, en fait les sous-domaines, entre projet wikimedia, et Wikidata veut respecter le standard BCP47 à la lettre contrairement aux codes interwikis non conformes; de même OSM ne veut pas des codes interwikis de Wikimedia, sauf pour lier aux articles des wikis de Wikipedia et tout le reste devant être conforme à BCP47; le Wiktionnaire aussi ne veut pas des codes interwikis pour ses propres traductions locales à chaque édition qui supportent beaucoup plus de langues et écritures) !

Conclusion: fr.wikipedia ne régit pas les règles des traductions faites ici, même s'il oriente assez fortement les choix terminologiques (cependant dans une optique de la localisation de MediaWiki et assez peu concernant les contenus de Wikipedia dans les traductions françaises faites ici). Pour le reste c'est à fr.Wikipedia de gérer ses choix locaux sur son propre wiki et il doit se coordonner sinon avec les autres wikis et n'est pas en droit de décider tout seul avec ses propres décisions biaisées par une audience bien plus limitée. D'ailleurs nombre d'utilisateurs de Mediawiki ne veulent utiliser aucun contenu de fr.wikipedia et n'y contribuent pas du tout (ou très épisodiquement) alors qu'ils sont très actifs sur d'autres wikis (sur Wikimedia ou ailleurs).

Verdy p (talk)20:23, 28 November 2019

S’il te plait, Verdy_p, pour faciliter le débat, reste aussi concis que possible et évite les digressions, on y gagnera vraiment en clarté.

Question : désormais tu préfères ne plus mettre d’espace du tout ???

En tous cas, merci de ne plus faire de modifications d’espace tant que le débat n’aura pas été réglé. Ce n’est pas à coup de révocations que le débat va être réglé…

Pols12 (talk)15:22, 1 December 2019

Je n'ai pas voulu supprimer ces espaces. Si ça a eu lieu à un endroit c'est un problème d'interface car ils y étaient bien quand j'ai saisi ça (filtrage par l'interface de traduction?).

Verdy p (talk)01:44, 2 December 2019
 

Cinq personnes (en comptant l’autre discussion) se sont prononcées en faveur d’NBSP, il serait temps d’en prendre acte et de passer à autre chose.

Thibaut (talk)11:23, 2 December 2019

Au cas où, +1 aussi. Vigneron a bien résumé mon opinion.

Ash Crow (talk)15:19, 2 December 2019
 
 
 
 

Impossible de voir les réponses au delà du niveau d'indentation (bogue connu de LiquidThread). En tout cas, Apple lui-même ddéfinit bien NNBSP, il l'affiche aussi mais c'est un bogue dans sa police système UI qui n'affiche plus rien depuis MacOS8 avec cette police qui a été modifiée pour des versions de MacOS ultérieure (qui n'ont pas besoin de mapping), mais distribuée à tord sur des versions anciennes (qui demandaient encore un mapping explicite du caractère avec les anciens moteurs). Ca marche sur les autres polices car elles sont au courant du bogue et ont conservé un mapping de NNBSP. Et opn voit que tous les navigateurs pour Mac ne font pas la même chose et contournent ce bogue qui en est bien un sur certains Macs et iPhones). Mais Apple n'a pas changé ses recommandations. Son rendu avec sa police système propriétaire ne marche pas, mais sur le web rien n'oblige à utiliser cette police (Apple est tout aussi mauvais pour formater correctement les grands nombres dans son propre tableur en français ou dans les langues utilisant le format ISO standard, où ni la virgule ni le point ne sert de séparateur de groupe, mais un NNBSP est décrit comme neutre et ne souffre aucune des ambiguïtés entre séparateur décimal ou séparateur de groupe selon les langues et usages; le NNBSP est également standard dans les pays bilingues français/autre comme le Canada ou la Belgique ; la Suisse est originale en proposant l'apostrophe verticale comme séparateur de groupe, mais c'est peu utilisé). Le NNBSP n'est pas une "lubie" personnelle, elle est décrite dans de nombreux standards et soutenue aussi par Apple, même s'il a un bogue dans certains rendus (un bogue facilement contournable: la police système UI n'est de toute façon PAS conçue pour le contenu web et Apple a déjà convenu de régler ça cette année avec la sortie d'Unicode 13 au printemps et aussi ses propres remraques concernant le codage de la langue mongole où Apple est directement mentionné comme ne respectant pas un standard nécessaire). Et contrairement à une légende, l'introduction de NNBSP dans Unicode 4 était concomitante avec le premier encodage de l'écriture mongole mais n'était pas liée uniquement à son usage en mongol (un usage qui persiste encore mais qui va être bientôt abandonné): il se trouve seulement que pour le mongol il avait été décidé (à tord) d'unifier le séparateur de voyelle mongole avec la fine insécable; le séparateur mongol (MVS) a depuis été codé, mais il va être généralisé (NNBSP sera officiellement déprécié en faveur de MVS uniquement pour cette écriture, mais pas pour le reste: la fine reste une fine soutenue par l'ISO et les typographes pour diverses langues, y compris en anglais, et pas seulement le français et standardisée par CLDR et Unicode, présente dans ICU; et cela a été reconfirmé et renforcé partout dans CLDR là où elle manquait encore). Bref c'est un faux problème: ceux qui ont les moyens d'acheter du matériel Apple le font en connaissance de cause, et ceux qui pinaillent pour voir une espace peuvent le faire avec un réglage très simple du navigateur ou les préférences du wiki., ou avec toutes sortes d'outils de personnalisation pour leur smartphone (Apple n'impose pas du tout ses polices système pour tout et surtout pas le contenu dont il n'est pas à l'origine: applis tiersces et contenus web comme c'est le cas ici; et aucun typographe ni aucune publication n'utilise les polices système propriétaires d'Apple sans violer les droits d'auteur d'Apple).

Verdy p (talk)14:02, 8 December 2019

Comme dit plusieurs fois, il n’est pas possible de changer la police dans les préférences de Safari, ni sur les autres navigateurs sur iOS qui sont forcés d’utiliser le même moteur de rendu que Safari.

J’ai proposé un compromis qui a été accepté par plusieurs traducteurs, s’il y a quelqu’un qui pinaille c’est plutôt vous sinon cette discussion aurait déjà été close.

Thibaut (talk)14:25, 8 December 2019

Ils sont forcés d'utiliser le moteur de rendu, pas forcés d'utiliser les polices système (pas plus que les auteurs de sites webs comme ici). Ces polices systèmes n'ont jamasi été conçues pour produire du contenu, le web est nécessairement ouvert à d'autres appareils que ceux (bogués et chers) d'Apple. Et ça fait longtemps que les typographes utilisent des Mac mais jamais les polices Apple trop limitées: ils en ont de bien meilleures et ont des règles linguistiques et typographiques bien plus précises que ce que demande Apple pour l'UI priopriétaire de son OS uniquement, mais pas du tout pour les contenus.

Verdy p (talk)15:05, 8 December 2019

Il faut tenir compte non seulement de l'idéal, de ce que peut faire la machine mais ce que fait la machine par défaut car dans 99% des cas l'utilisateur sera dans ce cas.

Et donc la logique veut qu'on utilise l'espace insécable de largeur normale et non l'espace insécable fine. Car entre afficher une espace un peu trop grande et pas d'espace il n'y a pas photo.

Choix révisable dans quelques années si l'espace insécable fine est correctement affichée partout.

Trial (talk)17:28, 8 December 2019
 

Je viens de faire un test avec des polices autres que celles d'Apple et là non plus l'espace fine insécable ne s'affiche pas (alors qu'elle s'affiche sur d'autres programmes sur macOS).

On peut d'ailleurs remarquer des "tofu" avec la police libre DejaVu Sans Mono.

Thibaut (talk)13:22, 9 December 2019
 
 
 

Si j’ai bien suivi la discussion…

Est-ce que NNBSP pose un problème d’accessibilité ?[edit]

La discussion semble avoir montré que si NNBSP est parfois invisible, c’est un choix d’Apple et non un bogue. Donc on n’a pas à changer de caractère pour être sûr qu’il s’affiche comme on le souhaite.

(Sinon, c’est comme si on imposait l’écriture en noir sur blanc, même pour ceux qui utilisent un navigateur qui affiche les textes en blanc sur noir.)

Est-ce que NNBSP est idéalement souhaitable ?[edit]

J’en suis resté aux sources données par Thibaut120094 : pour !, ? et ; il faut une NNBSP, pour les « », il faut des NBSP.

Pols12 (talk)23:16, 8 December 2019
Edited by author.
Last edit: 19:22, 27 December 2019

Dans un monde idéal où tous les navigateurs gèrent correctement l'espace fine insécable, il faut une NNBSP pour : aussi.

Après quelques tests, Safari semble traiter l'espace fine insécable comme une espace insécable de largeur zéro (U+FEFF) comme il le faisait il y a quatre ans pour l'espace fine normale et ça a été corrigé, c'est un bug, pas un choix.

AJOUT : Avec d'autres polices, comme la police libre DejaVu Sans Mono, le navigateur affiche des "tofu" ou "caractères de remplacement ou de substitution", ce qui prouve bien que c'est un bug.

AJOUT 2 : Voir aussi bugs.webkit.org : [1][2][3] et BugZilla.

Thibaut (talk)13:40, 9 December 2019

Je n'ai pas la même lecture de ton ajout : ça veut dire que la police DejaVu n'a pas défini l'espace fin insécable, ni plus ni moins et la politique usuelle quand on essaye d'afficher un caractère absent de la police c'est d'afficher le caractère de remplacement. Donc pas un bogue, juste une police à ne pas utiliser si on veut afficher des espaces fines insécables. Ce que tu dis fait penser à ce que des polices définiraient l'espace fine comme un vide. Ce qui fait que beaucoup de polices sur Safari sont incapables de représenter les espaces fines. Et ces mêmes polices sur cette même machine affichent correctement des espaces fines en dehors de Safari ?

Trial (talk)18:56, 9 December 2019
 

Le caractère U+202F (NARROW NO-BREAK SPACE) est bien défini dans DejaVu Mono Sans.

Toutes ces polices fonctionnent correctement sur macOS en dehors de Safari.

La page de test est disponible ici.

Thibaut (talk)19:03, 9 December 2019
 

Je ne vois pas bien comment les programmeurs de Safari ont géré leur coup pour changer un caractère précis d’une police… Mais OK pour considérer ça comme un bogue jusqu’à qu’une source vienne confirmer que ce comportement est intentionnel (ou que le bogue soit corrigé chez 90 % des utilisateurs).

Donc, je crois qu’on est tous d’accord (sauf peut-être Verdy_p ?) pour ne plus utiliser NNBSP tant qu’il ne sera pas géré (ou assumé comme masqué intentionnellement) par Safari ?

Pols12 (talk)17:49, 10 December 2019

Que Verdy_p soit d'accord ou pas puisque la règle locale est d'utiliser &nbsp;, il faut utiliser &nbsp;.

Sinon il faut commencer par changer les règles locales puisque je n'ai vu personne s'opposer au message d'Eichel. Hormis Verdy_p je veux dire^^ mais même dans ce cas puisque la règle WP s'applique à la partie WP pour des raisons de cohérence il est bon que les choix soient compatibles.

Je n'ai pas connaissance de règles locales exigeant NNSP (encore une fois je ne dis pas si c'est bien dans le cas idéal - oui sans doute - ou pas, je réponds à la question posée : doit-on utiliser actuellement les espaces insécables fines ou pas et ma réponse actuellement est non).

Trial (talk)21:04, 10 December 2019

En effet, j’en avais oublié que des conventions existaient déjà sur Portal:Fr/MediaWiki. Donc comme il n’y a clairement pas une majorité en faveur du changement de ces règles, on reste à l’ancienne règle qui dit NBSP partout.

OK pour prendre les conventions typo de Wikipédia, mais uniquement pour tous les cas que nous n’avons pas tranché ici (en l’occurrence, l’apostrophe courbe fait consensus sur Translatewiki.net alors qu’elle n’est pas forcément recommandée sur Wikipédia).

Pols12 (talk)02:51, 11 December 2019
 
 
 
 
 

yes yes yes ... oui oui oui

During last rereading I was surprised to find multiple occurences of the same text ("Yes") to be translated in french. It was supposed to have only one proposed for translation since Yes=Oui (...always) Can somebody recall what we can do to signify that all the same occurences of a same text must only be translated once ? Thanks.

Examples of same text occurences: https://translatewiki.net/w/i.php?title=Wikimedia:Wikipedia-android-strings-close_all_tabs_confirm_yes/fr&action=history https://translatewiki.net/w/i.php?title=Wikimedia:Wikipedia-android-strings-clear_recent_searches_confirm_yes/fr&action=history https://translatewiki.net/w/i.php?title=Wikimedia:Wikipedia-android-strings-edit_abandon_confirm_yes/fr&action=history ...

Christian (talk)15:30, 9 August 2017

Megabyte: Mo ou bien MiB Mio MiO ?

Edited by author.
Last edit: 10:33, 8 August 2017

L'abbréviation de Megabyte traduite en Mo est souvent annulée en faveur de mébioctet (Mio). Devant la perplexité, je présente ci dessous la position de l'utilisateur 'Trial' pour la traduction. Etes vous d'accord ?

" Mo est l'abréviation d'un million (1 000 000) d'octets, soit un mégaoctet. Mio est l'abréviation de 2^20 (1 048 576) octets, c'est à dire d'un mébyoctet.

MiB (l'abréviation en Anglais) correspond à Mio en français. J'utilise o plutôt que B pour éviter la confusion entre bit et byte. De plus o est la représentation normalisée d'octet.

Wikitionary : mébioctet

À 4,89 % près nous sommes d'accord ;-).

N. B. : j'avais moi aussi transformé un MiB en Mo ;-) et après discussion je me suis rangé aux arguments invoqués, malgré le risque de confusion avec l'abréviation non normalisée de Mio pour million. Autant discuter sur ce fil de discussion si nécessaire afin qu'on soit en phase : Urhixidur: MiB,_Mio,_MiO

(*) en première approximation car les anglophones utilisent byte dans le sens de 8-bit byte. Eh oui un "byte" peut être un regroupement de bits qui ne soit pas au nombre de huit. Pourquoi n'utilisent-il pas octet qui existe aussi en anglais ? Là aussi une raison historique, une habitude je suppose. " Exemple :


Texte original anglais: "1 article, %1$.2f MB" Summary shown for a reading list that contains one article (singular); this string is formatted with a parameter containing the number of megabytes saved to disk for offline page reading. Historique: https://translatewiki.net/w/i.php?title=Wikimedia:Wikipedia-android-strings-format_reading_list_statistical_summary_singular/fr&action=history

Christian (talk)11:23, 7 August 2017

Précision : il ne s'agissait pas de l'abréviation MB de megabyte mais de l'abréviation MiB de mebibyte.

Trial (talk)17:43, 7 August 2017

Je suis assez d’accord avec cette proposition. "o" est bien l’abréviation d’octet, donc:

  • MB => Mo
  • MiB => Mio

(et idem pour les GB, GiB, etc.)

Gomoko (talk)06:32, 21 August 2017

La confusion potentielle entre préfixe décimal et binaire origine du côté anglais, où on n’est pas toujours certain si le préfixe est correct. Pour une mesure de mémoire, le préfixe binaire est presque certain, tandis que pour une taille de fichier, un débit de transmission, etc., le préfixe décimal est le plus probable. Il faut essayer à chaque fois d’obtenir l’unité réellement utilisée des développeurs, ce qui semble souvent plus difficile que d’arracher des dents.

Urhixidur (talk)17:52, 6 December 2017

Je ne sais pas, je n'ai jamais essayé de m'arracher les dents^^. Mais ça semble être de cet ordre-là. Avec les SDD il est de plus en plus courant que les capacités soient données en To mais que les capacités réelles soient en Tio, ce que laisse 7% de place pour le système de gestion du disque (comme par exemple pour déplacer des données qui ne bougent pas vers un secteur vieilli, ce qui permet une usure plus régulière du disque). Donc pour la mémoire de stockage, le préfixe a aussi tendance à devenir décimal. Le SI (Système International) vaincra^^.

Trial (talk)16:28, 8 December 2019

Pour les tailles de fichier, les unités binaires sont presque certaines aussi; les fichiers sont des éléments gérés par les OS, qui sont optimisés pour les système binaire. Les unités décimales en revanche restent pour les débits sur réseaux et bus, et pour les capacités de disques dur affichées par les constructeurs. Mais quand on les monte dans un OS, il rapporte la taille des partitions et la taille des systèmes de fichieirs formatés et l'espace libre dans le système binaire; de me^me la capacité mémoire RAM (auissi bien dans les OS que pour les contructeurs de barettes, mais pas les cartes mémoire flash et les SSD qui sont en décimal pour les constructeurs (parce qu'en bainrie cela ferait moins, une partie de la capacité étant réservée à la gestion par le firmware).

Verdy p (talk)00:24, 9 December 2019
 
 
 
 
 

Rectifications de 1990

Bonjour,

Je me suis fait corriger plusieurs fois les mots que j’avais écrit en orthographe rectifiée (boite, sureté…), voire en orthographe tolérée de 1976/1977.

Y a-t-il déjà eu un débat ?

D’un côté, c’est énervant de se faire « corriger » quelque chose de correct. D’un autre côté, c’est très perturbant pour un lecteur de voir deux orthographes différentes se côtoyer sur une même page.

Pols12 (talk)15:44, 1 December 2019

Je ne pense pas que ces mots soient en deux orthographes, cependant les accents circonflexes sur i et u (qui ne sont pas supprimables sur tous les mots!) sont toujours corrects dans les deux orthographes mais leur absence ne l'est pas dans l'ortho traditionnelle et choque encore beaucoup de gens (cette réforme a en plus été très peu soutenue et il y a encore plein de dicos qui la refusent). Autant les préserver dans une présentation soignée, puisque cela ne gène personne à la lecture. Je vois toujours beaucoup plus d'occurrence de "boîte" et "sûr(eté)(s)" que "boite"; et utiliser "sur" ou "du" à la place de "sûr" et "dû" est toujours incorrect, ce qui est une irrégularité nouvelle juste tolérée dans la réforme, mais vraiment pas recommandé quand il est en fait plus simple de toujours mettre l'accent quelque soit la façon dont on accorde, comme c'était le cas avant la "réforme" 1990 qui a eu bien des critiques; pour "boite" on peut cependant discuter car il n'y a pas d'ambiguïté (ou "d'ambigüité" admis aussi maintenant !) quelque soit l'accord ou les dérivés.

Verdy p (talk)02:27, 2 December 2019
 

Je viens de créer Portal:Fr/MediaWiki/Orthographes multiples pour lister les quelques mots que j’ai croisés et qui m’ont questionné.

Dans l’idéal, à chaque fois que quelqu’un change l’orthographe d’un mot pour uniformiser les traductions, il faudrait l’ajouter à cette liste.

Attention, on parle bien d’orthographe : les problèmes de synonymie ont plutôt leur place dans le glossaire.

Pols12 (talk)15:25, 4 December 2019

Quand je dis que je "ne pense pas que ces mots soient en deux orthographes", cela veut dire ici; la suppression de l'accent ciorconflexe sur u et sur i (admise depuis 1990) est source de problème car elle n'est pas uniforme. Par exemple "sûr" et "dû" ne peuvent PAS être remplacés par "sur" et "du" même si au féminin ou au pluriel on le peut; de fait cela provoque des hésitations inutiles. Autant le garder, donc aussi écrire "sûreté" et non "sureté". Mais la réforme de 1990 et assez mal passée, pour ceux qui ne l'admette pas c'est une faute, pour ceux qui l'admettent les deux orthographes sont possibles donc la conservation ne doit gêner personne. On garde donc l'ortho traditionnelle.

Verdy p (talk)18:40, 4 December 2019

Jusqu’à mon message, j’ai l’impression que les traducteurs ont toujours réussi à faire consensus, pas besoin d’imposer de bloc toutes les rectifications ou de les empêcher toutes.

Par exemple, l’orthographe soudée de « plateforme » fait consensus dans les traductions (sans doute par anglicisme, mais peu importe), je trouverais ça stupide de modifier toutes les occurrences au prétexte qu’« on garde l’ortho traditionnelle ».

Pols12 (talk)14:14, 5 December 2019

Ta question portait sur boite et sureté, pas sur plateforme.

Philippe t'a répondu sur boîte et sûreté (sans digresser).

Certes il existe une île (^^) de personnes souhaitant imposer la réforme de 1990. Dans la réforme il y a d'un côté les circonflexes dont la suppression choque beaucoup de monde (question d'habitude) et la tendance à la suppression des traits d'union dans les mots utilisés fréquemment ensemble : il ne viendrait à l'esprit de personne d'écrire tourne-vis, car c'est devenu tournevis. Plate-forme versus plateforme c'est juste la généralisation de 1990.

Inutile de créer d'hypothétiques divergences là où les gens sont d'accord.

Je propose de conserver les circonflexes et de virer les traits d'union (‐) quand l'usage y tend.

Tout comme pour utiliser évènement même si événement (graphie traditionnelle) est correct : évènement se prononce comme il s'écrit, contrairement à événement.

Trial (talk)17:41, 8 December 2019
 
 
 
 

Comment traduire 'hunk' ?

Je suis en train de relire les traductions et je tombe sur différentes formes: 'gros morceau' 'bloc' 'hunk' au gré de chacun. Peut-on normaliser la traduction de 'hunk' ? Avis ? Merci.

ChristianW (talk)17:05, 7 January 2019

Dans Phabricator, il s’agirait de gros morceau de code source. Je propose de prolonger la métaphore en français avec un mot synonyme de « morceau ». Voilà ceux qui me sont venus :

  • pièce
  • tronçon
  • pavé

Ce dernier a l’avantage de déjà désigner un gros morceau de texte dans la langue française (« écrire un pavé »)

Pols12 (talk)01:09, 10 October 2019

+1 pour pavé

Trial (talk)17:29, 8 December 2019
 
 

Traductions désuètes depuis la source en anglais

Bonjour !

Suis-je le seul à trouver cette expression ambigu : « Traductions désuètes depuis la source en anglais » ?

Comment la comprenez-vous à première lecture :

  • c’est la source qui est « en anglais »,
  • ou bien ce sont les traductions qui sont « en anglais » ?

Votre avis est le bienvenu sur MediaWiki_talk:Tux-sst-outdated/fr.

Merci !

Pols12 (talk)15:12, 8 December 2019

De la traduction des genres en français

Edited by author.
Last edit: 01:17, 16 November 2013

ProgVal a modifié récemment des messages du type « Contributions de l’utilisateur » pour qu’ils affichent « utilisateur/utilisatrice » si le genre n’a pas été renseigné. J’y vois deux inconvénients : le premier est je considère que il n’y a pas vraiment de nécessité d’afficher le fait que le genre est inconnu (c’est certes discutable), le second est que cela est vraiment très moche dans la boîte à outils de la colonne de gauche (voir par exemple w:fr:Utilisateur:Brion VIBBER). Qu’en pensent les éventuelles personnes qui suivent cette page ?

— Ltrl G19:05, 15 November 2013

Pour ma part, j'en pense qu'en français par défaut c'est le masculin qui l'emporte donc que la modification n'est pas opportune.

Linedwell (talk)19:09, 15 November 2013

Le « masculin l’emporte » est très discutable (cf. les travaux de sociologie du genre), et c’est pourquoi je préfère éviter d’utiliser cette « règle » autant que possible.

Néanmoins, je reconnais que cette forme n’est pas forcément la plus esthétique dans une toolbox, mais je l’ai préférée à un « utilisateur/trice » car plus compréhensible.

Je vous laisse changer la formulation si vous pensez que c’est mieux.

ProgVal (talk)19:22, 15 November 2013
 

Entièrement d'accord. En plus d'être incorrecte, cette formulation est particulièrement lourde et inesthétique. À réverter selon moi.

Ayack (talk)19:58, 15 November 2013

Dans ce cas, y aurait-il un moyen de « forker » une langue de façon à laisser le choix entre ces deux variantes du français aux personnes configurant un wiki ? (Ce que fait par exemple SPIP) Comme ça tout le monde serait satisfait

ProgVal (talk)20:43, 15 November 2013

Ce qu’il faudrait forker, c’est le français, pour ajouter un neutre.

Plus sérieusement, je ne pense pas qu’il y ait moyen de forker la traduction ici-même et je doute qu’une demande pour aller dans ce sens soit acceptée.

— Ltrl G01:26, 16 November 2013

Il y a déjà des propositions dans ce sens ; par exemple « utilisateurice », mais quand on essaye de s’en servir, c’est loin de faire consensus… donc j’essaye des trucs plus consensuels, tels « utilisateur/trice » ou « utilisateur/utilisatrice ».

Je ne comprends pas pourquoi ça serait impossible d’avoir deux variantes du français (français masculin, l’actuel ; et français neutre), alors qu’en allemand, il y a bien deux variantes différentes (une polie avec « Sie », et une plus familière avec « Du »).

ProgVal (talk)09:30, 16 November 2013
 
 
 
 

Tous ces changements sont à révoquer, ça alourdit inutilement l'interface, il n'est pas possible de traduire un site sans tenir compte de la mise en page et de l'ergonomie, voir message sur le BA de wp-fr. Ça serait bien que ce genre de gros changements soit discuté un peu avant, au moins signalé sur le bistro de Wikipédia fr, car maintenant il va falloir du temps pour que ce soit corrigé et déployé.

Akeron (talk)13:32, 18 November 2013

Je ne pensais pas que les modifications étaient appliquées immédiatement et sans relecture, désolé.

ProgVal (talk)17:52, 18 November 2013

Les modifications sont intégrées à la version de développement tous les jours (en tout cas il me semble en voir à chaque fois que je fais la mise à jour de ma copie) et MediaWiki est mis à jour toutes les une ou deux semaines (je ne sais plus) sur Wikipédia, sans plus de relecture que ce que peuvent faire les contributeurs de TWN.

C’est d’ailleurs indiqué à l’inscription : « Your translations are transferred to the standard product every few days or every few weeks depending on the product. Please notice that it may take longer before you see your translation in the actual product. It can be just a few days before they appear on Wikipedia, but a few months can pass between each new release of FreeCol. » (copié depuis le message de bienvenue sur votre page de discussion)

— Ltrl G19:23, 18 November 2013

J’avais interprété ça comme signifiant qu’il y avait une validation. Je m’étais trompé, désolé

ProgVal (talk)19:33, 18 November 2013

En consultant des pages comme w:fr:Spécial:Liste des Utilisateurs/autopatroller, j'aurais tendance à penser que l'indication "Créé(e) le" est liée au compte, et non à l'utilisateur ou l'utilisatrice. C'est pourquoi je proposerais de remettre l'ancienne version de MediaWiki:Usercreated/fr, bien qu'apparemment le nom de cette page suggère les choses différemment. Mais créer un utilisateur, est-ce que c'est plus clair que créer un compte ? J'aurais tendance à opter pour la deuxième solution, plus claire et plus juste, l'utilisateur pouvant déjà être présent et créer un nouveau compte...

Cordialement,

Automatik (talk)20:51, 18 November 2013
 
 
 
 

Je découvre ce thread (je viens rarement ici). Je dirais que la meilleure façon de faire actuellement est de demander aux développeurs de donner la possibilité de genrer certains messages en passant le nom de l’utilisateurice quand cela est vraiment applicable : comme dans MediaWiki:Contributions, mais pas quand le message parle de plusieurs utilisateurs non spécifiés ou d’un utilisateur dont il est impossible de savoir le genre (comme les contributeurs non-enregistrés/IPs). Pour cela, il faut ouvrir un ticket sur bugzilla en indiquant le nom du message à genrer.

~ Seb35 [^_^]10:55, 17 May 2014

Sauf que l’on parle ici de messages dans lesquels le genre est déjà supporté. Le problème venait de modifications de ce type (justement sur <contributions>), qui alourdissaient le message dans le cas où l’utilisateur n’a pas renseigné son genre.

— Ltrl G18:01, 21 May 2014

Si ce message a pour traduction "utilisateur" et "utilisatrice" suivant le genre si le genre est renseigné, on ne doit pas écrire "utilisateur" si le genre n'est pas renseigné. Car dans ce cas on ne saurait le genre de l'utilisateur que si cette personne a renseigné son genre par féminin. Utilisateur/-trice, Utilisateur ou utilisatrice, voir un utilisateur-e ;-) seraient préférables. Pour faire plus concis :

  • utilisateur
  • utilisatrice
  • usager

Comme usagère est peu usité, on peut considéré usager comme neutre.

Trial (talk)11:25, 5 August 2017
 
 
 

Il me semble que « Correcteur » est trop restreint. Sur Wikisource, nous utilisons « Éditeur scientifique » (celui qui établit le texte).

Marc (talk)20:05, 5 March 2012

En Anglais, stp.

Siebrand21:14, 5 March 2012

« Correcteur » is perhaps too specific. For instance, contributors of French Wikisource use « Éditeur scientifique », meaning a person who corrects, verifies, establishes a text.

Marc (talk)23:35, 5 March 2012

Thanks for the explanation. I'll move this one to Portal_talk:Fr. Feel free to continue in French.

Siebrand16:36, 6 March 2012
 
 

Si j'ai bien compris, editor peut désigner celui qui établit un texte, comme par exemple l'éditeur scientifique d'un texte ancien. Mais dans ce cas, le mot français « correcteur » a un sens bien plus restreint que le mot anglais. Les contributeurs de Wikisource utilise « éditeur scientifique ».

Marc (talk)14:43, 11 March 2012

Peut-être faut-il poser la question sur Commons, s'il y a un portail ou bistrot des francophones.

Je n'ai pas les connaissances pour répondre, mais les dictionnaires indiqueraient plutôt « rédacteur » comme traduction.

Dans la traduction de l'ISBD, editor est traduit une fois par « éditeur scientifique », deux fois, par « éditeur » ; « series editor » devient « éditeur de la collection ».

La difficulté de la traduction du terme est telle que w:editing n'a pas de lien interwiki vers la wikipédia française.

Pols12 (talk)18:59, 12 May 2016
 
 

Point à la fin des phrases

Salut !

Pour les messages composés d'une seule phrase (les notifications par exemple, les légendes d'image, etc.), on omet souvent, le point à la fin de la phrase (même si la norme l'interdit). Concernant la traduction, peut-on rajouter un point si l'anglais ne l'a pas mis, ou doit-on traduire tel quel, avec la faute typographique (par exemple) ?

Le cas échéant, une option d'un menu déroulant doit-elle prendre un point (par exemple) ?

Pols12 (talk)15:12, 12 May 2016

Je serais d'avis de dire oui pour le point en fin de phrase unique (mais pas dans le cadre de l'exemple donné car c'est inesthétique après une proposition introduite par deux-points).

En ce qui concerne les listes déroulantes, vu qu'il ne s'agit pas vraiment de phrases, le point surchargerait, àmha inutilement le menu.

Cordialement,

Linedwell [talk]15:20, 12 May 2016

OK, merci pour ta réponse.

Par contre, je ne trouve personnellement pas le point après deux-points inesthétique.

Pols12 (talk)16:50, 12 May 2016
 
 

Glossaire de traduction

Les seuls guides de traduction que j'ai trouvé jusqu'à présent étaient Portal_talk:Fr/Liste des mots usuels avec leur traduction (9 mots) et English-French Wikimedia Glossary (concernant plus Wikimedia que MediaWiki).

Pour permettre de maintenir la cohérence des traductions, j'ai commencé une version plus complète spécifiquement pour MediaWiki sur Portal:Fr/MediaWiki. N'hésitez pas à compléter.

Orlodrim (talk)16:13, 12 December 2015

Bonjour,

Je propose de remplacer « Activer l’expérimentation d’affichage des nouveaux médias » par « Activer la nouvelle visionneuse de médias ». La formulation actuelle n'est pas très explicite et erronnée (il ne s'agit pas des nouveaux médias mais d'une nouvelle visionneuse de médias). Plusieurs wikimédiens qui souhaitent désactiver le Media Viewer ont du mal à trouver la bonne case à décocher dans les préférences.

Ca permettra d'utiliser le même terme que sur la page d'aide w:fr:Aide:Visionneuse de médias.

Pyb (talk)13:52, 16 May 2014

je suis favorable à cette proposition.

Linedwell (talk)14:06, 16 May 2014

@Pyb: Fait. N’hésites pas à demander les droits de traducteur pour pouvoir faire les modifs directement.

~ Seb35 [^_^]10:05, 17 May 2014
 
 

Adding a new variant to the French translation

Hi,

Short version: Could you add a new variant of French, called “gender-neutral French” (“français neutre”, in French)?

Long version: I recently updated the French translation of MediaWiki, fixing the gender of expressions referring to users whose gender is unknown (or not accessible with {{GENDER}}), by using a neutral form instead of the masculine form. (This is equivalent to using the gender-neutral “they” instead of “he” for someone whose gender is unknown or non-binary.) However, some other French translators opposed that they consider “he” to be neutral, and thus are about to revert my changes.

So, I asked if it was possible to add a new variant of French (let's call it “gender-neutral French”, as opposed to the current one, “masculine French”) as SPIP developpers did, and they told me to ask here. So, here am I: Could you add a new variant of French, called “gender-neutral French” (« français neutre », in French)?

Best regards, Valentin

ProgVal (talk)20:48, 17 November 2013

MediaWiki localisation is gender neutral. The degree to which a language can or needs to be bent in order to be gender neutral varies, but I'm sure French offers sufficient "neutralisation" devices for you to reach the goal here. The best way is not always the most "shockingly gender neutral", sometimes you need a bit of creativity: needs some hard work and discussion among translators, there are no shortcuts.

Con simpatia cisalpina, Federico

Nemo (talk)00:38, 18 November 2013

I already tried… in translations I used lesser neutral translations to make them “lesser shocking” than the language I usually use, but they still are refused by the three other translators I discussed with.

ProgVal (talk)08:02, 18 November 2013

Best talk about this on a talk page like Portal_talk:Fr based on goals and examples, and only make change after reaching consensus now that you know this...

P.s. Thanks for the tweet. It made me discover this thread.

Siebrand10:49, 18 November 2013

As I said earlier, I already asked there, and have been told to ask here…

ProgVal (talk)18:07, 18 November 2013
 
 
 
 

Apostrophes

Bonjour,

Les apostrophes typographiques (’) dans l'interface de mediawiki posent des problèmes d'accessibilités car la recherche ne trouve rien lorsqu'on utilise l'apostrophe normalement effectuée avec le clavier ('). Il y a le même problème avec la majorité des navigateurs internet lors d'une recherche dans une page. A cause de l'apostrophe typographique il n'est pas possible de rédiger une documentation accessible sur les fonctions de mediawiki, par exemple une documentation sur l'option « Date d’expiration » de la page sur les protections :

  • Si je garde les apostrophes typographiques dans la documentation, alors elle n'est plus trouvable avec une recherche normale, car personne ne tape des apostrophes typographiques.
  • Si je remplace par des apostrophes courantes, ce n'est plus accessible à une recherche faite à partir d'un copier/coller de l'élément de l'interface, ce qui peut être pratique dans certains cas.

On pourrait penser qu'un texte qui ne diffère que d'une apostrophe serait quand même trouvé, mais aucun résultat n'est retourné, comme s'il n'y avait aucune page contenant ce texte.

Ces problème me gêne beaucoup dans mon travail, certaines normes d'accessibilités nous imposent de pouvoir trouver facilement certaines informations non évidentes via une recherche accessible depuis toutes les pages. Ce n'est actuellement pas possible avec le fonctionnement de la recherche et des apostrophes typographiques dans l'interface. En attendant que le problème des recherches soit corrigé il faudrait donc utiliser l'apostrophe courante « ' » dans l'interface de mediawiki, car c'est celle qui est tapée par défaut par les utilisateurs.

Isildur (talk)20:07, 23 December 2012

Tout à fait d'accord, il n'est pas normal de maintenir une apostrophe qui cause des problèmes d'accessibilités. C'est sans doute pour cela que les messages originaux en anglais n'utilisent pas l'apostrophe typographique alors que ça devrait être le cas s'ils suivaient les recommandations typographiques pour l'anglais. L'interface doit tenir compte des limites du logiciel, dans ce cas les capacités de recherche de MediaWiki et des programmes de lecture (navigateurs).

Sandji (talk)15:30, 27 December 2012

+1. Mais où la décision de l'apostrophe doit-elle se prendre ?

Hercule (talk)12:16, 7 July 2013
 
 

MediaWiki:Mobile-frontend-editor-license

In MediaWiki:Mobile-frontend-editor-license/fr the word "photo" is included, which I think needs changing to the French for text.

Lloffiwr (talk)11:51, 7 July 2013

I corrected it.

Hercule (talk)12:14, 7 July 2013
 

Sauvegarder vs Enregistrer? MediaWiki:Savedprefs/fr uses sauvegarder, but googling around, it seems that enregistrer is more appropriate in these contexts.

Hello7113:37, 3 November 2012

Not sure whether reverter or something else should be used. Wiktionary says "(Informatique) Revenir à, retourner vers.", or "(Jargon des wikis) Reverter.".

Hello7102:21, 3 November 2012

Je propose de traduire "Enrollment token" par "fiche d'inscription". Est-ce correct ? Merci

Cquoi (talk)11:23, 13 June 2012
First page
First page
Previous page
Previous page
Last page
Last page