User talk:Verdy p

Jump to navigation Jump to search

Support requests

@Nemo )


Thread titleRepliesLast modified
Blacklist115:36, 2 July 2022
Empty translations119:26, 20 June 2022
Reviews on my early contributions115:09, 20 June 2022
Do not edit /en texts316:02, 13 June 2022
Multiples PLURALs116:05, 7 June 2022
Template:Languages311:38, 4 June 2022
Main Page translate009:33, 23 May 2022
Fallback language for Nogai 020:14, 15 May 2022
Translitteration rules for Nogai (ISO 639: nog) between Latin and Cyrillic scripts1013:49, 11 May 2022
Request for nog-cyrl and nog-latn codes of Nogai language1113:48, 11 May 2022
Editing old messages on Support310:41, 27 April 2022
Éléments représentés110:32, 23 March 2022
Don't write in Hebrew910:58, 22 March 2022
Changements inutiles avec GENDER et PLURAL1620:38, 17 March 2022
les images119:35, 14 March 2022
Your Interlingua portal changes300:35, 6 March 2022
Points de suspension116:45, 1 March 2022
MW high prio links105:01, 26 February 2022
Suppressed215:56, 24 February 2022
MediaWiki:Proofreadpage-indexquality-alt/fr114:06, 17 February 2022
First page
First page
Previous page
Previous page
Last page
Last page

Bonjour Verdy p,

Où est-ce que cela a été « discuté » ? Le moteur de recherche ne trouve rien.

Je sais que les synonymes « allowlist » et « denylist » sont préférés en anglais aujourd’hui mais MediaWiki utilise toujours « blacklist » et « whitelist » et les traductions « liste noire » et « liste blanche » sont toujours usitées en français aujourd’hui (cf. dictionnaires : [1][2][3][4][5][6]), y compris dans la communauté Wikimedia.


Thibaut (talk)12:40, 2 July 2022

C'est la typologie "noir=rejeté" contre "blanc=accepté" qui a été discutée ailleurs dans d'autres messages où on demandait d'éviter cette formulation malheureusement connotée historiquement. Or on peut très bien s'en passer dans nuire à la carté (même si l'anglais utilise encore "blacklist" et "whitelist" (mais là aussi c'est contesté et discuté notamment dans les groupes qui traitent déjà de changer les terminologies excluantes, et tu cites déjà "allowlist" and "denylist", mais qui n'a pas encore été unifié partout).

Je ne nie pas que c'est et ça a été utilisé en français (aussi en anglais, de même que les termes trop sexés) mais que cet usage est à revoir autant que possible quand on peut parfaitement s'en passer.

Verdy p (talk)15:34, 2 July 2022

Empty translations

H Verdy, you have created some /aa translations and emptied some later. Therefore they were exported with "". A revert was necessary:

As reminder: Emptying messages does not work. You have to delete them.

Raymond16:34, 20 June 2022

Yes but I cannot delete them. There was a quirk during navigation, and the language selection was unexpectedly changed to "aa" instead of "fr".

For now there's no way in the Translate UI to revert a creation by accident (the deletion is denied, EVEN in the case where I am the only author); reverts only work when there is a previous version which can be restored.

So I as I could not delete them (permission denied), I juste emptied them (but as it was impossible to validate them, I marked them as "fuzzy" manually: NO resource were submited as completely empty, they contained exactly "!!FUZZY!!" after my revert).

They should have NEVER been exported at all, given the existing translation rate, but if this happened, you have a bug in your exporting rules, which bypass/ignore the minimum completion level or that can even export new messages containing only "!!FUZZY!!")

After that I though it was still safe; your export occured later (and I was not using the site for several hours as I was not even at home) to use my PC and I had no other connection.

Theses creations were expected (even if I thought that those resources were already translated, I thought they were renamed in the source or edited to be reformulated. (so they needed to be trnalated again, or they were not correctly moved and there was some transient effect). Checking them after setting again the language in "fr", I saw they were already all translated and unaffectd in French (and not just the 5 messages affected only in Afar), so I returned to select "aa" and blanked them with just the "!!FUZZY!!" mark (the only thing that was accepted).

Thanks for deleting them anyway. I did my maximum that I could perform in a short time with no more than a few minutes.

I don't know why the language selection was unpectedly changed to "aa" Afar (I could not find any reason in the recent navigation) when looking at my browser history) I suppose this could have been caused by some server timeout or a lost UI event that was not captured by my browser (but may be this is a bug in the Javascript for ULS which may in some unknown circonstances select instantly the first language code avaialble without showing that this selection occured "automatically", e.g. some duplicate click event managed in some racing conditions. This happened in a browser tab that was open (but idle) for several hours. Some UI evnet in that case may have been handled in the background and caused by other events carptured by the browser from the navigation in an unrelated tab, or by some broadcasted event genereted by Windows. These are suppositions, I can't explain why this occured.

Note that such unexpected switch to one language to another affect other users (rarely, but this happens for unexplained reasons that I cannot reproduce for now; and I've already noticved in the past that this alsos occured by yourself, and you did not notice it when I reverted you when you submitted translations to an unrealted language). Note that "aa" (Afar) is NOT even in one of my prefered languages. And I already had a couple of tabs opened with French selected in the USL, they were not affected; so this occured in a single , when I closed some other tabs open on TWN that I did not need to keep in the browser.

Take note that I had noticed the error and made my attempts to fix it (this affected only 5 messages in the same translation module). Note also that I did not use the ULS selector, I just refrenshed the page for the affected tabb and it was already showing "fr" as the current selection: I looked at my own history, and to investigate, and see what resoiurceds could have been affected, and made my maximum to revert these small "damages" (which were not dramatic, these were only recent "creations" in a langua for a module that acually had no prior translation for that message group, and I acted promptly to fix it, soit was certainly not exported anywhere and no other wikis were affected).

Verdy p (talk)19:09, 20 June 2022

Reviews on my early contributions

Hi, It's been a while since my last contribution, thanks a lot for the review and edits on my Phabricator translations! ; ) Best regards

Tektasc (talk)12:50, 20 June 2022

Bit thanks to you too !

Translating Phabricator is a huge task (still not complete ,this is the only part incomplete in French) : I have advanced on all projects, and almost all of them have been 100% reviewed, except some complete modules of Mediawiki where I continue reviewing things (slowly too, because these translations are old and changing things required more pridence and acting slowly as well) Phabricator is also much more complex, and there are many ambiguitioes and it requires lot of searches to see the actual meaning or if there is an already existing and agreed terminology. In many cases though, I may find obvious typos that can be fixed easily (e.g. changing an incorrect masculine for "interface" into a feminine in French).

I also tend to "uniformize" the format of translated messages. I also complete the associated "/qqq" pages to check missing "Identical" or "Related" templates (Phabricator also frequently uses a terminology largely adopted by other projects, including MediaWiki; these "/qqq" pages hwoever distinguish each target project so that context (and possible deviations/desunification made specifically in one project will not necessarily affect all other projects). But these "/qqq" doc pages are great accelerators (thanks to their immediate integration in the Translate UI; it also helps fixing a terminology and create a stable one, or change it uniformly and coherently if there's a discussion concluding that such term whould be changed).

For some terms there's no easy translation, and translating them word for word would be even less clear than the original English, or evern incorrect in French: In such case I have to think many times to find a formulation that remains easy to understand but still respect the original meaning (e.g. changing between a passive or active form, or sometimes splitting a long sentence into two parts, and avoinding repetitions of the same term when such repetition in English was avoided, or when English had no other choice that was easy to understand; critical terms are those implying a decision or action of the user, notably input buttons in forms, especially if they are dangerous or could have a big impact, or because the englush term has a more precise definition and use in English when the similar term in French has more common lemma definitions that would mean something else than what was intended).

Due to its complexity, I have left Phabricator as a last task to complete slowly just because it was more technical and to be used by much less people (but I make efforts trying to make it more accessible to untrained people, so that Phabricator can be used with a wider audience). I ma conscient that Phabricator is also not translated in many languages and that providing a good translation into French will also help translators of other languages trying to decipher the English messages (which may be ambiguous for them too: many translators that can read English can also read at least partially French to get suggestions or because it can provide a useful disambiguating help).

Verdy p (talk)15:09, 20 June 2022

Do not edit /en texts

This has no effect other than confusing our change tracking system. If something needs changes, do propose those to the developers.

Nike (talk)14:42, 13 June 2022

Where have I missed sending a supprot request to them?

Verdy p (talk)15:35, 13 June 2022

There were changes in FreeCol, MediaWiki core and other message groups. Mostly from earlier this year.

Nike (talk)15:58, 13 June 2022

Without context, I cannot reply anything. I've submitted comments to all these developers I think (on the suppmlied contact link if available), plus frequently on the support page when they were not reachable directly. Most of them did not receive any reply, sometimles they were fixed in the source and resubmited here for translation (so these messages became fuzzy in translations that were already fixing them and need to be confirmed again).

Verdy p (talk)16:02, 13 June 2022

Multiples PLURALs

À propos de ce changement :

Est-ce une bonne chose ? Le message est plus long, génère plus d'appels PLURAL et est plus difficile à relire. Je soupçonne que ce n'est pas avantageux du tout.

Urhixidur (talk)15:14, 7 June 2022

Non le message est même plus court, et cela réduit la longueur totale des paramètres passés (une ressource comptée ayant des quotas) et la résolution des paramètres vides est instantanée. Les PLURAL ne génèrent aussi aucun appel, puisque ce sont des "builtin" au sein même du parseur (sachant que les paramètres identiques ne sont pas dupliqués). Tout ce qui est factorisable profite aux performances (je sais c'est peu, mais on a de nombreux cas où cela se produit dans plein de messages, et la mémoire gagnée est visible dans les statistiques d'analyse, tout en localisant au plus près). Pour le relecture je ne vois pas le problème réel, c'est très explicite.

Verdy p (talk)16:05, 7 June 2022



I've just discovered that the template at the top Localisation guidelines fully works only if every relevant language code is mentioned there. I've added a few codes that were relevant for that page, but many more are missing. It's the kind of template that you like to maintain. Can you perhaps add the missing codes some time?

Amir E. Aharoni (talk)09:45, 4 June 2022

The template is a fallback for pages that are NOT translated with the Translate extension. It CANNOT display all languages, because it is limited by Mediawiki (that limits to a mximum of 50 calls to #ifexist)

So yes, it focuses just an subset of "major" languages with official status. Other languages however are listed when you click on "Other languages" which list them with a search (but does not display the language names, just the pagenames with the language code extension).

There's no way to support all languages by this template (and there's still no other way to avoid using #ifexist, and list existing languages, as there's still no other Mediawki extensions like Lua modules that allows listing pages found with a MediaWiki search API and format them in a list).

If pages are translated with the translate UI (this can only be done by translate admins), you don't need that template, and the lateral language bar on the right can be used to link to other languages.

Please don't add more language codes, this breaks pages, which fail to locate relevant links; the list of tested languages is limited to avoid breaking pages due to the Mediawiki limit (max 50 #ifexist in ALL the content of the page, including other nav templates).

This is already noted in HTML comments used by the template. also the list of tested languages at top of the template MUST be in sync with the final switch that handles the link to "Other languages".

Verdy p (talk)10:08, 4 June 2022

Then it shouldn't exist. It is misleading and makes people think that some pages don't exist in their languages even though they do.

Amir E. Aharoni (talk)10:42, 4 June 2022

The link "Other languages" list them all, it's jsut one link further away. This template is there since many years. The translated page UI and the inclusion of the list of translated languages has been made many years after. If you want to have more languages listed (in the side bar), you need to mark the page for translation (for now there's no other way), and ONLY then we can remove the template from the top of the page. But preparing a page for translation requires to retranslate them, or reimport existing translations from their page history (if they were accurate and in sync) and this takes some editing time.

Note that we are talking about pages that have been created and translated many years ago, before the site evolved to get some more capacity (the translationj UI was already there, but for years they were not listing other languages in the side bar, which was initially designed for Interwiki links on wikis with multiple linguistic editions, such as Wikipedia or Wiktionary, and not for linking translations available on the local multilingual site, like this wiki, or Wikimedia Commons, or MetaWiki); there's a problem however for intergrting this sidebar on wikis that need both lists (local translations and interwiki links, such as Wikisource: they need two separate lists)

Note also that some pages (e.g. Language Portals, or Glossaries) exist in different languages but are not translations of the same base content. So we cannot use the Language sidebar which woiuld list only translated pages, when their contents are actually different and not meant to be translations but language-specific. We still need a way to link these pages together (where some parts only may be actually translated, possibly by transcluding a translatable template, such as in existing portals hose most important parts are translatable).

However language portals are not linked this way: there are indexed by categories and by statistic pages. Some language portals may contain a specific "See also" section for linking to portals for a few related languages: we don't need a language bar for them, the list of links is edited separately on each portal. These seem arbitrary choices, but they minimize the maintenance cost and also make these lists more relevant: a long list of languages (especially when it is not sorted and does not show enough info than a single language name is not so easy to navigate). But listing some relevant languages allows people to find relevant pages, even if they are still not translated and the support for each language can progress incrementally without loosing focus over time.

Even if a list of languages is not "complete", it still makes people aware that the current content is not just for a single language and that there are interesting other languages to look at (including for looking at differences: this is important for developers to see how their code will adapt to a varity of languages or scripts and to develop a mor international community instead of focusing just some users in some country). Translations will never be terminated (not even in English, which is also not the best source of information for all topics, as such source may often be severely biased by a limtied view and lack of consideration for native speakers!). That's why IMHO the "language portals" are important on this wiki: you'll find informations that you would not find easily everywhere else, because they are a central hub from hiwhc other relevant links can be referenced for various projects.

Verdy p (talk)10:53, 4 June 2022

Translitteration rules for Nogai (ISO 639: nog) between Latin and Cyrillic scripts

Edited by 2 users.
Last edit: 14:43, 28 April 2022

This informative talk has been moved to Portal:Nog/Latn-Cyrl transliteration, where it is maintained and should remain visible to the community.

TayfunEt. (talk)19:35, 27 April 2022

@TayfunEt.: Note: I transformed your unreadable/unformatted list into a table. I did not add any additional pairs or letters (but some may be needed) and made the table sortable.

But consider the difficulties (annoted) that a transliterator has to handle.

Disambiguation rules must be confirmed, but also specified more precisely for the ambiguous cases noted with "(?)".

From the sources I've read the disambiguation between K and Q in Latin, is that Cyrillic notes the Latin letters "q" or "Q" (or the Arabic letter "Qaf") with digrams "къ" or "Къ" (or "КЪ" contextually for fully capitalized words, i.e. when immediately followed by another capital).

Then there remains the question of Cyrillic letters "ь" or "ъ" if they may occur as initials, i.e. not as the 2nd letter of a Cyrillic digram. You indicate this should be empty in Latin. But some sources seem to use apostrophes (preferably curly) for transliterating "ь" (or "Ь") to Latin, so that the conversion is reversible back to Cyrillic (notably proper names).

There may also need some additional transliteration rules for proper names possibly borrowed from Ukrainian or Belarusian, notably their variants for the Latin letter "I", and for other digrams with "ъ" or "Ъ" for traditional names from Arabic or Persian/Farsi origins, and initially transliterated from Arabic to Cyrillic with these Cyrillic digrams: converting them to Latin may use also apostrophes ror "h/H" which could become ambigous when converted back to Cyrillic "x" or "Х" where it was a digram "xъ" or "ХЪ").

I've seen also some uses of the consonnantic Latin digrams 'ng', 'dj' and 'dz', as well as the occasional use of other diacritics (caron or dot below) on other letters (I'm not sure how to match them in Cyrillic). In Romania, there seems to be alternatives for 'g'/'gh', plus some additional vocalic digrams. And an additional rule seems to exist between Latin 'u', 'v' and 'w' (and between Cyrillic 'у' and 'в').

Once this table is fully fixed an confirmed, it should be posted into the Portal:Nog page. And then submitted to comments from linguist experts (to see if we need to handle more exceptions), and if we need to also add support for the special MediaWiki syntax -{ ... }- as a helper for automatic transliterators in articles where there's a need to handle more exceptions. At that time the transliteration rules should be proposed to MediaWiki developers to implement them, so they become immediately available (and so that we no longer need translation specializations for Nogai between these two scripts). Adding support for Arabic script may be postponed to later if needed (are there Nogai writers in Iran or still using the Arabic script for islamic texts, including in Dagestan and Turkey?).

Verdy p (talk)20:55, 27 April 2022
Edited by author.
Last edit: 13:49, 28 April 2022

This two letters ("ь" and "ъ") are only found in Russian words (but (!!!!) the letters аь, уь, оь and нъ are also for native Nogai words) and in Latin is it not used (like Crimean Tatar). For example the word "февраль" → "fevral" (is also in Crimean Tatar). The Cyrl "Е е" is "Ye ye" when is it the first letter of the word (ел → yel). Q and Ğ comes after the hard vowels (а ы о у ;a ı o u) багша → bağşa, окув → oquv. Also when the second letter is a hard vowel is the first letter Q/Ğ (Карт → Qart). And thank you for making the table!

TayfunEt. (talk)12:50, 28 April 2022
Edited by author.
Last edit: 14:22, 28 April 2022

With your response I updated the table, if it is ready, it may be imported in a subpage of Portal:Nog, such as Portal:Nog/Latn-Cyrl transliteration.

Just posting an alphabet is insufficient to implement and support a reliable transliterator in MediaWiki that would be very useful in wikis to avoid maintaining distinct pages, and it could also allow using a Latin-based input method, even if the articles are stored in Cyrillic (but still readable in Latin, thanks to the transliterator that would come handy as a tab at top of pages, like in Chinese or Serbian, with stored user preferences).

Note that for the Cyrillic letter 'ь' or 'Ь' which does not follow a vowel 'а', 'А', 'о', or 'О' to form a digram in Cyrillic (that is transliterated to 'ä', Ä', 'ö', 'Ö' in Latin) that may occur in loan words borrowed from Russian or Ukrainian (notably proper names), there may still exist the need to support a way to input it in a Latin input method, so that the Cyrillic letter 'ь' or 'ь' will be stored in the article. A way to do that would be to support an apostrophe (' or ’) in the input method or another sign like '`' that can still be typed easily on a Latin keyboard: the Cyrillic letter 'ь' or 'Ь' would be stored, but rendered as nothing in Latin by the transliterator from Cyrillic to Latin when it does not follow a Cyrillic letter 'а', 'А', 'о', or 'О'.

Note also that you did not reply about

  • the Latin distinction of 'v' or 'V', vs. 'w' 'W' (only 'в' or 'В' in Cyrillic); they occasionnaly form digrams as well that may be distinguished easily in Latin, but written specially in Cyrillic (with additional digrams or diacritics?)
  • other existing vocaling digrams using 'ь' or 'ь' in Cyrillic (for diphtongs in loan words, borrowed from other languages).
  • other existing consonnantic digrams using 'ъ' or 'Ъ' in Cyrillic (for loan words, most probably islamic related words borrowed from Arabic or Persian/Farsi , or from other languages which have a few additional consonnants, that may be transcribed for example aspirated consonnants as 'kh', 'bh'...).

A similar table could be made for Crimean Tatar as well with the same benefit.

Verdy p (talk)13:22, 28 April 2022
Edited by another user.
Last edit: 14:22, 28 April 2022

Ok we can edit the sign ' for ь when it's needed in names and I did make the Page: Portal:Nog/Latn-Cyrl transliteration

TayfunEt. (talk)13:47, 28 April 2022

Now it's time to ask to reviewers speaking/writing Nogai (notably those in Southeastern Romania or Turkey around the Black Sea).

Crimean Tatars have a different need, but Romanian Tatars, as well as Crimean Tatars that fled the area of conflict between Russia and Ukraine, or those living in the conflict area in eastern Moldova may have some views.

And in Southern Romania, they are also in contact with Bulgars from which they may have borrowed loan words, or jointly borrowed words from Romanian, or from Moldovan (Romanian written in Cyrillic and also under influence of Russian or Ukrainian). Along the Romanian coast of the Black Sea, there are also contacts with Greeks (speaking some form of "Pontic" but still using the Greek alphabet, more similar to Cyrillic and transliterating it as well to Latin in Romania, when they fled Turkey but did not go to Greece at its century-old independance from the former Ottoman Empire).

Verdy p (talk)14:00, 28 April 2022

And the letters аь, уь, оь and нъ are for native Nogai words, but why you did write only in Russian and Ukrainian words?

TayfunEt. (talk)13:57, 28 April 2022

I interpreted what you said about the letters 'ь' and 'ъ'. May be you were not clear ? OK I've removed this note (and the yellow color for these cases, the yellow meaning that it is occuring only in load words)

I moved the table at top of this talk thread outside this thread (replaced by a link). This avoiuds maintaining the two pages.

Also there's still a transliteration issue between Cyrillic 'э Э' and 'е Е', when not at initial position, as they both give the same Latin letters 'e E'.

  • It's not a problem for articles and translations already written in Cyrillic (because they will be correctly rendered as intended in Latin), but can be a problem for inputing text 'e E' in Latin in an input method: which Cyrillic letter should it choose in that case for the stored page, 'э Э' or 'е Е' ?
  • Is it possible to input an Latin digram like 'e’ E’', or 'ye' 'YE' at the initial (even if it normally does not occur in Nogai words) to get 'е Е' in Cyrillic, while inputting only 'e E' in Latin, but not at the initial, would produce 'э Э' in Cyrillic ?
  • It can also be a potential issue for loan words (especially for proper names borrowed from various languages written in Latin which have a clear distinction between 'e E' and 'ye YE').

If you take the Russian name for "Kyev" and not the Ukrainian name "Kyiv", we don't want to get "Kev".... Though for that case, the Cyrillic letter 'й Й' would be used to preserve that 'y Y' phonem in Latin. The other problem would be the initial Cyrillic 'K', that Nogai-Latin would potentially write as a Latin 'Q'... but would still write it as a Latin 'K' because the Cyrillic 'K' is followed by an intermediate Cyrillic soft 'й' or 'Й' (before 'и' or 'И') with the borrowed Ukrainian name, or because the Cyrillic 'K' is followed by a Cyrillic hard 'е Е' with the borrowed Russian name.

Now if you consider loan words from Arabic or Persian, there's a strong phonetic distinction between 'k K' and 'q Q', that does not respect the usual Nogai orthography (notably for religious terms where it would be important to preserve that distinction). In Turkish, the Latin letters 'k K' and 'q Q' are considered distinctive enough, and the same is true for the Arabic script which causes no confusion. The confusion can come in Cyrillic, and other Cyrillic-written Turkic languages of Central Asia have opted for using digrams with the Cyrillic letter 'к К', or use Cyrillic variants of that letter (e.g. with an attached leg or crossing bar) for one of these cases.

Verdy p (talk)14:06, 28 April 2022

Request for nog-cyrl and nog-latn codes of Nogai language

Hello, is it possible that we can get a nog-cyrl and nog-latn codes?

TayfunEt. (talk)07:31, 7 May 2022

I've already replied to you, I cannot make this decision. visibly you're attempting to submit this request again and again every day at top of the Support list, and I doubt this can succeed, this could instead irritate the site admins. All you can do is to search other users that will support your request, but asking this alone will not succeed and will less likely succeed if you iterate it every day (site admins may even decide to block you, they are really susceptible for very minor edits, even when not sollicitating them directly). Get sure that they've already read your message in Support, and given their reply, they are waiting for other references or demands from other users to confirm your own demand.

Verdy p (talk)09:22, 7 May 2022

Amire80 deletes your and my edits in Portal:Nog (also in Wikipedia), can you please talk with him about that, because this is getting on my nerves!

TayfunEt. (talk)10:04, 8 May 2022

There are many references, including in Wikipedia Such as this one (page 274)

Amire80 is russifying the subject, ignoring (denying) that there are now MORE Nogai people living today in Turkey and Romania, where they use the Latin script than there are in Dagestan (Russia), Crimea and Urkaine.

Verdy p (talk)10:10, 8 May 2022

Here is also a man from Romania who is talking in Nogai language and saying that there are many nogais.

And what can we do that he stops this?

TayfunEt. (talk)10:17, 8 May 2022
Edited by author.
Last edit: 10:43, 8 May 2022

We can provide published books (see for example references in French Wikipedia, because Amire80 also deleted references in the English Wikipedia) You may also look at references in Romanian Wikipedia and Turkish Wikipedia.

Other searches are possible as well in Google Books, but you may look into many other libraries (in various countries). I have found references as well at the "Bibliothèque nationale de France" (BnF) such as

May be Amire80 will stop when we list serious books from ethnologues and linguists. Clearly he does not care about Facebook (especially not about videos like this one, as they don't demonstrate any written text, neither Cyrillic nor Latin)

Verdy p (talk)10:23, 8 May 2022

Editing old messages on Support

Please stop editing other people's old messages on Support. This includes adding links to Portals. It's confusing and not helpful.

Amir E. Aharoni (talk)18:40, 14 November 2021

I think it is useful to follow the topic when these basic links were missing (notably for looking up language codes). It helps finding the response and they are not "old" as they were not answered or not completely, still waiting for a response or action. I did not modify any term. And it helps looking up for past talks as well (notably because language names alone are frequently ambiguous and need precision to make sure we talk about the same thing). It was not supposed to hurt anyone (and I don't think it has disturbed anyone, except possibly you if you track some threads that reappear later.

Verdy p (talk)22:58, 14 November 2021

It's OK to fix language codes on portals.

Don't edit the text of what other people wrote in conversations without a good reason. Missing language codes or missing links to portals is NOT a good reason. It is disruptive.

Amir E. Aharoni (talk)07:25, 15 November 2021

I am asking you again, for the last time: stop editing old messages on Support. This is useless and disruptive. Your edits here are NOT helpful in any way. A wrong link or a wrong template parameter in a talk page message from 2010 can stay wrong. Reading that message only to realize that it was posted in 2010 wastes my time. Please don't bother explaining it. Just stop.

Amir E. Aharoni (talk)10:41, 27 April 2022

Éléments représentés

Bonjour Verdy,

Merci de traduire l'interface de mon application Android !

Comme tu le sais probablement, Commons demande aux utilisateurs de remplir 3 informations pour chaque image:

C'est pourquoi le mot "description" ne convient pas pour la troisième information.

Merci et bonne journée ! :-)

Nicolas Raoul (talk)04:58, 23 March 2022

Tu écrits bien tard. Il y avait 2 traductions différentes (pas incohérentes) pour "depict(ed/ion)" pour des messages anciens ou plus récents.

Et pas la peine d'expliquer je sais déjà qu'il y a 3 types d'infos, et il n'y a absolument jamais eu de confusion des 3 ("description" servait aussi mais pas pour les données structurées, c'est un champ de la boite wiki historique, et qui est une forme résumée des 2 autres types d'infos, mais pas du tout dans le même contexte)

Il y a déjà eu une unification de "depict(ed/ion)" dans un sens (vers "décrire"/"description"), puis hier déjà dans l'autre (vers "éléments représentés").

Et cela avant même que tu postes ce message ici (bref ta demande est déjà passée hier avant que tu la fasses ce matin, il n'y a rien à faire de plus.

(Pour "caption" la traduction utilisée c'est "légende" et cela n'a pas changé !)

Verdy p (talk)10:25, 23 March 2022

Don't write in Hebrew

You created a list of translated names of writing systems in Hebrew.

I deleted it. That list is wrong. I don't have time to explain all the ways in which it is wrong. It can't be right for a simple reason: You don't know Hebrew.

Writing translations in a language you don't know just to fill a list does more harm than good.

Don't write in Hebrew on translatewiki, or on any Wikimedia website. It's not the first time I'm asking you not to write in Hebrew. Not with machine translation, not with a dictionary, not with anything. Don't write in Hebrew.

Amir E. Aharoni (talk)20:36, 21 March 2022

Where? I don't fill any "list". If there are *isolated* things they come from existing resources used elsewhere also in isolation (e.g. Wikipedia article names related to exactly the same topics, or in Wikidata).

Verdy p (talk)20:41, 21 March 2022

At Template:Scriptname/he. I deleted it.

You also did it for Russian. You somehow got lucky and most of it is correct, but this doesn't mean you should try your luck again, in any language. Most of the time you'll be wrong.

Please, don't ever write in languages you don't know. There are plenty of volunteers here who can write in their languages. Correct English is better than a bad machine translation.

Amir E. Aharoni (talk)21:04, 21 March 2022
Edited by author.
Last edit: 21:21, 21 March 2022

These are not translated messages, but part of a generic list that is specific to this site. And it has all the links needed to contribute it. And for a page where it says that only English and French are normative and all others are informative. I made lot of searches on these terms to find what seemed to be the most relevant terms. This never came from an automatic translator.

You may disagree on one term and change them, but even the ISO 15924 standard lsits several common terms in English or French (that why there are codes, and not jsut names). And this does not alter at all the codification and their use.

They came from sources that already cite ISO 15924 as a reference, (inclmuding Hebrew Wikipedia, or Russian Wikipedia, or Wikidata). May be these other common sources are not accurate or incomplete. fixing them would, work and fixing them in this local template is very easy as well.

Simple deletion of a template you did is just harmful, it does not work and breaks pages that attempt to display something, using relevant fallbacks.

Verdy p (talk)21:15, 21 March 2022

Where is this "other ISO 15924 list in Hebrew"?

Amir E. Aharoni (talk)21:20, 21 March 2022

These sources are not difficult to find, e.g. L10n support for Linux in Ubuntu, Debian, Fedora (those are using LGPL most often, but sometimes use CC0 or dual licencing for use in their documentation sites) and various other common translation projects (including CLDR data, where it was "vetted by experts", others are marked as "provisional").

Other sources use CCBYSA (Wikipedia), or CC0 (Wikidata). Comparing them can help find the best matches and common alternates. The terms are taken isolately, compared separately. No collection is taken as a whole. And isolated terms like these then become out of scope of copyright (the adhoc database copyright applies only to a "significant" part of the database, if it can be isolated as coming from one source only, but as items are validatred separately with different sources compared or fixed separately, and they originately come from the common langage found in many dictionnaries and in public domain publications... licencing is not an issue for each term, fixed by multiple people aat different times). The assembly of these code lists (and their presentation) however fall into this site licence.

If you're concerned about Hebrew, I suggest you complete the missing data. This won't be long for you.

I made the "framework" for it so that it can be done easily and for almost all cases these were never made "complete" for 100% of scripts (it. included fallbacks to English already, annotated with a "FIXME" comment so that the list could contain all codes without providing a translation). I patiently made the search item by item. But you lazily deleted everything without any prior asking about what could be done.

And you could as well review Wikidata entries that are linked to ISO 15924 codes: these are the data that will be the most likely reused across all projects for designating languages and scripts).

Verdy p (talk)21:47, 21 March 2022

Changements inutiles avec GENDER et PLURAL


Quel est l’intérêt :

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

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

Pols12 (talk)18:59, 12 December 2019

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

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

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

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

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

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

Pols12 (talk)16:02, 17 December 2019

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

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

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

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

Pols12 (talk)17:59, 17 December 2019

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

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

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

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

Pols12 (talk)16:12, 19 December 2019

Où est la "question technique" ?

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

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

Pols12 (talk)20:03, 19 December 2019

Rebelote. Merci pour ton travail de relecture, mais ne fais de modifications inutiles qui nous font perdre du temps stp.

Pols12 (talk)23:41, 25 February 2022

C'est bien plus lisible à relire et également moins couteux et plus rapide sur le serveur avec des paramètres vides qui indiquent justement que la variable n'a aucun d'effet dans le texte qu'on peu lire tel quel (rappeler que les traducteurs ne sont pas tous techniciens du wiki: plus la partie "technique" est réduite mieux c'est et c'est également plus facile à relire et faire accepter par les correcteurs orthographiques (qui n'aiment pas trop les barres verticales collées entre deux mots pourtant non joints parmi les paramètres qui sont exclusifs les uns des autres. C'est plus léger aussi pour afficher la page des messages et le voir dans son entier sans trop sauts de lignes multiples dans l'interface: on relit plus vite ensuite. La relecture pourtant que je fais relève des fautes d'orthographie et des incohérences de traductions, voire aussi des oublis (et des tas de messages obsolètes non remis à jour): il faut bien que ça se fasse (la plupart des messages dans la masse de ceux de Mediawiki n('ont jamais été révisés, notamment les moins courants de l'interface technique ou des API, journaux, messages d'erreurs, et des interfaces pour administrateurs.

Verdy p (talk)23:49, 25 February 2022

Je trouve aussi ces changements inutiles et font perdre du temps aux relecteurs qui doivent tester si ces bidouilles fonctionnent, cf. [1][2].

Wikipédia a une très bonne page à ce sujet : w:fr:Wikipédia:Ne vous préoccupez pas de performance (adapté de w:en:Wikipedia:Don't worry about performance).

Thibaut (talk)16:41, 1 March 2022

Je ne me préoccupe pas des performances. mais bien de la facilité de lecture, les barres verticales juxtaposées au texte étant moins facile à lire.

Et le groupement proposé en anglais n'a pas de sens même en anglais, souvent cela ne concerne que les langues slaves qui accordent les verbes selon le genre du référent, mais de façon encore différente de nos participes (selon les temps composés, la forme active/passive, les modes et placements de nos compléments d'objets). Sio cela ne fait pas sens en français, on le sort de ce contexte inadéquat pour remettre dans la partie en plein texte, que reconnait mieux les correcteurs d'orthographiques (qui ne signalent pas "d'anomalie" quand il y a deux mots séparés uniquement par des "|" attachés: plus de soulignement ondulé en rouge par exemple, c'est bien une facilité pour la relecture, le navigateur proposant à tord d'insérer une espace voire même de remplacer cette barre verticale).

Verdy p (talk)16:55, 1 March 2022

Ce n'est pas une "perte de temps" que de passer du temps justement sur des tonnes d'endroits où les fautes ont été oubliées et délaissées depuis longtemps. Certes cela fait que des corrections faites ont à relire (parfois à nouveaux car cela n'avait pas été remarqué dans une relecture précédente), mais pour les quelques cas où cela arrive, on est loin d'inonder les relecteurs (qui sont déjà très peu nombreux). se montrer désagréable sur quelque chose qui aurait pu être correct dès le départ et demande juste à être revu une fois (et plus rapidement car les modifs n'ont plus qu'à être acceptées).

Le reste et le plus gros du travail vient des changements et ajouts des sources à traduire: c'est là qu'on passe le plus de temps, mais ensuite du soucis d'homogénéiser le lexique utilisé (autant que possible) tout en évitant autant que possible les confusions (notamment sur les verbes d'action dans l'IHM).

Verdy p (talk)17:02, 1 March 2022
Edited by author.
Last edit: 20:38, 17 March 2022

Nobody reproach you for your huge review work, but please stop doing this kind of fully useless edit (other examples: 1, 2, 3). Thank you.

Pols12 (talk)19:31, 17 March 2022

Tu as mal lu : il y a bel et bien des corrections (les féminins corrects, les accords corrects), ce n'est pas inutile comme tu le crois: au passage c'est aussi plus facile à relire si on isole les différences réelles hors des champs spéciaux. Et pourquoi écris-tu ici en anglais sur des traductions en français ? Penses-tu corriger le français sur la base de ton anglais ? Alors que ta page indique une connaissance du français supérieure à l'anglais (à moins que ce soit le contraire !)

Sinon je ne fais aucune traduction automatisée, c'est là que la revue est utile pour repérer les petits trucs gênants ou réellement initules comme passer une chaîne invariable dans un paramètre de fonction sensée faire une sélection. Ne pas passer le paramètre se résout aussitôt sur le serveur car c'est en cache, sans appel interne supplémentaire.

Je sais que la source anglaise a tendance à en mettre un peu partout autour de "you(r)" ou des verbes conjugés (à destination des traducteurs en langues slaves et pour signaler que c'est pris en charge) parce mais pas toujours où il faudrait (et il en manque souvent pour les traductions en forme passives, adjectifs et autres accords ou formes alternatives marquant le genre et le nombre). Mais ce n'est pas une raison d'imiter ça (pour qu'il n'y ait pas d'anomalie signalée je laisse une appel de fonction vide, mais le texte invariable est bien traduit comme invariable et on relit les phrases bien plus facilement ce qui permet aussi de mieux repérer les petits détails. A mon avis ces inclusions inutiles dans les source en anglais ne devraient pas être là, le message devrait plutôt être documenté pour indiquer les variables réellement utilisables pour ces variantes.

Et TWN ne devrait pas exiger une de ces fonctions "manquantes" quand on n'en a en fait pas besoin, ni invalider un ajout (pour certaines langues il faut aussi ajouter des appels à "grammar:", totalement absents en anglais). Et pour l'instant il n'y a pas de prise en charge des élisions nécessaires, et trop souvent des ambiguités en anglais entre verbes et noms. C'est dur de repérer ça, je documente (dans les pages "/qqq") quand je trouve. Et je complète les modèles "Identical/*" pour ensuite réviser le glossaire et avoir une traduction aussi homogène et cohérente que possible (pas simple parfois avec les ambiguités anglophones et les usages d'un même terme dans des sens non unifiés dans une autre langue).

Bref si d'autres passaient autant de temps que moi pour ces relectures (oubliées depuis longtemps), ça arriverait moins souvent mais le plus gros est fait et maintenant je relis les groupes de messages au complet un par un, au moment où je les trouve à changer (il y a beaucoup de groupes dans Mediawiki, Phabricator, et OSM: tous les passer en revue en une fois c'est pas terrible si on veut garder la cohérence d'ensemble et savoir où et quoi corriger s'il faut unifier).

Les pages de doc (/qqq) que je complète servent aussi aux autres langues : cela aussi se passe en revue et s'organise pour que la "mémoire de traduction" soit efficace pour tout le monde. Et je pense que cela accélère ou facilite les traductions dans des tas de langues qui sont en chantier et "se cherchent" un glossaire adéquat mais aussi adapté à leurs différences d'interprétation ou de formulation selon le contexte.

Certains ne sont peut-être pas d'accord avec mes edits, je ne suis pas à l'abri d'une erreur, mais kje fais aussi attention que possible pour faciliter la relecture après moi. Et souvent ceux qui annulent quelques modifs que j'ai faites ont raison (pour une cause que je n'avais pas vue). Mais ça arrive rarement, ou je corrige si on me signale (ici, et pas sur un autre site dans une discussion que je ne suis pas et dont on ne m'avertit même pas).

Verdy p (talk)20:07, 17 March 2022

les images

Pour l'annulation de ma correction 'Veuillez ne téléverser que les images que vous avez créées vous-mêmes.', il s'agit bien d'utiliser l'article DEFINI qui s'applique dans ce cas en français car le contexte indique bien de quelles images il s'agit: les siennes. --

Christian 🇫🇷 FR (talk)11:14, 14 March 2022

Non, le sens est bien que parmi LES images téléversées (elles ne sont pas toutes de nous), seules certaines (DES images) viennent de nous. Et parmi LES images que nous avons créées, seules certaines (DES images) sont téléversées. L'uitilisateur est libre de choisir quelles images (qu'il a créées) il veut téléverser. Ce nombre n'est PAS défini.

"Veuillez ne télécharger "des" images QUE si vous les avez créées vous-mêmes." LE sens de "QUE LES" implique une restriction dans les deux sens, soit aucune, soit toutes, et ce n'est pas ce qu'on veut, utiliser l'article défini est bien un contre-sens.

Verdy p (talk)19:35, 14 March 2022

Your Interlingua portal changes

It would have been nice to have some discussion before your radical changes to Portal:Ia. I like the addition of letter headings to the glossary, but I don't like it that the glossary is now virtually impossible to find. What is against it being on the main Portal:Ia page?

McDutchie (talk)22:39, 3 March 2022

Why do you think it is impossible to find ? I've just moved it upper on the page where it is even more visible than before. Or which page are your talking about if that's not this portal? There's never been any "letter headings" in the portal itself, as there was no glossary there, except in a separate subpage. If you speak about headings, those changes were in Portal:Ia/Consistentia in traduction (whose link in the Portal:Ia is proeminent, and emphasized in bold, may be you want it to be even bigger? It was not big before).

Verdy p (talk)07:48, 4 March 2022

The glossary was never in a separate subpage, you're the one who moved it there. I'm going to undo that now as I do not like this change and I do not see any good reason for it.

McDutchie (talk)21:28, 5 March 2022

OK, but this is very different from other "portals" that, as their name imply should just be a colelction of ressources. All other languages manage subpages for various things, and notably the glossary which is very expansible. It also uses a consequent size in the summary. That's why I placed the strong link to the glossary just below the summary. And I also linked this glossary to other glossaries (there are new ones including one new which is fully translatable across all languages. There are also multiple glossaries for specific projects (not Wikimedia or Mediawiki), that your revert will now hide. For maintenance purpose, your revert will be moredifficult to manage consistantly. It is the creation of cross-language glossaries that motivated the separation of your glossary in a separate subpage, making the portal what it was at its origin: a portal for all ressources. Some portals ontain a few additional sections but they are much more limited in goals, and when these extensions become consequent, they all use separate pages.

Verdy p (talk)00:33, 6 March 2022

Points de suspension


Pourriez-vous respecter le choix des développeurs et ne pas remplacer le caractère unique pour les points de suspension ? [1][2]

Le caractère unique rend sans problème avec la majorité des polices d’écriture.


Thibaut (talk)16:19, 1 March 2022

Ce n'est pas le cas, ces points sont là pour compatibalité avec certains anciens terminaux mais leur rendu est souvent incorrect, ils sont trop serrés (et souvent trop fins typographiquement) car présents dans des polices comme s'ils avait une chasse fixe.

Unicode le dit bien, leur existence vient uniquement de la compatibilité avec les anciens jeux de caractères à 8 bits et il les marque bien comme caractères de "compatiblité", désuets depuis longtemps, juste là encore pour la conversion bijective avec ces anciens jeux non compatibles avec l'UCS.

D'ailleurs la plupart des pages et sources des développeurs ont justement changé ces "3-points" (historiques) en 3 caractères séparés, en raison des problèmes de rendu (et de lisibilité): ils ne sont pas accessibles, et jamais nécessaires dans aucun document nativement créé en Unicode.

On ne fait pas du tout ici une appli pour un vieux terminal à jeu historique 8 bits ou pour un télétype ou machine à écrire à chasse fixe; de la même façon on n'utilise pas "--" pour un tiret demi-cadratin, ni "----" pour un tiret cadratin (parce que les anciens jeux de caractères 8bits ne disposaient pas de ces caractères). Le caractère unique sera produit automatiquement dans les environnements limités qui veulent les compacter en une position et non trois, au prix de la lisibilité (mais aujourd'hui toutes les imprimantes sont "graphiques", ont n'utilise plus les "boules" ou "balais" de caractères métalliques préformés pour la chasse fixe.

Le rendu de ces chaines dans l'IHM de Mediawiki est toujours dans un contexte à polices à chasse variable (et adaptée selon la langue et l'écriture utilisée, ce que ces caractères de compatibilité justement n'autorisent pas).

De plus la ponctuation est toujours spécifique d'une langue ou une écriture, elle s'adapte à elle et se traduit. On n'a pas du tout à reprendre dans un document traduit la ponctuation conçue pour l'anglais dans un contexte qui n'est pas du tout technique. C'est pour ça qu'on a d'autres conventions en français pour la typographie et l'espacement de la ponctuation et pour sa métrique et le choix de symboles de citation. Pour ça aussi qu'en arménien les rôles des "deux-points" et du "point" sont inversé. Qu'en grec le point d'interrogation est notre point-virgule. Qu'en espagnol on ajoute en tête de phrase les points d'interrogation et d'exclamation renversés. Que la virgule est en miroir en écriture arabe....

Verdy p (talk)16:38, 1 March 2022

MW high prio links

Please stop adding unnecessary complicated wikitext to MW high prio links. It's just a list. It is supposed to be easy to change. Adding more wikitext formatting to it makes it hard. No one complained about it.

Amir E. Aharoni (talk)04:42, 26 February 2022

I don't know what you think is complicate: it makes the list mich more usable, notably because you post it multiple times directly to user pages of users that get massively polluted with a very boring list instead of what they would like to present for themselves.

These long vertical lists make their user page almost unusable for something else. I just made two list titles to clarify the two sublists and then just organized these two lists into autoscaled columns. Now when you post these lists multiple times, they are correctly identifying the language for which you posted it.

And the addition was very minimimalist: two embedded templates for columns, bold subtitles for each list, and clear indication of the language code.

What is "complicate?", shouldn't you care about what users will see on their user page and allow these links to be more read and interpreted for easier use? I've not removed any item it is presentational. And still easy to change (these are still standard bulletted lists, their individual items are identical, the list order is not changed at all). And users won't edit these lists themselves (only you, but at the same time you'll change all users pages using the template by adding visible contents to them).

And why do you post that in user pages themselves and not in a thread of their talk page? After all, it is you that is sending them a message. And users would be able to read it and dismiss it, or read it later, while selecting what will interest them in their user page (and annotate items themselves as they want, something impossible with your pseudo-template that can change at any time many user pages) And now that you continue adding items to these lists, this is becoming a problem for many user pages that you have invaded massively (and with a very poor layout). As a consequence, I've seen various users dropping your post that you placed on their page (as if you were forbidding users to make their own content there about themselves). I don't believe this can be useful with the form you use.

Verdy p (talk)04:52, 26 February 2022


T’es bien certain de ce changement ? "Suppressed" a plus de chance de correspondre à « masquer » qu’à « supprimer ».

Urhixidur (talk)13:36, 24 February 2022
Edited by author.
Last edit: 15:14, 24 February 2022

Il y a plusieurs termes pour des actions différentes sur les messages des flux de discussions structurées :

  • "delete / undelete" (traduit comme "supprimer / restaurer")
  • "suppress / unsuppress" (traduit comme "masquer / rétablir"), à ne pas confondre non plus avec
  • "hide / unhide" (traduit comme "cacher / montrer")

La cohérence est effectivement à vérifier (au moyen par exemple des termes anglais apparentés, listés dans les pages "/qqq" à compléter au besoin s'il en manque pour ce glossaire spécifique des Discussions structurées), car ce n'est déjà pas homogène partout et tout ça peut prêter à confusion.

Verdy p (talk)13:46, 24 February 2022

Il y a un modèle {{Related|Flow-action}} pour résumer les actions dans la doc "/qqq" des messages (cela concerne en fait toutes les langues). S'il est manquant dans une des variantes, ce serait bien de l'y ajouter, afin de faire ce tri indispensable à la cohérence et lever les ambiguïtés.

D'ailleurs je songe y intégrer directement {{Related|Flow-content}} (à rediriger ensuite ou à vider, car les deux sont fortement liés, à mois de les garder séparés et affichés l'un sous l'autre pour n'en dérouler qu'une partie si cela facilite leur lecture ou comparaison) et il y a d'autres messages sur les actions journalisées et les droits d'utilisateurs.

Et encore avec {{Related|Flow-moderation-title}}, on a :

On peut voir que ce n'est pas non plus homogène avec le reste de MediaWiki concernant d'une part les actions sur les pages, ainsi que le déroulement du sommaire et des boîtes de navigation (qui n'implique aucune action sur le serveur, juste une action de l'utilisateur lors de la simple consultation d'une page, sans avoir en changer l'état pour les autres, ni avoir à la recharger).

Cela n'aide pas non plus à l'adoption de Flow / Discussions pratiques à la place des pages de discussion classiques en wikitexte.

Et je ne suis même pas sûr non plus de l'homogénéité de LiquidThreads (comme sur cette page ici, même si cette autre extension n'est plus maintenue) et que la transition entre LQT et Flow peut être elle aussi assez perturbante.

A revoir aussi le vocabulaire utilisé pour la modération ou la revue des pages "stables" dans d'autres extensions. Tout ça devrait être remis à plat (pour éviter aussi des conflits inutiles portant sur des changements de traduction inattendus mais parfaitement explicables) : homogénéiser ça et rendre cohérent est devenu indispensable, mais il faut pour cela des outils de suivi et de comparaison permettant aussi d'en discuter et revoir le vocabulaire commun.

Verdy p (talk)14:51, 24 February 2022

Bonjour ! Désolé de te déranger. Je suis l'un des développeur de l'extension ProofreadPage et un contributeur sur Wikisource en français. Il y a eu un débat sur Wikisource en français à propos de la modification de traduction que tu as faite sur MediaWiki:Proofreadpage-indexquality-alt/fr. C'est pour cela que je me suis permis de rechanger la traduction après consensus sur Wikisource en français qui est le premier projet concerné par cette traduction. Tu as ensuite revert cette modifications et celles de User:Thibaut120094 sur d'autres messages. Est-ce volontaire de ta part ? Si oui, pourquoi ? N'hésite pas à en discuter là bas, c'est sans doute le meilleur endroit. Cela serait bien qu'on trouve un concensus sur le sujet.

Tpt (talk)08:16, 17 February 2022

Je ne fais aucune révocation volontaire, c'est malheureusement un défaut de l'interface de TWN qui ne permet pas de présenter les historiques, ni aucune décision pour un projet donné, ou dans une langue donnée.

Quand on fait de la relecture (et il y a énormément de choses qui n'ont pas été relues dans MediaWiki, 50% des messages encore en français, avec encore de nombreuses fautes jamais corrigées depuis leur première traduction), on peut vite oublier sur quel module (coeur ou extension) on travaille, et la terminologie pour un des modules peut ne pas être cohérente avec celle d'un autre. Avec plus de 1091 modules dans MediaWiki pour plus de 40 000 messages, il faut des mois pour faire cette revue, on oublie totalement même les corrections qui ont été apportées plusieurs fois (sans même qu'on sache qu'il y a eu une annulation, ou qu'on puisse même s'en souvenir).

Bref, tant que ce ne sera pas documenté dans les pages "/qqq", il n'y a aucun autre moyen facile de savoir avec l'interface de traduction (et l'interface de l'éditeur de MediaWiki, page par page, est inutilisable pour savoir ce qui est marqué "à relire").

Ce genre d'incident arriverait à n'importe qui, et particulièrement si on contribue beaucoup TWN (j'en suis le deuxième utilisateur pour le français sur la durée totale, et constamment le premier en moyenne mensuelle depuis quelques années). Il est donc normal que quelques unes de ces modifs voient annulées, mais l'immense majorité sont des vraies traductions nouvelles, et des corrections réelles de problèmes oubliés/négligés depuis longtemps.

D'autre part, la terminologie n'est pas du tout aussi unifiée que tu le penses, et ça se voit dans la mémoire des traductions (panneaux "messages identiques" et "messages apparentées" qui ont été ajoutés dans les pages "/qqq", ainsi que ce que trouve le moteur de recherche, qui pour l'instant n'affiche pas non plus les statuts et commentaires de modifs de ces messages).

Je fais au mieux possible, mais il y a toujours des erreurs possibles. Globalement sur le volume, c'est très largement positifs, et les prétendues "erreurs" qui n'en sont pas car pas documentées et correctement suivies dont très peu nombreuses. Cela va accrocher sur un terme de temps en temps et une poignées de messages, mais c'est très faible par rapport aux milliers de messages traduits ou corrigés (et revus après coup parce qu'il y a eu aussi des changements dans le logiciel ou une autre décision communautaire qui là en revanche a fait attention à correctement unifier les choix terminologiques et à documenter ces changements pour les rendre *visibles*).

De plus le groupe "MediaWiki" est un pseudo-groupe. Il est (comme aussi Phabricator) beaucoup trop volumineux et ne devrait pas être présenté ainsi, en mélangeant tous les messages de tous les groupes inclus dedans (plus de 1091 aujourd'hui!). Cela n'aide pas du tout à progresser dans le calme et savoir où on en est: il manque sur TWN un système de "pointage" qui éviterait de se voir présenter la totalités des groupes de messages selon des filtres trop simples.

Une idée serait un système de "pointage" qui permettra à chacun de gérer des étiquettes (tags ou icones colorées) et des notes sur un groupe de messages particulier. Cela serait stocké dans les pages utilisateurs (sous-pages contenant des listes ou tables paires de clé/valeur pour chaque groupe de messages marqué) afin de suivre certains groupes particulier ou ajouter des notes perso, des liens vers des discussions passées ou d'autres sites, et pouvoir s'en souvenir.

De même TWN ne sait toujours pas gérer les notes générales relatives à un groupe de messages entier (uniquement message par message) ou à une langue particulière (uniquement en anglais supposé dans les pages "/qqq" message par message... il faudrait des sous-pages "/qqq/fr" au second niveau en permettant aux page "/qqq" d'être non pas traductibles, mais d'afficher des suppléments). On n'est donc pas aidé !

Enfin le "gadget terminologique" n'est pas encore utilisé (en version bêta expérimentale, et il pose d'autres soucis : on verra un peu plus tard mais pour l'instant il est testé sur des langues très minoritaires avec peu de contributeurs ou des langues nouvellement ajoutées, mais pas les langues déjà très avancées où il n'est pas encore utilisable)

Dernier point : si un wiki particulier a des exigences qui lui sont propres, c'est à lui de mettre en place un outil d'import plus intelligent, qui permet de mettre "en attente" des messages qui ont fait l'objet d'un consensus local et dont la modif par un import automatique pourrait lui poser problème.

TWN ne peut pas lui-même gérer des décisions contradictoires prises sur des wikis différents avec des communautés différentes (même si elles "parlent" la même langue) et surtout si ces wikis externes n'ont toujours mis en place aucun canal de retour efficace vers TWN.

D'ailleurs il est symptomatique que ces critiques dirigées moi sur quelques messages se perpétuent aussi sur TWN sur tous les contributeurs de TWN les plus actifs (pas tellement ceux qui traduisent la première fois mais qui ne relisent rien, et laissent échapper des tas de petites fautes, mais ceux qui font l'indispensable travail de relecture).

C'est statistiquement inévitable et il faut éviter de monter cela en épingle avec des menaces ou des attaques perso sur un cheveu qui néglige totalement l'important travail déjà fourni, demandant beaucoup de patience et d'assiduité et très ingrat (que pas grand monde va même remarquer et pour lequel quasi personne ne dit merci: ce travail on le croit acquis, mais il a bien fallu quelqu'un pour le faire et c'est rarement ceux qui ont mené ces attaques ou critiques dirigées sur les autres wikis, et encore moins ceux qui ensuite y alimentent ces débats mais n'ont le plus vouent jamais rien fait sur TWN, ou n'ont pas voulu s'y impliquer, de peur de devenir eux-mêmes des cibles exposées aux critiques, voir pire de subir des menaces et des blocages inopinés sans le droit même de se défendre : "décision communautaire" parait-il, mais sans procès, sans avocat, sans témoins, sans appel...).

Bref merci de garder votre calme et imaginer des solutions et aider à les mettre en place en proposant des modifications et améliorations des systèmes de coopération et de remontées d'informations. En attendant il faut discuter, parfois la solution est immédiate et ne cause aucun soucis. Je peux comprendre. Et d'ailleurs la plupart des annulations je les accepte aussitôt, même avant qu'on m'écrive ici, comme c'est le cas sur ce sujet; j'ai accepté ces corrections/annulations directement parce que j'ai eu le moyen de m'en rendre compte. Et je n'ai même pas été notifié sur TWN, ni sur aucun autre wiki de Wikimedia de telles discussions : en quoi suis-je "coupable" de quelque chose et pourquoi on vient présupposer (totalement à tord) un acte délibéré de malveillance?

Verdy p (talk)13:18, 17 February 2022
First page
First page
Previous page
Previous page
Last page
Last page