User talk:Verdy p

From translatewiki.net
Jump to navigation Jump to search

Contents

Thread titleRepliesLast modified
Mantis:Codev-5c00df-Edit timetrack915:36, 10 October 2019
Espaces fines insécables entre les guillemets600:47, 10 October 2019
Outreach Wiki 1114:24, 9 October 2019
Messages du wiktionnaire identifiant les langues514:27, 8 October 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.114:19, 8 October 2019
L'ellipse013:24, 8 October 2019
Xtools-support, -oppose, -neutral118:01, 7 October 2019
MediaWiki:History-fieldset-title/fr : Filtrer les versions/révisions221:58, 13 September 2019
Qu'êtes-vous en train de faire ?313:40, 5 September 2019
Machine translation107:55, 5 September 2019
Szy601:30, 18 July 2019
Hausa in the United States1601:55, 16 July 2019
Please stop revert war822:02, 15 July 2019
Portal:Zh514:04, 31 January 2018
Chiffres et espaces insécables118:15, 13 November 2017
Thank you223:17, 6 September 2017
Feedback for new search translation features123:11, 17 July 2016
page initiale d'où est issue la phrase à traduire ?123:05, 17 July 2016
Traduction de MediaWiki : pluralité320:05, 10 May 2016
Changes to message's documentation722:04, 10 April 2016
First page
First page
Previous page
Previous page
Last page
Last page

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
 
 
 
 
 

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
 
 
 
 
 

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
 

MediaWiki:History-fieldset-title/fr : Filtrer les versions/révisions

Salut Verdy p,

Comme je l'avais indiqué dans l'historique, revision (en) = modification (c'est un faux-ami), mais MediaWiki:History-title/fr utilise "versions" plutôt que modification.

The RedBurn (talk)21:35, 12 September 2019

Ce n'est pas ce qui est utilisé partout, avant de modifier une chaine j'ai vu que pas mal d'autres utilisaient "révisions", ce qui correspond justement au processus de passage en revue qui est dans Mediawiki (ce n'est pas toujours clair dans Mediawiki si cela signifie "edit"/modifier donc modification, ou "review"/"passer en revue" donc révision (à laquelle on répond par une approbation, une annulation, ou une annulation partielle avec modification. Selon les wikis en fait seules les "révisions" sont visibles dans l'historique, pas les modifs (quand elles sont en attente d'approbation). De là à parler de "faux-amis", je pense que c'est plutôt une ambiguïté et que la terminologoe n'est pas non plus en homogène et claire en anglais, comment pourrait-elle l'être en français ? En fait le contexte joue beaucoup (mais pas indiqué dans les traductions partielles, car le module "MediaWiki" est malheureusement beaucoup trop gros (avec déjà plus de 3000 chaines à traduire pour le seul module "core": Mediawiki est difficile à traduire et maintenir car pas assez modularisé). Un bon module de traduction ne devrait pas dépasser les 300 chaines (c'est le cas pour la plupart des modules d'extension, sauf un ou deux qui eux aussi peuvent être démencemment gros, ce qui ne facilite pas du tout l'homogénéité)

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

Dans ce cas-ci, c'est ce qui est affiché au dessus de l'historique d'une page, par exemple https://translatewiki.net/w/i.php?title=MediaWiki:History-title/fr&action=history

"versions" permet de combiner "révisions" et "modifications" donc je trouve cette traduction (dont je ne connais par l'auteur) pas mal pour cet usage.

The RedBurn (talk)21:58, 13 September 2019
 
 

Qu'êtes-vous en train de faire ?

Je reçois à l'instant une 30aine de notifications de modifications réalisées en à peine 2-3 minutes, il y a trois heures, sur des traductions d'iNaturalist auxquelles j'ai participées. Toutes (sondage sur un tiers) émanent de votre part (vous en êtes ientifié comme l'auteurà, en moins de 5 min, et sont toutes des non-modifications !? Êtes-vous effectivement l'auteur de ces actions, ou bien votre compte a-t-il été piraté par un robot ? Ou bien avez-vous (tenté de ) dresser un 'bot mais qui vous a échappé ? Bien curieux en tout cas. --Eric.LEWIN (talk) 23:11, 4 September 2019 (UTC)

Eric.LEWIN (talk)23:11, 4 September 2019

Aucun bot ! Je fais de la relecture, certaines sont de simples espaces fines insécables, toutes mises manuellement, d'autres sont des fautes de français, des traductions de marques comem si c'était des noms communs... Il est possible que ces notifs t'arrivent groupées parce que le site les envoie par mail ou autre de façon groupées, mais les horodatages des modifs devraient indiquer clairement que ce n'est pas du tout "automatisé" comme tu le croies. Note: je fais tous ça avec l'interface web standard de traduction, avec ses formulaires. Et pas du tout au hasard non plus: je valide plein de choses telles quelles, je corrige certaines, certaines corrections sont mineures (juste typographiques, parfois des fautes d'accord ou des majuscules, parfois des lettres oubliées: je relis réellement).

Verdy p (talk)23:15, 4 September 2019

Très bien, merci pour l'éclaircissement ; je pense que j'étais bien en droit de m'inquiéter de ce si soudain afflux de notifications issus d'une même source, TranslateWiki, initiées par un même utilisateur, vous-même. Affaire close.

Tout de même, en tant que co-membre traducteur, merci pour les corrections, notamment les '  ' (&nbsp;) par rapport aux ' ' (&#32;) que le présent éditeur web ne semble pas vouloir prendre en compte dans ma configuration, je viens de le tester à l'instant. Et merci pour les autres coquilles que j'aurais pu laisser. Kore

Eric.LEWIN (talk)09:37, 5 September 2019

ce ne sont pas des NBSP (U+00A0) mais des fines insécables (NNBSP U+202F)...

Verdy p (talk)13:40, 5 September 2019
 
 
 

Machine translation

I see you apparently add machine translations to pages like Template:Disabled language. I think it'd better not to do that. To my understanding translators are expected to have sufficient language skills here, translations are expected to be correct and read natural in target languages. Even if used only locally on translatewiki.net, such texts shed poor light on the rest of the content as well.

Pikne12:58, 31 July 2019

Machine translations? I edit everything manually. I added some translations because someone requested it and found that the English message was not enough (he argued that the message was only seen in English, and this was wrong). Even if the message does not look the best you can still fix it, this has no impact on the supported translations in this wiki this is just a generic informative message. And it's still better than showing an English message to people that don't understand it correctly and complain now about the fact that their language is disabled without seeing the provided link, even if these languages were really disabled: the link in the message goes to a page explaining what can be done.

Even an approximate translation if better than the English message alone: it is easier to fix correctly, notably in a template which may otherwise be edited incorrectly with incorrect syntax: the syntax is already there.


Note quand même que 30 modifs en 5 minutes ce n'est pas du tout énorme lors d'une relecture, ça fait une dizaine de secondes par message, sachant qu'ils sont pour la plupart très courts. Les "non-modifs" sont sans doute des modifs que tu ne vois pas comme le changement d'une espace en espace fine insécable (et ça prend une ou deux seconde à faire dans l'éditeur avec un copier-coller). On est très loin des performances d'un "bot" qui peut aller beaucoup plus vite.

Si tu as trop de notifications, c'est à toi de régler le problème dans tes propres paramètres de suivi auxquels tu as souscrit toi-même, ou de gérer des filtres de classement du courriel dans ton outil de messagerie. C'est tout à fait normal dans ce cas de recevoir ces notifications, j'en reçois également beaucoup, j'en relis quelques-unes mais si elles sont similaires et du même auteur, je passe très vite dessus.

Tu peux aussi purger ta liste de suivi

Mais note que ce wiki a toujours un bogue quand la liste de suivi contient quelques milliers de pages, on ne peut plus la modifier avec l'éditeur standard des préférences (ce wiki manque de performance et affiche une erreur pour temps dépassé à formater la page, on doit utiliser l'édition de la liste en mode "raw", et on se prend encore même dans ce cas des erreurs lors de l'envoi de la liste brute modifiée/triée dans un éditeur externes, et il faut souvent renvoyer la liste plusieurs fois pour qu'elle passe (si elle contient encore quelques milliers de pages) : une erreur peut s'afficher encore si on soumet à nouveau, mais si on recharge l'éditeur de liste de suivi en mode brut on voit que la liste modifiée a pourtant bien été enregistrée.
C'est un vieux bogue, une limite de Mediawiki qui ne sait toujours pas gérer comme il faudrait les listes de suivi en proposant une fonction de recherche et de tri efficace sur des extraits de la liste de suivi sélectionnés par critère ou en mode paginé (comme les catégories avec 200 entrées par page). Même la fonction de purge totale de la liste de suivi ne fonctionne pas du tout et affiche une erreur (elle ne purge alors rien du tout)...
Donc pour l'instant pas d'autre moyen que d'utiliser l'éditeur de suivi en mode brut (avec un formulaire affichant une ligne par nom complet de page suivie et incluant toutes les pages dans tous les espaces de noms, sans aucun tri).
Je ne peux rien faire ici contre ce problème, il faut demander sur Phabricator aux auteurs MediaWiki de régler ça.
Verdy p (talk)14:14, 31 July 2019
 

I assume this is just because no one has stepped up to be a translator in that language?

dcljr (talk)07:51, 16 July 2019

Someone started to create a page for it, I just categorized it, but that user did not complete the request to open it. I checked that language in the translation tool, it was not available so I marked it explicitly as disabled (for now), until there's some translator requesting it. The warning at top of the page (now correctly setup) can be removed once there are candidates to do that job. Note: Translatewiki.net does not require that the language is enabled in Wikimedia (with at least an incubator), because Translatewiki.net supports various other projects (not all made or supported by Wikimedia). This means that the Mediawki UI also does not require to be translated, if the translation is started for a project not using MediaWiki (e.g. someone requests it for adding translations in FreeCol). But anyway the essential core messages of Mediawiki should be translated to request the addition of an Incubator, in order to test the language correctly with an actual working UI. This requires about 700 messages and can normally be done in a few hours. Candidates for the addition of a new language should be consistant in their request, and it's esier if they find a least a second contributor to review their work and cooperate. And probably Translatewiki.net admins will require these two separate contributors. There's a support page on this wiki to ask for such additions: I do not decide for the support of any language on this wiki. By adding the warning on the page, this includes a link in the message to a page describing what to do to enable a new language. I just checked the provided language name (with the link to the Wikipedia article about it), I checked that the language code was correct and then made some cleanup and basic arrangement to show the actual state of that language. "Sakizaya" is a Formosan language spoken by a minority in Taiwan (I'm not even sure it currently uses the Latin script as it was indicated). There are a couple of others minority languages in Taiwan that ARE enabled.

Verdy p (talk)17:05, 16 July 2019

Hmm. OK, well, the "someone" who started the page was me, in response to m:Requests for new languages/Wikipedia Sakizaya#January 2019 update. I know nothing personally about the language itself; I just figured creating the Portal page would be helpful. (Note that d:Q718269 claims the Latin script is used, and the current contents of incubator:Wp/szy would seem to support this.)

It looks like the translation efforts currently going on under the "ais" code needs to be moved to happen under the new "szy" code. To this end, I have created Thread:Support/Sakizaya.

See also (if you haven't already) Template talk:Disabled language#Confusing, where I complain about ambiguity in the (English) message of that template. [grin]

dcljr (talk)01:23, 17 July 2019

If you intend to open that language, you should visit the link provided which explains what to do: and this means contacting the site support as instructed on that page (that I did not write: this is the procedure that site admins expect to be followed). It's not me that you must contact (I cannot unlock the language for you), I just helped in cleaning up/categorizing the site and adding the relevant links, to accelerate the process and reduce the site maintenance that admins don't have the time to do completely themselves.

Verdy p (talk)05:11, 17 July 2019

I appreciate the information you have given here, but as I said above, I do not know the language, so I would not be the one asking to "open" it for translation. My followup message was merely to give you additional context and information about things you alluded to in your reply, not a request for assistance from you.

dcljr (talk)22:29, 17 July 2019
Edited by author.
Last edit: 01:30, 18 July 2019

Note that you were the first to "allude" something directly in your first message saying "I assume this is... ?". Then I said "someone" beause I did no tremember who had created the page I had fixed to explicit the fact that it is still not enabled. I've not alluded anything about you when I said "someone", until you told that this was you that created that pager and why.

And to be clear: that's me that you contacted first for this topic before you got to the Support page that I instructed you to visit and where now you have sent a new request (so implicitly you thought that I could provide such support and I told you that I could not do that).

But as you also affirm you don't know that language, I think you still cannot request such addition. So let's wait for an actual translator requesting it. For now your initial page had no value, and you must know that creating a portal page does not mean that it automatically creates the support for that language: the banner is then useful and accurate because it explains clearly what must then be done to enable it. And if you don't know that language, how can you affirm that another existing translation effort made on another language code is incorrect? May be the English name used for that language code is incorrect (too broad): this happens sometimes with macrolanguages, where one major variant has its name commonly used for the whole macrolanguage (wellknown cases: "Chinese" which is a macrolanguage but whose code is used actually for one Sinitic language, Mandarin which is part of the macrolanguage, and not for other parts like Yue/Cantonese, Wu, or Min Nan)

Verdy p (talk)22:40, 17 July 2019
 
 
 
 
 

Hausa in the United States

There is not a "large" native population of Hausa speakers in the United States. Stop adding that.

Koavf (d) (en-N/en-US, es-2/es-US, de-1, pt-1)07:18, 15 July 2019

"Languages of" includes languages that have an officially recognized status of minority language.

Even English Wikipedia agrees (and there are sources on it).

Hausa is an important Lingua Franca in Africa, and this has spread in US too.

Note that this does not mean a national/federal recognition, but several states have made such recognition (and please don't forget that US has no "de jure" official language, English is just used de facto, like also now Spanish, and French historically.

Verdy p (talk)07:22, 15 July 2019

"several states have made such recognition"

Source?

Koavf (d) (en-N/en-US, es-2/es-US, de-1, pt-1)07:23, 15 July 2019
 

And why are you breaking what I am trying to build: an exhaustive classification of all the languages we support here. There was nothing on this wiki about that before. Of course the classification is still incomplete, but I've done all according to the consensus that already exists in EN.Wikipedia (and its reference sources) and in laws. If you dispute these facts, then make your dispute in EN.Wikipedia to challenge its consensus. For Hausa, the info comes directly from the EN.WP article wikipedia:Hausa language.

Verdy p (talk)07:24, 15 July 2019

And that was unsourced, so I have removed it. What you are building is nonsense.

Koavf (d) (en-N/en-US, es-2/es-US, de-1, pt-1)19:15, 15 July 2019

Why don't you go to EN.WP to contest these assertions ? Establish the consensus there, it will be more acceptable than trying to define it here, where the community is much smaller. I just use the most prevalent and significant consensus. If you succeed in WP.EN (and get consensus there), then no problem to remove it here. Note that my inclusion did NOT include any criteria of "large". This category just establishes a link for an attested usage (which really exists, with many Afro-Americans with Chadic origins, even in countries that are dominantly English-speaking like Nigeria, and with American descendants of these countries that want to restore the right to use their origin language in US, as a significant part of their culture). So what I did really makes sense (just like for Amerindian languages, which may still not have "official" status but are locally recognized, and where these languages are obviously languages of the US and almost nowhere else: think about Cherokee or Navajo for example: where would you expect to find them if not as "languages of the US").

Note: if ever your recent edit in EN.WP is reverted (you made them after this talk), and EN.WP disagrees with your edits, the link will have to be restored on this wiki. Note that even Google makes pages in Hausa for users in US, because it is significant enough. This wiki accepts languages spoken by lots of minorities and intends to support these languages accurately to allow their development in wikis and applications delivered in countries where these languages are still minorities. This wiki and Wikimedia respect these minorities, wherever they live and where they have a significant organization. Some of these languages are spoken only by a few thousands people, but Hausa speakers in US are largely over this threshold (and their number is growing: they already outweight the speakers of almost all Amerindian languages). The same is true for Russian, Hindi, Arabic, Pashto, Japanese, Vietnamese, Thai, Portuguese, and Chinese in US, with lots of publications, and even public advertizing and public displays in these languages, and with various public programs to support their development in local communities, and job positions in public offices (including the US Army) offered for American speakers of these "important" languages.

Note that I did not add them as "Official" languages (whose category for US strictly includes de jure no languages at federal level, not even English, but contains languages that have official or majority de facto status in at least one state, and so includes English, Spanish and French (which are used in the formal legislation founding the US federation in in the constitution of several states or organized dependencies); and I wonder if it should not include Alemanic for the Amish community, and a few Amerindian languages like Cree, Navajo, Cherokee, or some Siouan languages, for the officially existing Amerindian reserves and territories, and Hawaiian of course.)

Note that for languages that are official only in some parts of the US, we can include them as "languages of the US", but can have subcategories in US where they are "official". There are already some categories for some parts of several countries (including dependencies, or non-internationally recognized countries territories like Taiwan). We already have now a full list of the 192 UN members (all other subnational or supranational regions are separated).

Verdy p (talk)20:41, 15 July 2019

Easily over a hundred languages are spoken in the United States: no one would characterize them as being languages of the United States, since they did not originate here, have no legal status, and only a small percentage of the population speak them. I'm sure that *someone* speaks Greek in Russia: is Greek a "language of Russia"?

I see no value in creating Category:Official languages of North Dakota: this project doesn't need anything as granular as that. Saying that Nakota is an official language of the United States is sufficient.

You've also created sheer nonsense like Category:Official languages of Antarctica. Please get some consensus for all of these changes.

Koavf (d) (en-N/en-US, es-2/es-US, de-1, pt-1)21:31, 15 July 2019

Antarctica is there for completeness (but as a special territory) because of ISO 3166-1 (and links using it) but its official languages exist: these are the 4 official languages of the international treaty. Beside that, there's no "local" language listed, only these 4 "official" ones. You may think it is not needed, but as I progress in sorting languages and making various link wort correctly, those early categories get progressively populated and get more significant with what we can discover as already being used or needed. I don't want to leave read links or create too many exceptions in the generic templates that can be used to populate them (these exceptions create additional maintenance costs, I want to reduce that cost to the minimum so that most things can be infered and automated accurately, without creating new errors or miscategorizations).

I've not "changed" things like what you state, all this are created by me directly (including the category for US that now you want to challenge, and that I never "changed" from another user contribution, it did not exist before me).

So only you for now is attempting to do "changes" from what I created, and you did not try to get any consensus at least with me before. But these categories were welcome by many users (and even approved by other admins on this wiki).

But Hawaii and Alaska could have their own category (even if they are integrated states), just like Puerto Rico and other organized territories (because of their specific local legislation which have various exceptions to the US federal laws).

Verdy p (talk)21:54, 15 July 2019
 
 
 
 
 

Please stop revert war

Edited by author.
Last edit: 07:55, 15 July 2019

Please stop reverting MediaWiki:Mwe-upwiz-license-cc-zero/qqq. I tried the things you suggested in there and they do not work. It is not acceptable to suggest translators do things which do not work.

So, please please remove suggestions now and file a task in Phabricator or request in Support to make it possible to use localised urls in these messages in a way that works and is supported.

Nike (talk)14:53, 12 February 2018
Edited by author.
Last edit: 16:32, 12 February 2018

I've said already that the simple replacement (i.e. deletion) of "$2" to translate these was NOT working: you can type a translation like this, it is recorded but immediately marked as "FUZZY" meaning that what you do has the same effect as deleting a translation completely.

The top banner indicates we want to have these translations including adapting the URL. So that's what you want to, but your way does not work at all and will never work.

But "$2" has to be kept somewhere (at least in a comment or otherwise made visible): the translate tool ensures that all original placeholders are present, and if any one is missing, the translation is marked as incomplete/fuzzy and not used at all: the effect is that people will effectively see the untranslated English text as a fallback.

Since the begining this is what I want to avoid. For now what you do is exactly the same has saying that these resources are completely untranslatable and will remain in English for all !

Please suggest something that allows NOT including "$2" without marking the transaltion as "fuzzy" because it is missing : this does not exist for now in the translate tool to mark a variable placeholder as "optional", or explicitly replaced by another content than what is defined in the "var": for now the only existing way is to place the $2 in comments or make it visible.

I don't know why the Upload wizard complains about the presence of HTML comments in resources, when everything else in MediaWiki works like this. May be if HTML comments does not work, the wizard will accept "" with an empty string result, but I doubt it will work if the Upload Wizard in facts performs its own parsing of the resource and expects a format that the Translation tool is currently unable to deliver anywhere.

So yes I suggest fixing the UploadWizard code so that it will parse the wikicode or standard HTML correctly and will not buildup some incoherent presentation of what it contains.

Note that I have not "reverted" things, but documented what was working and what was not, in order to explain (and demonstrate to you) that your attempt was failing all the time.

Initially I placed the HTML comment just after the "[" before the URL, someone said it was parsed by the UploadWizard incorrectly, then I tried to place the $2 AFTER the link (completely outside of it). Waht the UploadWizard does is some internal tricky magic transform, but you've not proposed anything that allows the Translate tool to accept any one of the translations you submitted: in all cases we saw "incomplete translation" statistitics, and many users have tried something; only what I propose is for now aceptable for the translate tool.

We absolutely need a solution to fix either (or both):

  • The UploadWizard (so that it correctly handles the HTML or wiki content and does not reencode it in a non-standard custom way);
  • The translation tool (to mark a variable placeholder where a translation wants to explicitly replace its content without marking the translation as "fuzzy" because it is missing);

otherwise we will never see the correct translations expected (not even yours !).


Note that for URLs to Commons licences all the replacement URLs have the property of sharing the same prefix (and it is the content of $2) but we cannot "glue" "deed.fr" just after $2 because of the current supported syntax of placeholders; if we use "$2deed.fr" the Translation tool will think we want to use a non-existing variable named "2deed" (so the transaltions will be also marked as "fuzzy" and the translation package will remain "incomplete", not 100% translated) :

This is also a defect of the Translation tool which offers no clean way to indicate explicitly where a "$variable-name" is terminated in the translated resource. I think it should support "${2}deed.fr" here (like in Bash command files where this extended syntax is used for that purpose to avoid the tricky escaping) or more generally ${variable-name}, or the alternative syntaxe "%2%" (like in DOS/Windows command files) which is probably simpler to type (the set of characters allowed in variable names between the "%"-pair should be only letters, digits, or some only punctuations: underscore, hyphen, colon, excluding controls and whitespaces, semicolons, commas, full stops, percent, question marks, exclamation marks, single and double quotation marks, and probably others, otherwise there will be "false positive" detection of dummy variables in translated items).

My preference would be the syntax using paired punctuations with ${variable name}, but other suggestions are possible: $<variable name> or $[variable name] or $(variable name) or $"variable name" or $'variable name' (this solution is more liberal on the set of characters we accept in variable names used in translatables source).

Verdy p (talk)15:59, 12 February 2018

Placing a html comment anywhere in the string does not work. That is worse than having the link point to the English version (which has a language selector).

If you want to deviate from the excepted translation (link pointing to the English), you must file a bug or support requests. Suggesting hacks that do not work is not acceptable.

We also export fuzzy translations, so your assumption that fuzzy translations are not exported is not correct.

As a site admin, it is my duty to ensure our translators get good advice, it's not my duty to fix i18n issues in the products.

I'll try to make this very clear: altering the message documentation or translations to work around i18n issue is NOT OKAY. The proper process is to report i18n issues to the developers so that they can make a proper solution.

Nike (talk)16:31, 12 February 2018

"fuzzy" translations will be edited all the time by any translator. You should not use them as a trick in the Upload Wizard. It is really a bad solution which will constantly drive translators to try fixing them.

So what you're saying to translators is to use a trick to insert fuzzy translations that won't be checked at all. No one on TranslateWiki (except you) expect these "fuzzy" strings to be effectively correct. But as you manage this wiki, you should be interested in fixing the hosted Translation tool to support more explicit variable name termination, or marking a required variable as "used" with an empty replacement value which will be absent from the export (but only if the project to translate accepts such absence by explicitly marking a placeholder as optional: this is not the case for many projects that expect ALL placeholders to be present, notably placeholders for C/C++ format strings, an absence of the placeholder causing severe software bugs such as null pointer exceptions, or using integer values in other placeholders as if they were pointer values, causing security breaches such as making local variables hidden on the application stack to become visible).

Please fix the Upload Wizard (it should not use any fuzzy translation at all). Only this Wizard does not follow the MediaWiki wellknown practices and uses custom parsing deviating from recommendations. HTML comments are not "tricks" they are part of the Wiki standard since ever ! but using "fuzzy" translations IS A REAL TRICK which should never happen with TranslateWiki (which should even better not export them at all, they are fuzzy for various reasons, including incorrect syntax, missing required placeholders, unmatched paired punctuation, incorrect encoding,... !)

And the proper way to report i18n issues to developers is via the editable /qqq documentation that they will get from TranslateWiki exports along with translated items for all languages ! This is used in many projects to report cases where there should be plural forms, or genitive forms, or gender variants. Other ways to report these issues are nearly impossible to find in the interface and varies from project to project (there's no standard way to indicate where to submit these issues).

Verdy p (talk)16:37, 12 February 2018
Edited by author.
Last edit: 15:36, 9 July 2019

The real truth is that the new UploadWizard is incorrectly parsinf the "[$2 legal text]" which is supposed to be an external link in the Mediawiki syntax, as if it was a wikilink (normally with the syntax "legal text") and then uses the first parameter of the link (the URL "//creativecommons.org/licenses/.../") by prepending it directly to the base URL of the wiki pages). It is already broken including in English as the final URL (in the generated HTML) is also invalid as it gives (for example on Common) the following HTML code:

  <a href="https://commons.wiki.org/wiki///creativecommons.org/licenses/.../">

For doing this, it makes a special simplified parsing of the translated item. Then it checks the "weakly parsed URL": if it starts by "//" or "http://" or "https://", it won't prepend the base URL of the wiki, but will use that URL directly as is (once again without looking if there are HTML comments or even if in fact its syntax is invalid); if the "weakly parsed URL" starts by anything else, it assumes this is a a FULLPAGENAME, and so it will prepend the wiki's base URL for articles.

Only then it will start converting this broken code using MediaWiki parser to generate the HTML and finally the link.

So the presence of "" at start of the url using the syntax "[url text]" effectively does not work (this was the initial report, concerning ONLY the new broken UploaWizard deployed on Commons, but not the previous one on all other wikis), but the suggestion to put it outseide the link really works: my suggestion was correct, it fixes it and is compatible with BOTH the legacy UploadWizard and the new one (even if the later is still using a severely broken code), and it does not require any fuzzy translations (that are NOT used at all, I can confirm it, they are replaced by the original untranslated English text!)

The only working translations are those using "[$2 some-translated-text]" (e.g. the translation in Chinese) **without** following the indication to localize the URL (this inidcation was not added by me it was a desire to localize it given by the UploadWizard authors themselves (and of course the origional "[$2 untranslated-English-text]". So Chinese does not follow the top indication given to translators in a bold red text at top, and does not attempt to localize the URL at all.

The bug is not in translations, but in the new UploadWizard implementation (as used on commons but not all wikis which still use the former non-broken UploadWizard), it exists independantly of my suggestions or even if one uses the "fuzzy" translations that have removed "$2" and placed another URL there (in which case the fuzzy translation is NOT used at all by former implementations of the UploadWizard in all other wikis).

The bug is really in that new version of the Wizard, not working at all on Commons, whatever we put or don't put in these translations (the new version works ONLY in English where localisation of the URL is not used, even if it could be there to point to the "deed.en" version instead of using the automatic langague selector in CreativeCommons, which may display another language than English, depending on language settings of the webbrowser used to navigate, which may not be always the user's prefered language if the local webbrowser settings cannot be changed by that user, or may not be implemetned at all on some devices not transmitting any "user language" preferences to the web server, or because these browser settings are cleared by privacy tools installed on the same device as the webbrowser).

My suggestion to put the dummy placeholder "" completely outside the link is correct (yes I tested it, others that pretend it does not work have in fact NOT tested it), and fixes the issue, even before the new broken UploadWizard (insufficiently tested) is fixed and it works with legacy implementations of the wizard on other wikis (i.e. most Wikipedias that allow importing images locally instead of on Commons, and almost all non-Wikimedia wikis).

My suggestion is not a hack as you think, it avoids having to use any fuzzy transaltions that are normally rejected everywhere in MediaWiki (replaced by non-fuzzy fallbacks or the untranslated text).

But yes a better solution would be to be able to instruct the "TranslateLinter" used on this wiki to mark the placeholders that are optional, or that can be safely repeated (i.e. instruct if a variable has 0-n occurences allowed, instead of just 1 by default), or that can be safely reordered (most placeholders in C/C++ such as "%s" or "%d" are not reorderable), or that can be modified (e.g. formatting options in C/C++, e.g. for formatting dates or for currency amounts with a different number of decimals: this kind of linting is complex to instruct, and shoudl not be the first pritority you'll want to work on). With just the "occurences number" linting instruction saying that 0 occurences is allowed, the linter will accept the absence of a placeholder in the translation, and will then not mark it as fuzzy.

Summary: fuzzy translations are ALWAYS undesirable they ALWAYS need to be fixed on this site; but saying to project maintainer to still use them will cause much troubles and much more severe bugs in applications, so your suggestion is a real HACK.

Verdy p (talk)19:03, 12 February 2018

There is way to have Translate not mark translations with unused variables as not fuzzy if this is reported . There is also a possibility that this issue will be fixed in UploadWizard if it is reported to the developers in Phabricator.

Again, it's not my duty to fix UploadWizard.

Again, qqq is not the way to communicate with developers. That's what the "Ask question" button is for. It will leave a message in this wiki, which can then be relayed to Phabricator, if necessary.

But all my time goes into trying to make you understand this. I am going to revert the changes to the message documentation since you did not do it. I will block you if you will try to add them back again.

Nike (talk)08:48, 13 February 2018
 
 
 
 
 

Please, do not add links to /zh, that's disabled here.

Liuxinyu970226 (talk)04:14, 31 January 2018

Also, your currently edits result some unexpected problems, e.g. in Portal:Ug, it resulted links like https://translatewiki.net/w/i.php?title=Special:Translate&language=Ug-Latn and https://translatewiki.net/w/i.php?title=Special:Translate&language=Ug-Cyrl, where the "U", "L" and "C" are capitalised, but the actual URL (https://translatewiki.net/w/i.php?title=Special:Translate&language=ug-latn ) require all lower cases.

Liuxinyu970226 (talk)04:20, 31 January 2018
 

And suddenly, this is another unexpected issue that I've found, after those changes, in Kazakh portal page, the links after "Cyrl" and "Latn" appear, but links after "Arab" (https://translatewiki.net/w/i.php?title=Special:Translate&language=kk-arab and https://translatewiki.net/w/i.php?title=Special:Recentchanges&trailer=%2Fkk-arab&translations=only), which is the first ISO 15924 value, are missing.

Liuxinyu970226 (talk)09:26, 31 January 2018

Now use "15924-1=" instead of "15924=" when the default ISO 15924 script is not implied and the language code must be suffixed by a script code or variant code.

This solves the 3 cases: Kazakh ("kk" disabled need "kk-cyrl"), Uighur ("ug" disabled need "ug-arab"), and Chinese ("zh" disabled need "zh-hans").

If translations can still be done one unsuffixed language code (in its default script), AND on suffixed language code, use

  • "|15924=Scr0" for the default implied script (ambiguous/mixed),
  • "|15924-2=Scr1" for the *first* script
  • "|15924-3=Scr2" for the second script

But normally we should have only:

  • "|15924-1=Scr1" for the *first* script
  • "|15924-2=Scr2" for the *second* script

Variants are not impacted.

I documented this case in the template to make it more flexible

Verdy p (talk)10:56, 31 January 2018
 

"zh" is now disabled by assigning it the default script code "|15924-1=Hans" instead of "|15924=Hans" (before it was even "|15924=Hani" but it is disabled too, this script variant is not recognized).

Using "|15924-1=*" enforces the use of a script code suffix even for this default script.

Verdy p (talk)14:04, 31 January 2018
 

Chiffres et espaces insécables

Salut !

Les conventions typographiques de Wikipédia citent à juste titre le Lexique des règles typographiques en usage à l’imprimerie nationale : « Un nombre en chiffres arabes ou romains ne sera jamais séparé du nom qui le précède ou qui le suit. »

Il n’était donc pas nécessaire de la supprimer comme tu l’as fait.

Bonne continuation !

Pols12 (talk)16:53, 13 November 2017

si c'est un numéral, l'espace insécable n'est justifiée que devant une abréviation ou un symbole d'unité, pas pour un nom ou groupe nominal accordé de façon régulière comme un mot.

Dans "Les 12 hommes" il n'y a aucune espace insécable, pas plus que dans "12 octets" ni dans "65 millions d'habitants" ni après les derniers chiffres de "65 000 000 habitants" où seuls les groupes de chiffres sont séparés par des fines insécables. L'espace insécable (toujours fine entre les groupes de chiffres, ou avant une abréviation ou un symbole d'unité **invariable**) n'est donc pas justifié du tout ici.

Cas particulier: uniquement les romains quand ils sont un ordinal après un nom sont insécable du nom qui le suit (cet espace n'est pas une fine) : "Article<NBSP>Ier", "chapitre II", "Elisabeth<NBSP>II", mais sinon en tant que numéral non ordinal les romains sont sécables comme des déterminants ("un livre" ou "1 livre"). Cependant une règle de style *contextuelle* évite de laisser orphelins le nombre et le nom seulement s'il y a un ou deux chiffres, donc "12<NBSP>francs" mais "123<SPACE>francs" et "12<FINE>000<SPACE>francs".

- <SPACE> c'est une espace sécable justifiable normale (le séparateur de mots, d'au moins un quart de cadratin) - <NBSP> c'est une espace insécable justifiable normale (d'au moins un quart de cadratin mais souvent plus avec des polices "larges" et un demi-cadratin comme les chiffres/lettres en police à chasse fixe : sa largeur suit celle des autres espaces sécables) - <FINE> c'est une espace insécable non justifiable fine (d'au plus 1/5 de cadratin, souvent 1/6, parfois 1/8 avec des polices étroites); cette espace ne se justifie normalement pas, sauf dans des présentations à colonnes de texte très étroites si les autres espaces justifiables sont étendus au delà de 1 cadratin... et seulement après avoir joué sur l'interlettrage (l'approche) entre tous les caractères (lettres, chiffres, ponctuations, espaces) sauf entre caractères liés sans interlettrage qui doivent rester collés et qu'on le peut pas lier non plus par un trait de jonction cursive qui peut être allongé de la même façon que l'interlettrage): la fine respecte la proportionnalité dans ce cas, mais l'interlettrage dynamique est compliqué à mettre en oeuvre pour la justification totale des paragraphes entre les deux marges.

Sans interlettrage dynamique pour la justification totale, la <FINE> a une chasse fixe (contrairement à <SPACE> qui lui absorbera tout pour aller jusqu'au cadratin avant de combler le reste de façon équitable entre tous les caractères y compris <SPACE>, <NBSP> et <FINE>)

Attention donc au contexte d'utilisation: le wiki n'est pas un cas d'utilisation en colonnes de textes étroites. Mais même dans ce cas (exemple : utilisation dans des colonnes de tableaux, l'espace entre "12 octets" en toutes lettres sera bien sécable, contrairement à "12<FINE>o", ou "12<FINE>€").

Ce que dicte réellement l'imprimerie nationale dépend du contexte: l'impression des textes de loi (très verbeux), impose de gagner de la place pour la version journal, et "12<SPACE>octets" sera sécable de la même façon que "12<SPACE>septembre" où le nombre est pourtant un ordinal (adjectif d'un nom "jour" sous-entendu) et non un déterminant cardinal du nom "septembre". La mise en page dicte pas mal de chose mais sur le wiki elle est imprévisible et on doit prévoir le pire: il n'est pas justifié d'empêcher la coupure de ligne entre le numéral cardinal utilisé comme déterminant. Et même pour éviter les cas de nombres "orphelins" séparés du nom à la ligne suivante ce n'est pas le codage qui jouera mais un paramètre de style fixant la largeur minimale qu'on peut laisser orpheline: cette largeur minimale s'applique aussi sur le dernier mot de fin de ligne, mais "bonnet de nuit" peut tout à fait être coupé sur chacun des deux espaces avant et après "de"; et dans "[...] Il cria : de l'eau ! [...]" on peut tout à fait couper avant ou après "de". Les règles de style évitent de couper les phrases si possible pour n'en laisser qu'un seul mot court (moins d'un cadratin) séparé, mais là encore il n'y a pas de différence de codage entre les espaces séparateurs de mots selon la position dans les phrases: c'est le moteur de rendu qui déterminera les espaces les plus appropriés à couper mais il n'y a aucune espace interdite à priori (donc pas besoin de marquer comme insécable).

Dans "12<FINE>o", ou "12<FINE>€" on a une une unité abrégée ou symbolique: là c'est bon de prendre une fine insécable (non ce n'est pas un <NBSP> !) De même les espaces devant ou derrière certaines ponctuations («»:!?) sont des <FINE>.

Verdy p (talk)18:15, 13 November 2017
 
a piece of the cheese

Hoi, I blogged about the great work you did for Mifos. It is really important and appreciated.. Please continue.. Thanks,

GerardM22:42, 21 October 2010

I'd like to echo Gerard's comment. Thank you! I'm sorry we aren't part of the translation rally.

Meonkeys23:03, 21 October 2010
 

Actually, as opposed in what you assumed, I was not competing at all for the WM translation rally at that time. Such competition looks a bit stupid for me, I don't care about getting a rank, my interest will go where I think my help could be useful and appreciated.

This was the case for this one because at that time the project was starting and very few WM users were interested in it, exactly because they were just competing for the WM rally, not me, and many of these new rallied translations were in fact poor and required many corrections later after review, to be coherent in terminology or to solve bugs and ambiguities or even for correcting lot of basic orthographic or grammatical errors, or worse complete misunderstanding or generated pages that are completely unreadable/unmeaningful after such speedy translation process: in such rally the transaltors translate as muc has they can, one string after the other, without taking care of the context of use, and they don't care documenting or discussing ambiguity problems that very frequently exist in English (notably because of non explicit grammar, abuse of WM-specific English jargons, or many very different meanings of the same orthographic term).

I'm not perfect, and others may still have a different opinion on the best way to translate things, and some other changes in each project may require adjusting some terms if they create new ambiguities. But now MIFOS has been gradually and slowly adding only small additions, and its French translation state is easily kept at 100% by various translators doing that slowly and more carefully for specific cases where it would be needed to check the meaning or adjust the user interface to keep it easily usable by MIFOS users.

Verdy p (talk)23:17, 6 September 2017
 

Feedback for new search translation features

Hi!

We have introduced new features in Search Translations. Please read about it in phabricator or test wiki. It would be really helpful if you could give us some feedback about the new features in Search Translations.

Thank you and we shall be waiting for your feedback.

Phoenix303 (talk)05:36, 15 July 2015

Unusable: the tests links (including those listed in Phabricator) return an error 402 (Bad Gateway). This test server is actually not working (or not reachable from the public Internet, possibly only in the WMF internal LAN: possibly a problem in configuring routings, or firewalls, or some DNS).

Verdy p (talk)23:09, 17 July 2016
 

page initiale d'où est issue la phrase à traduire ?

Beaucoup de traductions sont annulées car vous ajoutez une explication qui ne figure pas dans la phrase à traduire. Comment peut on remonter au contexte où la phrase anglaise est utilisée pour mieux coller à l'idée que l'auteur a voulu transmettre et ainsi orienter la traduction ? Merci. Christian, 92.

Christian (talk)18:39, 17 July 2016

Note: "l'auteur" n'est pas tout seul sur Wikimedia ou MediaWiki, il peut s'être lui-même trompé dans la version anglaise: il n'y a pas que le message à traduire verbatim, il faut comprendre où et comment il est utilisé (et la doc à côté mentionne l'usage: il suffit de regarder). Il est alors justifié de sécarter du texte anglais (qui sera corrigé séparément). Coller absolument au texte anglais (surtout quand il est faux car il a été mal interprété même dans son original) est contre-productif.

Verdy p (talk)23:03, 17 July 2016
 

Traduction de MediaWiki : pluralité

Bonjour,

Je reviens au sujet des 3 modifications que j'ai effectuées que vous avez annulées :

(Cela m'étonne d'ailleurs qu'il n'y en ait que trois puisque je croyais en avoir fait plus que cela de cette manière.)

J'ai bien compris le système de {{PLURAL}} à la lecture des traductions existantes, toutefois je pensais mieux coller au texte original avec ma traduction car le cas du zéro n'était jamais pris en compte dans ces messages (et les utiliser avec un zéro donnait des phrases incorrectes en anglais). J'ai donc supposé que ces messages n'étaient jamais utilisés avec le cas zéro. Je pense que cela se voit particulièrement dans la deuxième modification, où once ne peut correspondre qu'à 1. Pour ce même message, il m'est avis que la distinction du cas « une seule fois » nécessitera un effort inutile de la part du lecteur lorsqu'il verra un message avec un format un peu différent. Si l'on peut éviter de distinguer des cas, il vaut mieux le faire. En anglais, on dit également rarement two times et pourtant le cas twice n'a pas été distingué ; seulement le cas du 1 puisque sinon il y aurait eu une faute de grammaire.

En espérant obtenir plus d'explications, bien cordialement,

Frigory (talk)18:55, 9 May 2016

Pourtant j'ai bien vu le cas "0" qu'il est utile de distinguer plus clairement (par une phrase négative ou "aucun"). Je ne vois pas ce qui empêche un message de clarifier (et même en anglais on trouve aussi cette distrinction du 0 et du 1, indépendamment du singulier ou pluriel).

Je ne vois pas ce qui pourrait demander plus d'effort pour le lecteur que de voir directement le cas 0 clairement sans avoir à distinguer un chiffre. Surtout que la traduction qui existait présupposait que le singulier était forcément "1" (vrai en anglais, car zéro y est pluriel, mais faux en français). La distinction est nécessaire pour ne pas lire "un" alors que ce devrait être "zéro".

Ce qui est distingué en français n'a pas à l'être en anglais de la même façon. Oui la grammaire est différente, mais dans les deux cas on peut distinguer le cas zéro soit du singulier générique en français, soit du pluriel générique en anglais.

Ca donne donc {{GENDER:$valeur|0=cas zéro|singulier|pluriel}}

Le nombre de cas à distinguer varie selon les langues les traductions n'ont JAMAIS l'obligation de suivre le modèle anglais (en russe par exemple il y a d'autres nombres que le singulier et le pluriel, en indonésien il n'y a pas de distinction de nombre). On DOIT adapter le nombre de formes dans GENDER selon la langue et en suivant ses propres règles et pas celles de l'anglais.

Verdy p (talk)21:21, 9 May 2016

D'accord pour la deuxième modification annulée alors.

Par contre, pour les deux autres, je persiste. L'idée n'est pas de se plier au modèle anglais mais de constater que ces messages ne sont jamais utilisés avec le cas zéro (tu sembles dire que c'est le cas : « et même en anglais on trouve aussi cette distrinction du 0 et du 1 », mais je ne vois pas où). Le contexte est d'ailleurs « This message is displayed at the top of a category page showing the number of pages in the category when not all pages in a category are counted. » qui semble dire que le message est utilisé pour indiquer le nombre de pages listées lorsqu'elles ne sont pas toutes affichées, certainement parce qu'elles sont très nombreuses. Donc j'ai du mal à croire que le cas du zéro soit utile ici.

« Je ne vois pas ce qui pourrait demander plus d'effort pour le lecteur que de voir directement le cas 0 clairement sans avoir à distinguer un chiffre. » → Je parlais du cas « une seule fois » par rapport à « 1 fois », mais bon, j'abuse un peu. Je suis partisan du KISS ici.

Frigory (talk)20:02, 10 May 2016

C'est pourtant le cas justement quand on navigue d'une page à l'autre : on se retrouve parfois avec une page sans éléments.

Verdy p (talk)20:05, 10 May 2016
 
 
 

Changes to message's documentation

Hello. This changes (1, 2, 3 and 4) should be reported to phabricator, if you think they are needed.

Macofe (talk)04:31, 8 April 2016

It's simply not easy to locate where to report defects in source message, there are so many links to various places.

The easiest to report it is in the doc page (qqq) of each message (this suggests that developers are following changes to these docs when they create or update them), because the translation interface still lacks a possibility to comment changes, or to add message to the talk page associated to each translation (those talk pages, spread across multiple languages in separate are impossible to follow, but it is not impossible to follow the "qqq" documentation message.

Phabricator is not linked at all from translatewiki and not even in the "qqq" doc pages, which are also frequently empty.

I suggest to Wikimedia to create systematically a "qqq" doc page for each of their message, including a template linking to their Phabricator site on the appropriate section.

Verdy p (talk)04:41, 8 April 2016

It is actually very easy: The “Ask for more information” link under qqq goes directly to Phabricator. It used to go to Support, hence the label; I guess that it should be changed.

Amir E. Aharoni (talk)13:21, 8 April 2016

Actually there's NO such “Ask for more information” link under qqq...

Verdy p (talk)13:27, 8 April 2016

Yes there is.

See the red elipse
Macofe (talk)23:05, 8 April 2016

Not in the 4 qqq documentation messages listed above. You took an example in another message.

Verdy p (talk)23:51, 8 April 2016
 
 
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page