User talk:Verdy p

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Template:ISO 3166-2/FR[edit]

Hi Verdy. I see you're an editor at {{ISO 3166-2/FR}}, and was wondering if you could take a look at it and some of the other lang subtemplates, as they are showing "LangSwitch Error: no default". I can't figure out what the problem is. Cheers! Huntster (t @ c) 22:11, 29 April 2021 (UTC)[reply]

Comeone broke an important subtemplate: the switch could not properly resolve the defaults and multiple cases having the same return value. verdy_p (talk) 22:41, 29 April 2021 (UTC)[reply]
Thank you for looking into this so quickly and finding the solution. It's greatly appreciated! Huntster (t @ c) 23:00, 29 April 2021 (UTC)[reply]
Note: I had submitted the change made in the "sandbox" version of the base Template:LangSwitch (with which it is fully upward compatible) but it was unexpectedly reverted in the sandbox, while my version in the sandbox should have been imported in the base version: it is compatible simply because it just allows each parameter key used for cases (before the equal sign) to contain punctuation separators (like comma, semicolon, slash...) between language codes; this works because none of these separators are allowed in any valid language codes (which can only contain ASCII letters, digits or hyphens). This possibilty is still not offered in the base template (which is locked for editing, but does not properly validate the splitted keys as valid codes, even if it recognizes slashes as a separator; also the existing code is slower, and more memory intensive).
The implementation of the templates are in Lua modules of the same name, the significant difference is in that module:LangSwitch/sandbox (starting at line 111, and properly commented there, including the notice of change at top of the module).
The alternative would require duplicating many lines in LangSwitch that are mapping different language codes (including the special "default") to the same return value. This saves a lot in terms of cost for tempalte expansions like this one (but can be useful in general for any other use of Template:LangSwitch when multiple languages are returning the same translation. verdy_p (talk) 23:29, 29 April 2021 (UTC)[reply]
You updated the sandbox, but has there been any discussion on the module's talk page about actually porting it over? Honestly, I used to love working with templates, but the added complexity of modules killed it for me. Huntster (t @ c) 00:20, 30 April 2021 (UTC)[reply]
This was made long time ago. Sometimes users don't look at the difference, and the update policies are different across wikis, so differences are not managed centrally. Various people don't care and in fact there's still no central discussion space across wikis to track the needs. This will come later but there's some work for wikifunctions that will allow comparing features and extendinfg the docs (and integrate fixes that were tested since long but never committed in the main version). Some people think that what is accurate for English Wikipedia (which is actually monolingual and doesn't care much aboui international sites) will be accurate for other wikis, so they make false assumption. Thanks there's an history and we can still look at what was fixed but broken by such assumption. verdy_p (talk) 07:24, 30 April 2021 (UTC)[reply]

Category:The_Cayman_Islands[edit]

Category discussion warning

The Cayman Islands has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category.

In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!


2A02:2F05:110B:4400:B51C:8256:CF04:3F97 20:20, 18 May 2021 (UTC)[reply]

We need your feedback![edit]

Hello. Apologies if this message is not in your native language: please feel free to respond in the language of your choice. Thank you!

I am writing to you because we are looking for feedback for a new Wikimedia Foundation project, Structured Data Across Wikimedia (SDAW). SDAW is a grant-funded programme that will explore ways to structure content on wikitext pages in a way that will be machine-recognizable and -relatable, in order to make reading, editing, and searching easier and more accessible across projects and on the Internet. We are now focusing on designing and building image suggestion features for experienced users.

We have some questions to ask you about your experience with uploading images here on Wikimedia Commons and then adding them to Wikipedia. You can answer these questions on a specific feedback page on Mediawiki, where we will gather feedback. As I said, these questions are in English, but your answers do not need to be in English! You can also answer in your own language, if you feel more comfortable.

Once the collecting of feedback will be over, we will sum it up and share with you a summary, along with updated mocks that will incorporate your inputs.

Also, if you want to keep in touch with us or you want to know more about the project, you can subscribe to our newsletter.

Hope to hear from you soon! -- Sannita (WMF) (talk to me!) 09:56, 2 August 2021 (UTC)[reply]


Code issues in User:Verdy p/common.js[edit]

Hi Verdy p, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

  1. You edited User:Verdy p/common.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
  2. Though, that change appears to introduce 2 new jshint issues — the page's status is now having warnings. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
  3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
  1. ISSUE: line 43 character 37: The object literal notation {} is preferable. - Evidence: var NavigationBoxes = new Object();
  2. ISSUE: line 64 character 18: Don't make functions within a loop. - Evidence: });

Your CommonsMaintenanceBot (talk) at 12:36, 7 August 2021 (UTC).[reply]

Bad reports. "jshint" is completely WRONG in the two listed "issues" :
  • a literal "{}" is NOT equivalent to a "new Object()" (not the correct parent class: "{}" does not define "Object" as its defining protype class).
  • there's NO loop bug in the "evidence", as it is correct syntax for an event handler to terminate the local function definition, and closing the function call to set this locally defined handler. The handler needs a closure with the current value of a variable inside each loop, each loop needing a different index value. We really need to redefine the local function at each loop to provide different values, that very small function cannot be extracted outside the loop !
This code for my PERSONAL pages is WORKING and has been tested since years on MANY wikis. verdy_p (talk) 12:41, 7 August 2021 (UTC)[reply]

Data:DateI18n.tab[edit]

Hello Verdy p, I have reverted your edits to Data:DateI18n.tab because they broke compatibility with older versions of Module:DateI18n. That translation data is used across dozens of other wikis, and none were updated to support it. AntiCompositeNumber (talk) 23:20, 6 September 2021 (UTC)[reply]

I don't know why, the format is the same. is that caused by renamed keys in the datatable (using 'hms' instead of 'HMS', because 'M' is ambiguous between mintues and months and I fixed a case here in Commons where an 'M' caused failure)? Can you cite these external wikis that don't work with that? Isn't it simple for these wikis to support the new names with 'hms' (and alias only existing ones using "M" for month, only for compatibility with legacy data)?
This is not a "good faith edit with false assumptions". I made many tests, but of course I was not aware that external wikis could use this data. Fixing supported keys should be easy. And I initially planned to support additional date/time formats (that require this distinction, notably formats for time only).
verdy_p (talk) 23:28, 6 September 2021 (UTC)[reply]
@Verdy p: If you look at s:bn:লেখক:কেনেথ সোমারলেড ম্যাকডোনাল্ড, a page for an author on the Bengali Wikisource, you will see that the birth date ("জন্ম তারিখ") on the right-hand side now has stray single quotes within that were not present prior to your edits. Mahir256 (talk) 00:06, 7 September 2021 (UTC)[reply]
This should not happen, single quotes for litterals were needed since long in multiple languages (and supported in the module) before my edit in many formats. The module correctly convert them to ASCII double quotes just before calling the #time parser function: so the module version in Bengali wiki has a bug if it does not do this conversion. verdy_p (talk) 00:11, 7 September 2021 (UTC)[reply]
The module on enwiki does the same thing, by the way. Asserting that every other module with identical source code to that currently on bnwikisource had a bug prior to your edits (especially when the single quotes in my example above did not appear until after those edits) seems rather dishonest. Mahir256 (talk) 00:13, 7 September 2021 (UTC)[reply]
Using bird names is dishonnest. Single quotes were used in tabular data since very long in many languages (may be not in Bengali language, but then you did not test what happened when rendering other languages in the same Bengali wiki).
And there's NO problem in the English Wikipedia as you state. So show real proofs instead of making assumptions. The only possible breaking change was renaming TWO legacy keys using 'HMS' into 'hms'. It's not at all a problem of formats where single quotes for litterals should work as is (and they do work in other wikis), without needing them to use double quotes (that need to be escaped with backslash in JSON strings).
Here's your proof. Have fun trying to get the template changed there. Mahir256 (talk) 00:30, 7 September 2021 (UTC)[reply]
This is also a bug here in English Wikipedia: it does not always change single quotes for litterals into double quotes, it does it ONLY for litterals inside values given as JSON tables. And this is NOT sufficient for various languages that need to embed litteral text in simple date formats (not using JSON subtables): see languages adding affixes or words with Latin letters (reserved by #time: these words or affices must be escaped within ASCII double quotes in #time, but ASCII double quotes do not work in Tabular data where ASCII single quotes are used instead)! verdy_p (talk) 00:40, 7 September 2021 (UTC)[reply]
Also you should know that, unlike Javascript or Lua, strings in JSON can only be delimited by ASCII double quotes, not single quotes, and that the MediaWiki #time parser function also accepts only ASCII double quotes for litterals (that would also need to be escaped (within JSON subtables encoded as string values for the Tabular data format, this would require double-escaping the double quotes around #time litterals, and this would not be easily editable!). That's why single and double quotes are handled specially, as documented (and this was already the case since long before my edits patiently tested with many cases). verdy_p (talk) 00:18, 7 September 2021 (UTC)[reply]
This attempt to deflect blame does not change the fact that you broke things, and then edit warred your brokenness back in even after knowing that you had broken things. Besides, why should the English Wikipedia care about how to properly format dates in non-English languages? Pppery (talk) 03:06, 7 September 2021 (UTC)[reply]
I do not "deflect blame" as you state in an agression. I've not broken anything.
But tried to find a solution (when it was correctly reported that EN.WP had a problem with it) by just removing the single quote in the data for English specifically (because the module itself on EN.WP cannot be fixed). This is not an "edit war" and there was no revert but a real fix for that case.
Even the English Wikipedia will have to support other user languages with this data. Not all is in English. And I've definitely NOT broken the compatibility. The bug remains in the module loaded in those wikis (and you ask to fix the modules on those wikis, but in English Wikipedia it is not modifiable). It's a fact that the fix for non-working single quotes (documented) is very simple in the module: basically one line of code to move down. If English Wikipedia needed to format dates only to English, it would not even need that DateI18n data at all !
And it's also a fact that that Wikipedia does not properly synchronize data. I made lot of tests and isolated this bug to fix it here. But you reject the fault to me, that's really unfair. verdy_p (talk) 09:36, 7 September 2021 (UTC)[reply]
You were informed that your changes broke compatibility with other wikis, but you decided to reinstate those changes. This, predictably, broke templates on dozens of other wikis. When you were again informed that your changes broke templates on other wikis, you doubled down instead of self-reverting or otherwise helping to fix the problem. Considering your previous blocks for edit warring and the discussions in User talk:Verdy p/archive16 and User talk:Verdy p/archive17, I am revoking your template editor rights in accordance with Commons:Template editor § Revocation. You may request the right again at COM:RFR. To the reviewing administrator: I suggest that Verdy p not be granted template editor unless they have refrained from edit warring or controversial changes without prior discussion for at least 6 months – 1 year. --AntiCompositeNumber (talk) 16:03, 7 September 2021 (UTC)[reply]
No I asked for details, they were not given initially. I had made many tests, and found no failure. And this was not an edit warring at all. Things should have been documented first before assuming that this was causing problems elsewhere. I talked about the fixes I made. I hjad even included compatibility code since the beginning. The bug is actually not on this wiki but other wikis where I did not edit their local copy of the locked module. I had found a bug causing by 'M' when parsing dates where there was a confusion between months and minutes. So I made many tests to see how to fix it. One of the step was to make sure that the data table was editable, and working as expected (and it was). Making this table clearer and keeping it easily editable was also a goal I kept. The intent was to support more date formats (than those that existed today, and that are sitll continuing to work nad be supported as they are). I added some missing documentation to make things clearer (after checking all the assumptions). It's always frightening to fix things and find later that some other external site do not work, but this was not expected and had to be demosntrated. It diod not cause damage for long as the gix was fast to do, I did not leave the bug as is, leaving thze task to others. verdy_p (talk) 16:19, 7 September 2021 (UTC)[reply]

Plus que quelques jours pour participer à Wiki Loves Monuments France ![edit]

Bonjour,

Le concours Wiki Loves Monuments France est ouvert pour une semaine encore, jusqu'au 30 septembre. Déjà plus de 6 000 photos ont été importées cette année alors vous aussi rejoignez le concours ! Cette campagne de contribution concerne tous les monuments et objets mobiliers présents dans la base Mérimée et dans la base Palissy. De l'imposant château aux ruines industrielles, de la verrière décorative au reliquaire, c'est un impressionnant patrimoine qui attend d'être photographié et documenté. Vous pouvez dès à présent mettre en ligne autant de photos que vous le souhaitez de ces monuments et objets du patrimoine français. Nous attendons vos photos avec impatience !

Les plus belles photos seront sélectionnées par un jury national composé d'amateurs et de professionnels, de contributeurs à Wikimedia Commons et d'acteurs du patrimoine. Un jury international constituera ensuite une sélection des meilleures photographies mondiales.

Si vous avez des questions, l'équipe organisatrice se fera un plaisir d'y répondre.

P.S. : vous recevez ce message parce que vous avez participé au concours Wiki Loves Monuments en France

MediaWiki message delivery (talk) 12:34, 26 September 2021 (UTC)[reply]