|
2019-02-20 11:58:16
|
<Samwalton9>
|
I'm having some issues with a database query, can someone sanity check that I'm not missing something obvious?
|
|
2019-02-20 11:58:32
|
<Samwalton9>
|
https://quarry.wmflabs.org/query/33585 is returning zero results, but the user has clearly made edits: https://en.wikipedia.org/wiki/Special:Contributions/Craub
|
|
2019-02-20 11:58:42
|
<Samwalton9>
|
If I change "Craub" to "Samwalton9" my edits show up no problem.
|
|
2019-02-20 11:59:25
|
<bawolff>
|
Samwalton9: Its been more than 30 days
|
|
2019-02-20 11:59:36
|
<bawolff>
|
Recentchanges only has last 30 days. use the revision table instead
|
|
2019-02-20 12:00:00
|
<Samwalton9>
|
Ah, of course - thank you!
|
|
2019-02-20 13:43:52
|
<The_Photographer>
|
hi
|
|
2019-02-20 13:44:29
|
<The_Photographer>
|
Is there a stipulated time for this? https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress/Wilfredor
|
|
2019-02-20 13:45:01
|
<The_Photographer>
|
I need to make some contributions, however, I am blocked during this process
|
|
2019-02-20 13:49:20
|
<Zppix>
|
The_Photographer: I think (I could be wrong) but it just based upon how long it takes for the change to be accepted by all the databases
|
|
2019-02-20 13:50:32
|
<The_Photographer>
|
Could it take a week more?
|
|
2019-02-20 13:58:49
|
<Zppix>
|
The_Photographer: I think it depends on edit count
|
|
2019-02-20 14:15:29
|
<The_Photographer>
|
Zppix: there is a photo contest and if I do not upload the photos in the next week, I will not be able to compete
|
|
2019-02-20 14:16:52
|
<Zppix>
|
The_Photographer: im reaching out to find someone who would know more
|
|
2019-02-20 14:17:59
|
<[1997kB]>
|
Zppix, The_Photographer, it's being resolved.
|
|
2019-02-20 14:19:05
|
<Zppix>
|
Thank you! [1997kB]
|
|
2019-02-20 14:19:38
|
<[1997kB]>
|
https://phabricator.wikimedia.org/T215107
|
|
2019-02-20 14:20:08
|
<[1997kB]>
|
a patch is for review.
|
|
2019-02-20 14:23:29
|
<Zppix>
|
The_Photographer: once the patch above is reviewed your rename progress should continue, sadly theres not much more that can be done
|
|
2019-02-20 14:23:32
|
<Zppix>
|
(afaik)
|
|
2019-02-20 14:54:32
|
<superyetkin>
|
is there anyone who can help with https://phabricator.wikimedia.org/T203158 ?
|
|
2019-02-20 14:55:29
|
<The_Photographer>
|
Zppix: ok thanks
|
|
2019-02-20 14:58:42
|
<Zppix>
|
superyetkin: looking sorry for the delay
|
|
2019-02-20 14:59:20
|
<Zppix>
|
oh yes, i remember this have you tried greping (or searching) the code for something could be related to this?
|
|
2019-02-20 15:00:07
|
<superyetkin>
|
I implemented the uca-tr change mhyself
|
|
2019-02-20 15:00:29
|
<superyetkin>
|
but I am not sure if there is a better optiomn to represent the alphabet
|
|
2019-02-20 15:00:40
|
<wm-bot>
|
Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: @Tonina_WMDE & @tgr - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-02-20 15:00:55
|
<superyetkin>
|
I mean something else rather than uca-tr?
|
|
2019-02-20 15:01:23
|
<Zppix>
|
superyetkin: that would have to be discussed with the people the change would affect in my opinion
|
|
2019-02-20 15:01:43
|
<superyetkin>
|
oh, this is clearly a bug
|
|
2019-02-20 15:02:04
|
<Zppix>
|
superyetkin: wait, im lost, i thought you said you already implemented the change?
|
|
2019-02-20 15:02:11
|
<superyetkin>
|
The Turkish alphabet has the letter � (capitalized as I)
|
|
2019-02-20 15:02:27
|
<superyetkin>
|
let me clarify
|
|
2019-02-20 15:02:41
|
<bawolff>
|
opens the bug
|
|
2019-02-20 15:02:47
|
<Zppix>
|
superyetkin: Oh i see now
|
|
2019-02-20 15:02:54
|
<superyetkin>
|
I implemented the category sorting routine by adjusting the configuration to uca-tr
|
|
2019-02-20 15:02:57
|
<Zppix>
|
bawolff: you got this?
|
|
2019-02-20 15:03:09
|
<superyetkin>
|
but this issue appeared then
|
|
2019-02-20 15:03:32
|
<bawolff>
|
yeah, i can take a look. I worked on the code that decides which letter is the uppercase variant back in the day
|
|
2019-02-20 15:04:23
|
<Zppix>
|
bawolff: thanks... superyetkin bawolff will be able to help you better than I can he has a lot more expierence with mediawiki than i.
|
|
2019-02-20 15:05:58
|
<superyetkin>
|
ok, thanks
|
|
2019-02-20 15:12:38
|
<bawolff>
|
superyetkin: Let me make sure I understand correctly, there's the letter ý, and it should be shown as I in the category section letters, but instead is being shown as ı?
|
|
2019-02-20 15:14:38
|
<bawolff>
|
wait, no
|
|
2019-02-20 15:15:26
|
<bawolff>
|
The issue is, that on the page https://tr.wikipedia.org/wiki/Kategori:Bat%C4%B1_Asya_%C3%BClkeleri the section with "Irak" in it, should come under the header "I" but instead its coming under "ı"
|
|
2019-02-20 15:18:25
|
<superyetkin>
|
yes, the letter � is not capitalized
|
|
2019-02-20 15:18:57
|
<superyetkin>
|
shall we continue here or in a private session?
|
|
2019-02-20 15:20:14
|
<bawolff>
|
Better here, as if I say something wrong, people can correct me
|
|
2019-02-20 15:21:17
|
<bawolff>
|
Is "ý" considered the same letter as "ı"?
|
|
2019-02-20 15:22:43
|
<superyetkin>
|
the characters you type are not shown correctly
|
|
2019-02-20 15:22:47
|
<superyetkin>
|
let me retype them
|
|
2019-02-20 15:22:59
|
<superyetkin>
|
the capitalized version of � is I in Turkish
|
|
2019-02-20 15:23:12
|
<superyetkin>
|
and the same goes for i and �
|
|
2019-02-20 15:23:21
|
<superyetkin>
|
the latter works fine
|
|
2019-02-20 15:23:30
|
<superyetkin>
|
with uca-tr, I mean
|
|
2019-02-20 15:24:02
|
<superyetkin>
|
I am not sure if the standard (uca-tr) supports it or not
|
|
2019-02-20 15:24:40
|
<bawolff>
|
oh right, because ý has the code point in iso-8859-1 that ı has in iso-8859-9
|
|
2019-02-20 15:24:59
|
<bawolff>
|
so I got confused
|
|
2019-02-20 15:25:12
|
<bawolff>
|
but i understand what you mean now
|
|
2019-02-20 15:30:51
|
<superyetkin>
|
so, do you think the problem is in the uca-tr definition?
|
|
2019-02-20 15:38:13
|
<bawolff>
|
I think its more a MW problem
|
|
2019-02-20 15:39:10
|
<bawolff>
|
still refamilarizing himself with how the icu collation code works
|
|
2019-02-20 15:40:47
|
<superyetkin>
|
wow, how can you do this, by the way?
|
|
2019-02-20 15:40:58
|
<superyetkin>
|
to make the text "* bawolff still refamilarizing himself with how the icu collation code works" appear there?
|
|
2019-02-20 15:41:13
|
<bawolff>
|
use /me
|
|
2019-02-20 15:41:22
|
<bawolff>
|
/me still refamilarizing himself with how the icu collation code works
|
|
2019-02-20 15:41:59
|
<superyetkin>
|
trying to solve T203158
|
|
2019-02-20 15:42:12
|
<superyetkin>
|
hmm, thanks
|
|
2019-02-20 15:44:27
|
<bawolff>
|
I think maybe it might be related to the definition at https://github.com/unicode-org/icu/blob/master/icu4c/source/data/coll/tr.txt
|
|
2019-02-20 15:45:25
|
<bawolff>
|
err maybe not
|
|
2019-02-20 15:46:11
|
<bawolff>
|
err nevermind
|
|
2019-02-20 15:46:13
|
<bawolff>
|
that's unrelated
|
|
2019-02-20 15:50:18
|
<wm-bot>
|
Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @Tonina_WMDE & @tgr - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-02-20 15:53:07
|
<hauskatze>
|
hi mainframe98 :)
|
|
2019-02-20 15:53:29
|
<mainframe98>
|
Hello hauskatze
|
|
2019-02-20 16:00:28
|
<Tonina_WMDE>
|
We had two topics added prior to the meeting and we will start with those.
|
|
2019-02-20 16:00:28
|
<Tonina_WMDE>
|
Hi everyone and welcome to this week's Technical Advice IRC Meeting with me and @tgr o/
|
|
2019-02-20 16:01:00
|
<tgr>
|
Hi all!
|
|
2019-02-20 16:01:15
|
<mainframe98_>
|
Hello
|
|
2019-02-20 16:01:18
|
<superyetkin>
|
can you look at https://phabricator.wikimedia.org/T203158 ?
|
|
2019-02-20 16:04:10
|
<mainframe98_>
|
Right, I had a question related to identifying wikis in a multi-wiki environment, like WMF for example. How does one identify one wiki from another? Using $wgDBName does not work in setups with table prefixes, but the recent changes to wfWikiId and Wikimap don't convince me that it is the better solution
|
|
2019-02-20 16:05:03
|
<Tonina_WMDE>
|
I think tgr had an idea about that ^
|
|
2019-02-20 16:05:13
|
<bawolff>
|
Typically we used DBName-DBPrefix format
|
|
2019-02-20 16:05:35
|
<tgr>
|
internally MediaWiki either uses wfWikiID() or DatabaseDomain::getId()
|
|
2019-02-20 16:06:16
|
<tgr>
|
which use $wgDBName or "$wgDBName-$wgDBPrefix" if there is a prefix
|
|
2019-02-20 16:06:45
|
<bawolff>
|
And if your db name has a '-' in it, everything goes to hell
|
|
2019-02-20 16:07:30
|
<tgr>
|
DatabaseDomain uses "$wgDbName-$wgDBmwschema-$wgDBPrefix" if there is also a prefix (not sure why the other doesn't)
|
|
2019-02-20 16:07:41
|
<tgr>
|
...there is also a schema, I mean
|
|
2019-02-20 16:08:05
|
<tgr>
|
for engines like Postgres which support schemas
|
|
2019-02-20 16:08:36
|
<tgr>
|
and yes, they handle encoding weird characters differently
|
|
2019-02-20 16:09:28
|
<mainframe98_>
|
So based on that, that would indicate that using WikiMap::getCurrentWikiDbDomain is better than wfWikiId, because it includes the schema? The MW-version requirement is irrelevant for my purpose.
|
|
2019-02-20 16:10:06
|
<tgr>
|
what are you trying to use it for?
|
|
2019-02-20 16:10:25
|
<tgr>
|
wikifarms are a messy area generally, with no proper support in core
|
|
2019-02-20 16:10:32
|
<mainframe98_>
|
Trying to distinguish one wiki from another.
|
|
2019-02-20 16:11:15
|
<tgr>
|
some things use wiki domain names (and then do various hacks to account for mobile domains, which is again something not properly supported in core)
|
|
2019-02-20 16:11:41
|
<mainframe98_>
|
I've got configuration that should apply to one wiki, but (potentially) not the other, so I need to ensure I'm storing the wiki identifier (not the name, as it can change) correctly
|
|
2019-02-20 16:12:57
|
<mainframe98_>
|
It doesn't seem like WikiMap does distinguish between mobile domains and regular domains though, so that should be fine.
|
|
2019-02-20 16:14:16
|
<duesen_>
|
the concept of internal wiki IDs is not very well defined and a bit fuzzy around the edges
|
|
2019-02-20 16:14:24
|
<duesen_>
|
especialyl its relationship to database "domains"
|
|
2019-02-20 16:14:47
|
<tgr>
|
if your question is what WikiMap uses for ids, that's DatabaseDomain
|
|
2019-02-20 16:15:16
|
<tgr>
|
but I think a wikifarm where two wikis only differ in the schema would blow up quite badly
|
|
2019-02-20 16:15:24
|
<duesen_>
|
wfWikiId should yield a unique identifier within the wiki farm. the structure of that identifier should be opaque.
|
|
2019-02-20 16:17:16
|
<Tonina_WMDE>
|
mainframe98_: Regarding the topic "setting ref="noopener" on OOUI buttons". Yes, it is possible to do that. I don't know if you're using the ooui button element directly or as part of another ooui class but you can try to pass the attribute and its value in the config options when you're creating the instance. If that doesn't work then after you create the button it should be ok to do button.$element.attr('ref', 'noopener')
|
|
2019-02-20 16:17:24
|
<tgr>
|
also I'm not sure SiteConfiguration works out of the box
|
|
2019-02-20 16:18:19
|
<mainframe98_>
|
tgr: SiteConfiguration works out of the box as far as I can determine. I've built a small wiki family using that. It did only distinguish on database name, so it didn't encounter any edge cases
|
|
2019-02-20 16:19:41
|
<mainframe98_>
|
Tonina_WMDE: It's actually in PHP. I'm pretty sure there's no JavaScript touching the button at all.
|
|
2019-02-20 16:20:31
|
<Tonina_WMDE>
|
superyetkin: seems like people are already looking at the phab ticket and bawolff asked for some clarification
|
|
2019-02-20 16:20:46
|
<bawolff>
|
Yep, I'm looking into it
|
|
2019-02-20 16:21:12
|
<mainframe98_>
|
(PHP) ButtonWidget can only set "rel" to nofollow, or nothing at all. Since it's locked down that much (https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/php/widgets/ButtonWidget.php$171) I'm curious to know if it's not necessary for those buttons
|
|
2019-02-20 16:22:15
|
<tgr>
|
For one thing, SiteConfiguration involves calling a command line mainteanance script which runs with another wiki id and dumps serialized data, so any configuration value that does not roundtrip with serialization will be damaged
|
|
2019-02-20 16:22:55
|
<tgr>
|
also I vaguely remember it only giving access to a certain subset of configuration settings but I'm not really familiar with it
|
|
2019-02-20 16:23:24
|
<mainframe98_>
|
Luckily, I never had to rely on that, which is why I'm asking these questions - I'm trying to build something that circumvents that thing, but it needs to correctly identify wikis.
|
|
2019-02-20 16:25:15
|
<tgr>
|
chache prefixes use WikiMap::getCurrentWikiDbDomain()->getId() internally
|
|
2019-02-20 16:25:26
|
<tgr>
|
using wfWikiID() should be fine too
|
|
2019-02-20 16:27:09
|
<mainframe98_>
|
Yet looking at 491661 for example, wfWikiId is replaced by WikiMap::getCurrentWikiDbDomain()->getId(). Am I missing something? If both are fine, why use one above the other?
|
|
2019-02-20 16:30:08
|
<tgr>
|
wfWikiID cannot differentiate between a wiki in the foo database with table prefix bar, and a wiki in the foo-bar database for example
|
|
2019-02-20 16:30:34
|
<tgr>
|
eventually it will be fully replaced by the DB domain, I imagine
|
|
2019-02-20 16:30:44
|
<tgr>
|
but in normal scenarios it should work
|
|
2019-02-20 16:31:39
|
<tgr>
|
re: OOUI, yeah there are plenty of cases where it does not support a valid HTML attributr
|
|
2019-02-20 16:31:48
|
<tgr>
|
feel free to submit patches etc.
|
|
2019-02-20 16:32:01
|
<mainframe98_>
|
Well, experience has taught me that that usually ends badly (for me at least) so if there's a better alternative, I'd rather do it right from the start. I'll pick WikiMap/DatabaseDomain then, it has a few handy methods that express themselves better than wfWikiId does
|
|
2019-02-20 16:33:23
|
<mainframe98_>
|
I'll go and see if I can create a patch for that OOUI widget then.
|
|
2019-02-20 16:33:53
|
<mainframe98_>
|
Thanks for the answers. This should help me along quite a bit.
|
|
2019-02-20 16:38:27
|
<Tonina_WMDE>
|
okayy any other questions, we have like 20 more minutes
|
|
2019-02-20 16:39:13
|
<bawolff>
|
superyetkin: So i guess tr is the first collation to encounter this bug, as its the first one to take two letters that used to be primary different (in english) and make them secondary different. Most collations do the opposite
|
|
2019-02-20 16:53:13
|
<bawolff>
|
For some reason, I can't seem to copy and paste unicode into vi. that's odd
|
|
2019-02-20 16:57:18
|
<mainframe98_>
|
I've got to go. Thank you all for the help!
|
|
2019-02-20 17:01:19
|
<Tonina_WMDE>
|
ok I guess that's all for today. Thanks everyone! o/
|
|
2019-02-20 17:02:51
|
<superyetkin>
|
bawolff: hmm
|
|
2019-02-20 17:03:06
|
<superyetkin>
|
so, what do you suggest?
|
|
2019-02-20 17:18:21
|
<bawolff>
|
superyetkin: I think easiest is to remove lowercase dotless i from consideration. I submitted a patch to do that
|
|
2019-02-20 17:31:34
|
<revansx[m]>
|
bawolff: is this the #wikimedia-tech channel?
|
|
2019-02-20 17:31:37
|
<superyetkin>
|
bawolff: ok, thanks for that
|
|
2019-02-20 17:31:46
|
<bawolff>
|
revansx[m]: yes
|
|
2019-02-20 17:31:49
|
<superyetkin>
|
revansx[m]: yes, it is
|
|
2019-02-20 17:32:00
|
<revansx[m]>
|
thanks!
|
|
2019-02-20 17:32:26
|
<revansx[m]>
|
is it too late to ask a question?
|
|
2019-02-20 17:33:33
|
<superyetkin>
|
it is never too late to ask a question and seek an answer :)
|
|
2019-02-20 17:34:50
|
<revansx[m]>
|
wonderful. thanks.. i'm running MW 1.30 and 4.3 (c35e352) 12:50, 14 March 2018 .. and I'm having trouble with popup forms
|
|
2019-02-20 17:37:06
|
<revansx[m]>
|
sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/dsFRTiOCxuHswfiuwMIzENhp >
|
|
2019-02-20 17:38:17
|
<revansx[m]>
|
sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/qqYOpPZSeRfAIsHujwUwdgwX >
|
|
2019-02-20 17:52:01
|
<bawolff>
|
revansx[m]: if nobody answers you here, try also #semanticmediawiki
|
|
2019-02-20 17:57:07
|
<revansx[m]>
|
aye
|
|
2019-02-20 19:29:48
|
<snitch>
|
[[Tech]]; Ekkasit Aemsa-Ard; /* แก้ไขครับไม่ใช่แก้ตัวครับ */ new section; https://meta.wikimedia.org/w/index.php?diff=18889293&oldid=18852767&rcid=13218737
|
|
2019-02-20 20:13:58
|
<snitch>
|
[[Tech]]; Schniggendiller; Undo revision 18889293 by [[Special:Contributions/Ekkasit Aemsa-Ard|Ekkasit Aemsa-Ard]] ([[User talk:Ekkasit Aemsa-Ard|talk]]): ???; https://meta.wikimedia.org/w/index.php?diff=18889348&oldid=18889293&rcid=13218890
|
|
2019-02-20 21:55:31
|
<rhinosf1>
|
Can you connect multiple MediaWiki Accounts to one Phabricator Account? If so, how?
|
|
2019-02-20 21:57:42
|
<MatmaRex>
|
no
|
|
2019-02-20 22:00:12
|
<rhinosf1>
|
Thanks for the quick reply, was asking as I'll be on RhinosF1 (public) on Wikipedia for next few days and don't see point of having multiple phab Accounts. Amy advice?
|
|
2019-02-20 22:05:32
|
<rhinosf1>
|
^^ Bawolff - Any advice? Logged in to my public Unified account but phab doesn't support linking accounts. How can both be used to get into the same phab Account?
|
|
2019-02-20 22:06:50
|
<rhinosf1>
|
E.g. RhinosF1 and RhinosF1 (public) be connected on phab.
|
|
2019-02-20 22:07:47
|
<paladox>
|
that's not possible i think
|
|
2019-02-20 22:07:54
|
<paladox>
|
you can only attach one account
|
|
2019-02-20 22:09:35
|
<rhinosf1>
|
What's the best way to link things like monitored tickets?
|
|
2019-02-20 22:10:00
|
<rhinosf1>
|
Would be good if MediaWiki had shared watchlists.
|
|
2019-02-20 22:12:54
|
<bawolff>
|
You can attach one wikitech account and one SUL mediawiki account to your phab account
|
|
2019-02-20 22:13:06
|
<bawolff>
|
You can't connect two SUL accounts to the same phab account
|
|
2019-02-20 22:14:55
|
<rhinosf1>
|
Bawolff - I have 2 MediaWiki Accounts - RhinosF1 and RhinosF1 (public) but want to keep my subscribed tasks and everything is that possible? 2. Has anyone ever suggested shared watchlists/notifications on Wikipedia for public/tests Accounts linked to main account.
|
|
2019-02-20 22:15:41
|
<paladox>
|
rhinosf1 no that's not possible.
|
|
2019-02-20 22:15:54
|
<paladox>
|
you can only have one oAuth account attached to your phab account.
|
|
2019-02-20 22:16:19
|
<paladox>
|
so you can remove one and add another (but you cannot have 2 at the same time) unless it's a wikitech account.
|
|
2019-02-20 22:16:35
|
<bawolff>
|
For 2, I think its unlikely anyone will work on that tbh
|
|
2019-02-20 22:16:38
|
<paladox>
|
in which case you can have one oauth account and one ldap account attached to your phab account.
|
|
2019-02-20 22:17:56
|
<rhinosf1>
|
I see and it would need massive consensus Bawolff.
|
|
2019-02-20 22:18:32
|
<bawolff>
|
Its also a lot of work for something that benefits a small number of people
|
|
2019-02-20 22:18:50
|
<rhinosf1>
|
I'll just have to click around on my ToDoList and watch out for emails.
|
|
2019-02-20 22:19:10
|
<rhinosf1>
|
Bawolff - I can imagine.
|
|
2019-02-20 22:54:41
|
<ebernhardson>
|
Is there a simple, generic way to map from a wiki db name to it's language? For example ukwikimedia needs to map to english, not ukranian
|
|
2019-02-20 22:55:20
|
<ebernhardson>
|
additionally this is from outside mediawiki
|
|
2019-02-20 22:55:30
|
<ebernhardson>
|
(and somewhere that can't make web requests)
|
|
2019-02-20 22:55:43
|
<MatmaRex>
|
no. copy-paste the list from somewhere in operations/mediawiki-config :)
|
|
2019-02-20 22:56:11
|
<ebernhardson>
|
well, i guess that will work at least :)
|
|
2019-02-20 22:57:23
|
<MatmaRex>
|
search for wgLanguageCode
|