Fri, Aug 18
I don't know what "DDLB" is - "dropdown/listbox"? Anyway, I'm guessing that the "Type" dropdown isn't getting populated because you have neither the Cargo nor Semantic MediaWiki extensions installed. This looks like a bug in Page Forms - if neither of those extensions are installed, the "Type" column shouldn't be getting displayed at all.
Fri, Aug 11
Tue, Aug 8
Tue, Aug 1
Mon, Jul 31
Yes, I mean creating categories on the fly - and adding them to the appropriate parent category. This could potentially even mean editing multiple category pages at the same time: if a new category is added "between" two existing categories, then the subcategory needs to be modified to have a new parent category.
Fri, Jul 28
Okay, I just added "Category" back to the set of namespaces that #autoedit is allowed on. Is that enough to fix this issue? Or would you want some way to do inline editing within the "tree" input?
Better late than never! I finally checked in this patch, with some modifications. I did include the text change you made, to "Calculate coordinates using address", since it makes a lot more sense in the context of "feeds to map". I'm looking forward to announcing this great new feature. And I'm also looking forward to implementing that other, related change we discussed - replacing the "Set marker" button for the raw coordinates field with "checkmark" and "X" buttons that only show up if the user edits that field.
There goes my theory, then! Well, perhaps re-adding #autoedit support for category pages will be enough to get this working, at least via a hack. I'll look into that.
Thu, Jul 27
Wed, Jul 26
This is an interesting issue - there are technical, UI/UX and data design concerns here.
Jul 21 2017
The "tree" input type is probably better suited for that kind of thing. Do you know about "tree"? And if so, do you still think autocompletion is preferable?
Jul 12 2017
What does that mean? You have some custom wikitext that displays the magnifying glass character and puts a link around it?
Jul 9 2017
The good news: everything works well now!
Jul 7 2017
Alright, I think you're right about the magnifying glass.
Jul 6 2017
This looks great! I have one question, about something I didn't notice before: why did you switch the address-lookup and coordinate-entry inputs?
You may be right about this. Having a "filter" image would be misleading in its own way, since it's not the current set of results that would get filtered on.
Great! The code looks good now.
Jul 5 2017
Okay, great! I think the use of the string 'all' is kind of a hack - it would probably be better to have a different $displayParams key - but that's a minor point.
Hi - to be clear, all the form stuff is part of the Page Forms extension, not Semantic MediaWiki. (I guess you knew that, since you assigned it to the right place.
Jul 3 2017
Sorry I never responded to this!
Jul 2 2017
Jun 30 2017
Jun 29 2017
Jun 28 2017
Okay, I set up this code on my wiki. The new feature looks good! There are some coding choices I disagree with (I don't think the image needs to be a global variable - it can be hardcoded), but those are pretty minor. Overall, this seems like a good feature.
Jun 23 2017
Jun 22 2017
Jun 20 2017
That line of the code is:
Jun 19 2017
As a thought experiment, imagane a contributor who is very misogynist but also very respectful of social contracts. This person uses gerrit.wikimedia.org to host their code but runs their own issue tracker. Female dveelopers get mocked and insulted when they file bugs, but their code submissions are treated politely because the gerrit ToU demands that. It seems ridiculous to me to suggest that the Wikimedia technical community should accept such a situation and not do anything against it, on the grounds that only part of the development happens outside our technical spaces.
Jun 16 2017
@Brilligtove - unfortunately, no; but you can make it easier for your users by turning that input into a "combobox" instead of a dropdown, so that they can start typing the value that they want to choose.
Jun 15 2017
Yes, now I get it. And adding that module for "datatables" makes sense - and for any other format that might need it.
Jun 14 2017
Sorry for the delay. Yes, you may be right about all the UI stuff - it would probably help to see it in action.
@Jonathan3 - sorry for the delay. This is fantastic! I haven't tried it out, but this looks like an extremely clean solution, and will provide a very helpful feature. I just have a few small comments:
Jun 13 2017
Oh, I didn't realize that @Isarra also made essentially the same point that I did.
@Nuria - I believe that's incorrect; the code of conduct defines Wikimedia technical spaces as "physical spaces, such as Wikimedia technical events and Wikimedia technical presentations in other events, and virtual spaces (MediaWiki.org, wikitech.wikimedia.org, Phabricator, Gerrit, technical mailing lists, technical IRC channels, and Etherpad)."
I'm not sure I should wade into this controversy, but here goes...
Jun 12 2017
I'm changing this to "Invalid", since the "menuselect" input type no longer really exists.
I assume these have been resolved... anyone should feel free to re-open if not.
Jun 9 2017
Okay, I get it. It does seem that a PHP-based solution (don't show "Enter address here" in the first place) would be much better than a JS-based solution (show "Enter address here", then hide it).
Oh, very interesting. I agree that it would be great to have some sort of functionality like this. A few thoughts:
You could definitely do it via a hook and separate code... it wouldn't be that helpful for other users, but if you need something right away, that could be the way to go. It probably makes the most sense for you to just add in the hook yourself in to your version of the Cargo code. Though if/when you do that, let me know what the line (i.e., the new Hooks::run() call) is that you added to the Cargo code - I'm always happy to add more hooks in to my code.
Great! I think this patch is getting closer to what we need.
Jun 7 2017
Jun 5 2017
Jun 1 2017
Okay, this is merged in! And Approved Revs now requires MediaWiki 1.22. I made some minor changes to the formatting, comments, and some variable names, and fixed some message names in the qqq file; and the new file is now in the main directory, not in an /api directory. Other than that, the code is the same. Please let me know if there are any issues with this.
It's great that you're going to look into automatically detecting map feeding!
It would also be possible to customise layout (e.g. table), or do several queries, or do a compound query (e.g. for different coloured markers on a map), or just add customised text.
May 31 2017
Okay, that's interesting. It seems to me that the only really customizable thing is which extra fields to display, though. You wrote this:
May 30 2017
This is interesting. Do you have a specific use case where this would be useful? If so, could you describe it?
May 26 2017
Oh, okay. "REL_1.21" just means MediaWiki version 1.21 ("REL" stands for "release"). I'm fine with dropping support for MW 1.21 - it came out four years ago (almost to the day), which is quite a long time ago, and it's not a long-term support version.
@Reasno - I guess you're storing property information via templates? Anyway, bad news about this project - it's not happening this summer. The student we had chosen to do it got poached by another organization (I didn't know they could do that - it's due to new rules that were implemented this summer), so we were left without a student. Hopefully this feature will still get implemented, though, via another GSoC or some other way.
Sorry, I totally forgot about this. What's the current status of this patch - is it ready for merging? Are there still some unaddressed issues?