Jump to content

User talk:Johnuniq/Archive 18

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15Archive 16Archive 17Archive 18Archive 19Archive 20Archive 25

Sorry to trouble you again. I don't know how to fix the "Lua error in Module:HK-MTR_stations/data at line 833: bad argument #1 to 'ipairs' (table expected, got nil)" with my very limited knowledge. The module is loaded by Module:HK-MTR stations and transcluded in {{HK-MTR stations/sandbox}}. -- Sameboat - 同舟 (talk · contri.) 03:17, 2 January 2015 (UTC)

Glad to help! However, I do not see an error at that page. Perhaps it has to be called with a parameter? At any rate, the error refers to line 833 (for i, code in ipairs(t.stations) do) and it is saying that the thing in parentheses (t.stations) is nil. That means the table t does not have a stations item. I'll figure that out when I know what actually causes the error to be shown. By the way, line 834 (stations[code] = true_station) is wrong because true_station is (I guess) an element in a table, so it would need to be something.true_station. What do I have to do to see the error, and what should it be showing instead of an error? I'll be away for a couple of hours but will look on return. Johnuniq (talk) 03:46, 2 January 2015 (UTC)
The module it's being tested at template:HK-MTR stations/testcases. Thanks for your kindness. -- Sameboat - 同舟 (talk · contri.) 03:54, 2 January 2015 (UTC)
I'm dashing away, but the immediate issue is the asiaworld_expo item which has station instead of stations. Johnuniq (talk) 03:58, 2 January 2015 (UTC)
You are right. The error in testcases now instead reads "Script error: The module returned a nil value. It is supposed to return an export table." -- Sameboat - 同舟 (talk · contri.) 04:03, 2 January 2015 (UTC)

I'm back earlier than expected, but I'll be away for a while later. One minor issue is that Template:HK-MTR stations/sandbox does not need to pass {{{1}}} to the module because the module can easily get that information. At any rate, if you do want to pass it, a pipe must be included ({{{1|}}}) so that if the template is used with no parameter, the module will get an empty string as the argument. As it is now, the module would receive argument "{{{1}}}" (those seven characters) which cause confusion.

In Module:HK-MTR stations, at p.station = makeInvokeFunction('_station'), the element _station has not yet been defined, so that cannot work. I have no idea what makeInvokeFunction is supposed to do, but perhaps that line has to be moved to the end, and the module needs to finish with return p.

The module uses mw.loadData('Module:HK-MTR stations/data') but that only works if the submodule contains pure data. Because it contains code, another error will occur. The code has to be moved from the data module to the main module. Alternatively, use require instead of loadData.

If you could explain what the template/module is supposed to do in big-picture terms (what is the input? what is the output?), I might be able to understand what is wanted, and could make suggestions. As it is, I cannot see why a loop is needed (for k, t in pairs(data) do). There must be a better way of doing whatever is needed. Johnuniq (talk) 05:15, 2 January 2015 (UTC)

makeInvokeFunction was copied from module:MTR which was initially written by Mr. Stradivarius[[1].
Module:HK-MTR stations is meant to replace {{HK-MTR stations}} (for MTR metro stations), {{HK-MTRL stations}} (for Light Rail (MTR) stops) and all MTR station livery style template in order to have {{HK-MTRL color}} and {{HK-MTRL stations}} deleted and a centralized management of all MTR station data which will be transcluded by {{s-line}} (stations/true_station/link) and {{infobox station}} (code/style/thbgcolor/thcolor/thgradient) in the articles of MTR metro stations and MTR Light Rail stops. -- Sameboat - 同舟 (talk · contri.) 06:05, 2 January 2015 (UTC)

@Sameboat - 同舟: Let's worry about the arguments later. For testing, you can add a "TEST" line:

    local code = args[1] or ''
    code = 'AsiaWorld–Expo'  -- TEST

I do not understand exactly what the code is doing, but the first step should be to remove that loop in the data module. I'm sure it is not needed. Please look at the following and tell me if I'm missing something.

Following is from Module:HK-MTR stations/data.

local data = {
    asiaworld_expo = {
        stations = {'AsiaWorld–Expo', 'AsiaWorld-Expo'},
        true_station = 'AsiaWorld–Expo',
        link = 'AsiaWorld–Expo Station',
        thbgcolor = 'ffffff',
        thcolor = '000000',
        code='AWE',
        differ = true,
    },
    airport = {
        stations = {'Airport'},
        link = 'Airport Station (MTR)',
        code='AIR',
        thbgcolor = '808080',
        thcolor = 'ffffff',
    },
}
-- Loop to generate wanted tables not shown here.

That should be rewritten something like this.

local stations = {
    ['AsiaWorld–Expo'] = {
        true_station = 'AsiaWorld–Expo',
        link = 'AsiaWorld–Expo Station',
        thbgcolor = 'ffffff',
        thcolor = '000000',
        code='AWE',
        differ = true,
    },
    ['Airport'] = {
        link = 'Airport Station (MTR)',
        code='AIR',
        thbgcolor = '808080',
        thcolor = 'ffffff',
    },
}

local aliases = {
    -- Alternative name = Name used as key in data table.
    ['AsiaWorld–Expo'] = 'AsiaWorld-Expo',
}

-- No need for a loop to generate wanted tables.
return { stations = stations, aliases = aliases }

Then the main module (Module:HK-MTR stations) would have something like this:

    local station = data.stations[code] or data.stations[data.aliases[code]]
    if station then
        -- station has all required information
    else
        -- station not known
    end

As far as I can tell, the original key names like asiaworld_expo are not used by the current module, and they are not needed. Do you want to rewrite it like the above? Do you want me to do it? Johnuniq (talk) 06:43, 2 January 2015 (UTC)

Thanks for the suggestion. I will try it myself when I'm home (still busy at work). But I can safely say that "true_station" and "differ" are no longer needed with the "redirect" of local aliases. -- Sameboat - 同舟 (talk · contri.) 08:32, 2 January 2015 (UTC)
I have changed everything I can but still the testcases reports error of 'the module returned a nil value. It is supposed to return an export table'. -- Sameboat - 同舟 (talk · contri.) 02:04, 3 January 2015 (UTC)
@Sameboat - 同舟: I'm putting links to the pages here so I can easily find them. If there are any more I should know about, please add them.
I've got some time to look at this now, and I think I won't be interrupted for a while, so please don't change anything for an hour or so while I have a look. I assume this is not live, so I can just edit as I want without any concern? Johnuniq (talk) 02:31, 3 January 2015 (UTC)
OK, but perhaps expect to encounter one edit conflict of the modules but you can safely overwrite with your own version. I will leave them to your hand by now. -- Sameboat - 同舟 (talk · contri.)
Just another note about the lr=true, this is used for disambiguating the articles of "metro station-light rail stop" interchange hub such as Tuen Mun Station and Tuen Mun Stop. In other word, the " lr" in "Tuen Mun lr" should be trimmed for the piped link of the light rail stop to work. -- Sameboat - 同舟 (talk · contri.) 02:45, 3 January 2015 (UTC)

HK-MTR stations

@Sameboat - 同舟: First edit done—see the testcases. I don't understand what this module is trying to do. Please spell out what you are saying about "lr" in terms of "if lr is true then do what?". Why is "lr = true" needed in the data when the module could very easily determine that the code ends with " lr" (space then lr) and use that to do something? What is supposed to happen for the third testcase ("Lo Wu/Lok Ma Chau")? I assume the data will be enhanced to include more information because at the moment it is not doing much.

Hmmm, I see this line in the data aliases:

    ['[[Lo Wu Station|Lo Wu]] or [[Lok Ma Chau Station|Lok Ma Chau]]'] = {'Lo Wu/Lok Ma Chau'},

What is that supposed to do? Is it supposed to handle the case "{HK-MTR stations/sandbox|Lo Wu/Lok Ma Chau}" test? Would someone really enter a slash? Why is that item in aliases when it could be in stations? When I proposed aliases, I was thinking that there may be two alternative names which both refer to the same item of data. If that is not the case, aliases should be removed. If you would explain the big picture, I would be in a much better position of knowing how it should be organized. Johnuniq (talk) 03:17, 3 January 2015 (UTC)

I guess you overlooked my previous reply about the lr. "Lo Wu/Lok Ma Chau" and all those with unlink=true are for displaying termini by {{s-line}} as shown in Fanling Station ({{S-line/HK-MTR right/East Rail}} and Tin Shui Wai Stop ({{S-line/HK-MTRL left/705}}, {{S-line/HK-MTRL right/706}}). Also if the key is not available in the data module, it would assume the entry means light rail stop instead of metro station, so no need for the error_text. -- Sameboat - 同舟 (talk · contri.) 03:21, 3 January 2015 (UTC)
I would have to spend a lot of time figuring out what the module is supposed to do, and I was hoping to avoid that by simply getting instructions—imagine I'm a computer and tell me things like "if the code ends with a space and then lr, omit those three characters and do this". Or, if you don't want it to examine those three characters, but to use the lr=true, that's fine too, although a brief explanation of the redundancy would be good. Or, for each testcase, tell me the exact wikitext that should be output. Johnuniq (talk) 03:50, 3 January 2015 (UTC)
(Everything involved with S-line is always getting quite messy...) The p.station part of the module is meant to handle both {{HK-MTR stations}} and {{HK-MTRL stations}} templates (although I have no idea why there is that warning message for "one-way" value.) Here's the list the input and expected output:
input ouput done note
Tuen Mun [[Tuen Mun Station|Tuen Mun]] Checked
Admiralty [[Admiralty Station (MTR)|Admiralty]] need_dab
Victoria Park [[Causeway Bay North Station|Causeway Bay North]] aliases
Tuen Mun lr [[Tuen Mun Stop|Tuen Mun]] lr
Lo Wu/Lok Ma Chau [[Lo Wu Station|Lo Wu]] or [[Lok Ma Chau Station|Lok Ma Chau]] aliases, unlink
Tin Shui Wai Circular counter-clockwise Tin Shui Wai Circular<br />(counter-clockwise) aliases, unlink
Kei Lun [[Kei Lun Stop|Kei Lun]] Light Rail stop with no key in the data module
Metro station ends with "Station", some may need disambiguation qualifier "(MTR)"; Light Rail stop ends with "Stop". Hope this help and sorry for the complication and confusion. -- Sameboat - 同舟 (talk · contri.) 04:10, 3 January 2015 (UTC)
I intentionally not include all those light rail stops with no interchange with metro station in the data module because they are unambiguous and all share the same thbgcolor and thcolor of the Light Rail livery while all those metro stations use different livery style which will be eventually fetched to {{infobox MTR}} (which currently translcudes templates like {{Infobox MTR/Choi Hung style}} to define the infobox style in the station article, c.f. Choi Hung Station). Those latter parameters are part of the planned separate function of the module. -- Sameboat - 同舟 (talk · contri.) 04:21, 3 January 2015 (UTC)

@Sameboat - 同舟: The original data included (for two different items):

    stations = {'AsiaWorld–Expo', 'AsiaWorld-Expo'},
    stations = {'Causeway Bay North', 'Victoria Park'},

My guess was that these defined alternative names that could be used to identify an item. In the second case, for example, input 'Causeway Bay North' would give the same result as using input 'Victoria Park', except that if there are some cases where the input text appears in the output, that would be different. Therefore I expected to see only the two examples above in aliases. My guess is that everything else that is now in aliases should be in the main stations table.

I also think that all the link='xxx' lines need to be restored. If that is so, I would do it because I can do edits like that pretty easily and reliably.

The first item in the original data included:

    stations = {'Lo Wu/Lok Ma Chau'},
    link = '[[Lo Wu Station|Lo Wu]] or [[Lok Ma Chau Station|Lok Ma Chau]]',
    unlink = true

What does "unlink" mean (in general as well as in this example)? Why not simply have a link entry in each table; that link can include a wikilink if the item should be linked, and can not include a wikilink if it should not be linked. Or, is the link wanted at some times and not at others? Therefore some input would be needed to say whether the link is wanted? So why have an "unlink" item? Johnuniq (talk) 07:03, 3 January 2015 (UTC)

1) "AsiaWorld-Expo" is not the correct spelling because it uses hyphen instead of en dash; "Victoria Park" and "Pak Shek Kok" are an outdated project names of the planned stations and it's unlikely these "alternative names" would be used in the S-line template in any circumstance. I added them to the aliases table just to avoid "negligence" by the module.
2) Yes. I naively wanted to reduce the size of the data module so I removed all link/true_station values. But another major reason is that we want the S-line template to use piped link so the text "station/stop" is not shown for reducing text length (especially because the S-line template is transcluded in the very tight station infobox, c.f. Sha Tin Station). Also both "Tin Shui Wai Circulars" in particular use no link at all. If it makes very little difference of performance, you can restore all links/true_station values and remove unlink.
3) My another intention with lr is to tell the module to load the Light Rail livery color (fetched from module:MTR/data) instead of metro. Maybe there is a more efficient way to do that 'cause it's just 4 ambiguous LR stops need it? -- Sameboat - 同舟 (talk · contri.) 07:47, 3 January 2015 (UTC)
I have done some minor changes to move the code towards what I think is needed, but there is a lot that does not make sense to me at the moment. You might look at what I've done and see what you think. I haven't done anything with unlink yet. I have to leave it now, and won't get back to this for perhaps 20 hours. It would be helpful if you could think of any exceptions that would not be handled by the code so far, and add to the input/output table above to show what the code needs to do that it does not do already. I guess you know that Special:ExpandTemplates can be useful to see exactly what the template outputs. Johnuniq (talk) 09:30, 3 January 2015 (UTC)
I updated {{HK-MTR stations/testcases}}. Also I boldly update both modules so now all the testcases works as expected and unlink is no longer needed with the text == link condition. Although I'm wondering if there is better approach than repeating the value for link and text in data module. -- Sameboat - 同舟 (talk · contri.) 10:07, 3 January 2015 (UTC)
I added p.style by myself and it works pretty much as expected. But how do I load/require data in one module from another module with specific value. I wanna load the RGB hex 'd3a809' from module:MTR/data inside the 'light_rail' table so whenever the Light Rail livery color value has been updated in module:MTR/data, the same value is instantly updated in HK-MTR stations as well. -- Sameboat - 同舟 (talk · contri.) 12:39, 3 January 2015 (UTC)

@Sameboat - 同舟: The same error text is used three times ("errorText('Need station or stop name')"). It is much better to fix that now because leaving it until later means it will be forgotten.

In the data for 'one-way', I replaced {{!}} with &#124; because the text that a module returns is not processed in the manner that wikitext typed into an article is processed. Indeed, the module is called as a result of processing the wikitext, and what the module outputs is too late for further processing. What that means is that stuff like {{!}} won't work.

I did a style fix with error_text (I assume you want camelCase), and some minor fixes.

I have no idea what the idea of your change to link == text is because I don't understand what the module is supposed to do. However, that doesn't matter.

I'll look at Module:MTR/data later but it has the bizarre loop that used to be in Module:HK-MTR stations/data and the first thing I would want to do is to remove that code! I would have to examine the code to be sure (and I don't want to examine such a strange idea), but you might find that mtr_data.colors.LR has the 'd3a809' value. Johnuniq (talk) 05:25, 4 January 2015 (UTC)

For text == link, let me put this in a simpler way: if there is only text but no link, then station function only output the text value and does not wrap the text with internal link markup [[ ]], so we can remove the duplicated values in the stations table.
Indeed I don't comprehend the loop structure in module:MTR/data. You are welcomed to refine when you have the time and mood. --Sameboat - 同舟 (talk · contri.) 07:21, 4 January 2015 (UTC)

HK-MTR stations 3

@Sameboat - 同舟: See Template:HK-MTR stations/testcases and its talk page for a system that convert uses to test changes to the module (see Template:Convert/testcases/sandbox1 and its talk page for an example of its use with over a thousand tests). If you wanted, you could make lots of tests; note that the talk page shows how to generate the results of running the tests so you do not need to manually enter all the expected wikitext. The strange thing is that I previewed the results on the talk page and saw that all the tests had passed, but when I saved the page, it showed two tests as failing. That appears to have been caused by recent edits to the module. I'll leave this for now but will return to it. Johnuniq (talk) 08:50, 4 January 2015 (UTC)

Sorry. Recently it has been edited by 3 users (including me). I have reverted my version after your last edit bu retained those by user:Jc86035. I will stop by now. -- Sameboat - 同舟 (talk · contri.) 08:59, 4 January 2015 (UTC)
Don't stop on my account! I was not complaining; I was just reporting that the testcases showed some issues that would need attention. When people have finished, if you want, ask me to have a look. However, I like to refactor stuff!

Why do 194 articles link to Module:HK-MTR stations (see whatlinkshere)? A quick test shows there is something in {{s-line}} which is responsible, but I thought that module was unused and so was safe to experiment on. Johnuniq (talk) 09:25, 4 January 2015 (UTC)

I was tempted to try it again. Thankfully now all inputs in Template talk:HK-MTR stations/testcases have passed, but please check if any thing not done well in the station function. -- Sameboat - 同舟 (talk · contri.) 09:27, 4 January 2015 (UTC)

Your own edit summary breaks the rule you appear to advocate

If people ignore all rules anyway, why make this one? When writing a comment that you intend to be civil, it is very insulting to assume that the reader would not be able to handle the same comment phrased more directly. Connor Behan (talk) 01:35, 7 January 2015 (UTC)

The question of you is very interesting. Some years ago I read the advice that avoiding "you" was desirable in order to reduce tension from discussions, particularly written discussions where the writer may be feeling quite cheerful, but their words may appear combative in cold print. When I first saw the advice to avoid "you" I was initially surprised to see such a silly idea, but on thinking it over I saw that it is in fact very helpful. After observing the utility of avoiding you, I now go to quite a bit of trouble to follow the advice because it helps focus discussion on the underlying issue (is some text desirable in an article), and avoids distractions such as whether another editor is wrong. Your edit to the WP:NPA policy included removal of 'In disputes, the word "you" should be avoided when possible' with edit summary "Removing a rule that would make Wikipedia a worse place. Being civil or not has nothing to do with using the passive voice." I was hoping that people would recognize that my revert with edit summary "you are wrong" was ironically pointing out that the advice to avoid "you" is actually very good—clearly my edit summary did nothing but inflame the situation. So, I'm sorry to have been offensive, but I thought those three words would work well to demonstrate the soundness of the original text. I am normally quite nice, but sometimes cannot avoid absurdist humor. Re the policy: I believe that removing advice from policies is not desirable—such pages should provide guidance on how to proceed, particularly when it is counter-intuitive but demonstrably useful. Obviously the advice is general guidance with lots of exceptions. Johnuniq (talk) 02:36, 7 January 2015 (UTC)
I probably would've objected here no matter what, but after reading your edit summary, I felt compelled to say that this is the type of edit summary that you and everyone else should be free to make. It is perfectly possible to say "you" without being confrontational, which is why putting the word in the same ballpark as personal attacks seems heavyhanded. Cheers. Connor Behan (talk) 04:50, 7 January 2015 (UTC)

Lua question

I am writing some Lua codes outside of Wikimedia and need your suggestion: I have multiple sub-modules which store lists of data. The structure of the sub-modules are literally the same as module:HK-MTR stations/data.

local MTR = require('Module:Metrostations/MTR')
local Shenzhen_Metro = require('Module:Metrostations/Shenzhen_Metro')
 
local p = {}

function p.whatever( frame )
	local system = frame.args[1]
	local code = frame.args[2]
	station = system.stations[code]
	local id, result
	id = station.id
	result = code .. id
	return result
end

return p

In this case, I get the error of "attempt to index field 'stations' (a nil value)" unless I change station = system.stations[code] to station = MTR.stations[code]. How do I require different data module based on the input of args[1]? Thank you very much. -- Sameboat - 同舟 (talk · contri.) 11:01, 9 January 2015 (UTC)

@Sameboat - 同舟: First, let's make sure frame.args is what is wanted, and you know the following:

local pframe = frame:getParent()
local config = frame.args  -- arguments from the template definition
local args = pframe.args   -- arguments from the page calling the template

If a page contains {{example|abc|def}} and Template:Example contains {{#invoke:example|main|hello}}, and after the above code, config[1] is 'hello' and args[1] is 'abc' while args[2] is 'def'.

You say "outside of Wikimedia". If wanted, you could email me details, but only if wanted. If the system uses Scribunto as MediaWiki does, then frame.args[1] can only be nil or a string. Therefore, system can never be a table, so system.x will always fail.

Something like the following may do the job.

    local system = frame.args[1]  -- suppose this is 'MTR'
    local code = frame.args[2]
    if not system or not code then
        return 'Error'
    end
    local data = require('Module:Metrostations/' .. system)
    local station = data.stations[code]
    return code .. station.id

The above will give an ugly error message if frame.args[1] is wrong (like 'mtr' instead of 'MTR'). There are two approaches: (1) have a table of all the valid system values and check the argument is valid before using it, or (2) use pcall to call require so a reasonable error message can be given if it is invalid.

By the way, I've been playing with a couple of projects but was planning to see what had happened to the modules in our previous discussion in due course. Johnuniq (talk) 23:13, 9 January 2015 (UTC)

Thanks for your concise instructions. I tested in my Wikipedia sandbox module and it works (testcases) as well as my Lua module in Wikia. I wonder if I've done well for creating a local function for the frame.args so it can be shared by other functions. (No, I don't exactly understand how frame.args works. I don't do programming outside of wikis.)
The function "station" of Module:HK-MTR stations works pretty well in the succession templates of MTR stations articles. User:Jc86035 greatly expanded it but it might not be worth it due to oppositions in here and here, I'm neutral on this matter, though. -- Sameboat - 同舟 (talk · contri.) 03:47, 10 January 2015 (UTC)

Convert at zhwiki

@Sameboat - 同舟: Please check the following and tell me what you think. I'm putting this on my talk because we were just talking, and this will be easier for me to find in the future.

I'm looking at a tricky enhancement to convert for enwiki. It's "automatic per units" where you can convert a unit like kW/L (energy power per volume) without the unit needing to have been defined. I run tests on a local computer. Those tests include a lot of old stuff, including tests I made when working on convert at zhwiki. I just made a minor tweak to the code, and it caused the following error report from my tests. The "Expected" line shows the output that convert used to give, before the change I made an hour ago. The BAD line shows what it is outputting now (it's not necessarily wrong—it's marked "BAD" because the result is different from what it used to be).

{{convert|1|mpgus|abbr=on|lk=on}}     BAD  1 [[汽車燃油經濟性|mi/US gal]](240 [[汽車燃油經濟性|L/100 km]];1.2 [[汽車燃油經濟性|mi/imp gal]])
                                 Expected  1 [[汽車燃油經濟性|mi/US gal]](240 [[汽車燃油經濟性|L/ km]];1.2 [[汽車燃油經濟性|mi/imp gal]])
{{convert|1|mpgus|lk=on}}             BAD  1[[汽車燃油經濟性|英里每美制加侖]](240[[汽車燃油經濟性|公升每100-{zh:公里;zh-cn:千米;zh-tw:公里;zh-hk:公里;}-]];1.2[[汽車燃油經濟性|英里每英制加侖]])
                                 Expected  1[[汽車燃油經濟性|英里每美制加侖]](240[[汽車燃油經濟性|公升每-{zh:公里;zh-cn:千米;zh-tw:公里;zh-hk:公里;}-]];1.2[[汽車燃油經濟性|英里每英制加侖]])

I just got the following from zh:Special:ExpandTemplates, that is, using the current module at zhwiki which was last updated on 8 October 2014 (these match the "Expected" lines above; the links are blue at zhwiki):

For enwiki, the new module gives these results (this is the same as it has been for a long time, I think):

The difference between the BAD and the Expected lines is that the BAD lines have "100" before "km" because it is liters per 100 kilometers. It's too weird for me figure out at the moment, so please tell me which is actually correct. Are the BAD lines correct? Are the Expected lines correct? (One of them has to be wrong!) I have no idea how the tweak I just made could have resulted in this... Johnuniq (talk) 10:55, 11 January 2015 (UTC)

Thx for inviting me. I need some more time to comprehend the whole thing because "fuel economy" isn't the topic I cared before, so I don't quite understand the deal of removing "100" from the result. As I've tried in zh.wp it gives the "expected result" (sans "100") instead of the "bad result". -- Sameboat - 同舟 (talk · contri.) 12:51, 11 January 2015 (UTC)
Driving 1 mile per US gallon consumes fuel at the rate of 240 liters per 100 kilometers, that is, 2.4 liters per kilometer.
What I'm asking for is confirmation that the zhwiki result is wrong—there is no magic in the text whereby the reader would somehow think it was talking about 100 kilometers? That looks "obvious" but I'm only guessing. We must not have noticed this bug. Johnuniq (talk) 01:39, 12 January 2015 (UTC)
Even in Chinese, the "expected result" is wrong. You do need to divide the resultant figure of "L/100 km" by 100 for "L/ km". -- Sameboat - 同舟 (talk · contri.) 04:32, 12 January 2015 (UTC)

A velociraptor for you instead for a kitten!

A velociraptor for you instead for a kitten!
Thanks for your edit on templates on Dinosaur size. Dinosaur Fan (talk) 08:36, 11 January 2015 (UTC)
Dinosaur Fan, that must be new. Neat. Flyer22 (talk) 08:38, 11 January 2015 (UTC)
Dinosaur Fan: Wow, thanks! My edit was very trivial—I hate to think what I would have found here if I'd done something major! I guess velociraptors are easier to feed than kittens? I hope it's house trained. Johnuniq (talk) 09:15, 11 January 2015 (UTC)

@Johnuniq: Just separate it from Montanabw's pony so it won't have Japanese Horse Meat or Basashi for dinner! Hahahahaha! Dinosaur Fan (talk) 10:12, 15 January 2015 (UTC)

Would your velociraptor want some Edmontosaurus meat?
Feed some Edmontosaurus meat for your velociraptor!

@Johnuniq: Just feed the velociraptor it with this:

[Image of can of food to feed a velociraptor; image now deleted]

Thanks, but I think I'll just let it loose at WP:ANI—that food can looks convenient, but I might have to get a bit close. Hmmm, perhaps I would not have to open the can? Johnuniq (talk) 02:55, 16 January 2015 (UTC)

I have not done any edits, please help

Hi,

I keep getting messages about warnings from wikipedia about unconstructive edits and vandalism, however I have personally not done any edits. I am not sure if this means my system has been hacked into or someone is using my ip address? Please advise.

Thanks — Preceding unsigned comment added by 86.189.14.114 (talk) 00:35, 17 January 2015 (UTC)

I put a warning at User talk:86.189.14.114 on 5 September 2014 because someone from that IP address had performed two bad edits (diff and diff). You probably are now using that IP and the old warnings are not relevant, so I have removed them. When leaving a comment on a talk page, please sign the comment by typing a space and then four tilde characters at the end of the last line. See WP:TP. Johnuniq (talk) 00:43, 17 January 2015 (UTC)

Please state your objections to article content clearly in article talk page. Bare "No consensus" is well known to be an invalid argument. -M.Altenmann >t 10:03, 21 January 2015 (UTC)

Re:Metrics request

Per our off-wiki conversation, the WP:TWL is interested in two historical queries about the usage of our partnerships. To clarify, here is the information that we are looking for:

  • The historical changes in links on our WP:Cochrane partnership at at least 2 months intervals between June 2013 and October 2014. I have been using the query at Special:LinkSearch to provide real-time metrics. The Queried "http://onlinelibrary.wiley.com/doi/10.1002/14651858.*" represents the part of Wiley's DOI directory which includes the Cochrane Library's holdings: all dois that have suffixes like 10.1002/14651858.IDENTIFIER are Cochrane items.
  • As for extending the JStor metrics: I want to look at the trends for JStor stable Urls, from 2013-01-02 every two months until July 14, because of the described templates that inserted search queries at Wikipedia:JSTOR/Metrics. I have been using this LinkSearch Query instead of the general *.jstor.org/ because the vast majority (but not all) of the links that aren't stable links, are automatically generated search queries, and thus the stable search is more representative of the relationship with the Wikipedia community by the donation by JStor, rather then Jstors general utility as a research environment.

Are you still interested/willing to run these numbers? And sorry for starting the conversation off-wiki: we have been doing a lot of off-wiki coordination because of the amount of sensitive data we handle from partners and users. I hope this answers the questions that you had,Astinson (WMF) (talk) 18:04, 23 January 2015 (UTC)

Thanks for bringing it here. Yes, I'll do what I can to get that data. To spell it out, for Cochrane I will look for links like:
onlinelibrary.wiley.com/doi/10.1002/14651858.ANYTHING
and will not find links like:
onlinelibrary.wiley.com/doi/10.1002/14651858ANYTHING
In other words, there must be a dot before "ANYTHING". Let me know if that is not what is wanted.
I only have the external link dumps up to May 2014 so as a first step I am downloading everything since then (fortunately it is still available). I'll chew this over for a few days and will ping you when I've got something. Johnuniq (talk) 03:02, 24 January 2015 (UTC)
Hi Johnuniq, the first line for Wiley is what I am looking for: but I think either would work, there shouldn't be any significant difference in the two queries. Thank you again for the support! Really looking forward to seeing what you find :) Astinson (WMF) (talk) 16:03, 26 January 2015 (UTC)
Hi John, I figure this is the best place for an overview comment: great job on both, going to use both sets to communicate with our partners updates on the usage rates! This also gives me a sense of the proportional relationships between the talk and other page links and the general linksearch. Thanks and have a great week! Astinson (WMF) (talk) 22:24, 6 February 2015 (UTC)

JSTOR results

Count of links to jstor.org

The following is corrected data posted today. It replaces the previous results (which can be seen at this permalink). The graph is also updated, although a caching problem means I am seeing the old version at the moment. Johnuniq (talk) 02:37, 3 February 2015 (UTC)

Date Unique articles Unique links Total links Old articles Old links Old total links Duplicates
2011-06-20 10,788 14,623 17,726 19,953 27,727 33,001 12
2011-07-22 11,045 14,937 18,131 20,263 28,121 33,486 12
2011-09-01 11,621 15,733 19,125 20,696 28,825 34,359 12
2012-02-11 15,712 20,792 25,726 22,808 29,886 36,294 12
2012-03-07 16,010 21,116 26,142 23,471 30,600 37,115 12
2012-04-03 16,349 21,558 26,685 23,733 30,963 37,588 12
2012-05-02 16,925 22,242 27,528 24,318 31,619 38,400 12
2012-06-01 17,223 23,147 28,185 24,668 32,598 60,531 21,329
2012-07-02 17,510 23,099 28,576 25,698 33,290 40,313 29
2012-08-02 17,752 23,430 29,019 26,089 33,783 40,897 0
2012-09-02 18,038 23,786 29,507 26,412 34,164 41,431 0
2012-10-01 18,287 24,121 29,940 26,756 34,614 41,981 0
2012-11-01 18,575 24,570 30,503 27,070 35,103 42,578 0
2012-12-01 18,881 25,046 31,064 27,607 35,803 43,402 0
2013-01-02 19,296 25,633 31,784 28,055 36,460 44,187 0
2013-02-04 19,669 26,344 32,632 28,496 37,111 45,016 0
2013-03-04 20,183 27,065 33,520 82,983 91,903 100,024 0
2013-04-03 20,460 27,515 34,048 83,679 92,826 100,984 0
2013-05-03 20,847 28,116 34,778 84,666 94,049 102,352 2
2013-06-04 20,929 28,236 34,931 84,881 94,304 102,644 2
2013-07-08 21,686 29,341 36,327 86,430 96,285 104,920 3
2013-08-05 22,052 29,838 36,968 87,253 97,268 106,059 2
2013-09-04 22,396 30,350 37,636 88,258 98,458 107,415 2
2013-10-01 22,754 32,765 38,514 89,031 101,316 121,514 12,734
2013-11-04 23,233 32,513 39,611 90,125 101,643 137,188 26,631
2013-12-02 23,649 33,080 40,309 90,843 102,537 138,574 26,982
2014-01-02 24,000 33,636 40,970 27,256
2014-02-03 24,434 34,345 41,845 27,925
2014-03-04 24,798 34,851 42,502 28,148
2014-04-02 25,241 35,424 43,233 28,533
2014-05-02 25,573 35,911 43,885 28,848
2014-06-14 26,003 36,527 44,616 29,109
2014-07-07 26,255 36,718 44,905 29,110
2014-08-11 26,636 37,289 45,655 29,493
2014-09-03 27,020 37,803 46,467 29,922
2014-10-08 27,477 38,476 47,273 30,329
2014-11-06 27,907 39,179 48,124 30,788
2014-12-08 28,412 39,897 49,032 31,264
2015-01-12 28,869 40,635 49,923 31,640
  • New results (Unique articles, Unique links, Total links and Duplicates) were recalculated at January 2015. Link = www.jstor.org/stable/something
  • Old results (Old articles, Old links, Old total links) were calculated December 2013. Link = jstor.org/something

@Astinson (WMF): The above shows the fixed data—I'm confident it's correct as I have done quite a few checks, but there are no guarantees at Wikipedia! I uploaded a new graph for the new data. The labels on the x-axis now show the actual dates, and the graphs for the new data show a rise between the third and fourth dates. That is simply because the fourth date is five months after the third—the values are actually smoothly increasing month-by-month. My latest pain is that the new graph I uploaded is not being displayed (I uploaded it twice because that misled me!). If you ctrl-click the above graph the file page will open in a new tab. In that tab, click the graph as if you wanted to see the full-size image. That shows the correct image. I assume there is a caching problem, but if there is something I should have done, please tell me. Johnuniq (talk) 02:55, 3 February 2015 (UTC)

Groan. I just needed to press Ctrl-F5 to fix the image caching. I've never had to do that at Wikipedia, although I've often used ?action=purge which failed to help in this case. Johnuniq (talk) 03:03, 3 February 2015 (UTC)

Old discussion

  • Following is obsolete: the data originally posted was wrong because my script had a bug and was often wrong when deciding whether a particular page was an article. The above data is correct. Johnuniq (talk) 02:37, 3 February 2015 (UTC)

These results are somewhat preliminary as I have just produced them. By the time I have looked at the other request I will be me more confident that these are good. I have spent a ridiculous number of hours getting all this because of two interesting problems. First, some MediaWiki changes meant that at a certain date the format of the dump files changed and it took a long time for me to work out why my results had gone haywire. While investigating, I noticed a second problem, namely that many link records were duplicated—for example my results would show two identical links to jstor in one article. In the past that has occurred, but only occasionally, and only when the article actually had two identical links. This time, there were lots of duplicates even when the article had only one link. Eventually I worked out that it was due to protocol relative links like //www.jstor.org/stable/3130273 which are recorded in the database twice—once indexed under "http" and once under "https". As a workaround, I decided to just eliminate all duplicate records from the report. That can be regarded as a feature because if an article has two identical links, the editor probably should have used a single reference (which would be regarded as a single link). At any rate, that's what the new results do. The "Duplicate" column shows how many duplicate links have been omitted. Obviously something very strange happened in June 2012, but apart from that the only significant duplicates are due to the steady use of protocol relative links.

I ran the scripts (updated to deal with the database changes) against all the external links dumps that I have. The table and graph above show the new results and those determined a year ago. The new results find a much smaller number of links because the URL is much more restrictive. By the way, examining the data files shows that there are hundreds of dubious links and I probably should produce a list for wikignomes to fix. The results include http, https, and protocol relative. There are only a handful of https links and they probably should be converted to protocol relative.

Re the graph: The x-axis is automatically labeled and the dates it shows are interpolated and not the actual dates. They are good enough so I didn't bother fixing them. The new results are much more believable than the old—as discussed, they became misleading when seach links started being added to articles. Johnuniq (talk) 09:51, 28 January 2015 (UTC)

Wow! Thank you for the fantastic work and thank you for going to great lengths to fix your numbers! I am wondering if something else is going on as well: for example, the linksearch query is producing a different number than the numbers from the dumps (even accounting for the double counted pages). For example,on 8/12/2014, I have 55635 links being reported by the query. Accounting for the doubles on 8/11/2014: (28,392 + 2*18,211) there is 64814 links according to your numbers. Did you include a space other than article space? I wonder what the linksearch tool is doing differently, that might be correcting for some of the problems you are identifying (but obviously not for the http(s)// problem). It would be interesting to do a comparison between the links you are pulling from dumps, and a group pulled around the same time as a dump.
Now that you mention the doubles, I also found that looking through the LinkSearch Query: I fixed one related to the "|jstor =" variable in cite journal. Good to know that error is existing. Probably an AWB+Bot set of tasks. I might make a pass at some of those during volunteer hours in the next month or so (though don't rely on me, if other volunteers get to it, thats fine: two jobs are making Wikipedia volunteer time rare occurrences). I will ponder a bit more and look at that when I have little bit more time this/next week. In the meantime, looking forward to the cochrane numbers. Astinson (WMF) (talk) 21:15, 28 January 2015 (UTC)
There is a major SNAFU somewhere. LinkSearch does not show duplicates so the discrepancy is not due to the duplicates problem. The way LinkSearch works (I have found this from experiment) is that if you enter something like jstor.org/stable/1234 it assumes you want http links only. Using LinkSearch for www.jstor.org/stable/20069986 shows nothing, but if you add https (LinkSearch https://www.jstor.org/stable/20069986) it finds France–Thailand relations where that link is used. A protocol relative link has two entries in the EL table, but LinkSearch only searches for either http or https but not both, therefore LinkSearch will never find two entries so it does not have a duplicate problem. My script was examining the raw table and it finds both entries (my script counts both http and https links).
I have another script which uses the API to do the equivalent of LinkSearch and I just ran it. It finds 50,414 links in 29,075 articles today, whereas my search tool finds 31,331 links in 18,012 articles in the 12 January 2015 dump. Major FU! I haven't checked the duplicate issue when using the API, but I might have found a clue for another cause. The EL dump contains just the link and the page_id, not the page title. Therefore I have to do some other trickiness to work out if the page_id is for an article or for another namespace. I have found a few cases where for some as yet unknown reason a page_id for an article is not detected as such by my script. I'll be a day or two before I get this sorted out... Johnuniq (talk) 09:25, 29 January 2015 (UTC)
Progress report: I have found my bug—it's a simple blunder with bad consequences, namely that thousands of records were skipped. The good news is that the bug was introduced when trying to cope with the change in the format of the dump files which I mentioned above, and that means the old results (from last year and before) are not affected. It's only the results above that are wrong.
I'm using a regex to extract records from the dump (a bad idea because it's fragile, but the alternative would be to write a small but full-scale parser in C ... a fair bit of work). Some of the new fields can have value NULL and my regex failed when encountering records with them. More later. Johnuniq (talk) 00:57, 30 January 2015 (UTC)
You caught my oversight in the LinkSearch, but thanks for the great work more generally in fixing your tool/numbers. You are doing a fair bit more work, then I was expecting, and am extremely grateful! I hope these resolve themselves without too much more diving on your part. Please don't build a parser if you don't need to; if worse comes to worse, we could go without the longterm JSTOR metrics: the Cochrane ones are a bit more important however (and might be easier to find in a query). Astinson (WMF) (talk) 16:29, 30 January 2015 (UTC)

Update

I have rewritten the parser in my script (replacing the silly regex hacks with proper csv parsing) and have done some independent checks that give confidence it is working. I'm running it all again to generate results at the moment, but it will take some hours to finish (an externallinks dump file is 12GB!), and more time after that for me to assemble the results and give them a final sanity check. I wanted my dump parser to work, and I knew that the original procedure was flawed, so I'm glad to have rewritten it.

Meanwhile, I had a quick look at the Cochrane issue and searched the most-recent dump (2015-01-12) for links that contain "onlinelibrary.wiley.com/doi/10.1002/14651858". I put the raw results at User:Johnuniq/wiley#Februrary 2015. There are only 112 articles and 145 unique links—that does not sound much. Is that all you expected? I'll ping you again when finished, in a day or two. Johnuniq (talk) 09:31, 2 February 2015 (UTC)

@Astinson (WMF): I'm pinging in a separate edit because experience shows that notifications fail when adding a heading. By the way, I just noticed that LinkSearch now includes my wiley subpage. If that is irritating, please undo my edit to remove them so the LinkSearch results aren't disrupted. Johnuniq (talk) 09:34, 2 February 2015 (UTC)

Hey Johnuniq, using this search I got 404 results on 1-20-2015, and that includes a fair number of talk page links, I would imagine (based on the current search). I will undo the edits, just so we aren't inflating those numbers (we could always park that information on Meta, if you want to keep some live records of the links). Thanks for all the great work: there is no rush, and if it simplifies things, we just need to identify change over time on these, if going from every 2 months to every 3 months for numbers helps, that would be just fine. Astinson (WMF) (talk) 19:51, 2 February 2015 (UTC)

Cochrane results

The following is a count of all external links containing "onlinelibrary.wiley.com/doi/10.1002/14651858" (not case sensitive) in articles, found by examining dumps like enwiki-20150112-externallinks.sql.gz downloadable from here. Links in pages other than articles are not included.

Date Unique articles Unique links Total links
2011-06-20 0 0 0
2011-07-22 0 0 0
2011-09-01 0 0 0
2012-02-11 13 12 13
2012-03-07 14 13 14
2012-04-03 14 13 14
2012-05-02 16 15 16
2012-06-01 19 18 19
2012-07-02 20 21 22
2012-08-02 22 23 24
2012-09-02 22 23 24
2012-10-01 23 24 25
2012-11-01 24 25 26
2012-12-01 25 26 27
2013-01-02 26 27 28
2013-02-04 27 28 29
2013-03-04 35 34 37
2013-04-03 34 33 36
2013-05-03 34 33 36
2013-06-04 35 34 37
2013-07-08 40 41 46
2013-08-05 41 42 49
2013-09-04 42 44 50
2013-10-01 47 46 55
2013-11-04 55 55 66
2013-12-02 67 75 87
2014-01-02 63 72 81
2014-02-03 65 76 86
2014-03-04 75 91 101
2014-04-02 76 92 102
2014-05-02 80 90 100
2014-06-14 84 97 105
2014-07-07 91 109 117
2014-08-11 93 107 114
2014-09-03 92 107 114
2014-10-08 95 111 118
2014-11-06 105 124 134
2014-12-08 109 128 138
2015-01-12 111 135 145

I searched all the dump files I have. No articles had duplicate links. Johnuniq (talk) 05:35, 3 February 2015 (UTC)

I just ran LinkSearch. There are currently 313 matching links, but after removing all the non-article pages, 145 links in 112 articles remained. There is an extra article due to editing since 2015-01-12. Looks good! Johnuniq (talk) 06:21, 3 February 2015 (UTC)

Barnstar

The da Vinci Barnstar
For committing to so much bug hunting and number crunching in the quest to support Wikipedia Library metrics, Astinson (WMF) (talk) 16:29, 30 January 2015 (UTC)

Talkback

Hello, Johnuniq. You have new messages at 208.81.212.222's talk page.
Message added 18:43, 23 January 2015 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

I'm sorry

I didn't think. I was so happy to get a reply from her. Paul Austin (talk) 09:15, 25 January 2015 (UTC)

No problem! I'll reply on your talk. Johnuniq (talk) 09:50, 25 January 2015 (UTC)

Talkback

Hello, Johnuniq. You have new messages at I dream of horses's talk page.
Message added 14:52, 26 January 2015 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Koko Nigel

You probably won't believe this but I blocked him for 5 hours this afternoon and the minute the block expired he continues to edit as if nothing had happened. Reblocked fo 24 hours this time in the hope that he will communicate. --Kudpung กุดผึ้ง (talk) 15:47, 26 January 2015 (UTC)

Thanks for looking at the situation. In case you missed it, I gave a link to an archived WP:AN discussion at the user's talk. I asked for some help at WT:AAR#Monitoring needed. There is some underlying problem. Johnuniq (talk) 22:03, 26 January 2015 (UTC)

Courtesy Notification

Hello, and thank you for your notification relating to the GamerGate Community Sanctions. I'm not entirely familiar with the procedural aspects in play here, but am I supposed to add your username to the notification list as well, since we engaged in a content discussion on the 4Chan talk page? Seems silly, since you're obviously already familiar with the sanctions, and I don't want to leave the impression that the notification is in any way retaliatory. But at the same time, I do want to be equitable. ColorOfSuffering (talk) 20:33, 27 January 2015 (UTC)

STOP!!!

Information icon Please refrain from making unconstructive edits to Wikipedia. Your edits appear to be disruptive and have been reverted or removed.

  • If you are engaged in an article content dispute with another editor then please discuss the matter with the editor at their talk page, or the article's talk page. Alternatively you can read Wikipedia's dispute resolution page, and ask for independent help at one of the relevant notice boards.
  • If you are engaged in any other form of dispute that is not covered on the dispute resolution page, please seek assistance at Wikipedia's Administrators' noticeboard/Incidents.

Please ensure you are familiar with Wikipedia's policies and guidelines, and please do not continue to make edits that appear disruptive, until the dispute is resolved through consensus. Continuing to edit disruptively could result in loss of editing privileges. Thank you. 67.163.88.57 (talk) 04:06, 29 January 2015 (UTC)

GSL article Inappropriate talk section

Hello. Thank you for your insight and effort, but I'm afraid it looks like that IP editor is back, and not happy with your changes... https://wiki.riteme.site/w/index.php?title=Talk%3AGun_show_loophole&diff=644652445&oldid=644652185 -- What should I do? Thanks again. Darknipples (talk) 04:21, 29 January 2015 (UTC)

Yes, I know. Just leave it to me. I will probably have to formally notify you and LB about what I do next, but I'm just doing that to tick the boxes. I actually suggest that you and LB do nothing. I don't know what will happen but I'll outline the situation and leave it for admins to resolve. We will all have to be patient (see the section just above this). Johnuniq (talk) 05:01, 29 January 2015 (UTC)

A barnstar for you!

The Anti-Vandalism Barnstar
I can't thank you enough. Darknipples (talk) 10:01, 29 January 2015 (UTC)

Lua: false result of mw.text.split

As you can see the "row" function in my Module:Sandbox/Sameboat/m1, I use mw.text.split to split the argument into table values which pretty much works well, except that I don't know how to create a fail-safe in case there is no separator (\\) present after the entry of a new line so the loop insert some placeholder value which continues to create an empty wiki table cell (see User:Sameboat/sandbox#row, the "key 8" row). (I overlooked the Wikiversity tutorial which is something exactly I need to learn Scribunto.) Thank you. -- Sameboat - 同舟 (talk · contri.) 01:33, 30 January 2015 (UTC)

Thoughts:

  • By the way, it is sometimes useful to put a template into Special:ExpandTemplates and see exactly what it outputs. That might be useful.
  • mw.text.split returns a "numbered" list, for example { 'a', 'b', 'c', 'd' }.
  • I would expect the row "filler1\\filler3" to be split into three columns: "filler1", "" (empty string), "filler3". That might give strange results in the loop. I don't have the energy to think about that now.
  • Iterating using pairs() returns rows in an arbitrary order. It may give the rows in the order you want, but in general it will not. It must not be used for this application.
-- Loops should be like this.
for k1, v1 in ipairs(mw.text.split(somelist, '\n')) do
    for k2, v2 in ipairs(mw.text.split(v1, '\\')) do

My mind is elsewhere and all I can do now is offer the above thoughts. Please spell out what you want the module to do with the double backslash. What should happen if the input has two backslashes like abc\def\ghi? Johnuniq (talk) 03:11, 30 January 2015 (UTC)

There is no rush to reply :) About that "filler1\\filler3", it's just for testing what if a "template user" (who only applies the template in the article instead of fiddling with template or module codes) uses the template/module not intended by the template/module designer. If I would like to be very safe, the module should ignore anything begins with the 2nd backslash (in this case, "\filler3") so only "filler1\" is returned for that table row. But really I can simply write in the doc to warn the user not to use the template that way in order to keep the module code as simple as possible. Similarly I can also require the presence of the backslash on every new line otherwise it won't work as intended. -- Sameboat - 同舟 (talk · contri.)

Following is how you would ignore bad input. It may be convenient to concatenate a backslash to v1 so the first and second columns are guaranteed to exist.

for k1, v1 in ipairs(mw.text.split(somelist, '\n')) do
    for k2, v2 in ipairs(mw.text.split(v1 .. '\\', '\\')) do
        if k2 > 2 then break end

Johnuniq (talk) 05:01, 30 January 2015 (UTC)

Thank you. It works like charm. -- Sameboat - 同舟 (talk · contri.) 05:22, 30 January 2015 (UTC)

Lua: global or local var?

I'm writing Lua module in other wikia project. The module in question groups various infobox templates with different styles and data cells into one single function. The major incentive for doing this is because these infoboxes (>10) usually are used in the same time in a single article. As I read from lua.org which says local var runs faster than global var. The thing is, I quickly hit the Scribunto cap of 200 local variables per function because there are so many named parameters. I manage to avoid the limitation by sharing non-conflicting parameters with one local var, also by changing some local var to global. What's your practice of global var? -- Sameboat - 同舟 (talk · contri.) 08:06, 17 February 2015 (UTC)

I never use global variables except where they are actually required (which is very rare, apart from accessing things like mw which is a global variable). I am concerned about efficiency, but we would probably never notice any difference in speed from using local/global. My main concern about globals is that they can hide simple typos which lead to silly bugs. For example, consider:
local count = whatever
...
return cout
The last line is a typo which is easy to see here but not so easy in a complex module: cout is a global variable holding nil, when count was intended.
If you want, post a link to the module at Wikia and I'll have a quick look because it sounds like things should be done a different way as 200 locals should never be needed. Generally, it is much better to put related things in a table so there would be one local (the table), which might have 200 key/value pairs. Using items from a table would be a tiny bit slower than having a separate local variable, but much easier to comprehend. Also, the table can be passed to functions to do required work. The 200 is a hard limit of Lua, by the way, not Scribunto. Johnuniq (talk) 08:38, 17 February 2015 (UTC)
Thank you. Module, testcases. In the testcases page, infoboxes of the left side use the Lua module and the right side use the original templates. -- Sameboat - 同舟 (talk · contri.) 08:48, 17 February 2015 (UTC)

That's a bit too big for comprehension, but here are some ideas, completely untested. The first couple of points are just "by the way" things I noticed and you can ignore them

-- By the way, you do not need Module:Arguments. Instead of:
local args = getArgs(frame, {parentOnly = true})
-- the following works:
local args = frame:getParent().args

-- When a key is a simple word which would work as a Lua variable,
-- the key can be used after a dot. That is, instead of:
    styles['statlow']
-- you can use:
    styles.statlow

-- The current code includes the following two lines.
local death = args.Death or args.death or args.DE or args.De or args.de
local dark = args.Darkness or args.darkness or args.Dark or args.dark or args.DK or args.Dk or args.dk

-- Suggested replacement (all similar locals would be treated like these examples).
local property_names = {
    death = { 'Death', 'death', 'DE', 'De', 'de' },
    dark = { 'Darkness', 'darkness', 'Dark', 'dark', 'DK', 'Dk', 'dk' },
}

local function get_properties(args)
    local properties = {}
    for k, v in pairs(property_names) do
        for _, name in ipairs(v) do
            if args[name] then
                properties[k] = args[name]
                break
            end
        end
        -- If wanted, a default could be set here. For example, use one of:
        properties[k] = properties[k] or '-'  -- if '-' is wanted as the default
        properties[k] = properties[k] or v.default  -- if add ", default = 'whatever'" to each row in property_names
        properties[k] = properties[k] or v.default or '-'
    end
    return properties
end

-- In the function where the arguments are processed, use the following.
local properties = get_properties(args)
-- Then use properties.death instead of the local variable death.
-- Since that is used a lot, perhaps use a single letter instead of "properties".

The code has many lines like if gameg == 'smt4' then. A lot of that should probably be defined in a table, but it would take me too long to understand what is required to make a recommendation. The aim is to understand what the program has to do, then try to put the rules for that behavior in a data table. That would eliminate the immense amount of repetition in the current module. Good luck, and try me again if you have a specific question. Johnuniq (talk) 09:49, 17 February 2015 (UTC)

Thank you. I will try that later but your suggestions already explain lot of things I could never come up with. Just a confirmation: according to your suggestion, do properties.x and properties.y cost one single variable in the same function but still hold separate values/assignments? (Sorry for unauthentic terminology.) -- Sameboat - 同舟 (talk · contri.) 10:39, 17 February 2015 (UTC)
Yes. The "local properties = {}" is the single local variable, and properties.x means properties['x'] which means the item in the properties table with key 'x' (or nil if none exists). Johnuniq (talk) 10:46, 17 February 2015 (UTC)

I followed your instruction and modified the module greatly to avoid the local limit, the testcases pretty much works fine. Sadly I still don't get how local args = frame:getParent().args works in place of module:Arguments. It seems the p function has to be modified somehow to cope with the change. Also I did a little twist on "get_prop" function (I shortened "properties" to "prop" due to its high repetition in the module) to define keys which should be given a default empty string value, even though I can set the empty string value for all keys and then change the "not" operator in the Stats function with "~=''". Either way, I wonder if there's any shortcut or better practice to state var == 'a' or var == 'b' or var == 'c' .... Thank you. -- Sameboat - 同舟 (talk · contri.) 16:20, 17 February 2015 (UTC)

It doesn't matter, and as Module:Arguments is working, you may as well not bother changing it. Removing it would require removing the p.stats line, changing _stats(args) to stats(frame), and putting the getParent stuff in the stats function. Do the same for _row and row. Don't bother!
My quick reaction re the defaults would be to use something I said earlier; example:
level = { 'Level', 'level', 'Lv', 'lv', 'lvl', 'LV', 'LVL', default = '' },
...
Instead of if k == 'level' or ... use:
prop[k] = prop[k] or v.default
An alternative would be to have another table that defines the wanted defaults:
local defaults = { level = '', investigate = '', ... }
And use:
prop[k] = prop[k] or default[k]
In general, you would use a "set" to check a variable against a large number of fixed values. Lua does not support sets directly, but they are easily simulated using a table with each value set to true.
local have_default_empty = { level = true, investigate = true, ... }
if have_default_empty[k] then ... end
Warning: I'm in a rush, and haven't studied the above! Johnuniq (talk) 23:03, 17 February 2015 (UTC)

Continue

I followed your suggestion and now the module in wikia works well. I split the Property_names table to a separate module because it's about 11k and the main module itself already exceeds 100k. So what's your threshold of splitting the module? The main Stats module now contains SL of if/else which I guess not the way you prefer, but when I experiment with table, the returned result of table key/value is in arbitrary order. Wikiversity:Lua/Tables simply says the issue is inevitable without suggesting any workaround... Thank you. -- Sameboat - 同舟 (talk · contri.) 08:54, 26 February 2015 (UTC)

I don't have a recommendation of when to split a module. Module:Convert is way too big, and if one were writing a conventional program it would be split into at least a dozen files in order to make it more comprehensible and manageable. However, splitting has a penalty in that you have to go somewhere else to see the other code, and splitting increases complexity. I don't mind a single big program providing it is reasonably compartmentalized and sort-of proceeds from the top of the file to the bottom.
The reason Module:Convert/data is split is that it is a gigantic blob of data which is much more efficiently accessed using mw.loadData. If ten converts appear on a single page, MediaWiki will load and execute Module:Convert ten times. However, Module:Convert/data will be loaded only once per page (that's because of the loadData; if require were used, it would also be loaded ten times).
The way to access data in a preferred order is to have another table. You might have table X which contains lots of key–value pairs. If you use pairs(X) the keys will be accessed in an arbitrary order. The solution is to make another table, say Y, which is numbered: local Y = { 'a', 'b', ... } where 'a' and 'b' are the names of keys in X. Then you can have for _, key in ipairs(Y) and operate on X[key] in the ipairs loop. That would be useful if a loop could avoid repeating a large number of if/else statements. Johnuniq (talk) 10:44, 26 February 2015 (UTC)
I'm experimenting in Module:Sandbox/Sameboat/m1. Just a totally random question: how do I start the ipairs loop from index other than 1? (Say, 2). Thank you. -- Sameboat - 同舟 (talk · contri.) 12:52, 26 February 2015 (UTC)

Here are three ways to iterate from 2.

t = { 'a', 'b', 'c', 'd' }
for i, v in ipairs(t) do
    if i > 1 then
        print(i, v)
    end
end
for i = 2, #t do
    print(i, t[i])
end
for i = 2, 1e6 do  -- where 1e6 (1 million) is larger than needed
    if not t[i] then break end
    print(i, t[i])
end

For a strange order, use another table.

t = { 'a', 'b', 'c', 'd', color = 'red' }
for _, v in ipairs({ 3, 'color', 4, 2 }) do
	print(t[v])
end

By the way, I use the following for accummulating results.

local function collection()
	-- Return a table to hold items.
	return {
		n = 0,
		add = function (self, item)
			self.n = self.n + 1
			self[self.n] = item
		end,
		join = function (self, sep)
			return table.concat(self, sep)
		end,
	}
end

local function work()
	local results = collection()
	for i = 1, 5 do
		results:add('i = ' .. i)
	end
	return results:join('\n')
end

local s = work()  -- this is a string of 5 lines

Johnuniq (talk) 00:23, 27 February 2015 (UTC)

Hello! You have been selected to receive an invitation to participate in the closure review for the recent RfC regarding the AfC Helper script. You've been chosen because you participated in the original RfC. Should you wish to respond, your contribution to this discussion will be appreciated. This message is automated. Replies will not be noticed. --QEDKTC 14:24, 18 February 2015 (UTC)

ANI notice concerning Javalenok

Information icon There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Thank you. - DVdm (talk) 17:08, 23 February 2015 (UTC)

Thanks, that had a rather obvious outcome. Johnuniq (talk) 23:11, 23 February 2015 (UTC)

Handwritten barnstar

In this period of low of topical activity, I want to compliment you with your contributions to the big {{convert}}. You keeping an overview and a cool, both in code and in the talkpage (where I roam and distract), taught me something. We met some 18 months ago, I am a better editor now. Thanks -DePiep (talk) 21:44, 24 February 2015 (UTC)

Wow, thanks very much, and thanks for all your help! Johnuniq (talk) 00:35, 25 February 2015 (UTC)

Just some random practice of Lua coding. The module in question while functions as intended, behaves weirdly when I enable the "fallback" return (line 60) intended for unmatched table t1 key with args[1] value: all valid args[1] entries for t1 key's value (as can be seen in {{LACMTA icon/testcases}}) fallback to line 60 without exception. Thanks for your help all along. -- Sameboat - 同舟 (talk · contri.) 16:07, 1 March 2015 (UTC)

If line 60 is uncommented the if becomes:

if something then return X else return Y end

so it always terminates after the first loop.

Are the loops needed? I would use an aliases table as I think we discussed previously.

    local key = code:lower()
    local result = t1[key] or t1[aliases[key]]
    -- (and change t1 so the above works)

By the way, Lua's lower() works well and is fast, but only when dealing with standard English characters. If the input might use non-en characters you would need to use the mw.ustring library. Johnuniq (talk) 00:35, 2 March 2015 (UTC)

I figured that the "fallback" should be put outside of the for loop. As for the for loop itself, from what I know the original template tells editors to use "aliases" instead of the full name (i.e. the key name in t1), so it's inevitable to have the template to translate the abbreviation/alias for the actual name. Pretty much the similar case of module:MTR/data (not module:HK-MTR stations/data). If I use a separate aliases table, this table will be as tall as the main table which I guess (a huge assumption) the difference of efficiency is minimal. -- Sameboat - 同舟 (talk · contri.) 01:20, 2 March 2015 (UTC)

Shakespeare authorship question

Hi! Just wondering why you undid an edit on the 'Shakespeare Authorship Question.' Do you really think that the statement 'the historical record is unequivocal in assigning the authorship of the Shakespeare canon to William Shakespeare' is not misleading? Surely if the historical evidence WAS unequivocal there would be no question! And after all that is what the page is about. In fact it is the very fact that the historical evidence IS equivocal which created the whole fascinating debate. Just because Martin 1965 was of the opinion that it was unequivocal does not mean that this can be simply left as an unquestioned statement which may mislead readers seeking fact rather than opinion.

Best wishes,

Fascinated to hear your response. — Preceding unsigned comment added by 46.208.27.196 (talk) 01:18, 7 March 2015 (UTC)

It's not so simple. For one thing, the topic has been subjected to an enormous amount of POV pushing, and after much disruption the matter went to arbitration, see WP:ARBSAQ. There are hundreds of topics at Wikipedia where enthusiasts like to inject doubt, from Climate change to Ayurveda, and a lot more. Every topic has denialists and enthusiasts and it is not possible to make everyone happy. At any rate, if you want to pursue the proposed edit, please raise the matter at Talk:Shakespeare authorship question. People are unlikely to want to discuss it much because we're still exhausted from the previous battles, but the essence is that articles like SAQ are based on what scholarly sources say—it's more than just some old guy's opinion. Justifying a change would need doubt from a source by an acknowledged expert on Shakespearean issues and Elizabethan history. Johnuniq (talk) 02:03, 7 March 2015 (UTC)
The record is unequivocal; those who question the identity of Shakespeare question the historical record. Tom Reedy (talk) 03:32, 7 March 2015 (UTC)
Hi Tom! Things have been pretty quiet lately, but it's good to hear from you. Johnuniq (talk) 05:40, 7 March 2015 (UTC)

What you call a 'scholarly source' is Milward W Martin's 'Was Shakespeare Shakespeare?' (1965). Martin was no Shakespearian scholar, as you well know. He was legal representative of Pepsi Cola and his only other book is a history of Pepsi Cola. His is the only citation you have given for this incredible claim. — Preceding unsigned comment added by 213.1.36.187 (talk) 12:11, 7 March 2015 (UTC)

Convert + peerreviewer

Thanks for your message & fixes to United Kingdom. I should have spotted the error with "sq mi". I think this was generated by User:AndyZ/peerreviewer but the owner/developer of this appears to be inactive.— Rod talk 07:43, 9 March 2015 (UTC)

Thanks, happy editing! Johnuniq (talk) 10:19, 9 March 2015 (UTC)

Elon Musk

Information icon Please refrain from making unconstructive edits to Wikipedia, as you did at Elon Musk. Your edits appear to be disruptive and have been reverted or removed.

  • If you are engaged in an article content dispute with another editor then please discuss the matter with the editor at their talk page, or the article's talk page. Alternatively you can read Wikipedia's dispute resolution page, and ask for independent help at one of the relevant notice boards.
  • If you are engaged in any other form of dispute that is not covered on the dispute resolution page, please seek assistance at Wikipedia's Administrators' noticeboard/Incidents.

Please ensure you are familiar with Wikipedia's policies and guidelines, and please do not continue to make edits that appear disruptive, until the dispute is resolved through consensus. Continuing to edit disruptively could result in loss of editing privileges.

If you are going to revert pages and post warnings to other users, please at least have read the guidelines. You removed information that was posted in good faith, and warned a user for reverting vandalism by a user who was inventing his own guidelines. If you are going to warn users and revert content, at least warn the person who was breaking guidelines and removing content under his own set of rules. Please read the edits and reversions, as well as WP guidelines before errantly reverting and harassing others.

Thank you. — Preceding unsigned comment added by DbivansMCMLXXXVI (talkcontribs) 22:43, 15 March 2015 (UTC)

Elon Musk (edit | talk | history | protect | delete | links | watch | logs | views)
Confidence is good, but it might be a little misplaced for a two-week-old account with 33 edits. I suggest asking questions rather than explaining procedures to others. It wasn't a "warning"; I was merely informing (diff) a new user of what happens. Please click "new section" at the top of a talk page when wanting to create a new topic (I added a section heading here), and remember to sign comments. Johnuniq (talk) 01:21, 16 March 2015 (UTC)

Units stuff

Just wanted to mention that the redirect for "Legal stone" was deleted Wikipedia:Redirects_for_discussion/Log/2015_February_18#Legal_stone in case you want to note this on the list. I am hoping (finally!) to have a bit more time for WP editing. There is much to do -- I just noticed the picul article really is quite a mess, including a bit about "stone", which seems to be a different unit altogether. Perhaps we could make an effort to revive the measurement project page, which I believe is defunct. Imaginatorium (talk) 03:51, 17 March 2015 (UTC)

First, I noticed your edit at Fathom (to remove symbol "ftm") and I commented at Talk:Fathom#Abbreviation "ftm". A series of comical events led me to be fooled by the "ftm" that was in the article when I had looked at it previously. At any rate, I am undoing the misconception, see Template talk:Convert#Fathom symbol revert. There is nothing needed from you, and in fact you don't need to look at those links! Just FYI.
Re User:Johnuniq/sandbox3, I am in a bit of a mess with a few things going on here but mainly off-wiki. I have some notes about updates to that page (thanks for the above which I did not notice), and I intend getting around to it RSN. The good news is that (I think) there have not been any more new "articles". I'll have to pass on doing anything at the moment, but I intend returning. I should be clear in a week, and please hammer me if I'm not. Yes, many of the unit articles need improvements. Thanks for all your efforts! Johnuniq (talk) 04:19, 17 March 2015 (UTC)

about undoing my tagging edits.

I wish to feet responses on my talk page.

About the section expansion tag, ok no problem you can remove it, but not the no references tags, there is a reason why they must be kept there. According to Wikipedia rules, all sections must have at least one or more sources. If they do not have sources this tag must be placed to show that there is a reason why one can delete that section.

Also, about that section expansion tag. I discovered from the rules just now that tag should be used on sections that have less than 4 or 5 lines, since a section must be at least a paragraph in order for it to be considered a section on Wikipedia.

Thank you in advance. Have a nice day.  :) Doorknob747 23:45, 20 March 2015 (UTC) — Preceding unsigned comment added by Doorknob747 (talkcontribs)

I'm trying to summit my site . what steps should i take?


thanks

carlos — Preceding unsigned comment added by Carlos21122 (talkcontribs) 06:22, 23 March 2015 (UTC)

problem

Now it is asking if one were to do it via a multipxer for Jd and Kd thru Ja and Ka and each gerated by using a multiplexer that is a 8 to 1 line multiplexer for each J and K controll. it says to write down the 8 input lines of each multiplxer, including alternatives. It says the least significant address lines is the ones and is connected to Qa and the most significant the fours, adress line is for each multiplexer is Qc. It states that Qb is connected to the twos adress lines in each case.

please helpDoorknob747 (talk) 16:29, 25 March 2015 (UTC)

Sorry, but I've got a lot of other things to do, and can't say more than what I posted at WP:Reference desk/Computing. Johnuniq (talk) 01:13, 26 March 2015 (UTC)

Chembox convert struggles

Hi John! I hope you're doing well. I'm struggling with the chembox convert thing again - this time with expressing a flash point greater than or less than something. At Fonofos, I'm trying to put in a flash point of ">201" but it's telling me that it's an invalid number to convert. Is there a way I can have the ">" in a different parameter or do I need to manually use the convert templates? Thanks so much! Best, Emily Temple-Wood (NIOSH) (talk) 19:06, 26 March 2015 (UTC)

LOL! People are going to think I know what I'm doing! Anyway, this edit seems to have done the job. The docs at {{Chembox}} led me to "more on temperatures" which is a subpage at Template:Chembox CalcTemperatures, and decoding that led to my edit. It looks like most of the docs talk about the melting point settings, with the implication that the same principles apply to the others. Johnuniq (talk) 23:25, 26 March 2015 (UTC)
You certainly know more than I do about this! :) Thanks so much for your help! Emily Temple-Wood (NIOSH) (talk) 15:20, 27 March 2015 (UTC)

Double standards?

Good day Johnuniq, can you explain for me please your reasons for condemning "MetricStronk" for being an SPA and for changing the style of existing articles to SI with edits marked as minor, whilst at the same time apparently condoning exactly the same actions, over years, by "Archon 2488"? Hugh8 (talk) 00:21, 29 March 2015 (UTC)

Please find something else to do—anyone who puts all their energy into arguing about any kind of style issue is going to have a short wiki-life. Johnuniq (talk) 11:12, 29 March 2015 (UTC)
Yes, double standards indeed. I see your SPA friend is still changing the style of existing articles to SI with edits marked as minor ([2]). Now I see you are in cahoots with another thinly veiled metrication "enthusiast":- "Michael Glass". His edit history is also full of ducks and dives aimed at 100% metrication. He's relentlessly substituting existing references with metric references in 100s of articles, then coming back later and metricating them on the pretence that the references give metric! Crafty, eh? And his name is all over numerous disputes about that. It's clear now where your loyalties lie, and I'm sorry I wasted my time coming to you for help in trying to reverse "MetricStronk"'s work, and "Archon 2488"'s support of it. Now we have you, "Metric Stronk", "Archon 2488" and "Michael Glass" all apparently working to the same barely hidden agenda. And now, between you, you have hammered home "MetricStronk"'s metrication of the "Thundersnow" article. Hugh8 (talk) 10:32, 31 March 2015 (UTC)

Information icon There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Thank you. — Preceding unsigned comment added by Hugh8 (talkcontribs) 20:19, 3 April 2015 (UTC)

I have some questions about editing and editors

Hello, I got your message about editing and welcoming me, etc. Thanks. Now I have a question. Another wiki editor removed my edit from the article on St. Paul the Apostle. My edit removed a sourced statement which claimed that the conversion of St. Paul was a propaganda piece instead of genuine conversion. I removed this, not only because it is offensive to Christians (which Wikipedia seems to love to offend), but also because any cursory reading of the book of Acts and Paul's own epistles renders the propaganda theory utterly ridiculous. St. Paul could not have lived and died for something he knew to be a lie. From his epistles it is clear that Paul had a genuine conversion experience and that he believed what he said was true. But this other editor removed my comment because he claimed that it was on the basis of my "personal opinion" that I was dismissing a so-called "sourced statement." First of all, the conversion of Paul is not my opinion, it is a fact recorded in the Bible and borne out by 2,000 years of Christian history. Second, simply because a statement is "sourced" does NOT mean it cannot be wrong, and in this case, the statement was not only wrong but it was stupid and offensive. So what should I do here? Feel free to email me at tpkatsa at gmail dot com to discuss further. Thank you. Tpkatsa (talk) 20:44, 7 April 2015 (UTC)

The issue is this edit (11 February 2014) at Paul the Apostle. The reply at the article talk is a bit strong, but that may be due to the fact that there has been quite a lot of disruption on some related topics in the last few months, with people wanting to push various barrows. The reply points out that the text you removed is no longer in the article, so debating whether someone should have reverted your removal is not productive. In general, however, opinions on what should be in an article need to be expressed more in terms of Wikipedia's policies (overview at WP:5P), and less on the basis of an editor's analysis of the situation. Bear in mind that many enthusiasts love to add tidbits to articles to promote some view they favor, and such editing needs to be handled calmly—such disputes happen all the time. By the way, editors expect new topics to be at the bottom of a talk page—the way to do that is to click "new section" at the top. Johnuniq (talk) 23:53, 7 April 2015 (UTC)

A beer for you!

Thanks for the smile and appreciation—I was pretty stoked when the mail idea popped in my head, so I'm glad that it went over well with most of the editing community. Ed [talk] [majestic titan] 03:00, 4 April 2015 (UTC)
Wow, an excellent April 1 Signpost, and free beer! Thanks!
For my records, this relates to some comments at WP:AN (permalink). Johnuniq (talk) 09:46, 4 April 2015 (UTC)

convert at fa.wiki

Hi, would please check why {{Convert|22.5|cm|in}} at fa.wiki doesn't use persian text like other convertions?

{{Convert|22.5|cm|in}} > ۲۲٫۵ سانتیمتر (۸٫۹ in) but it should be ۲۲٫۵ سانتیمتر (۸٫۹ اینچ)

for other convertions it is ok like

{{convert|3.21|kg|lb}} > ۳٫۲۱ کیلوگرم (۷٫۱ پوند)

Yamaha5 (talk) 20:03, 5 April 2015 (UTC)

The immediate problem is that fa:Module:Convert/data includes a definition starting with ["in"] which includes symbol = "in", and that defines the symbol (abbreviation) for inch to be "in"—change that as needed. However, the more fundamental problem is that fawiki is not using the makeunits module to translate names, as I think was briefly mentioned on your talk, and at User:Johnuniq/translate#Unit names. It would be better to use the master list of units approach (see examples at the "Unit names" link), however it might be a bit too late for all the required work to be worthwhile now. Johnuniq (talk) 03:09, 6 April 2015 (UTC)
Thank you for your reply. for cases which doesn't have abbr=, how can i set abbr=off as default?
Unicode-bidi directs have problem with Persian numbers and Latin characters like this. it is much better to have abbr=off as default.Yamaha5 (talk) 21:32, 6 April 2015 (UTC)
Are you aware that fa:Template:Convert had "|abbr=off always" removed in this edit?
If you want, edit the template to restore that, or change it to "|abbr=off default". See User:Johnuniq/translate#Abbreviations off.
Let me know how it works out. Johnuniq (talk) 22:17, 6 April 2015 (UTC)
:) thanks. It works fineYamaha5 (talk) 13:46, 7 April 2015 (UTC)

Hi Is it worth trying to obtain contact details for the victim's family, to get their approval for the Wikipedia entry on Kylie? Given that, unlike some other famous cases, there is no Kylie Maybury Foundation or such founded by the family, they may value their privacy. Paul Austin (talk) 09:18, 8 April 2015 (UTC)

No, editors should not contact the family of a six-year-old girl who was kidnapped, raped and murdered in 1984. People outside the family should not intrude in a situation like that, however good our intentions. You've done all that's possible with the article. Johnuniq (talk) 09:32, 8 April 2015 (UTC)

I managed to find this bit about discretionary sanctions. I thought to appeal to the person who enacted them, is there some other way I was not informed of? I was told April 4: "I am imposing for a period of 12 months the standard Gamergate topic ban" but I can see at Wikipedia:Arbitration/Requests/Case/GamerGate#Discretionary_sanctions that as of January 29 "The community Gamergate general sanctions are hereby rescinded" so that led me to think were were in a discussion process. If only "standard discretionary sanctions" apply then there is no such thing as a "standard Gamergate topic ban" because there's no more general sanctions for them, instead applying on an individualized basis. Ranze (talk) 08:37, 26 April 2015 (UTC)

You would also have seen the clause "All sanctions in force when this remedy is enacted are endorsed and will become standard discretionary sanctions governed by the standard procedure from the moment of enactment." (I underlined the key points). That means WP:ACDS#Appeals and modifications applies, so an appeal may be to the enforcing admin, or WP:AE, or WP:AN, or WP:ARCA. The last option is not likely to get a response other than a reiteration of what I've just said. If unsatisfied with the admin's response, the next step is WP:AE (or WP:AN—I don't recall seeing that option, but apparently it would be the editor's choice as to which one to use for an appeal). However, I advise caution because Wikipedia is an extremely pragmatic place and people at WP:AE or WP:AN would want to know how an adjustment would benefit the encyclopedia—what useful work is being prevented by the sanction? Consideration of the underlying rights-and-wrongs would also occur, but discretionary sanctions are extremely liberally applied because by the time things have gone through arbitration, the community has decided that anything that stops bickering is worthwhile. Therefore, an admin would have to be significantly wrong for an appeal to get anywhere. I don't think the wording used by the admin matters, so whether "standard Gamergate topic ban" is an accurate statement is probably irrelevant. Of course it's hard to predict the outcome at those venues, so my caution may not apply. My comment at User talk:Gamaliel#Topic ban was about a useful principle, namely that an appeal should mention what articles you would hope to improve if the topic ban were altered—that's the pragmatism I mentioned. Johnuniq (talk) 10:09, 26 April 2015 (UTC)

Notice of Edit warring noticeboard discussion

Information icon Hello. This message is being sent to inform you that there is currently a discussion involving you at Wikipedia:Administrators' noticeboard/Edit warring regarding a possible violation of Wikipedia's policy on edit warring. Thank you. PolenCelestial (talk) 02:53, 27 April 2015 (UTC)

A cup of coffee for you!

I did not mean to offend on the FGM talk page. Only trying to help. There is no way I can know what policies other editors are familiar with or may need to be reminded of. I don't see how the age of my account is relevant. I am a mildly experienced editor whose finally decided to create an account. Hope you have a great day! :-) OnlyInYourMind(talk) 19:59, 30 April 2015 (UTC)
And thanks for all the time you spend helping to improve Wikipedia! It looks like you've done a lot! :-) OnlyInYourMind(talk) 20:07, 30 April 2015 (UTC)

Hello! There is a DR/N request you may have interest in.

This message is being sent to let you know of a discussion at the Wikipedia:Dispute resolution noticeboard regarding a content dispute discussion you may have participated in. Content disputes can hold up article development and make editing difficult for editors. You are not required to participate, but you are both invited and encouraged to help this dispute come to a resolution. The discussion is at DRN:Female genital mutilation. Please join us to help form a consensus. Thank you! --Guy Macon (talk) 23:39, 1 May 2015 (UTC)