Portal talk:Fr/LiquidThreads

Cette page contient des discussions archivées utilisant l’extension Liquid Threads. Vous pouvez toujours participer aux conversations existantes, mais vous devriez commencer de nouvelles conversations en utilisant les nouveaux outils de discussion sur la page de discussion principale.

Bonjour,

Une fois n'est pas coutume, après le Wiktionnaire, c'est maintenant au tour de TranslateWiki.

Ce qui fait la qualité d'une traduction c'est qu'elle doit pouvoir être comprise du premier coup et ne pas laisser le lecteur perplexe (voir aussi principe de moindre surprise).

Urhixidur est en train de faire deux remplacements :

• le verbe « tweeter » et le nom « tweet » par les québécismes « gazouiller » et « gazouillis » respectivement ([1][2]).
  • Traduction conseillée par l'OQLF et le gouvernement canadien, elle reste inconnue des dictionnaires édités en France (contrairement au mot « tweet ») et de la plupart des francophones européens. On peut bien sûr deviner par le sens ou en retraduisant vers l'anglais, mais alors dans ce cas ce n'est plus une traduction, c'est une devinette.
• le mot « badge » par le mot « insigne »
  • Ça reste compréhensible pour la majorité des francophones mais cette note de l'OQLF nous éclaire sur les raisons de ce changement : « [l]'emprunt à l'anglais badge est généralisé dans l'usage du français européen depuis les années 60. Au Québec, c'est le terme français macaron qui s'est imposé dans l'usage; l'emprunt badge n'y comble aucune lacune lexicale. »
    • Pas accepté au Québec mais largement accepté en Europe où le mot est dans le TLFi depuis les années 70 et dans le dictionnaire de l'Académie française depuis 1990.

Bref, qu'en pensez-vous ?

J'espère qu'il ne va pas mettre macaron maintenant, un terme bien plus connu pour désigner les petits gâteaux formés de deux meringues plates et généralement rondes réunies par un fourrage à la crème. Ces gâteaux (souvent chers) qui ont maintenant fait le tour du monde, mais macaron rarement connu ou utilisé pour désigner un badge (et qui d'ailleurs désigne une forme arrondie et un usage bien précis de badge apposé ou collé sur une surface, un peu comme justement le gâteau) et encore moins un élément d'un interface utilisateur (le terme badge est utilisé dans Windows et Android par exemple).

Si le terme badge ne plait pas aux Québécois et Ontariens, on peut le remplacer dans la traduction "/fr-ca". Le mot insigne est attesté en français, mais vieilli (souvent restreint maintenant à un usage militaire ou un honneur officiel, et pas du tout utilisé dans le monde du travail, par exemple pour le contrôle d'accès ou le pointage horaire où badge s'est imposé également dans le monde du spectacle et des médias). Le terme macaron existe cependant en France mais uniquement pour un usage strictement militaire ou officiel d'une institution qui le décerne, pas pour les autres insignes ou badges commerciaux (y compris les logotypes) ou culturels. En France on utilise encore vignette dans l'usage civil (mais elles commencent à disparaitre de nos pare-brise de véhicules depuis qu'on passe au numérique pour les assurances, il en reste pour le contrôle technique et les critères anti-pollution).

Je ne sais pas trop le terme consacré en Suisse pour le marquage cantonal des plaques d'immatriculation (une armoirie à priori). En France et en Belgique il est permis (mais pas obligatoire car l'immatriculation est une compétence nationale) d'apposer un logo officiel d'une région ou collectivité locale (les armoiries traditionnelles et autres signes culturels sont je pense interdits) à côté du drapeau européen contenant le code pays F pour la France. Dans les deux cas ce ne sont pas des badges, ni des insignes ou macarons.

Pour les plaques suisses, on parle d'un « écusson ».

Je vois qu’Urhixidur annule les rétablissements du mot « badge » et sans venir discuter ici.

Quel est ton avis concernant « gazouillis » ?

Gazouilis c'est assez loin, et d'ailleurs même le rapprochement avec l'oiseau est en train de disparaître, depuis qu'E. Musk change la politique, les couleurs (le bleu réservé aux abonnés payants), le logo, on n'est même plus bien loin du changement du mot-marque. En revanche aucune problème avec le terme générique "clavardage" bien trouvé qui remplace avantageusement l'anglicisme "chat" parfois pseudo-francisé en "tchat" et leurs dérivés verbaux (sur le modèle de l'argot "tchatche" qui n'a pas vraiment le même sens mais désigne plutôt le charisme?) et "courriel" bien fondé avec une racine correcte et un suffixe assez commun.

• gazouillis ne me dérange pas, c’est mignon et compréhensible même si on l’attribue plus aux balbutiements des enfants. Ceci dit, je pense que les termes génériques « message » ou « publication » fonctionnent dans la plupart des cas ; je ne suis pas sûr qu’un terme supplémentaire soit nécessaire.
• insigne est tout à fait compréhensible en France. Si le mot badge gêne au Québec, alors je n’ai aucune opposition pour qu’on lui préfère insigne.

Je viens de tomber sur ces deux fiches de l'OQLF : [1][2].

Il semblerait que l'OQLF ne trouve rien à redire pour le mot « badge » quand il est utilisé dans un contexte numérique.

C'est aussi le mot recommandé par la Commission d'enrichissement de la langue française.

Urhixidur est maintenant en train de remplacer « infolettre » par des mots moins précis comme « bulletin d'information » ou « circulaire ».

Aucun des deux n'est recommandé par l'OQLF ou la Commission d'enrichissement de la langue française pour traduire « newsletter ».

Un bulletin d'information peut être une émission de radio et une circulaire peut être un document imprimé.

« Infolettre » — qui est un québécisme à la base — à l'avantage d'être entré dans le Larousse et Le Robert, donc compréhensible par l'ensemble des francophones.

Urhixidur remplace également les mots « alignement » (align) et « aligné » (align ou aligned) par « justification » ou « ferrer » [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17]. Il a également modifié le glossaire.

Terme certainement plus correct pour les puristes mais qui est inconnu pour le grand public, je ne sais pas vous mais si j'ouvre Microsoft Word ou LibreOffice Writer, je vois bien « aligné à gauche » et « aligné à droite ».

Je notifie VIGNERON qui connaît bien la typographie et qui pourra nous éclairer…

Là aussi, si "alignement" ou "aligné" ne convient pas, on peut préférer "cadrage" ou "cadré". (l'alignemetn n'en est pas forcément un, sinon il se ferait toujours uniquement verticalement le long de la marge et pas côte à côte au plus près de la marge).

La "justification" en revanche ne concerne pas du tout le cadrage à droite ou à gauche, mais l'ajustement de la présentation du contenu (y compris les espacements inter-caractères, ou en arabe l'insertion de lignes de jonction) permettant d'avoir (autant que possible) un cadrage du texte des deux côtés à la fois.

Il y a d'autres québéquismes (ou canadianismes) encore du même utilisateur. Pourquoi ne demande-t-il pas l'activation de la locale "/fr-ca" s'il tient à ces traductions locales ? Notez que jusqu'à présent de telles variantes ont été demandées dans les passé mais pas soutenues. Mais la discussion est ancienne et pourrait être relancée, à condition que ce ne soit pas soutenu par un unique utilisateur.

Jusqu'à présent cependant les traductions françaises ont été ouvertes aux contributions internationales et des néologismes canadiens sont souvent bien acceptés pour remplacer des lacunes ou des anglicismes malheureux trop repris en français, plus souvent par méconnaissance ou incompréhension, ou par paresse quand cela vient d'utilisateurs un peu trop techniciens et biaisés par leur métier ou compétences dans un domaine où l'anglais est trop souvent la référence. Mais les emprunts aux usages canadiens sont bienvenus en général, à condition que cela n'ajoute pas davantage à la polysémie des termes calquée sur la polysémie anglaise, car cela peut au contraire amoindrir la précision en augmentant les ambiguïtés de sens réel. D'autres emprunts sont également possibles en fouillant davantage le lexique français qu'on croit à tord tombé en désuétude (les canadiens le font souvent très bien).

Le cas des néologismes notamment basés sur des mots-valises calqués sur ceux de l'anglais sont beaucoup plus problématiques : c'est pratique pour les canadiens qui sont beaucoup souvent bilingues et à l'aise avec l'anglais pour comprendre facilement les subtilités de la polysémie anglophone et tout de suite faire un lien, mais beaucoup moins ailleurs. D'autres emprunts régionaux sont possibles (bienvenus aux Belges, Suisses, Africains... qui ont souvent conservé dans la langue française des usages qu'on pensait vieillis et perdus en France face aux anglicismes; mais parfois même ce qu'on croit être des anglicismes sont des emprunts à un français plus ancien qu'il nous appartient de remettre aux goût du jour, quitte à en restaurer l'orthographe et l'adapter aux usages modernes qui simplifient certains aspects.

Consultez les dictionnaires, cherchez les étymologies, considérez les affixes communs si on veut être créatif et pas rendre la langue plus confuse : le français a le goût de la précision à un niveau local, non soumis aux aléas contextuel, là où l'anglais a le goût de la rapidité et des sous-entendus contextuels avec une polysémie elle aussi riche mais aussi un riche choix de termes alternatifs pour lever occasionnellement des ambiguïtés contextuelles). Trouver de bons termes n'est pas toujours évident, on peut en trouver un et s'apercevoir bien plus tard qu'il pose problème dans d'autres contextes, alors que dès le début on avait le choix possible d'autres termes mais qui ne nous sont pas venus à l'esprit immédiatement (mais c'est le cas aussi dans toutes les autres langues, et même dans un contexte purement unilingue où il ne s'agit même pas de traduire mais décrire assez fidèlement une situation avec des termes devant à priori être utilisables dans des contextes plus larges qu'une phrase isolée). Construire une terminologie commune est bien plus long que traduire un terme ou une phrase. Et ce travail long indue ensuite des relectures à faire et à rediscuter des anciens choix qu'on croyait pertinents, suffisants, clairement compréhensibles et distinguables.

Merci, pourrais-tu mettre à jour le glossaire en y ajoutant les subtilités entre chaque mot ?

Quel est ton avis concernant « bulletin d’information » au lieu d’« infolettre » ?

Pour ce qui est de bulletin vs. infolettre, je suis simplement allé du côté qui était déjà majoritairement représenté.

Personnellement, je préfère infolettre qui est plus court et tout à fait clair, même lors de la première rencontre du terme. Ça reste une préférence, bulletin d’information ne me scandalise pas.

Je n'ai pas de préférence a priori, même si bulletin d'information est plus long il est moins formel que infolettre, qui a un côté assez administratif (mais en fin de compte approprié au contexte de leur contenu souvent plus technique et très résumé pour le suivi d'un projet, que faits d'informations générales et de formations et présentations détaillées).

Je pense que si infolettre ne plait pas trop à Urhixidur c'est que c'est trop calqué sur l'anglais. Pourtant c'est le terme utilisé par l'ISO, mais l'ISO aurait pu aussi bien choisir l'expressions plus commune bulletin d'information (ou juste bulletin, car tous les bulletins contiennent des informations, suivent l'actualité et paraissent de façon assez régulière et souvent attendue à l'avance ou chaque fois qu'une condition l'impose par exemple dans une norme pour annoncer les nouvelles versions, les changements de service à venir, les errata et les annonces légales, ou l'organisation d'un événement récurrent).

En tout cas pas circulaire qui est un document réglementaire d'organisation qui s'impose au sein d'une hiérarchie administrative et qu'on est sensé devoir lire (et même attester de l'avoir non seulement reçue mais lue et comprise, au besoin en renvoyant des questions à l'auteur de la circulaire si ce n'est pas assez clair ou pas simple à appliquer et qu'il y a des difficultés imprévues), et qui décrit une conduite à tenir ou explique comment appliquer une décision ou une politique générale et souvent impose un retour d'information. La circulaire a des destinataires bien précis (elle peut être souvent confidentielle au sein d'un service), alors qu'une newsletter (bulletin ou infolettre ou n'est qu'informative et on n'est pas obligé d'y souscrire ou la lire, elle revêt un caractère plutôt promotionnel et s'adresse indirectement à tout le monde sans imposer une action immédiate (elle peut en revanche aider ses lecteurs à comprendre ce qui se passe et ensuite pouvoir décider quoi faire et comment agir au mieux s'il se sent concerné, et peut donc annoncer dans son contenu l'existence de circulaires à caractère réglementaire).

Bonjour,

Dans Portal:Fr/Wikipedia_Library, je vois bibliothèque et Bibliothèque, bref un beau mélange. Selon moi, cette bibliothèque s'intitule comme une entité de la WMF. Donc, pour la première ligne du tableau uniquement, The Wikipedia Library devrait se traduire par « La Bibliothèque Wikipédia » . Qu'en pensez-vous ?

Cordialement.

Je partage la même analyse.

Voir la discussion de 2020 :

• deux traductions possibles :
  • comme nom commun « la bibliothèque de Wikipédia » (cela clarifie que « Wikipédia » n’est pas une bibliothèque)
  • comme nom propre, avec la majuscule au déterminant également : « La Bibliothèque Wikipédia » (on pourrait d’ailleurs quand même écrire « La Bibliothèque de Wikipédia », même si le risque de confusion est moindre).
• il faut rester cohérent entre Translatewiki.net, Wikipédia et Méta-Wiki.

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.

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.

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.

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.

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 ».

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.

Note que la prononciation traditionellement du mot événement s'entend traditionnellement comme c'est écrit, les deux premières voyelles "é" prononcées fermées et non différenciées. Mais il y a un glissement phonétique actuel tendant à ouvrir les voyelles fermées surtout avant des "consonnes liquides" (écrites avec des digrammes en français) ou nasalisées (cas du "n" après le deuxième "é" de évévenement).

Ca influence petit à petit la graphie comme la prononciation qui perd la différence de pas mel de voyelles "é"/"è" (si elles sont dans la syllabe initiale elle tendent à se prononcer fermées "é", les autres tendent à se prononcer ouvertes comme "è", et on a perdu depuis longtemps en français la différence de tonalité et de longueur entre "è"/"ê", comme aussi entre "a"/"â", "i"/"î", "o"/"ô", "u"/"û" ainsi que la plupart de nos anciennes diphtongues longues).

Et ça s'entend avec des débats entre ceux qui différencient ou pas les voyelles des syllabes non initiales des mots (pour l'écrit, l'orthographe n'a pas encore changé mais elle est de plus en plus souvent fautive) :

• ""(je) serai" (où "ai" est normalement prononcé fermé comme un "é" au futur, usage qui se perd de plus en plus alors qu'il a encore été enseigné il y a peu et l'est encore dans certaines écoles par des profs qui veulent faire prendre conscience de la concordance des temps et de l'orthographe), contre
• "(je) serais" (au conditionnel, toujours prononcé ouvert comme un "è"),

ou celles des syllabes initiales (évolution dans l'autre sens) :

• "les preuves" (les articles "des" ou "les", ou les mot "fait(s)", "lait", "mais", "met(s)", "quai(s)", "naît", "sait", "tes", "tais", normalement prononcés ouverts comme avec "è" tendent à se fermer et se prononcer de plus en plus souvent comme "lé", "dé", "fé", "ké", "mé", "né", "sé", "té"), contre
• "l'épreuve" (toujours prononcé fermé).

Cela ne se produit pas partout dans tous les mots: "l'été" (le nom prononcé fermé deux fois), "(je) l'étais" (fermé puis ouvert), "j'ai été" (l'auxiliaire ouvert, le participe prononcé fermé deux fois), "les taies" (les deux mots ouverts): la différenciation est conservée si elle évite une "allitération", c'est-à-dire la répétition phonétique des sons voyelles entre syllabes successives.

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.

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.

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.

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?

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.

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.)

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).

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

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

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.

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 ?

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).

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é…

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?).

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.

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

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).

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.

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.

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.

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.

Si j’ai bien suivi la discussion…

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

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 ?

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

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.

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 ?

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.

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 ?

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).

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).

Bonne nouvelle : le bogue est enfin corrigé dans iOS 14 et Safari 14 sur macOS qui ont été publiés le 16 septembre.

J'ai annulé mes remplacements effectués après cette date.

Donc on autorise NNBSP ? Et est-ce qu’on permet le remplacement massif de NBSP par NNBSP ? (Si oui, mieux vaut demander à un robot de le faire et avec le drapeau robot afin de ne pas notifier tous les utilisateurs sinon ça va inonder des tas de boites de courriels…

Pourquoi pas mais en faisant attention à ne pas le faire bêtement : les signes appariés tels que les guillemets ont, côté "intérieur" des espaces insécables de largeur standard et non des espaces fines si j'ai bien suivi le fil. Et bien-sûr des espaces ordinaires à l'extérieur le cas échéant.

Peut-être résumer le fil sur un espace (et non une pour ceux qui ont suivi ;-)) de projets wiki ? Car si les différents projets sont en phase ça évite les erreurs parce qu'on participe à un projet autre.

Mon résumé en trois phrases :

1. Les systèmes actuels supportent les nnbsp; qui correspondent à la règle typographique française pour les signes typographiques doubles tels que ; : ! ?.
2. Êtes-vous d'accord pour respecter cette règle ?
3. Vous opposez-vous à ce qu'un robot fasse la modification proprement (en respectant les espaces insécables des caractères appariés tel que le guillemet) ?

Pour l'intérieur des guillemets la fine est également en usage recommandé par nombre d'éditeurs de presse (au même titre que comme séparateur de groupes de chiffres, ou à côté des autres signes de ponctuation. Pour les deux-points, il y a deux usages (fine ou demi-cadratin) selon les éditeurs (certains recommandent la fine d'autre le demi-cadratin mais cela dépend du choix typographique des polices utilisées (en général avec les polices à empattements on préfère le demi-cadratin, mais sur le web ou les mobiles et l'affichage à l'écran en général les textes sont en polices sans empattement et la fine s'impose alors).

Les éditeurs de presse ou de livre historiquement utilisaient beaucoup les polices à empattement, mais c'est de moins en moins utilisé, et étant donné les métriques des polices modernes sans empattement, d'origine anglophone où la chasse entre les œils (non il n'y a pas de faute d'orthographe pour ce sens ce n'est pas "yeux") est moins large qu'en typographie française classique (ce qui explique l'usage de l'espace cadratin après un point de fin de phrase chez les anglophones, donc du "double espace" sur les anciennes machines à écrire à chasse fixe, où le point était en fait bien plus "épais" qu'il ne l'est aujourd'hui, simplement pour éviter de percer le papier lors de la frappe ou laisser assez d'encre pour qu'il soit visible sur une papier de mauvaise qualité et une encre pas forcément très homogène !), pour mieux se rapprocher de la typographie française avec les polices proportionnelles anglophones à chasse "serrée", on peut préférer l'espace demi-cadratin au lieu de la fine avant les deux-points.

Il faut bien voir que tout ça est une adaptation, et que cela dépend des métriques de conception des polices utilisées. Hors sur nos wikis et le web en général on a très majoritairement et par défaut des métriques anglophones et un contenu en polices sans empattement (pour la lisibilité sur des écrans à faible résolution, souvent bien plus faible que les 300 dpi, au moins, de l'impression soignée des publications des éditeurs).

Et il ne faut pas oublier pour quoi et par qui ont été écrites les "règles" typographique : d'abord pour des éditeurs de documents imprimés qui maitrisent les polices utilisées et leurs métriques, alors que nous on travaille sur des documents en ligne dont on ne connait pas du tout les métriques et où on ne connait pas non plus la résolution de rendu. Il faut être donc prudent... sans aller non plus vers l'excès en croyant à un rendu de type "machine à écrire" quand plus personne ne les utilise (et même si on a un rendu avec une police à chasse fixe, que ce soit une fine ou une espace demi-cadratin ne fera aucune différence visible, la police étendant la largeur de toute façon). Masiç condmaner tout le monde à des espaces insécables plus larges que nécessaire est assez stupide pour les deux-points ou les guillemets.

Pour les guillemets, ce n’est pas ce que recommande le Lexique des règles typographiques en usage à l'Imprimerie nationale ou l’OQLF (voir aussi ici), mais je ne vais pas insister.

Encore une fois tu te bases sur des recommandations pour les imprimeurs avec leurs polices de caractères dédiées (et avec empattements et en métriques francophones)... Sur le web iou la lecture à l'écran c'est différent (résolution faible et polices sans empattement et avec métriques anglophones la quasi-totalité du temps).

Bonjour,

Scriptance [ talk · contribs ] a récemment modifié plusieurs messages de traductions et ces modifs ont été annulées.

Autant je ne suis pas contre un changement de nos règles de traductions pour favoriser des termes neutres, autant cela ne peut pas se faire sans un minimum de concertation au préalable pour éviter les contre-sens et les erreurs (qv. notamment MediaWiki:Contributions-title/fr et certains des messages - pas tous, ce qui en plus est incohérent - contenant les termes "nouvel arrivant").

Cela tourne au passage en force et à la guerre d'édition, ne serait-il pas possible d'en discuter intelligemment ?

@Thibaut120094, Jules*, Od1n, and Gomoko:

si vous pouvez indiquer/justifier les "contresens" et "erreurs" ça peut aider. lister/catégoriser les trads concernées. à part ça... c'est juste trouver des termes épicènes. sinon j'ai vu qu'on pouvait aussi demander au support de faire 2 versions (comme pour l'allemand, une version avec Sie et une avec Du).

Petites apartés:

• Sie et du (avec une minuscule, car vous ne devez pas confondre Sie et sie en allemand) sont un autre problème.

• Pour le genre, prenez connaissance de MediaWiki:Contributions-title/qqq

Tout de bon.

user est à traduire, donc VIGNERON répond parfaitement aux indications : This message supports the use of {{GENDER:Optional username|Text for male|Text for female|Optional text for unspecified/neutral}}''.

+1

Cependant, pour les personnes non-binaires, c'est vrai que « Contributions de X » est un bon compromis (en plus ça prend moins de place à l'écran).

On pourrait imaginer quelque chose comme Contributions {{GENDER:$1|de l’utilisateur|de l’utilisatrice|de}} $1.

Cela me semble un bon compromis (et si il y a consensus, potentiellement généralisable à de nombreux autres messages).

@Scriptance, Jules*, Od1n, and Gomoko: qu'en pensez-vous ?

idem. je ne savais pas que c'était faisable. Quels messages échapperaient à cette solution (et donc quelle serait-elle pour ceux-ci?)

Ou Contributions de {{GENDER:$1|l’utilisateur |l’utilisatrice |}}$1, non ?

@Thibaut120094, Jules*, Od1n, Gomoko, VIGNERON, and Eihel:

Sauf erreur on s'était mis d'accord pour traduire les pages concernées sur le modèle de: Contributions de {{GENDER:$1|l’utilisateur |l’utilisatrice |}}$1 j'ai confirmation et possibilité de réaliser ce changement?

Pour un cas comme celui là, oui, je suis d'accord.

Pour MediaWiki:Growthexperiments-homepage-enable/fr, « nouvel arrivant » est plus usité, donc « Afficher la page d’accueil {{GENDER:$1|du nouvel arrivant |de la nouvelle arrivante |du novice}} », si tout le monde est d'accord. En tout cas, les guerres d'éditions ne sont pas le bon moyen (aussi sur MediaWiki:Contributions-title/fr, etc). Cordialement

@Thibaut120094, Jules*, Od1n, Gomoko, and VIGNERON: Eihel a répondu (merci). Avez-vous des choses à ajouter? Sans ça je procède aux changements convenus le dimanche 19. Cordialement.

Je suis fort occupé et je n'ai pas vraiment suivi la discussion, toutes mes excuses.

Ceci dit, je viens de voir passer quelques notifications qui me semble globalement bonnes. Par exemple, Special:Diff/10446547 est correct (même si arrivée récente et noviciat ce n'est pas exactement le même sens mais, par extension, j'admets le compromis). Par contre, pour Special:Diff/10446543, à part allonger le code du message, quel intérêt ? (y aurait-il une subtilité qui m'échappe, l'habitude est plutôt de factoriser le code qui peut l’être).

Oui,  MediaWiki:Passwordreset-username/fr gagnerait à utiliser le mot magique GENDER (mais même remarque que ci-dessus sur la factorisation du code).

Merci de ta réponse :) Concernant https://translatewiki.net/w/i.php?diff=10446543 c'est vrai que ça n'a pas vraiment d'intérêt, j'avais hésité, et c'est pour formuler exactement sur le même modèle que le compromis que j'ai modifié (par sécurité), on peut revenir à l'ancienne version ou la garder pour "harmoniser" les codes. Factoriser= raccourcir, au plus concis? ok je prendrai en compte pour https://translatewiki.net/wiki/MediaWiki:Passwordreset-username/fr

@VIGNERON: Par contre @Gomoko:, qui n'a pas répondu aux précédents pings sur cette discussion, s'est autorisé à reverter sans discussion les modifications faisant suite à ce que, sauf erreur, on peut appeler le consensus établit ici. Je fais quoi?

Bref: https://translatewiki.net/wiki/Thread:User_talk:Gomoko/Neutralisation_des_traductions#Neutralisation_des_traductions_60091

Bonjour @VIGNERON, Scriptance, Jules*, and Thibaut120094:,

Le mot magique GENDER semble fonctionner correctement, mais la tvar $1 semble ne pas être genrée dans MediaWiki:Contributions-title/fr. Aussi ai-je modifié MediaWiki:Contributions-title/qqq en conséquence.

Je vous conseillerais de la prudence, si j'ose me permettre, à la vue des discussions sur Discord et sur le bistro de WP du 10 courant. Lors d'une traduction, le mieux est d'« Afficher dans l’éditeur wiki » pour visualiser le résultat, puis d'enlever ce qui ne convient pas, quitte à s'éloigner d'une traduction totalement fidèle.

Bonne année.

@Eihel: Merci pour tes recherches :) . tvar€1 qui ne fonctionne pas c'est uniquement pour contributions-title/fr ou d'autres pages sont concernées? D'après ce que j'ai compris du bistro, al faut ajouter Scriptance à la place de €1 (mon signe "dollar" est utilisé pour faire des "u"), ou pas du tout? @VIGNERON, Jules*, and Thibaut120094: votre avis sur les contributions de @Gomoko: qui n'a pas souhaité intervenir ici mais dont les modifications ne suivent pas le consensus établi ici, avec pour argument (qui me semble entendable), que le paramètre gender n'étant pas employé dans la vo, il ne devrait pas l'être dans la vf (mais bon la prégnance du genre grammaticale est pas du tout la même dans ces 2 langues, et ce n'est pas le code qui est à traduire).

En attendant vos réponses, je remplace "du" par "de" (dans "tâches de novice"), solution qui intègre ses remarques sans nuire à la neutralité de genre convenue ici.

Bonne année

Scriptance, tu remarqueras que tu n’as pas reçu de notification alors que je te mentionne : elles ne fonctionnent pas automatiquement avec LiquidThread, puisqu’il n’y a pas de signature (il faut signer manuellement ou notifier depuis le résumé des modifications).

Il est en effet impossible d’utiliser une variable qui n’existe pas. Ajouter « $1 » si la variable n’est pas définie ne mènera à rien. Par contre, on peut demander aux développeurs d’ajouter une telle variable si elle est nécessaire.

Non, il ne faut surtout pas utiliser {{REVISIONUSER}} dans la traduction, c’était uniquement à des fins de test.

Pour contributions-title, je ne vois pas quel est le souci : je viens de tester avec le portugais brésilien, et le genrage fonctionne très bien. Pour information, les traductions de MediaWiki sont visibles instantanément sur Translatewiki.net, ce qui permet de tester sans attendre une semaine… Je repasse donc à la version de Jules* du 8 janvier.

Dans des nombreux messages sur FreeCol il y a {{tag:country|%nation%}}, bien que dans le message base il n'y a marqué que %nation%. Est-ce que c'est normale ?

Je ne vois pas du tout ton problème : la source de traduction (en anglais) mentionne bel et bien %nation% comme étant encapsulé dans un {{tag:country| }}, et parfois aussi on trouve d'autres "tags" de formatage (dans une syntaxe propre à FreeCol, et pas directement dans la syntaxe des modèles ou mots-clés magiques de Mediawiki), comme par exemple pour la capitalisation ou la dérivation des formes au pluriel.

(il peut être parfois nécessaire d'ajouter ou retirer ces tags spéciaux pour certaines traduction, comme par exemple mettre en capitale l'initiale d'un terme venant d'une variable avec {{ucfirst: }}, quand la traduction demande que ce terme soit placé en début de ligne, ou changer le nombre (singulier/pluriel) ou le cas grammatical (certaines langues) et produire les accords de genre/nombre/cas entre les termes traduits).

FreeCol définit ses tags qui sont à conserver au sein des messages : ce qui est variable et ce qui peut changer dans la traduction est correctement délimité. C'est documenté dans la page de description du projet FreeCol ici sur ce wiki: Translating:FreeCol.

Essayes-tu de comparer à ce qu'affiche au final FreeCol lui-même : il a son propre "moteur" de rendu de ces tags et utilise ses propres règles, et évidemment tu ne voies plus ces tags et juste le texte final formatté avec les variables substituées et les tags évalués par FreeCol (de sorte qu'il ne produit pas seulement du texte non plus mais peut ajouter une mise en forme des styles.

: la source de traduction (en anglais) mentionne bel et bien %nation% comme étant encapsulé dans un {{tag:country| }}, pas toujours, regarde FreeCol:Model.player.stance.alliance.others/en.

À quoi sert le {{ucfirst:}} et pourquoi n’est-il pas dans le message original ? User:Urhixidur a ajouté ces balises en 2015 sans donner de justification.

@Thibaut120094: Le ucfirst sert pour mettre la première lettre en majuscule (c'est un mot magique). Par contre {{tag:country| }} je ne l'ai jamais rencontré.

Je sais mais quel est l’intérêt de le mettre s’il n’est pas dans le message original ?

Justement ce n'est pas %country% (noms de pays, qui sont passés en anglais avant d'être traduit par le "tag:country") mais directement les noms de joueurs (comme %attacker%) qui sont passés et transcrits tels quels sans modification (il est possible que le code encadre les noms des joueurs déjà dans une balise d'isolation bidirectionnelle, ou entre caractères de contrôle Unicode équivalents, pour éviter un réordonnancement incorrect de la phrase: imagine un des joueurs ou les deux ayant des noms arabes, ou bien l'utilisation du message traduit en arabe avec des noms de joueurs en écriture latine, ça pourrait retourner un rendu incorrect et un quiproquo dans le jeu)

Je ne sais pas si FreeCol a été testé et est supposé être pris en charge dans une traduction arabe ou hébraïque. ou avec des noms de joueurs bidirectionnels

Mais je suppose que c'est aussi ce qui est fait pour les noms de pays et pourquoi un "tag:country" a pu être ajouté dans l'original (et donc aussi les traductions faites ici), pour la mise en forme ou pour ajouter une icône nationale, un drapeau, un blason, et colorer différemment les alliés ou adversaires, les mettre en gras, les surligner....

C'est le genre de choses qui change avec le temps et les signalement d'anomalies aux développeurs du jeu. De plus ce n'est pas nécessairement partout %country% si un message a besoin d'afficher pluseirus noms de pays avec %country1% ou %country2% ou juste %1% et %2% : les noms de cas variables sont à utiliser verbatim et ne se traduisent pas et leur valeur n'est pas nécessairement directement un nom de pays mais pourrait être un identifiant court indépendant de la langue (comme un code ISO 3166 ou l'identifiant d'un autre message traduit ailleurs).

Salut ! Un nouvel gadget a été crée, Project:Terminology gadget, quels mots vous croyez seront à mettre dans cette liste. @Verdy p, Gomoko, VIGNERON, Eihel, and Thibaut:

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ébioctet.

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

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

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.)

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.

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^^.

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 le 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 fichiers formatés et l'espace libre dans le système binaire ; de même la capacité mémoire RAM (aussi bien dans les OS que pour les constructeurs de barrettes, mais pas les cartes mémoire flash et les SSD qui sont en décimal pour les constructeurs (parce qu'en binaire cela ferait moins, une partie de la capacité étant réservée à la gestion par le firmware).

An issue has come up with the French translation of the Codev project. Briefly: the developer does not want to use the translations from translatewiki.net for French [1]. I am not sure what to do now. I am considering disabling translation to French here. What do you think?

Is it the correct developer ? You seem to point to a personal fork, the original being maintained in "https://github.com/lbayle/codev", not "https://github.com/mantisbt-plugins/codev" The French translations were correctly loaded 4 days ago in the original: https://github.com/lbayle/codev/tree/master/i18n/locale

https://github.com/mantisbt-plugins/codev is the official location. The translations are currently being committed but not used.

For sure, if Translatewiki.net translations are not used, they should be disabled: translators should not spend time to translate strings which would never be used.

So there's a conflict between two maintainers ? The "official" one being in fact a fork that its maintainer no longer wants to update. But as the original is still maintained (and apparently used), can we really say that these translations are not used ? This is a problem from the MantisBT project, that decided to use an unmaintained version of Codev, and may be MantisBT could change its policy and decide to create rits own separate fork of CodeV to effectively use these translations.

Bonjour les traducteurs,

La traduction de « Wikimedia Foundation » n'apparaît dans aucun glossaire de Portal:Fr. Il est sur Meta, mais sans traduction depuis longtemps. Perso, j'ai toujours traduit par « fondation Wikimedia » (sans accent, contrairement à Wikipédia). Ai-je loupé qque chose ?

En fait, j’ai ouvert un débat sur Meta-Wiki le 7 avril dernier, mais personne n’y a répondu…

Je pense que Meta-Wiki (qui coordonne les projets) est plus approprié pour discuter de cela que Translatewiki.net (traduction du logiciel, où l’expression “Wikimedia Foundation” apparait peu). Est-ce que ça vous dérange si on continue la discussion là-bas ? Peut-être en faisant du rameutage sur le bistro de Wikipédia si ça manque de participants.

Nope, pas de prob, Pols12. Mais il faudrait pinger les francophones pour recevoir des avis (c'est d'ailleurs pour ça que je viens ici ;)

Pour info, voir cette discussion.

Personnellement, je trouve le terme « téléverser » moins ambigu, c’est aussi un des rares québécismes à avoir traversé l’Atlantique puisqu’il est rentré dans le Larousse et est utilisé par divers projets libres.

Téléverser est idéal pour moi. Pas d’ambiguïté, un usage déjà large en informatique où l’on a besoin de précision et plusieurs organismes au fait de la chose l’ont adopté et le promeuvent.

Le choix de "téléverser" (et ses variations "téléversement", etc.) me semble également préférable. Le téléchargement induit dans l'usage un transfert "depuis Internet/un serveur vers soi" tandis que le téléversement indique bien l'action inverse "de soi vers une destination distante".

À mon sens, nos amis québécois ont inventé un nouveau mot qui n’apporte pas grand chose au niveau précision. Parce que "charger" (le préfixe "télé", on est d’accord, c’est pour le fait que c’est entre machines électroniques) n’implique pas de sens, ni depuis internet, ni vers internet (ou tout autre chose, comme un wiki). Quant à "verser", s’il implique un sens, c'est plutôt du haut vers le bas, ce qui n’a guère de sens dans le cas présent; il induit donc plus de confusion qu’autre chose (j’avoue que la première fois que je suis tombé sur une interface avec ce terme, je me suis bien demandé ce qu’il y avait derrière ce bouton/lien).

Donc pour moi, "télécharger" est le seul terme idoine, et il n’implique pas de sens. Si on veut à toute force ajouter un sens (ce qui est en général superflu, le contexte le donnant), c'est "télécharger vers" ou "télécharger depuis". L'action reste le (télé)chargement, et les prépositions sont là pour donner les précisions supplémentaires.

De grâce, utilisons le français tant que les termes idoines existent, et évitons autant que possible les barbarismes ou néologismes sans intérêt. Et n’oublions pas que wikimédia et les projets associés sont à destination de monsieur et madame tout le monde, pas seulement quelques geeks avec leur jargon particulier.

@Gomoko: Lyokoï et Linedwell préfèrent téléverser, mais ils ne sont pas Canadiens. Téléverser est un terme prévu pour tout le monde.

Le « versement d'une prime » est une rémunération complémentaire donnée (versée) pour un travail particulier. Si on emploie le même sens de circulation, le téléverseur est celui qui détient les données et les « verse » autre part. download avait un sens plus marqué au début des réseaux. Maintenant, il est employé comme une charge qui est déplacée, qu'importe le sens. download et upload ne sont pas les seuls termes faisant débat. On le voit encore dans Wikidata : « Pourquoi importer des données dans Wikidata. » dans [1] (il s'agit bien sûr d'exporter en place d'importer). « Téléverser » n'a pas d’ambiguïté sur le sens de circulation des données et devrait être privilégié, àmha.

Voir mes 4 modifications de MediaWiki ce jour. Vos opinions, vos remarques...

Quatre modifs en question : [1][2][3][4].

« importer » est la bonne traduction (il est d’ailleurs indiqué dans le glossaire avec « téléverser »), « exporter » c’est quand on télécharge un fichier généré par le serveur (« exporter en CSV », etc.).

Pas convaincu que ce soit vraiment « moins ambigu » ; par contre, c'est clairement le terme habituel depuis des dizaines d'années sur les projets Wiki et contrairement à ce qui est prétendu, ce n'est pas un terme "incorrect". Aucune raison de changer le statut quo sans raison valable.

Par contre User:VIGNERON, vous convainquez avec un argument que je ne peux réfuter : c'est ainsi depuis que c'est écrit ainsi... sur cette bonne vieille Terre, et pourtant, « elle tourne », disait déjà Galilée.

Eihel, nous savons tous ce que c’est qu’une importation et qu’une exportation. Je suis d’accord avec Mattho69, c’est une question de point-de-vue. En l’occurrence, on a toujours considéré, comme sur tous les sites web et logiciels, que l’utilisateur est derrière l’interface qu’il utilise (métaphoriquement).

Autrement dit, il contrôle le wiki, donc il importe sur le wiki des données depuis ailleurs (en l’occurrence, ailleurs, c’est son ordinateur, mais ça pourrait être un autre site web par exemple).

L’argument de VIGNERON, n’est pas du tout fallacieux : en ergonomie c’est ce qu’on appelle la cohérence (ici, interne et externe). Voici deux exemples où les mots ont bien cette signification : importer chez Google et exporter chez Facebook

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.

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.

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.

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… =)

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.

Discussion ici.

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

Des avis extérieurs seraient les bienvenus.

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 ;-).

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

Bonjour,

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

Des propositions ? (contexte)

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à.

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 ?

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

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...

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

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

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.

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… =)

Résumé : oui, si c'est bien normal car dans d'autres langues comme le finnois afin de répondre naturellement ce n'est pas "oui" mais par exemple "si".

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 ...

Voir https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Wikipedia-android-strings-yes/en_(2)

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.

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é »)

+1 pour pavé

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 !

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 ?

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.

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.

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

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

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.

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 »).

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é.

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

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)

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

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,

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.

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.

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.

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

En Anglais, stp.

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

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

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 ».

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.