[01:39:38] quiddity: I've been having thisproblem for a bout a month or so now as well... https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Typing_into_editor_or_edit_summary_on_large_articles_is_very_sluggish [01:39:43] this problem* [01:40:18] :/ [01:40:42] nod. I just finished summarizing in -perf. [01:41:12] * Josve05a hs never been to that channel :p [01:43:19] there are always more IRC channels/mailing lists/noticeboards/etc. Always. [02:07:08] Josve05a: I'm investigating [02:07:10] thanks for the report [02:07:16] and thanks quiddity for passing it along [02:07:53] (y) :) [02:08:11] I've been investigating it for the last two hours! ;) [02:08:43] (trying to find consistency/pattern, before asking for help elsewhere) [02:13:02] quiddity: time to file a Phab task? [02:13:13] Just finished typing: https://phabricator.wikimedia.org/T143182 [02:13:48] * Josve05a joins -perf. [02:14:04] * quiddity goes grocery shopping. >.> [02:14:47] * Josve05a made a typo, or nobody is there xD [10:53:00] Does anyone know why this (https://sr.wikipedia.org/wiki/Special:Diff/11994910/11994975) had to be added for https://sr.wikipedia.org/wiki/Template:Official_URL not to display a trailing "http://" in this article: https://sr.wikipedia.org/wiki/Кезон_Сити? Aside from some localization changes, the code is identical to the English wiki and it doesn't have that issue. [13:18:43] Srdjan_m: regexes are/can be language-dependent, so identical code can still work differently [13:19:09] Not sure about that specific case [20:03:53] rounding up ArchCom for E260 (gwicke`: RoanKattouw, Krinkle ) [20:57:07] gwicke`, brion: I've read before that the dialects of Chinese are as similar as the romance languages of europe [20:57:35] but traditional and simplified are not dialects, they are two different written representations of the same spoken dialect [20:58:09] yes, there are ambiguities in simplified chinese, it is not trivial to map it to spoken mandarin [20:58:18] Common usage of "dialect" also maps poorly to Chinese languages :) [20:58:18] you could compare it to arabic in that sense [20:58:59] arabic is usually written with vowels omitted, which means that you have to guess the vowels based on context [20:59:37] also there are post-1950 divergences in vocabulary [22:04:15] DanielK_WMDE_: in the ContentHandler project, IIRC I was against using integers in the API, I thought they should be mapped from strings to integers inside ContentHandler [22:04:30] whereas you started with integer API, integer DB [22:04:40] and you were prepared to switch to string API, string DB [22:05:27] I agreed to it on the condition that they would be nullable strings which would virtually always be null [22:05:55] maybe we can rename the revision columns for the migration? [22:06:13] TimStarling: yea, perhaps it was like that. the dba at the time was also involved. [22:06:30] I wish I had thought of the nice solution for an automatic mapping that legoktm came up with [22:06:32] so obvious [22:06:33] oh well [22:06:35] asher [22:06:48] yes, asher! [22:07:03] I do not think we need mediawiki code [22:07:04] jynus: what do you mean? [22:07:06] just [22:07:21] a series of steps for the migration [22:07:31] that should not take more than a few minutes to come up [22:07:41] how does renaming the columns help? [22:07:54] which colummns? [22:08:09] it is not about renaming, it is about converting the existing table into one of the 2 finals [22:08:19] so less data is moved around [22:08:34] I assume at the beginning there will be almost a 1:1 mapping? [22:08:42] jynus: we will still need the revision table, and much of what is in it, in the current place [22:08:51] do we? [22:09:00] or would it be easier to rename as content? [22:09:00] we need to move some of its columns to another table - and convert them at the same time. [22:09:08] no, that won't work [22:09:14] it was the same with the image table [22:09:20] revision has user, timestamp, comment, etc [22:09:21] it's kind of 1:1? `null` means different things depending on the rest of the row... [22:09:26] that belongs to the revision, not the content. [22:09:38] yes, DanielK_WMDE_ [22:10:02] but consider which will be the closest to the original [22:10:23] independenrly of the logic meaning [22:10:26] since we change the way that content and format are stored, the new table will be nothing like the revision table [22:10:50] a revision will be a revision, but maybe the new revision table will be much lighter? [22:11:03] a little. not much. [22:11:23] I am not sayin it should be like that [22:11:33] it will lose model and format, as well as (later?) length and hash. [22:11:34] only that it will be on or the other [22:11:52] actually no. [22:11:57] no? [22:12:01] it will not lose length and hash, we'll still need that, sorry [22:12:22] I think we should start with the structure you sent [22:12:26] so: the revision table will lose only content model and format, as far as I can tell. [22:12:27] or the current one [22:12:32] and come up with a transition plan [22:12:36] whatever it is [22:13:00] one where application can continue working while a large jobs is being executed [22:13:11] yes! tell me how you think we can best go from the current schema to the one in https://gerrit.wikimedia.org/r/#/c/302056/ (or the one in the rfc) [22:14:01] probably you should start doing that, and we can discuss it :-) [22:14:07] my naive approach would be to simply fill the new table chunk by chunk, have the apprication write to the old and new fields for a while, and at some point switch the application to only read from and write to the new fields [22:14:17] then we can kill (or ignore) the old fields [22:14:32] yes, just put that in a sytematic way [22:14:47] will do. but not tonight :) [22:14:51] of course [22:14:58] time for silly youtube videos [22:15:01] thanks for your help! [22:15:04] to go ahead, I meant [22:15:31] it can be done in a text file, like this: [22:16:38] https://phabricator.wikimedia.org/T130067#2376998 [22:17:06] good night [22:17:18] cu [22:21:59] quiddity: I've got a bug that I need help investigating... [22:22:10] mhm? [22:23:20] On category pages (such as https://commons.wikimedia.org/wiki/Category:Photographs_taken_by_Josve05a_using_the_pool_of_technology_at_Wikimedia_Sverige_(August_2016)) on Commons, before ~August I used to see the full file name (not sure if done by a gagdget, or nativly), but now post-August the file namesis "cut". I only see "Columba livia in Stockho" instead [22:23:20] of "Columba livia in Stockholm.jpg" under the file in the category-gallery... [22:23:32] gadget* [22:23:44] names are* [22:24:42] It's really annoying when I used to be able to copy the fie names from the category and paste in articles. Now I have to press the image to be able to copy the file name on the file description page... [22:25:20] quiddity: I'm not sure if this is something I've done to my settings, or if this has "happened" to everyone... [22:28:27] https://usercontent.irccloud-cdn.com/file/qjcv3u6l/ [22:28:29] See ^^ [22:28:30] marktraceur, do you know why filenames are (since recently) truncated in category pages? ^ (Josve05a I see that too). It does look cleaner (regular alignment), but is less usable. [22:28:57] Weird. [22:29:05] I don't know, but we can take a look [22:29:13] I tried searching phab quickly, but couldn't see anything obvious. [22:29:14] ty :) [22:29:22] Phile away if y'please [22:30:06] nod. Josve05a can you file? I have too many tabs open and being mentally juggled... [22:30:20] Sure thing :) [22:32:58] umm...not sure whch projects... [22:34:18] marktraceur, quiddity: Not so much details, but: https://phabricator.wikimedia.org/T143281 [22:34:22] at least someting... [22:34:41] Thanks, I have it open so I'll look at it tomorrow [22:36:44] Ty