User talk:Verdy p

Archives: 2008–2009 ‧ 2010 ‧ 2011 ‧ 2012 ‧ 2013 ‧ 2014 ‧ 2015 ‧ 2016 ‧ 2017 ‧ 2018 ‧ 2019–

---

My main discussion page is on the French edition of Wikipédia. But you may write here, as I will come regularly on Meta too. See: w:fr:Discussion Utilisateur:Verdy p. Thanks.

Thoughts on automatically localized Wikipedia links

Hello. When you have a chance, could you take a look at this proposal I made last year? Lots of translateable pages link to mainspace Wikipedia articles, often hardcoding the English Wikipedia version as a tvar. I created a template that is the equivalent of {{ll}} or Special:MyLanguage for Wikipedia articles. It uses the Wikidata Lua interface to get the localized sitelink and title (which can be overridden, as in the second parameter to {{ll}}). I'd appreciate any comments/criticisms. PiRSquared17 (talk) 23:35, 19 March 2019 (UTC)

The existing "LL" templates are not used for linking to other sites, but on pages on the same wiki using another language (e.g. those using the Translate extension). "Special:MyLanguage" can often be used, but not always.

What you request is a variant to link via a Widata item, so the parameter would be a Qnnn identifier and we need a parameter to select which kind of wiki project we want to link to.

That's what the "wikibase" extension is made for (would be written in Lua, even if it's interfaced with a template, because there's no other way to query Wikidata from any wiki directly with the wiki syntax alone).

Then what would be the default language to query? is it the prefered user language, or the content language of the local wiki, or the content language of the current page (if it can be detected from the full page name including subpages names or namespace, or because the page was generated by the Translate extension).

We need to specify the various use cases, may be the "shortcut names" like "LL" for such templates is too short to be explicit enough between these options, notably if we want to avoid named parameters, use implicit defaults. verdy_p (talk) 00:57, 20 March 2019 (UTC)

Yes, I am well aware of what LL and MyLanguage are for; I was just trying to use an analogy.

The way I implemented it at the time used {{{lang|{{int:lang}}}}}, i.e. the language can be passed in as a named parameter, and otherwise it defaults to the user's language in settings. This is the same thing that Special:MyLanguage and {{LL}} (a wrapper for MyLanguage) do. However, I could see an argument for instead using the page's content language (gathered using the subpage name), because that would make the links more consistent and not dependent on the user's particular settings. So maybe that would actually be better, now that I think about it.

You can play around with my current implementation if you want. The way I've currently implemented it, the following link and text should change when you change your language setting: Universe. The following link should change, but the text should stay the same: The Universe. (I'm not at all attached to my current implementation, but it's a start I guess.) PiRSquared17 (talk) 02:19, 20 March 2019 (UTC)

Any further comments? PiRSquared17 (talk) 00:33, 23 March 2019 (UTC)

Need help about Steward requests/Global/Preload/lock1 and Steward requests/Global/Preload/lock2

Hello, @Aldnonymous: redirect me here, so i'm here to talk about a idea.

I would like for request on Steward requests/Global be simpler. Actually we must copy and past a code and we need to edit the last section and add the code..

Start january, i created this page : Steward requests/Global/Preload/lock1 and Steward requests/Global/Preload/lock2 : two preload template to use here ici. Unfortunately, inputbox extension only take second level section title (==) and only at the bottom on the page.

Aldnonymous tell me you can help me for that. Thanks again. Tomybrz Bip Bip 19:19, 20 March 2019 (UTC)

@Tomybrz and Aldnonymous: Je ne comprend pas pourquoi il faut deux modèles, alors que la page ne demande que de créer une seule section en fin de page en copiant-collant le code indiqué et remplissant l'IP demandée (dans l'appel du modèle), et la raison.

Tu dis qu'il faut modifier la section précédente, c'est là que je ne te suis plus.

Je veux bien regarder mais je voudrais être sûr de comprendre ce que tu veux faire et la raison des deux modèles (deux variantes différentes pour des demandes de types différents?). En regardant ta page User:Tomybrz/draft je vois que cela correspond à deux boutons différents, chacun avec som modèle de preload. Bref c'est ou l'un ou l'autre, pas deux en même temps.

Dans les deux cas c'est pour faire une nouvelle demande et cela me semble normal que ce soit pour créer une nouvelle section (on n'a donc pas besoin d'un titre de second niveau pour utiliser l'inputbox), mais au besoin on peut malgré tout renseigner le titre de la section à créer: c'est peut-être ce qui te choque car on doit rééditer la section créée pour en changer le titre ou parce que la prévisualisation est limitée dans ce cas et qu'on peut encore améliorer le texte de la raison donnée, ou ajouter des IP pour une requête multiple, de la même façon qu'on peut répondre à la demande faite en postant dessous (n'importe qui réédite cette section, ne serait-ce que pour approuver d'un vote signé la demande).

Bref il ne faut peut-être pas trop compliquer: prérenseigner correctement c'est déjà bien mais n'interdit pas de modifier/compléter (et de toute façon cette section est déjà destinée à être modifiée à plusieurs reprises par différentes personnes pour donner suite à la demande).

@Aldnonymous: Sorry for the reply here in French, because I was first pinged here in French. But I may continue in English without problem if Tomybrz agrees. verdy_p (talk) 22:32, 20 March 2019 (UTC)

Its fine, please do speak in the language you are most comfortable to use :) --AldNonymous^Bicara? 04:05, 21 March 2019 (UTC)

Re: open proxies

(sweeping this one in from SRG)

I've withdrawn the steward request if you haven't seen my comment yet. I completely understand your concerns (and if you will, please accept this as an apology) and I'd like to apologise if I appeared overly agressive. Despite this, I disagree with the notion that the request was abusing the request system (is this unjustified enough, or are you not willing to abide by your own terms?) or that I was wasting the stewards' time. Spam is spam to me - what's the point in contacting editors that are presumably automated programs? I myself don't believe spambots/automated programs should be treated the same way as, say, the one-time vandal/promotional spammer that hopped between three wikis (you seem to be describing processes set in place for users like that; I respect those processes and abide by them in most circumstances); it's for the same reason that spambots that have only edited on one wiki are locked and open proxies are blocked even if they haven't edited (though I'll acknowledge that these IPs were from ISPs as you described) without prior discussion.

I have no issue with the IPs themselves at this moment in time. However I don't think you were wholely in the right (and I obviously wasn't either). Hiàn (talk) 01:44, 4 April 2019 (UTC)

The main reason is that you did not demonstrate that these were "open proxies". just single isolated IPs performing different edits with different concerns, and not on topics typically concerned by "spam" (what you insist on). Looking at those edits, these are independant users making independant edits in different time, from differenty locations, on separate topics, using different language levels/style, but not posting any "spam" (even if there were some links posted, these links were not found on other pages, and their placement on the edited pages were on topic). So your only concern is that you find these edits are not suitable for you, and that's why this should be discussed with the community. For me these are individial users, making their first few edits, and that should be guided and helped, insterad of banning them directly. The community is there to help and we must not exclude people for such reason, even if you think what they did was not correct or not the best way. And given that no one evert contacted them, they merit being treated fairly. That's what a community is made for: it exists also because it allows newcomers to start editing and we must encourage them and then invide them to discuss, but for that you must discuss with them. Refrain yourself exclusing all editors that just don't have your same style, or have different interest from you.

The help page about open proxies and how to welcome new users should help you. The stewards are not there to solve such issues that have not been demonstrated, and notably because you did not even tyry to discuss these cases with other people on your communities of interest. Note: NPOV is also a global policy, and you must accept a normal level of opposite opinions, even if you don't agree with them. So be fair. Every one has a right to speak, opinions have their place provided they are not imposed by force or threatening others. If you disagree with something ask editors to give some third party evidences. You must learn to discuss. verdy_p (talk) 03:08, 4 April 2019 (UTC)

Do you remotely know what spam is? I'm going to reiterate what I said one more time, this is spam made by automated programs. Have you seen wikt:simple:Special:Log/spamblacklist? The spam logs are there for a reason. If you legitimately mean to say they weren't spamming then I have no intention on discussing with you. The IPs I pulled were from that list. The community has long decided that it's not worth dealing with automated programs. The community has long decided that it's not worth entering discussions over how to welcome blatant spambots. It's not whether it is suitable to my liking or not. Literally every wiki doesn't think it's worth dealing with spambots - to welcome, guide and help automated programs. How many times must I reiterate that? Spam is spam. Simple enough, no? Is it worth wasting time on nothing? Automated spam won't reply. Automated spammers aren't editors. Perhaps what you need to learn is distinguishing between spambots and human editors.

And stop attacking me with little basis. I've made my point clear severalfold. These IPs were spamming - they were not simple vandals (I wouldn't block or request a lock if that was the case). I am by no means suppressing their opinion by force. I am by no means not tolerating their "opposite opinions". News flash - they're bots, not humans. It's not in your place to dictate how the community I'm part of runs. No one in their right fucking mind would consider negotiating with spambots. Enough said?

Because apparently we should treat all spambots as humans. And their attempt to create spam pages (with often blacklisted links) should be treated as their first edits (oh, how nice!) and them expressing their opinion. And getting them locked should be treated as suppressing their opinion and not adhering to NPOV.

You've made your point clear. I'll stay clear of whatever shit you decide to bring up in the future. Hiàn (talk) 19:43, 4 April 2019 (UTC)

I've not attacked you. I just said that you did not provide any evidence (and this is absolutely not a change of community policies that require such evidences). So don't start being unsulting as you just made here. I've been polite, you are no longer. verdy_p (talk) 15:30, 6 April 2019 (UTC)

The Affiliate-selected Board seats process welcomes your support

Hello. You are receiving this message because you are active in the field of translations <3 The movement needs you! The Nominations phase has started for the ongoing selection process of two Board members, and the timeline is quite tight.

A Translation Central is available to help translators figure out what's been covered and what's left to do. Over the course of the next few weeks, your attention on candidates' profiles is particularly welcome.

While there are four languages that are especially relevant for multiple affiliates (namely Arabic, French, Russian and Spanish), you can also add others. If you can't help: please see if you know anyone in your circle who could, and spread the word :) Thank you! Elitre (WMF) and Facilitators of ASBS 2019, 13:20, 18 April 2019 (UTC)

The Research team could use your help

Hello. You are receiving this message because of your recent activity in the Translations namespace.

The Wikimedia Research team is developing a new algorithm that automatically recommends sections for editors to add to articles. Translations have already occurred for some of the few languages that we are testing in, except for Spanish and Russian. If you have some time in the next few days, please consider translating the short message (only 6 items) we aim to send out soon, in one or both of these languages. (And if you feel like you want to support your tester peers even more, you can do so by taking care of the related instructions page.)

Thank you! Jonathan Morgan & Diego Saez-Trumper, Wikimedia Foundation Research - 18:14, 19 June 2019 (UTC)

tpt-languages-separator/fr

Hi Verdy_p, do you happen to remember why you created tpt-languages-separator/fr using a   instead of  , as the other versions of that message used? Would you be opposed to switching it to the numeric form (or changing the others to the named entity) for consistency? (I would have asked this on TWN itself, but I am by no means a translator, and it looks like that's necessary to be able to actually leave messages there?) 「ディノ奴千？！」^{☎ Dinoguy1000} 21:50, 22 June 2019 (UTC)

There's a context of use in which named entities are not recognized (the string is not always passed though an HTML parser, but sometimes has to be processed in Lua, which only interpret numeric entities). And for now that cannot be fixed eaily in these Lua modules, even if both are treated correctly by Mediawiki and by standard HTML parsers in browsers.

Note that in other contexts, neither is correct, because the actual character used in French is U+202F/NNBSP (and not U+00A0/NBSP and not even THINSP which is breakable!) for most punctuations (but not this one).

Now this is quite old (5 years and never changed after my initial setting), the reasons at that time may no longer apply today. verdy_p (talk) 21:54, 22 June 2019 (UTC)

Yes, I know, Sardinian is Romance Language not Slavic

Hello! I've never set the Sardianian Wiktionary in the Slavic languages section, but in the "locked editions" of the Romanic languages projects, after Rhaeto-romance Wiktionary, section that you have already deleted. --Limotecariu (talk) 12:00, 28 June 2019 (UTC)

Other locked versions are kept in their family, just sorted at end of them and not "counted". verdy_p (talk) 12:01, 28 June 2019 (UTC)

Please translate the Editing newsletter

Would you please translate VisualEditor/Newsletter/2019/July into your favorite language for me? I'd really appreciate it. Whatamidoing (WMF) (talk) 17:30, 19 July 2019 (UTC)

Main page and the Universal language selector

Hello, Verdy p,

the language selector works for sr but doesn't work if a user manually select sr-ec or sr-el. It works with uselang=sr-el&variant=sr-el, but even then the translated main title of the page is not transliterated from Cyrillic to Latin script.

I've noticed that the Universal Language Selector doesn’t work automatically, even if it did work almost a year ago.

I've read that "Universal Language Selector is no longer using setlang URL parameter." (mw:Wikimedia Language engineering/Reports/2015-September#Development update), which is probably why Special:MyLanguage do not work automatically with the internationalisation set by the user in preferences.

Also, the Template:Main Page/Sisterprojects doesn’t function, at least for me, since it doesn’t redirect to local languages. But it functions on its own, at Шаблон:Main Page/Sisterprojects/sr.

I’ve helped to solve similar situations at mw:Template_talk:Languages#Croatian_language and at testwikidata:MediaWiki talk:Mainpage/hr.

I realize now that special:diff/19315218 will not solve the issue, but I think it is correct. Hope you could help. Thanks in advance. Truly yours, -- Nesmir Kudilovic (talk) 14:58, 21 August 2019 (UTC)

I don't know you say it's not working. "?uselang=*" in the URL parameter still works for me to select a UI translation (independantly of the use of "variant=*" to select a transliteration of the page content, but not the UI).

I've not used any "uselang=*" parameter in the URL, it was only the name of a template parameter which was used long before ULS was deployed and is still used today, even if the URL parameter has appeared and was named differently.

Yes there was a time where the URL also accepted "uselang=*" parameter, to match the name of the parameter of older templates, but this alias was removed and should not affect how the wiki is displayed if you use the correct name in the URL (no need to change the template parameter name). verdy_p (talk) 15:10, 21 August 2019 (UTC)

May be there exists some pages in wikis that use the incorrect URL parameter name, but it's easy to fix. I don't think there is such case in existing templates. But you don't provide any example link to a page where the link does not work as expected. verdy_p (talk) 15:12, 21 August 2019 (UTC)

The problem is just that with Special:MyLanguage, the setlang=* is used, not the uselang which works. -- Nesmir Kudilovic (talk) 15:13, 21 August 2019 (UTC)

Ok so this cannot be fixed in the wiki by editing pages. If the bug occurs in the link displayed in any special page, you need to submit a bugreport for the Mediawiki extension implementing it.

But really "Special:MyLanguage/*" is not supposed to use any other language than the user's own language (in his preferences or when the user selects himself the language with the ULS), so it should not even use "uselang=*" or "setlang=*".

Most probably if you see differences now, it's because that extension was changed (but I've never used "Special:MyLanguage/*" with any language parameter). verdy_p (talk) 15:17, 21 August 2019 (UTC)

Also I've checked "Template:Main Page/Sisterprojects" and it's working perfectly. Most probably your personal page has some custom settings (CSS/Javascript), or some other quirky preferences incorrectly set in your user account that causes it not to work. Do you experiment errors reported in the browser's javascript console ? Are you sure this is not caused by a bad plugin in your browser ? verdy_p (talk) 15:25, 21 August 2019 (UTC)

Example, I set up a different language on Meta-Wiki, lets say Bosnian language, and the Special:MyLanguage doesn't open that translation on entering (as logged-in user). It opens in English from the link at sr.wikipedia, so the automatic part doesn't work.

As for the browser, it is very easy that my custom .css is making the trouble. I will check that, thanks for the replies. -- Nesmir Kudilovic (talk) 15:32, 21 August 2019 (UTC)

if you use "Special:MyLanguage/anypage" it will open the "anypage/*" translation which is available in your language (as set in your user preferences), or one of its predefined fallback. It is not supposed to set or change the "uselang=*" parameter (which is already the user's language by default set for the UI). "Special:MyLanguage/*" avoids using many costly "#ifexist" to see if a page has a trnaslation or not, and then redirect you to that translated page. Now if you provide a "variant=*" or "uselang=*"parameter to the link, it will be used to render the found translated page (whatever language it is) in order to customize its UI (uselang=*") or the transliteration (variant=*") but it does not change the target page on which they will go (if you edit the page, the edited page will be the page found by "Special:MyLanguage/anypage" i.e. "anypage/(lang)" with the language matching the found translation, independantly of the "uselang=*" parameter for its surrounding global UI, or the "variant=*" to transliterate it (transliteration is based on the exiting page content and does not modify it, and an automated process on the wikiserver side, but the original script of the edited page will be shown and saved as is; variant transliterators are implemented only for specific languages and specific wikis on which they have been installed and allowed, and you know that there's such transliterators available with additional tags at top of the page).

Note that "setlang=*" was working before but it's effect was like "uselang=*" but permanent: it was modifying also the user's preference (with explicit consent by just following a link anywhere on a page, even if there was a notification displayed at top of page that the current user language was changed, but without details if the change was kept resident). It's no longer possible for a page to force such change by just clicking on a link (because if the user then cliock the "back" button, it will not return to the page where it was with the same language): users must change their preferences themselves explicitly, by explicitly changing their settings in preferences of by using the ULS interface. The functionality of "uselang=*" however has been kept because it's temporary and does not change the user's prefered language. verdy_p (talk) 16:12, 21 August 2019 (UTC)

Seems it partially works when the translatable page is transcluded in an ordinary (ns:0) page, like in Glavna strana (sr-el), Главна страна (sr-ec). I haven't been successful with Glavna stranica (hr). Thanks for the time you invested in this conversation with me. I've noticed the combination of Special:MyLanguage and setlang occurs when using the ULS on the top of the page (left from the user (name) page). Hope this all helps. Best wishes. -- Nesmir Kudilovic (talk) 19:56, 21 August 2019 (UTC)

I have no problem at all with the page Main_Page/sr which can be displayed in Serbian Cyrillic, Serbian Latin, and Croatian (or Bosnian Latin and Bosnian Cyrillic) without any problem (the translations come from the existing translated pages).

Not problem either with the page Main_Page/hr (which is where Glavna stranica goes) but if you don't see Serbian Cyrillic there, it's simply because it's only translated in Croatian and there's no Serbian Cyrillic version of this Croatian page).

Note that transliterators (variant=*) are not installed in Meta because they are very language-dependant (and using it on Meta would not work with many of its other hosted languages). So Meta has pages translated in their base language only (like /hr or /sr) or can have specific scrtipt variant created (like sr-cyrl, and sr-latn; note that sr-ec, and sr-el are NOT compliant BCP47 codes, they are only used as legacy codes in Wikipedia but anywhere else these codes would just mean "Serbian as spoken in Ecuador" or in "Greece" (with the special assignment of EL in addition to standard GR to Greece for the EU usage), but does not qualify at all to select any script or orthographic variant according to the BCP47 standard (note that none of "sr-ec", "sr-el", "sr-latn" and "sr-cyrl" are part of ISO 639; only "sr" is in ISO 639 and BCP47, and "sr-latn"/""sr-latn" are in the BCP47 standard; note also that BCP47 or ISO 639 allow codes to be in any lettercase but they have strong rules about their allowed format). verdy_p (talk) 20:11, 21 August 2019 (UTC)