User talk:Verdy p

From translatewiki.net
Jump to navigation Jump to search

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

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

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

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

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

First page
First page
Previous page
Previous page
Last page
Last page

https://translatewiki.net/w/i.php?title=Portal:Fr&diff=next&oldid=9788183

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

Urhixidur (talk)14:23, 31 December 2020

Bump.

Urhixidur (talk)13:19, 3 January 2021
 

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

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

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

Urhixidur (talk)13:56, 4 January 2021

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

Urhixidur (talk)15:20, 17 February 2021

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

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

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

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

https://translatewiki.net/w/i.php?title=Mantis:Codev-79c3c3-Are_you_sure_you_want_to_chang/fr

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

Urhixidur (talk)15:22, 17 February 2021

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

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

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

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

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

Nouvelle guerre d'édition

Bonjour,

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

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

VIGNERON (talk)14:03, 16 February 2021

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

VIGNERON (talk)14:24, 16 February 2021
 

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

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

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

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

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

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

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

VIGNERON (talk)14:40, 16 February 2021

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

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

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

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

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

VIGNERON (talk)14:47, 16 February 2021
 
 
 
 
 

Mass changes without consensus

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

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

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

Nemo (talk)09:53, 6 December 2020

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

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

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

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

Nemo (talk)20:54, 6 December 2020

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

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

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

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

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

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

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

Nemo (talk)18:44, 6 January 2021
 

Wikimedia:Wikiedudashboard-timeline.block_type

Re : https://translatewiki.net/w/i.php?title=Wikimedia:Wikiedudashboard-timeline.block_type/fr&diff=next&oldid=9309695 Tu as terminé la traduction avec un point, alors que l'original anglais l'omet. L'original serait fautif ?

Urhixidur (talk)13:39, 29 December 2020

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

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

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

Urhixidur (talk)14:15, 31 December 2020
 
 

Es-tu sûr ? ;-)

https://translatewiki.net/wiki/Wikimedia:Wikiedudashboard-users.remove_confirmation/fr Sûr est bien correct en français, c'est la traduction usuelle de "sure". "Certain" n'est pas strictement incorrect mais fait "bizarre". Voulez-vous vraiment supprimer le compte %{username} ? Est plus long mais évite le parenthésage du genre et explicite le rôle de %{username}.

Trial (talk)19:00, 29 December 2020

Vicuna:Uploadcheck-checks-running

Re : https://translatewiki.net/w/i.php?title=Vicuna:Uploadcheck-checks-running/fr&diff=next&oldid=9785412 Garder le « pluriel d'origine » n'ajoute rien à la traduction, à mon avis. La vérification du téléversement peut comprendre de multiples étapes ou branches parallèles, l'usager s'en fout, c'est une boîte noire. Je pense que dans ce cas-ci la règle d'or (Utiliser le singulier plutôt que le pluriel autant que possible) s'applique. Qu'en penses-tu ?

Urhixidur (talk)13:26, 29 December 2020

Mantis:S kb/fr

Bonjour,

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

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

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

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

Changements inutiles avec GENDER et PLURAL

Bonjour,

Quel est l’intérêt :

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

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

Pols12 (talk)18:59, 12 December 2019

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

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

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

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

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

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

Pols12 (talk)16:02, 17 December 2019

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

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

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

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

Pols12 (talk)17:59, 17 December 2019

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

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

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

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

Pols12 (talk)16:12, 19 December 2019

Où est la "question technique" ?

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

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

Pols12 (talk)20:03, 19 December 2019
 
 
 
 
 

Thank you for your help on the support page

Regards,

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

Espaces fines insécables entre les guillemets

Bonjour,

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

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

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

Cordialement.

Thibaut120094 (talk)11:53, 14 September 2019

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

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

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

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

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

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

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

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

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

Avez-vous des sources pour soutenir vos propos ?

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

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

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

Thibaut120094 (talk)12:47, 14 September 2019
 

De même l'OQLF indique clairement :

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

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

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

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

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

Thibaut120094 (talk)13:03, 14 September 2019

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

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

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

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

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

Pols12 (talk)00:47, 10 October 2019
 
 
 
 
 

Typographie dans les traductions

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

Eihel (talk)11:20, 28 November 2019

Bonjour Eihel,

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

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

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

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

Pols12 (talk)14:27, 1 December 2019
 

Inquiétudes

Re https://translatewiki.net/w/i.php?title=FreeCol:Model.event.resetNativeAlarm.name/fr&diff=next&oldid=9098833 « Balayer les inquiétudes » j’ai entendu parfois, mais la forme passive, jamais. « L’inquiétude des indigènes est rassurée » n’est pas satisfaisant non plus. Pourquoi pas plutôt « Les indigènes sont rassurés » ?

Urhixidur (talk)21:34, 1 November 2019

expressions usuelle "balayer les inquiétudes de la population", "la population française peut être tranquille, toutes ses inquiétudes balayées". Rassurer quelqu'un (ça c'est l'action commise sur la personne) ne veut pas dire que cela ôte ses inquiétudes (ça c'est l'effet espéré... qui se produit peut être) Et "être rassuré" ne veut pas dire qu'il y a eu une action tierce, ce peut être un effet auto-généré ou acquis depuis longtemps (donc pas d'inquiétude non plus au départ, alors que d'autres auraient de quoi être inquiets et avoir peur). Ici la phrase avait deux partie, une mentionnant l'action causale.

En tout cas "L'inquiétude [des indigènes] est rassurée" ne voulait rien dire (mélange cause/effet).

Verdy p (talk)21:51, 1 November 2019

Je me permets une incrustation ici.

Ici, je suis d’accord avec Verdy P : « Balayer les inquiétudes » ne me choque pas à la fois passive (exemple).

« rassurer les inquiétudes », je ne connaissais pas, mais ça existe toutefois, un exemple est donné dans le TLF.

« être rassuré », c’est bien avoir retrouvé une confiance perdue auparavant (cf TLF), ça pourrait convenir sans problème aussi.

Cette traduction n’était pas évidente mais vous arrivez à quelque chose de vraiment naturel !

Pols12 (talk)19:09, 12 November 2019

Note bien que le TLF mentionne que «rassurer quelquechose» est une forme seulement utilisée par métonymie, un abus de langage. Certains abus sont très communs et populaires (comme «boire un verre», étant donné que ce n'est pas le verre qu'on boit mais son contenu) mais toute métonymie est un raccourci faisant une confusion (entre cause et effet, agent et objet, objet réel et figuré comme dans «il pleut des cordes»). Quand c'est très peu commun, c'est une forme très étrange qui peut susciter des interrogations sur le sens même de la phrase, comme s'ils manquaient des mots nécessaires pour comprendre le sens réel. C'est alors toujours une source d'ambiguïté et ça ne veut plus rien dire quand les sens peuvent facilement partir dans tous les sens. Les références trouvées du TLF ne mentionnent cependant pas «rassurer une/des inquiétudes», mais avec d'autres objets qu'il est possible de «personnifier», comme si cette personne le demandait ou l'espérait. Une «inquiétude» peut difficilement être personnifiée, en elle-même elle n'est qu'un constat d'un état qui ne demande rien et va dans la direction opposée de celle de «rassurer», en somme on affirmerait dans la même phrase un sens et son contraire, ce qui donc ne signifie plus rien ou n'apporte plus rien et qu'on ne peut donc interpréter que dans toutes sortes de directions.

On trouve peut-être un unique exemple (vieilli) chez un auteur mais la métonymie n'est pas claire et en fait ne correspond même pas vraiment à la définition donnée de la métonymie d'objet, car pour moi cet auteur fait une métonymie de sujet (qui est inquiété: l'auteur Druond sous-entend qu'il y a des personnes proches sur place qui assistent à la scène, il ne les cite pas justement pour donner une atmosphère étrange et plutôt justement renforcer la sensation pesante d'inquiétude qu'il ne balaye pas du tout, en somme personne n'est vraiment rassuré, tout le monde, l'auteur compris comme si c'était un acteur de la scène, fait semblant et ne veut pas se montrer affecté et voudrait s'afficher fièrement comme rassuré, tout en sachant ou se doutant que personne ne l'est).

Les autres usages consistent à éviter de désigner directement le sujet, comme par retenue ou politesse, contre une accusation ad hominem qui pourrait être vue comme dégradante, on commence par désigner un autre état d'esprit puis on l'attribut indirectement à des personnes informellement désignée et pour laquelle on ne veut pas affirmer qu'elles sont inquiètes ou ont besoin d'être rassurée, comme si on voulait préserver leur fierté publique. "rassurer complètement la chasteté effarouchée du lecteur", évidemment il y a là déjà une attaque du lecteur, mais en plus si l'auteur ajoutait que le lecteur a en plus besoin d'être rassuré, l'auteur mépriserait son lecteur ou lui ferait un double affront

Autant dire que l'auteur veut ne pas les offusquer (ce n'est pas le cas aujourd'hui quand on entend une phrase aussi stupide que "je veux rassurer mes lecteurs en leur disant que je", où l'auteur s'approprie le libre cours des lecteurs et le droit de penser par eux-mêmes et leur ordonne presque de suivre les idées aveuglément, et souvent cette formule cache le manque d'arguments tangibles et vérifiables en dehors, l'auteur se fait proclamer comme autorité sur la conscience des autres, il ferme la porte à la réflexion personnelle et à l'évaluation ou la confrontation à d'autres avis extérieurs).

Bref toutes ces métonymies sont à éviter dans une traduction (d'autant plus que la grande majorité des métonymies n'ont pas d'équivalent dans les autres langues, on ne doit pas traduire mot pour mot et les introduire, même si elles sont consacrées dans la langue source et pas la languie cible ou le contraire, sauf si l'usage est consacré et bien établi dans les deux langues), elles n'aident certainement pas à clarifier le discours. On peut dire "il pleut des cordes" ou "il pleut des hallebardes" ou "il pleut comme vache qui pisse" en français, mais en anglais le mot à mot ne marche pas.

Notre président Macron ne se prive pas en français de prononcer des phrases intraduisibles à l'étranger, comme lors de sa récente visite en Chine, histoire de bien gêner ses hôtes chinois (ceci dit le président chinois a lui aussi trouvé quelques formules chinoises tout aussi savoureuses, impossibles à traduire: ce sont des pics de langages masqués qui évitent en fait des incidents diplomatiques puisqu'on est sûr que ceux qui comprennent ne sont pas ceux que la phrase désignait bien, ça sélectionne un auditoire et c'est donc une opération de communication publique extérieure, indirectement ça cherche à isoler celui qui ne comprend pas pour qu'il hésite sur la réponse à apporter, ces artifices de langages cherchent donc à déstabiliser et affirmer une autorité supérieure face à celui qui ne sait comment comprendre et répondre)

Autant que possible on évitera ces confusions sujet/objet, fait/cause, cas particulier/généralité... sinon on a des raisonnement absurdes ("tous les hommes sont égaux, les femmes sont égales aux hommes, donc tous les hommes sont des femmes"). D'une façon ou d'une autre cela sert à limiter l'auditoire et ça déforme le sens et la portée et cela cherche à modifier le rapport de force entre celui qui dit, écrit ou traduit, et ceux qui les écoutent ou les lisent.

Verdy p (talk)21:02, 12 November 2019
 
 
 

Salut à toi, et tout d'abord merci pour tes corrections typographiques sur mes interventions (les apostrophes et les espaces insécables) !

Concernant celle-ci : [1], il y a cependant une chose qui me chiffonne à propos de la suppression des mots "qui est", car les supprimer purement et simplement me semble donner une phrase incorrecte (mais je ne saurais expliquer en quoi), du coup je te propose donc :

  • de les remettre
  • ou d'enlever aussi le mot "celui" (ce qui apporte aussi davantage de concision)

Je te laisse voir ce qui te semble le mieux comme toujours :)

Bien cordialement,

AlNo (discuter/talk/hablar/falar)09:11, 22 October 2019

Dans la modif que tu indiques, il n'y a pas besoin de subordonnée. Ce n'est pas du tout incorrect mais bien français d'écrire "celui indiqué" et non "celui qui est indiqué", et pour le style c'est aussi préférable pour éviter les allitération ou répétitions de "qui ... qui" dans la même phrase (style vraiment "enfantin" et très peu soutenu, du genre: "c'est celui qui dit qu'y est !").

Là c'est tout à fait naturel et ça suit un rythme plus simple à lire sans changer l'ordre d'interprétation. Les subordonnées semblent simplifier mais leur première compréhension est comme deux phrases mais on se demande avec quoi s'attache la conjonction "qui" ou "que" qui n'a ni genre ni nombre et vient ensuite le marquer seulement plus tard éventuellement sur le verbe ou l'attribut: c'est moins compréhensible et on perd la structure générale de la phrase entière. En plus ça rallonge un peu. Les subordonnées sont lourdes, elles rompent le rythme et à éviter si on peut s'en passer....

Cependant J'évite les gérondifs en utilisant une subordonnée s'il n'y en a pas d'autres (cette phrase en est un exemple).

De façon générale, je pense qu'il ne faut pas mettre deux subordonnées l'une dans l'autre, sinon il vaut mieux reformuler et faire deux phrases ou une mention plus courte entre parenthèses.

Verdy p (talk)09:38, 22 October 2019

OK, et merci pour l'explication grammaticale :)

Et encore merci pour tout ton travail de fourmi !

Bien cordialement,

AlNo (discuter/talk/hablar/falar)12:15, 22 October 2019
 
 

Mantis:Codev-5c00df-Edit timetrack

En anglais "timetrack" désigne le temps déjà dépensé (imputé au budget d'un contrat ou d'une tâche). « Échéancier » a plutôt rapport à la planification à venir. https://en.wikipedia.org/wiki/Time-tracking_software

Urhixidur (talk)20:49, 8 October 2019

" a plutôt rapport avec ": les échéanciers montrant aussi bien les échéances passées (avec indication des avances et retards effectifs) que celles à venir (et les avances et retards prévus) sont monnaie courante, je ne vois pas ce qui impose seulement le sens passé, même pour ce projet codeVTT où il est particulièrement utile de connaitre ce qui s'est déjà passé pour mieux planifier l'avenir (même si une tâche est totalement passée, si elle a pris du retard et était suivie de tâches nécessitant un temps minimum difficilement compressible (avec les affectations de resources actuellement disponibles et planifiées) ces dernières prendront aussi du retard sur l'avenir.

Exemple: un lot logiciel a été livré avec 1 mois de retard, mais le client dispose par contrat d'une validation lui demandant 15 à 3 semaines : on ne peut toujours pas affecter du monde pour travailler sur le lot suivant sachant que suite au retour client, il faut encore 1 semaine de recette; le lot suivant qui demande 2 mois ne pourra commencer à être réalisé dans 3 à 4 semaines, et donc sa recette a déjà aussi au minimum 4 semaines à 1 mois de retard avant d'avoir commencé et il va falloir dégager du personnel qui normalement était prévu sur la réalisation d'autres tâches qui n'ont pas les contraintes de temps, sinon risquer de nouvelles pénalités qui peuvent être coûteuses quand elles se cumulent avec celles déjà du premier retard.

De même si des lots sont en avance, on peut parfois, mais pas toujours commencer le lot suivant car il peut dépendre de compétences qui ne seront pas encore disponibles immédiatement, mais une partie de l'avance sera éventuellement utilisable.

Les échéanciers de tâches ne sont pas réservés au seul avenir. De même pour les échéanciers de paiements (qui aussi dépendent des échéances passées quand elles n'ont pas eu lieu aux dates initialement prévues). Sur l'ensemble d'un projet, diviser arbitrairement sur la limite du présent ne donne pas de vue appropriée car elle est toujours instable, on préfère un échéancier partant d'un événement à date fixe pour planifier un projet et le suivre dans tout sons cycle et vérifier l'adéquation du plan prévu avec les mesures réelles du passé, et l'analyse des étapes passées pour mieux gérer les ressources pour l'avenir.

Sinon "timetrack" en anglais n'est pas non plus réservé non plus au seul passé. Le choix de la date de référence est arbitraire mais fixe et permet d'analyser ce qui suit sans se situer nécessairement à l'instant présent. En français on a différents mots pour différents métiers (par exemple "chemin de fer" dans le monde de la presse, l'édition et la publicité, "scénario" dans l'audio-visuel, "mise en scène" ou "production" dans les spectacles, "lotissement" dans les marchés publics ; dans les logiciels même pour l'internet on touche à divers métiers et le vocabulaire évolue tout autant selon à qui on destine les planifications et analyses). On trouve aussi "frise chronologique" pour une série d'événements, "diagrammes" (de Gant par exemple) dans la modélisation analytique du travail (services publics ou commerciaux) et aussi la conception de tâches partiellement ou totalement automatisées.

Je ne vois pour l'instant pas de meilleur terme que "échéancier" (sinon "calendrier" mais un calendrier peut être nu et non lié à un projet ou un ensemble particulier de tâches ou d'événements). Bref, que proposes-tu de mieux en échange que le terme anglais (qui n'est certainement pas plus clair pour le plus grand nombre de francophones) ?

Verdy p (talk)22:53, 8 October 2019

Le problème avec « échéancier » c’est que ça ne couvre que les dates, alors que le concept de "timetracking" concerne non seulement les dates (passées ou à venir, je le concède), mais aussi les allocations de personnel aux plages temporelles. C’est une question de facturation. https://fr.wikipedia.org/wiki/Gestion_de_projet parle d’« affectation de ressources ». Je ne trouve rien sur Termium, à l’OQLF ou sur IATE.

Urhixidur (talk)14:10, 9 October 2019

Un échéancier peut tout à fait concerner toutes sortes de ressources, pas que financières, mais aussi de disponibilité du personnel (planification des congés et suivi des congés maladie, embauches, plans sociaux, licenciements, démissions et départs en retraite prévus, formation, restructurations internes et déménagements), des matériels ou des services (les livraisons ou réservations par exemple).

Le terme est assez large pour couvrir tout ce qui peut se planifier sur un calendrier et inclut des décisions, qu'elles soient internes par ceux qui décident du projet ou par ceux qu'ils dirigent, ou externes par tout tiers dont dépend le projet.

Le terme "timetrack" en revanche peut mal être interprété en français non au fait du jargon anglophone (théorique) de la planification de projets, par exemple comme un simple suivi d'événements, juste par intérêt ou pour une simple analyse externe (exemple : suivi d'une compétition, présentation promotionnelle des performances d'un produit avant même toute décision de l'acquérir par un tiers qu'on ne connait même pas précisément et sur lequel on n'a pas de contrôle).

Pour l'instant tu ne proposes pas de meilleur terme et je pense sincèrement que "échéancier" marque bien l'esprit et s'étend et se comprend facilement aux divers usages couverts par le terme anglophone. Le terme "échéancier" est bien trouvé dans des tas de documents formels traduits dans les deux langues.

Il y a divers moteurs de recherche et dictionnaires sur le web montrant des mémoires de traduction avec des extraits de documents côte à cote, traduits par des professionnels ou utilisés dans l'enseignement et clairement le terme le plus fréquent (même s'il peut y avoir certains synonymes ou simplifications dans des contextes limités est bien "échéancier".

En revanche les documents francophones utilisant "timetrack" sont vraiment rares, ou pas formels du tout, et je n'en trouve aucun dans les documents formels administratifs français (par exemple, ceux des marchés publics), et pas plus en Belgique, en Suisse, ni même au Canada dans les provinces francophones où la francisation des termes est une règle bien suivie (et qui trouve souvent des termes magnifiques dont la France s'inspire ensuite mais souvent tardivement après des égarements par trop d'anglicismes utilisés sans réfléchir et ensuite déviés même de leur sens initial car justement mal compris et expliqués).

Verdy p (talk)14:38, 9 October 2019

Qu’une chose soit claire : je n’ai jamais prôné d’utiliser le terme anglais "timetrack". Je pensais que la discussion était entre ta proposition d’« échéancier » (dans un sens élargi —cf. https://gallica.bnf.fr/ark:/12148/bpt6k1200533r/f711.image) et le terme « imputation » qui est présent dans les traductions du moment. Les deux me semblent déficients.

Que dirais-tu de « suivi du temps » pour "timetracking" et « saisie de temps » pour "timetrack" ?

Urhixidur (talk)17:53, 9 October 2019

le terme imputation me semble faux aussi, je n'en suis pas l'auteur. Suivi du temps me parait tout autant un anglicisme par une traduction ultra littérale, qui en fait semble plus éloigner du sujet. Franchement le terme échéancier est bien présent dans la littérature concernée, et dans les documents formels (banques, marchés publics, organisations syndicales, organisations de défense des consommateurs, organisations professionnelles) et documents didactiques (écoles de commerce et universités). On trouve pas mal de documents anglais-français traduits cote à cote (notamment des tas d'exemples de contrats entre founisseurs et clients, en B2B comme en B2C) qui utilisent ce terme et pas une expressions aussi peu parlante que "suivi du temps". "Saisie de temps" me semble encore plus mauvais! Le temps ne se saisit pas, soit il se mesure (par différence) ou se date (selon un calendrier officiel) et le but n'est pas que de saisir le seul temps mais d'y associer des événements ou des tâches, mesurer les performances, et éventuellement le facturer ("le temps, c'est de l'argent" comme on dit dans ce sens-là), et pouvoir qualifier les dates et instants buttoirs ou critiques. Certes on peut toujours paraphraser, mais cela restera hésitant et on a des tonnes de tournures qui seront moins repérables que le terme consacré depuis longtemps, connu et repéré facilement dans une conversation ou dans tout projet formalisé.

Verdy p (talk)18:19, 9 October 2019
 
 
 
 
 

Outreach Wiki

Bonjour,

J'ai toujours entendu ce projet sous le nom 'Outreach Wiki' (ou la forme longue 'Wikimedia Outreach Wiki') mais jamais sous le nom de 'Wiki Sensibilisation'. C'est bien ce nom qui apparaît dans l'onglet du navigateur, dans les recherches Google (22 800 contre 105 résultats) ou bien qu'il est cité en source ici par exemple https://fr.wikipedia.org/wiki/Wikim%C3%A9dien_en_r%C3%A9sidence#cite_note-Outreach2-19 (et je n'arrive pas à retrouver le dépôt mais je suis à peu près sûr que le nom est déposé).

PS: pour comparaison (n'est pas raison), la plupart des autres langues ne traduisent pas ce nom propre non plus Special:PrefixIndex/MediaWiki:Project-localized-name-outreachwiki.

VIGNERON (talk)09:58, 26 September 2019

Le terme "sensibilisation" est là depuis le début de ce wiki... alors que Outreach ne signifie rien et est très confus pour la quasi-totalité des francophones (en témoigne les différentes façons souvent maladroites de le traduire). Ne pas oublier le but du wiki : on ne sensibilise personne dans un but qui est mal nommé. Depuis toujours le terme a été traduit, jusqu'à sa page d'accueil.

Le logo est unique uniquement parce qu'il n'y a qu'un seul logo sur le wiki multilingue. Mais le nom déposé n'est pas "Outreach" ni "Wikimedia Outreach", ce qui est déposé c'est "Wikimédia" qui n'est même pas dans la resource en anglais donnée à traduire. "Outreach" ou "Wiki Outreach" ne sont clairement pas des marques et ne l'ont jamais été, seulement le logo utilisé l'est (et il affiche uniquement "Wikimedia Outreach".

Quant aux autres langues, c'est bel et bien traduit si le terme a bien été compris, ou dans les langues à écriture non-latine et sans tradition d'utilisation des termes anglophones qui ne sont pas des marques.

C'est la même situation que pas mal d'autres wikis spécialisés de la Fondation: on traduit "Wiki" si possible séparément du terme qui le suit; seuls les mots-valises dédiés à certains projets seulement ont été déposé dans certaines langues après un vote communautaire formel pour les approuver (Wikipédia, Wiktionnaire, MediaWiki, Wikimedia, Phabricator, etc.). Mais pas "Meta-Wiki" et autres termes composés librement avec un terme générique signifiant qu'on traduit ou adapte séparément (tous les sites nommés "Wiki<espace ou tiret>quelquechose" ou "Wikimedia<espace ou tiret>quelquechose" (dont on traduit séparément les termes).

"Outreach" ne peut pas être déposé (c'est un terme générique consacré en anglais, mais pour un sens qui n'est bien compris qu'en anglais en jargon publicitaire et promotion commerciale, ce qui n'est pas le but de ce wiki qui se veut communautaire et explicitement ouvert au reste du monde et aux autres langues, pour être soutenu par la communauté et non directement la fondation qui seulement a accepté le projet pour y apporter un soutien limité, le plus gros étant fait par la communauté ! La Fondation pour ses communications a son propre wiki à son nom... qui est aussi traduit et déposé dans certaines langues utilisées aux USA ou langues de communication internationales), pas plus que "Wiki" utilisé ici. et la Fondation n'a pas besoin de déposer le nom "Wikimedia Outreach" car la protection du premier terme suffit et la composition suit seulement les règles communautaires pour la réutilisation du terme "Wikimedia" sur un logo. Ici il n'y a même pas le mot "Wikimedia".

Verdy p (talk)10:36, 26 September 2019

Bonjour Verdi p,

C'est tellement à côté de la plaque que je ne sais pas quoi répondre.

Bien sûr le mot « sensibilisation » est présent sur Outreach depuis le début, comme « encyclopédie » est présent sur Wikipédia depuis le début. Pour autant, on ne traduit « Wikipedia » par « wiki encyclopédie ».

« "Outreach" ne peut pas être déposé », c'est risible, si je n'arrive pas à retrouver le dépot de marque par la WMF, c'est justement parce qu'il y a trop de dépot de marque sous le nom "Outreach" ! 661 selon la base que WIPO. Selon cette même base il y a 654 dépôts avec la WMF comme titulaire mais visiblement aucun pour Outreach, sur ce point j'avais tort mais cela n'en reste pas un moins un nom propre.

Enfin bref, quand j'utiliserais Outreach à l'avenir, je serais obliger de faire des pirouettes et dire « le site qui s'appelle Wiki Outreach mais que quelqu'un à traduit à tort en Wiki Sensibilisation ». Merci pour le temps que tu me fais perdre.

PS: je vois que tu as maltraité d'autres noms propres de la même façon (comme InstantCommons devenu Instant Commons sans raison). Si cela continue, on ne pourra plus utiliser TranslateWiki si les traductions sont aussi mauvaises.

VIGNERON (talk)12:26, 8 October 2019

Instant Commons s'écrit aussi avec une espace dans la source en anglais ! Visiblement tu ne t'appuies que sur les diffs de la traduction elle-même sans lire la source et ses changements !

Verdy p (talk)12:34, 8 October 2019

InstantCommons ne prend évidemment pas d'espace (ni en anglais ni en français). Non, je ne m'appuie évidemment pas sur les diffs (pas uniquement en tout cas), je m'appuie sur le nom de l'outil tel que je l'utilise et le connaît ! Quand on veux faire une bonne traduction, il faut regarder le contexte d'utilisation. En l'occurrence, ce minimum de recul permet de se rendre compte que la source en anglais utilise l'espace à tort, pour s'en convaincre il suffit par exemple de suivre le lien directement fourni par MediaWiki:Config-instantcommons-help/fr.

Au final, je me contrefiche de Wiki Outreach ou InstantCommons, je n'ai fait la remarque que parce que je connais bien ce projet et cet outil. Par contre, mal traduire - qui plus est des noms propres - ça c'est dommage et dommageable (à l'avenir quand on me demandera, je préconiserai de ne pas utiliser de ne pas utiliser TranslateWiki pour les traductions).

VIGNERON (talk)12:54, 8 October 2019

Va te plaindre aux auteurs de l'outil qui ont bel et bien importé cet espace.

De même pour Outreach dont visiblemetn tu n'as pas suivi la génèse et les discussions d'alors : "'outreach" c'est non pas un nom de projet mais un terme générique du jargon commercial/promotionnel en vogue aux USA (mais pas dans d'autres pays anglophones) sous l'effet de quelques grandes écoles de commerce américaines et de l'administration interne de Wikimedia: on est loin de l'esprit Wikimedia. Et depuis toujours le site "Outreach" a demandé à ce qu'on traduise ce terme s'il n'était pas compris. Sa traduction a été faite depuis le début, même si pour l'anglais le terme "Outreach a été conservé tel quel.

Le terme "Sensibilisation" a été accepté depuis longtemps et a toujours été présent dans la version française du site (après diverses discussions pour savoir quel terme serait mieux adapté, étant donné que "outreach" n'a aucun sens ni usage connu et compris chez la plupart des francophones (hormis quelques admins habitués à travailler avec les équipes internes anglophone comme toi, qui n'a justement pas besoin de ce site, lequel ne s'adresse pas spécifiquement à ce petit groupe, mais depuis toujours se veut le plus ouvert possible et surtout pas aux seuls techniciens et admins, mais s'adresse a des organisateurs de communautés locales qui veulent faire comprendre les projets à des personnes moins éduquées car moins favorisées, et non multilingues).

Cherche un peu les définitions du terme "outreach" même dans un dictionnaire anglophone ou dans divers dicos de traduction, il n'y a strictement rien de clair hormis le petit monde des riches écoles de commerce américaines et les arcanes internes des employés de la Fondation (dont bon nombre ont du mal à comprendre encore le fonctionnement communautaire et sont centrés sur des activités très techniques, et sont même inaccessibles directement par la communauté).

Si tu veux contester le terme des années après, va sur le site en question en discuter à nouveau. Le projet "Outreach" n'est d'ailleurs pas directement supporté par la Fondation c'est une idée issue d'une conférence communautaire Wikimania, un petit groupe a lancé un mini projet puis cherché des avis communautaires plus étendus que les seuls anglophones initialement impliqués. Le projet n'a pas eu beaucoup de suite, il servait à préparer un plan de développement qui a ensuite été proposé à la Fondation, qui a donné ses avis, donné des moyens et ensuite distribué les rôles. Outreach reste un projet ijnformel destiné à être ouvert pour rassembler des idées diverses, son contenu est informel il n'a pas vocation du tout à être une "marque".

Verdy p (talk)14:14, 8 October 2019
 
 

Encore une fois je note que tu poursuis avec le ton polémique, à la limite de l'insulte ou l'attaque personnelle. Su un terme qui est traduit comme ça depuis ses tous débuts (et suite déjà à diverses discussions questionnant justement le choix de ce terme même en anglais : le nom anglais ne reflète pas du tout clairement les objectifs du site et surtout il ne s'adresse pas du tout à ceux qu'il veut justement impliquer dans ce projet, lequel a justement pour but de décentraliser les poles de décision et retirer les barrières techniques, linguistiques, ethnologiques, culturelles, et les rôles trop centralisés qui entachent lourdement et de plus en plus fortement Wikimedia des utilisateurs : la communauté Wikimédia est même en décroissance forte, beaucoup ont abandonné à cause de tout ça et sortir Wikimedia de son petit monde est de plus en plus difficile, tandis que Wikimedia essuie de plus en plus de critiques et attaques dans les autres médias dits "sérieux" mais souvent très orientés idéologiquement ou géographiquement).

Depuis le lancement de Outreach des tas de nouvelles barrières se sont ajoutées, et les rôles des petites équipes d'adminsitrateurs se sont renforcés avec aussi une grande marque très visible d'intolérance et une grande fermeture. Wikimedia a une bureaucratie centrale de plus en plus pesante (pire même que bon nombre de réseaux sociaux malgré leurs politiques restrictives et sans appel, mais qui sont obligés par la loi de respecter leurs utilisateurs et ne pas intervenir sur ce qui ne les regarde pas, à commencer par préserver la vie privée et surveilleur leur langage) et le monde entier le voit, et ses projets sont de plus en plus difficile à faire évoluer et même maintenir en place.

A cela s'ajoute un réel mépris vis à vis des utilisateurs qui font le plus d'effort et font le gros du travail, mais à qui on reproche des points mineurs en leur répondant par un language grossier ou les menaces, comme tu le fais en perdant ton calme. Si tu as des raisons d'être irrité, c'est pour des problèmes bien plus sérieux qui eux sont décrits dans des politiques communautaires (écrites et révisées par la communauté et non imposée de force par la bureaucratie en place pour lui faciliter le travail). Il n'y a rien dans ce que tu viens dire ici qui ne puisse être discuté de façon ouverte par les canaux normaux: demander aux utilisateurs de sortir du projet et utiliser des canaux privés, cela n'a rien non plus de collaboratif, c'est juste ajouter encore plus d'opacité aux prises de décisions. La règle de Wikimedia voudrait que tout se passe au grand jour et puisse être revu par le plus grand nombre, même en cas de désaccord (on ne peut jamais être d'accord avec tout le monde et tout contributeur un peu actif forcément irritera quelques individus sur des points de détail alors que rien ne les visait directement).

Verdy p (talk)14:42, 8 October 2019

Fin de discussion pour moi (puisque ce que je dis est de toute façon pris pour ce qu'il n'est pas et qu'il est impossible de te raisonner).

VIGNERON (talk)15:05, 8 October 2019

De me "raisonner" ? Comment le ferais-tu avec ce ton polémique ? Et il n'est pas question de raisonner, mais d'expliquer nos raisons ou nos désaccords sur certains points de vue.

Ce n'est pas le lieu ici (dans un échange un-à-un que personne d'autre ne peut suivre) de remettre en cause un terme adopté depuis des années (après mures réflexions et plusieurs hésitations), compris par plain de monde (sauf toi apparemment qui t'aperçois tout à coup des années après que le jargon technico-commercial anglophone que tu utilises est fort éloigné de l'objectif clairement affirmé du site depuis toujours). Je pense sincèrement que tu n'as pas compris du tout le but du site de sensibilisation, qui n'a jamais eu la volonté ni le but de développer une nouvelle "marque", mais bien de rassembler autour de lui sur un objectif élargi et compris par beaucoup plus de monde.

Si tu es convaincu que Outreach est bien pour toi pour l'usage technique dans ton petit monde, libre à toi. Ce site n'a aucune vocation à viser les personnels techniques anglophones les plus favorisés. Pour tous les autres, "Outreach" ne veut strictement rien dire du tout, c'est bien un jargon fermé et cela n'a jamais été une marque ou un nom propre (et d'ailleurs l'objet du site ne se limite pas à ce seul site qui n'est qu'un point d'échange et un des moyens de contact où on pourra trouver les pointeurs vers les autres espaces adéquats pour chaque communauté qui a vocation a pouvoir y participer).

Et si tu n'est toujours pas convaincu, je t'invite à consulter des mémoires de traduction officielles (même en jargon marketing, y compris universitaire ou politique) sur le sujet.

Par exemple : https://dictionnaire.reverso.net/anglais-francais/outreach

"Sensibilisation" est le terme le plus fréquent en français (à côté de "communication" qui est bien plus vague et qu'on ne peut employer sur wikimedia où il serait confondu avec l'équipe "ComCom" centrale de la Fondation qui justement ne s'occupe pas directement de la sensibilisation de proximité des utilisateurs mais défend ses intérêts propres), et sinon les expressions "de proximité" ou "sur le terrain". Tout travail dans ce domaine doit utiliser la langue de ceux à qui il s'adresse, c'est la base même de la technique décrite et de l'objectif clairement fixé.

Verdy p (talk)15:28, 8 October 2019
 
 
 
 
 

Messages du wiktionnaire identifiant les langues

Les codes gu kl lo pnb rn si ss connaissent des variantes, et il y a des écarts entre les noms choisis par le Wiktionnaire et ceux donnés par diverses normes. Mais comme ce sont des messages destinés à être utilisés par le Wiktionnaire, il ne faut pas que les noms de langues apparaissant dans ces messages soient différents de ceux utilisés par le Wiktionnaire. La « correction » appropriée est de changer les noms utilisés par le Wiktionnaire d'abord, et changer les noms dans les messages ensuite. Est-tu prêt à faire cet effort ?

Urhixidur (talk)02:29, 26 September 2019

Mais la doc indique le contraire : les messages que tu as annulés sont documentés ici sans AUCUNE référence au Wiktionnaire ! c'est au Wiktionnaire francophone de se corriger ensuite s'il veut autre chose. Ici on ne traduit pas pour un wiki particulier (même pas pour le Wiktionnaire, mais pour une extension MediaWiki utilisable sur divers wikis): je suis les normes internationales approuvées (ISO et surtout CLDR qui a fait déjà l'objet de revues par de nombreux experts linguistes)

Note : le Wiktionnaire francophone, s'il le veut, peut spécialiser ses messages dans sa propre base "Mediawiki:" en bloquant les réimports et créant un projet de suivi des ressources traduites localement de façon différente (à charge pour lui en,suite de suivre les évolutions du logiciel si les sources anglophones sont changées, sinon il risque une anomalie de rendu incorrect ou de nouvelles ambiguités. C'est la façon normale de procéder pour toutes les traductions de projets sur translatewiki.net, qui sont neutres pour tout utilisateur de MediaWiki (et pas qu'un seul wiki).

Il n'y a aucun moyen ici de suivre les "décisions" prises par quelques admins de chacun des wikis utilisant les traductions faites ici (il y en a des centaines conus et un nombre considérables inconnus à usage privé, tous leurs utilisateurs ne participent pas à tous les autres wikis), le seul moyen est de suivre au plus près les normes internationales en vigueur et tant pis pour les besoins d'un wiki particulier.

Les noms de langues sont compliqués à suivre pour qu'ils soient précis et non ambigus, il y a des tas de noms d'usage très ambigus utilisés pour des langues en fait différentes. CLDR et ISO tentent de résoudre ces ambiguités en collant au plus près de l'avis des linguistes experts (CLDR, Glottolog, LinguistList, ISO... Wikipédia est toujours classé en fin de liste des références car non stable et inhomogène, il sert juste à tenter de collecter des usages supplémentaires comme pistes possibles; c'est à Wikipédia et aux projets Wikimédia de suivre les normes, pas le contraire).

Verdy p (talk)02:31, 26 September 2019

« messages documentés ici sans AUCUNE référence au Wiktionnaire ». Sérieusement ? Ce sont des messages destinés aux wiktionnaires (cf. les noms des messages, par ex. MediaWiki:Project-localized-name-rnwiktionary), plus spécifiquement au wiktionnaire francophone (MediaWiki:Project-localized-name-rnwiktionary/fr). Ils ne seront vus nulle part ailleurs. C'est pour ça que je pense que ces messages doivent se plier aux normes du Wiktionnaire, non l'inverse.

Urhixidur (talk)12:46, 26 September 2019
 

Ils font références à différents wikis pour servir à lier différents wikis dans diverses langues. Ce ne sont pas des messages du Wiktionnaire ce sont des messages interwikis unifiés entre les différents wikis (et pas que les projets ouverts de Wikimédia)... Sérieusement, je sais lire: ce sont des ressources de Mediawiki pour tous les wikis basés sur Mediawiii, pas du Wiktionnaire lui-même, et d'autres wikis même francophones ont adopté les noms standards ISO ou CLDR qui ne dépendent pas du point de vue de quelques admins du seul Wiktionnaire francophone qui veulent imposer leur loi aux autres en changeant la norme sans même en référer avec eux. Le nom du Wiktionnaire francophone n'a pas besoin de ce message et concernant les noms des autres wikis, le Witkionnaire francophone peut bien utiliser ce qu'il veut pour lui (à la seule décision des admins du Wiktionnaire), il ne fait pas la loi sur les autres. D'autant qu'il ne peut pas ignorer non plus que les autres noms de langues ont vocation à être auissi dans le Wiktionnaire francophone, y compris avec ambiguité (alors que les éditions des wikis sont fondées sur les définitions de langues BCP47 issues de l'ISO 639, et de ses références ailleurs que Wikimedia seulement. Je crois que tu centres trop sur ce que tu crois voir, mais qui n'est même pas utilisé par le Wiktionnaire lui-même.

Verdy p (talk)13:24, 26 September 2019

Si je te comprends bien, un message comme Project-localized-name-rnwiktionary/fr, qui est le nom du Wiktionnaire roundi/rundi/kiroundi/kirundi en français, pourrait être utilisé ailleurs que sur le Wiktionnaire francophone ? Comme lorsque quelqu'un est sur un Wiktionnaire dans une autre langue que le français, qu'il voit un lien vers le Wiktionnaire susnommé, et qu'il a choisi que son interface soit en français ?

Urhixidur (talk)20:47, 26 September 2019

Justement c'est ça: c'est un des noms localisés parmi de nombreux wikis d'une même liste, cette liste est partagée entre tous les wikis quelque soit leur langue éditoriale, mais malgré tout traduite dans toutes les langues prises en charge dans leur interface utilisateur. Ces noms de wikis ne sont donc pas spécifiques au Wiktionnaire francophone, même si le Wiktionnaire francophone (dont le nom est traduit) est l'un des wikis cité dans diverses langues. La cohérence doit donc s'appuyer sur des normes de nommages internationales et pas les choix éditoriaux qui peuvent être contenus dans une version localisée spécifique d'un seul wiki. Cela n'empêche nullement le Wiktionnaire francophone ensuite de se choisir un nom éditorial à lui, s'il le veut, ou si ce nom (uniquement celui en français) a été enregistré comme marque protégée par la communauté Wikimédia et en accord avec les règles de copyright de la Fondation, ou directement protégée par la Fondation elle-même si elle convenu de prendre cela en charge ou parce que cela répond à ses propres choix stratégiques.

Verdy p (talk)23:02, 26 September 2019
 
 
 
 

[Mantis:Codev-dc93d6-Support, Doc, Training, Wiki,] [Mantis:Codev-053672-CodevTT support management] [Mantis:Codev-afd587-Support included] [Mantis:Codev-72127d-No Support] etc.

Puisque le domaine du projet Mantis:Codev est la gestion de projet, je pense que le mot "support" est utilisé dans le sens de « soutien » plus que dans celui de « prise en charge ». Dommage qu'il n'y ait rien dans les /qqq.

Urhixidur (talk)13:03, 8 October 2019

aucun moyen de savoir sans info de contexte. Mais le sens de prise en charge est le plus fréquent. Le terme "soutien" est pas vraiment mieux dans l'autre sens où je préfère le terme plus clair "assistance" plutôt que "base solide où est posé ou fixé un objet physique". Il y a aussi le sens de "parrainage"... Tous ces sens (sauf le support physique qui n'est évidemment pas inclus ici) sont possibles (de façon très inclusive) avec "prise en charge". On ne peut utiliser le mot "support" de façon claire qu'avec un complément (comme "équipe de support technique des utilisateurs"). On aimerait plus de précision, "support" tout seul étant vraiment trop vague hors contexte.

Verdy p (talk)13:58, 8 October 2019
 

J’ai remarqué sur https://translatewiki.net/w/i.php?title=MediaWiki:Prefixindex/fr&diff=next&oldid=2642494 que tu as remplacé l’ellipse (…) par trois points (...). Y a-t-il une raison technique ?

Urhixidur (talk)13:24, 8 October 2019

Xtools-support, -oppose, -neutral

Normalement ces messages de vote sont rendus par « Pour, Contre, Neutre ». Certes pas par « Soutien, S'opposer, Neutre ».

Urhixidur (talk)17:43, 7 October 2019

Je veux bien mais là je ne fais que la relecture et je n'ai pas le contexte complet des autres messages: c'était déjà les termes présents, avec une modif mineure ici sur l'apostrophe...

Verdy p (talk)18:01, 7 October 2019
 
First page
First page
Previous page
Previous page
Last page
Last page