This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Still working on Nanxun. I've added all information about sights and hotels to Wikidata. Is it possible to extend the listing editor features? It should fetch information about address, phone number, email, website from Wikidata as well.
On WV/de the listing template itself takes its information directly from WD. So we give our listings just the Wikidata-ID, not more, no addresses, no phone numbers... . Any plans to improve your listings as well? -- DerFussi17:33, 3 June 2017 (UTC)[reply]
Just a reminder. Are there any plans to improve your listing editor? I maintain all listings on Wikidata (incl. phonen umbers, bilingual addresses ...) Its a lot of work to type it in here as well. Even your copy button doesn't fetch all the necessary information. -- DerFussi11:20, 24 June 2018 (UTC)[reply]
Is it broken for anyone else? Tried using current and beta version. When I’m on the page for Asbury Park, clicking edit under the food section works find however under the drinks section it selects wrong info. What’s wrong? @Ryan: – Craig Davison (talk) 23:15, 17 April 2018 (UTC)[reply]
Actually, seems to have the same problem there. I get "Error: An unknown error has been encountered while attempting to save the listing, please try again: invalidsection" when trying to save. – Craig Davison (talk) 08:28, 18 April 2018 (UTC)[reply]
Does anyone have an idea what went wrong in this edit? I used the listings editor to add some text to the "content" of the listing, but a lot of different parts were affected in the surrounding section that I didn't even touch. Please also look at the resulting page [1]. Xsobev (talk) 09:25, 4 May 2018 (UTC)[reply]
I think the listings editor doesn't handle line breaks. Looks like in the edit you linked, there was an addition of two paragraph tags without their corresponding closing tags. I think I've had to add paragraphs to listings by hand before. Good luck! --ButteBag (talk) 23:10, 6 May 2018 (UTC)[reply]
The listing editor was written to convert newlines to paragraph tags, but in your example the airport was an inline listing, so the listing content should not have contained newlines (and now shouldn't contain paragraph tags). For a non-inline listing, newlines must be converted to paragraph tags for the listing to render properly in the lists used on Wikivoyage - leaving a newline in the listing would close the list and cause the content to appear as paragraphs following the list. See the following example::
listing content with newlines
content following a newlinemore content following a newline
...versus the following, which replaces newlines with paragraph tags:
Thanks for your explanations. So if a section is edited with "edit source", then a regular line break (by hitting enter) in the "content" field of the listings template will cause problems both with rendering and with the listings editor later on. Only that in the linked edit the rendering problems were not visible, because the listing was not part of an itemized list. So the only way to manually (with "edit source") add a correct line break in the "content" field of a listing template is to use "<p>" (or "<br>"?) instead. Is that correct? If using the listings editor and adding a regular line break (by hitting enter) in the "content" field, then the listings editor will automatically turn that into "<p>" when saving, and turn "<p>" into regular line breaks when showing the content. Is that also correct? So there seems to be a case, which isn't handled correctly: if the listings editor encounters regular line breaks that are already in the wiki source text. It should just convert them to "<p>" when saving, but somehow that doesn't happen.
I now also saw another use of the p-tag, which also seems to cause problems when using the listings editor: the first listing for Rome/Vatican#St._Peter's_Basilica. It replaces the "<p>", but not the (incorrect?) "</p>". Also the first "<p>" seems to cause two regular line breaks in the listings editor. Xsobev (talk) 08:49, 8 May 2018 (UTC)[reply]
I tried to "fix" the line breaks in the airport listing in Edinburgh#Get in by replacing them with "<p>", but the preview shows the same display errors (all following line breaks in the section are screwed up) as they can be seen here. Xsobev (talk) 08:09, 11 May 2018 (UTC)[reply]
I've been making some changes to the ListingEditor gadget in my userspace. I'm looking for feedback. If anyone is interested in testing the changes with me, you can disable your listing editor gadget and copy my common.js and common.css to switch over. Any feedback on the alterations to the appearance of the editor, including changes to the text, and on bugs/glitches would be appreciated.
Even if not testing, I'm looking for some other feedback, so please read on if you use the listing editor.
I've copied over the preview functionality from the German version, which is very useful. I've also added the automatic updating/addition of IATA codes for airports, and trimming of a trailing period in the price box (as you sometimes see new users writing, resulting in a double period). The significant-ish thing I've written in are lock checkboxes to prevent certain fields from updating from Wikidata, specifically the URL, coordinates, and image.
I've added tooltip text to warn users against using it if the Wikidata information is inaccurate, as a way to avoid fixing the information there, and instead suggesting some "acceptable" use cases. The ones I thought of are listed below:
Lock URL: Use this only if Wikidata links to a non-English website, and we have the English version set.
Lock coords: Use this only in case of the wrong coordinates being selected. For example, if the listing is for a river, and the Wikidata coordinates show the mouth of the river, while we want a point on the river.
Lock image: Use this only if we have a better image that we cannot put on Commons
Lock image: or if we have a subjectively better photo set here, and we have been prevented from changing the one in Wikidata to match
Lock image: or if we do not want an image here at all.
Can anyone think of any other use cases to write into the tooltip? Maybe some of these should be fixed on Wikidata's end? Alternately, should I remove the tooltip completely, and assume all editors know the appropriate times not to update from Wikidata?
Should I add lock checkboxes for any other fields? I couldn't think of any use cases for the others. Alternately, are the checkboxes useless and should I remove them completely? I ask this question also of the other changes, and of this endeavor as a whole.
Finally, one question for the community: would we consider switching to the RFC3966 standard for phone numbers? It is very similar to what we use now; the only difference is the addition of a dash after the country code and the area code equivalent. Doing so would allow use to use Wikidata phone and fax numbers. Example here
Sounds good, but I suppose usability folks would be afraid the interface could feel too complex with the lock boxes. One could have a box to activate them, with them otherwise greyed, I do not know whether that helps or makes it worse.
There are a few more reasons to lock our versions, mostly pertaining to our wanting visitor information while Wikidata may have general information. This concerns images as well as URLs. I think the tooltips are a good tool to standardise use. I think only the editors who spend time at the pub automatically get to know our reasoning.
Our current phone number standard is counter-intuitive for me and probably many others, but it tells what part of the number can be used when dialling locally (traditional phones do not allow dialling the +xx... global number). The RFC3966 standard does not provide an obvious way to do that ("." characters are allowed, should those be used? probably there is some other common use for them).
You might be able to get around that complexity by not using checkboxes, and instead offering "get all from Wikidata" (what we have now) followed by a little "Advanced" button, which gives you a new form with all the checkboxes.
On the phone numbers, I've long wondered why we use different formats for regular and toll-free phone numbers. I'd support making them match any sensible system. WhatamIdoing (talk) 15:44, 2 October 2018 (UTC)[reply]
The checkboxes are hopefully unobtrusive. They have no text next to them, just a lock icon. I would post a screenshot if I knew how. The "advanced" button is an option, though. Greying out, I'm not sure about, for a couple of reasons, one of them technical. However, in the meantime, I think I'll at least modify it to only show the checkboxes if there is a Wikidata ID set, much like the update link itself. That should simplify things at least for users adding new listings. ARR8 (talk) 16:14, 2 October 2018 (UTC)[reply]
One alternative to the checkboxes would be to import the Wikidata only into fields which are currently blank. If the local and Wikidata fields are both populated, but with different info, one line of static text somewhere could be displayed to indicate the mismatch - with the local data left intact unless the user manually removes or replaces it. K7L (talk) 16:38, 2 October 2018 (UTC)[reply]
Support: I think this makes most sense. Just extend the text to "Update empty shared fields...". The added benefit is that users that are not knowledgable/read enough won't overwrite stuff by accident...-- andree.sk(talk) 08:32, 6 October 2018 (UTC)[reply]
I have to admit, I don't really like this option. It seems like it adds a lot of time-consuming copy-pasting if the editor actually does want to overwrite the values, which I find myself doing more often than not. Still, it's possible, though a little challenging to figure out a good place to put the static text in a way that makes the intent obvious and still looks okay. ARR8 (talk) 18:56, 2 October 2018 (UTC)[reply]
It wouldn't involve "a lot of time-consuming copy-pasting if the editor actually does want to overwrite the values"; all they'd have to do is blank the existing field and click "import from Wikidata". K7L (talk) 17:52, 3 October 2018 (UTC)[reply]
You're right, I don't know why I didn't think of that. It's still not my favorite option, but I won't dismiss it out of hand; if there's a consensus that this is the direction we want to take the listing editor (and that we want to change it at all...), I'll do my best to implement that.
I've just changed it to show a tooltip and the preview. I doubt anyone's seen the screenshot yet, but I don't want to change things without notice. ARR8 (talk) 01:54, 5 October 2018 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Another update to the ListingEditor. Added a button to get the Wikidata ID from an entered Wikipedia article. I find that the Wikipedia autocomplete is much more intuitive than the Wikidata autocomplete. The button is just the letters "WP" next to the Wikidata box. Any thoughts are welcome.
I feel like I should mention that if anyone has any feature requests for tweaks to the editor, I would appreciate hearing them. I will obviously ask in the near future for this to be moved out of my userspace, once no one has any more input or objections. It would be nice if this update could address others' gripes with the editor, not just mine.
By the way, still no consensus on what to do with the checkboxes, or importing phone numbers from Wikidata. I'm leaving both as-is for now. If we don't reach a consensus, I'd like to revisit this in the future, perhaps after rolling out the uncontroversial changes (preview, etc.). Thanks to everyone who did respond so far. ARR8 (talk) 00:30, 7 October 2018 (UTC)[reply]
If making changes to the listing editor, can a mobile number field be added? There was a discussion ages ago which I thought came to the conclusion it wasca good idea but ascwith many things, somebody with knowledge, etc. needs to to make those changes. But I have no idea about finding those discussions PsamatheM (talk) 18:59, 20 October 2018 (UTC)[reply]
Sorry, that's not related to the listing editor. That's the template itself, {{listing}}. So while I could add a field, it wouldn't actually put the number anywhere on the page without matching template changes. ARR8 (talk) 19:58, 20 October 2018 (UTC)[reply]
Isn't it nowadays possible to have several comma separated numbers in the phone field, with comments in parenthesis: "phone=+358 9 123-456 (office), +358 40-123-456 (mobile)"? --LPfi (talk) 16:19, 21 October 2018 (UTC)[reply]
And the result is working phone number links (i.e. the template handles them), and the ErrorHighlighter does not warn about them. --LPfi (talk) 12:13, 22 October 2018 (UTC)[reply]
New changes
Hi all. I'll keep this short; following the last discussion, I have made some changes to the listing editor. There is a changelog, but of note is a new bidirectional Wikidata Sync window to complement the "update values" function; screenshot attached. This allows comparison of local and remote values and selecting the better of the two. The lock checkboxes are gone in favor of this. Being able to compare the values was suggested by User:K7L and supported by User:Andree.sk.
It also has links to quickly compare coordinates on a map. This should help address common grievances about editors overwriting good coordinates with worse ones (ping User:Ceever).
Unless anyone opposes, I'd like this to be linked to the Listing Editor Beta gadget, which currently is exactly the same as the regular listing editor. Only an admin can do this. I think this can be done now, as that gadget is explicitly said to be a testing feature.
Any feedback on anything is very welcome. Having tried the editor is not necessary to leave feedback. If requested, I can upload more screenshots. Feature requests are also welcome. If you're reading this, please comment.
I'll add some more notes here. Since I think the length of the last post was a reason it did not generate much discussion, I'll say it's unnecessary to read further.
I'll use this space to also ping User:LPfi and User:WhatamIdoing, who also participated in the earlier discussion, which I greatly appreciated.
Some questions I'd like some consensus on at some point, to drive the discussion:
1) The editor now has two modes for coordinate sync available in the settings. The first copies the coordinates from Wikidata when so requested; the other just removes them and let's them be auto-fetched from the Wikidata ID by the template. This was discussed here, and the community seemed to lean toward the first option, so I have set that for now.
2) the phone number question from the first discussion. Doesn't need to be addressed here; I'll open a discussion at the relevant policy page in the future.
3) Edits are now made on Wikidata. The API allows text to be appended to the edit summary; should we do that? E.g. en.wikivoyage.org Listing Editor.
4) Phrasing of the sync instructions visible in the screenshot.
A note on usability: I've added a few quality-of-life features, like the auto-select link, the clickable column headers, the clear all link, expanding the clickable area on links to the full width, etc. I would like to add as many of these as possible to make working with the editor easy for any given workflow/HID setup.
@Andree.sk: Thanks for the feedback. For point one: Actually, after you press the button, the changes do get uploaded. To Wikidata, that is; the local changes still need the edit summary put in, maybe some more edits, etc., so the listing editor itself also has the Submit button.
For point two, this is something I was thinking about. I did set up a naive auto-select, which can be accessed with the 'Auto' link under the headers. It's more conservative than what you were suggesting, but same idea. I was considering running it automatically when the dialog opened, but I thought that might be confusing for new editors, who might assume having some values pre-selected meant they were already in sync. If I'm being overly cautious, I'll happily set that up.
May I ask: have you tried out the new editor? If so, was the Auto-select not noticeable? Or maybe it was, but the description wasn't very good? Or maybe it's not in a convenient location to use every time? ARR8 (talk) 15:13, 24 November 2018 (UTC)[reply]
Oh, ooooooooh.... Well, I'm inclined to say that I quite like the upload-to-wikidata feature. However seeing that it deletes data from wikidata if one doesn't select anything, that looks quite dangerous (I'd say this operation is needed very sparsely). For sure wikidata may need different image or coordinates than wikivoyage, as we discussed in pub and elsewhere. I think if we want to mainline this, the interface should be made a big clearer to show what's going where, and when. Right off the bat, I'd say some buttons (like "Update wikidata entry", "Choose for the listing", "Cancel") would be better than the current solution ("whatever is selected goes right into wikidata, and will update the listing preview"). -- andree.sk(talk) 14:23, 9 December 2018 (UTC)[reply]
@Andree.sk: I think I see what you're getting at, but I'm not sure. I'll point out, first, that it doesn't delete the data if nothing is selected; if nothing is selected, it skips the field. It deletes from Wikidata if a blank space is selected (so, if we have no value in, say, the URL field, and Wikidata does, an editor can select the Wikivoyage column to delete the URL from Wikidata). If you understood correctly, that's fine, good to have this spelled out on the page in case anyone else has concerns.
Regarding the interface: If I understand correctly, you're proposing to split the "Submit" button up into two buttons? This would make it somewhat clearer what's going on, but I think there's some drawbacks: new editors would be initially confused ("where's the submit button?") and experienced editors would now have three clicks instead of one (Wikidata, Listing, Close). Additionally, people might forget to do one of those functions.
My intention was that the function would be clear from the word "Sync." The link to open it says "Sync" on it, the dialog says "Sync" on top - I believed that would imply bidirectional data transfer. If not, then, yes, we should figure out a way to make it clearer. I'm not sure about the buttons with those drawbacks I outlined, and I don't really want to add it to the top because, below, we were talking about shortening it... I could add a tooltip to the submit button outlining what it does, but that would be hidden away unless someone hovers over it. What do you think? ARR8 (talk) 15:36, 9 December 2018 (UTC)[reply]
@ARR8:, yep, you seem to have understood my points. I guess the dialog cannot be simple by design, it tries to work with 2 databases at once... I dare to consider myself a relatively advanced editor, and I was indeed confused, probably mainly by the text 'Update shared fields using values from Wikidata'. Maybe that should already state "Sync listing with wikidata"? I would say vast majority of random visitors don't even know what wikidata is (not to mention what's a "reference"), so I would say it's very much needed to be cautions and prevent destroying wikdiata (or wv for that matter) stuff by good-intentions-but-little-knowledge. The WD stuff is quite exposed, and likely quite poorly patrolled, so...
Regarding the tooltips, that likely really wouldn't help. But I think even though there's a 'push' against making the table bigger, we should really head for a clean (=obvious) UI, than nice UI. Of course, it doesn't make sense to have every functionality inside, but we should probably pick the group of people who this thing is really most useful for, and design it for them. At some point, advanced editors will just create the listings by hand - and the very beginners won't bother with WD anyway...
I can try to come up with some mockup of the layout, if you think it still makes sense. But don't mind me too much. I am usually too lazy to bother with this stuff anyway, and just add WD to the listing (because that implies fetching WD coords+image into the markers anyway). Of course, if the UI is good, it may change :-) -- andree.sk(talk) 20:30, 9 December 2018 (UTC)[reply]
I'll change the link text to "Sync shared fields to/from Wikidata". I thought I already had, but apparently not.
Regarding information loss - the changes are a measure to prevent losing information already in WV. This is something that would happen a lot with the old editor with users (frequently, me) fetching Wikidata values and overwriting information that was already here that may have been better.
Hopefully, these changes also make Wikidata sync more worthwhile for all kinds of editors to use. For newer users, the Wikidata ID can now be imported from the Wikipedia link, so they do not even have to know what Wikidata is. For more advanced users, there is finer control of what data to sync. Therefore, I would definitely be interested to hear what changes you think would make the editor better to use for you and editors like you.
However, I'm really not sure about splitting the "submit" function up. I can't help but think that would make things more confusing both for those looking to simply submit their changes and those looking for a quick workflow when working with listings. I think it would be good to find a solution here, but I don't think that's it. Either way, if you can think of a change that makes the UI easier to use as the expense of "cluttering" or expanding the table, I would definitely be interested in hearing it. Perhaps new additions to the table can be intelligently hidden unless necessary, like the Wikidata information, so I wouldn't worry about clutter. ARR8 (talk) 22:33, 9 December 2018 (UTC)[reply]
Hi ARR8. Thanks very much for your effort. I feel this is a great step forward and also will help cleaning up WD.
As I understand, the GPS coordinates are linked to a map, so I can verify directly which GPS is the best, right? Furthermore, the URLs are links as well? Which would help.
You said that the GPS coordinates are copied from WV to WD if selected, but the reference is not filled, right? Here I would definitely create a generic reference like "imported from Wikimedia project: English Wikipedia" and remove the existing one. Also, maybe a link to the relevant page on WV would help, I guess. But the latter might be overload.
Otherwise, I would shorten the description of the data sync a little. Also, I would definitely put like a big "Choose the correct data - unselect will not change anything" above everything. So that even when people do not bother to read, at least nothing is messed up due to any miscomprehension about the functionality, e.g. do I choose the target or the origin.
@Ceever: Thanks for the feedback and kind words. The GPS coordinates are linked to a map, yes. I have been using this to compare coordinates and have been finding it personally very helpful.
The URLs are not links, but that can be changed. There's pros and cons, but it probably makes more sense to make that change, so I think I'll do that.
The references: This is something I have been thinking about. Currently, I have been adding "Imported from English Wikivoyage" manually. Note that this doesn't apply only to coordinates, but also to any of the fields. My worry with doing it automatically is overwriting a real reference, for information like, say, a URL, because of a trivial change like correcting http:// to https://. So putting the reference in automatically has problems. Even if there were no references already, people who are adding coordinates would ideally put in the source they got their coordinates from, like OpenStreetMaps or Google Maps, which is preferred to simply writing Wikivoyage. My current thought is changing the reference if the only reference is currently "Imported from" another project or empty. How does that sound? Other than these cases, I'm not sure when we can be sure it's safe to change the reference.
You raise a good point about the instructions. I spelled everything out as a form of "fool-proofing" for new editors, but you're right that, in its current form, people may not read it. However, I think telling people to simply choose correct data can be misleading like in cases when both sites have correct data and we don't want them synced, e.g. if we have a travel website URL and WD has an official website URL.
Regarding the reference, isn't it equally or even more fatal to leave what is on WD already? Because that is just wrong then. I guess most people will not really bother about the reference (even though they should), but leaving something like "imported from Russian Wikipedia" is far worse that a generic "imported from English Wikivoyage". And if editors really bother about the reference, they will always head over to WD and adjust the generic term. Sure, a change of http to https might not be necessary the reference change, but nevertheless this change came from WV and not somewhere else. And if WV is the source for WD, that is just the way, like many other information are sourced on other WP sites for WD.
In addition, maybe you could add a link to WD with an emphasis to maintain the reference over there in more detail.
I understand your point about my proposal regarding the short advice. But of course, this is just a proposal, if you got something more appropriate, please go ahead. I was merely pointing out the issue with long descriptions, for which we must find a solution.
Good points. I'll address the easy one first: there is already a link to the WD item, in the title of the dialog window, and already a statement to maintain the references in the instructions. It is already slightly emphasized, but hopefully it'll stand out more once the instructions are shortened.
Anyway, here's my logic regarding references: Wikidata currently has a problem with the vast majority of the references being generic "imported from" some Wikimedia project. Some values have a reference that is an actual "stated in" reference, which points to something outside Wikimedia. I believe the goal for Wikidata is to maximize these.
That being said, I agree with you completely about the problem with "imported from" references being wrong (I said that above, but it maybe wasn't clear) so I've just added functionality to change the reference in case it is only an "imported from." This is somewhat of a compromise between our suggestions: the reference is changed even for minor changes like the https:// example, but it is also not changed if anything more sophisticated than "imported from" is present. Your thoughts?
I've shortened the instructions somewhat, as well.
All of these changes are in my userspace for now. I need an admin to copy them over, but I think I'll make a couple more changes before pinging and annoying admins. However if you (or anyone reading this) would like to test them, feel free to ask an admin to copy these changes over now. ARR8 (talk) 17:08, 1 December 2018 (UTC)[reply]
The new set of changes seems to be done. Fixes a few bugs, incorporates some requested small features, and has some minor cleanup. I'd like them to be copied over to the gadget for wider testing - @WOSlinker: if you're around, could you please do it?
Yes, this is something I just added. This is a longtime to-do for the listing editor, and the old behavior was inconsistent. It had some preset listing types is would treat with the alias, like {{see}}, but others that were arbitrarily called custom types, like {{go}}, which were not supported and would cause problems for users trying to edit them. Rather than keep up the distinction, I've switched it to treat the listing type as any other parameter. I don't think there are any downsides to this change, and I think I read somewhere that the listing aliases were going to be phased out for a while, anyway. Unless you think the old behavior was better? ARR8 (talk) 14:16, 5 December 2018 (UTC)[reply]
I don't see any obvious downsides, though I do think it seems a little weird to have an inconsistent situation where some "see" listings use the "see" alias but others use "listing | type=see". I guess the current situation is already somewhat inconsistent because of "listing | type=go" and similar. I don't have much of an opinion about this, but the behavior surprised me, so I thought I'd bring it up in case others see something that I've missed. —Granger (talk·contribs) 14:29, 5 December 2018 (UTC)[reply]
I see what you mean. Hopefully this problem could work itself out over time. It may also be worth updating the insert buttons over at MediaWiki:Common.js to switch to listing|type, and incorporate the other changes, like no newline after content (for the record, that supposedly makes listings work better with screen-readers). And, if there does turn out to be a material downside, I'd be happy to revert the change.
Thanks for your thoughts. If you think anything else about the changes is unintuitive or worth commenting on, please feel free to also post it here. ARR8 (talk) 14:44, 5 December 2018 (UTC)[reply]
@ARR8: I used the Wikidata sync window when editing Shenzhen today, and overall I thought it was great. There was one problem though: because the sync window was too narrow, it was hard to tell which radio button corresponded to which value (see screenshot). I figured out that I could solve the problem by dragging the bottom right corner to make the sync window wider, but it would be better if the window's default width wasn't so narrow. —Granger (talk·contribs) 03:40, 6 December 2018 (UTC)[reply]
Thanks for testing! This is indeed a problem; the default width, for me, is the same as in my screenshot above. It's supposed to be 85% of the main listing editor window, so it seems we have a bug with the editor in your particular browsing setup. I've tested on Chromium-based and Firefox - may I assume you're using Safari? ARR8 (talk) 05:04, 6 December 2018 (UTC)[reply]
No, actually, I was using Firefox on a Mac. A moment ago I tested it on Chrome on a Windows computer and the width was fine. When I get home I can check what version of Firefox and operating system I was using when I had the problem. —Granger (talk·contribs) 05:54, 6 December 2018 (UTC)[reply]
@Mx. Granger: Aha, I was just in the middle of replying. If it also happens in Firefox, then this might be a problem related to your resolution. Would you happen to know what that is?
I looked through the code and found a bug which might create unexpected behavior on certain resolutions. If yours was one of those, then that might be the the cause and I can get the fix implemented. ARR8 (talk) 14:52, 6 December 2018 (UTC)[reply]
Thanks for the fix! Now the "Wikidata Sync" window is 100% of the width of the "Edit Existing Listing" window. I take it that this is still not the expected behavior, but since it's wide enough to tell which radio buttons go with which values, I'm happy with it. —Granger (talk·contribs) 01:38, 7 December 2018 (UTC)[reply]
Kind of expected now. It's something of a workaround; I can get the sync window to be a fraction of the main window width on all resolutions, but it makes it very difficult to drag around. On large resolutions, it will still take the 85% width. Not that this is something most editors will notice, since I imagine many only edit on one device.
Once again, I greatly appreciate the feedback. Please don't hesitate to let me know if you think of anything that could be improved, or run into any more issues. ARR8 (talk) 04:40, 7 December 2018 (UTC)[reply]
I would like to suggest that the listing created uses the {{see}} , {{eat}} etc options rather than creating listing type=see. We have a large number of check scripts that use the format to report on the status of articles. For example used in the article status statistics in region expeditions like Wikivoyage:England Expedition. A search give false results, showing Haywards Heath as having no See listing at present. I see the comments below, was actually thinking of requesting to make "go" (and maybe also "event") a full class listing type, fixing the inconsistency that way round would be more useful. --Traveler100 (talk) 07:20, 11 December 2018 (UTC)[reply]
@Traveler100: This is a problem. I frequently add listing|type templates when I convert text to listings. I'd like to talk through a couple of proposals.
First, let's say we switch to using the alias templates for every listing. It would then make sense to deprecate the listing|type parameter, since that silently breaks some background scripts. But we can't do that, because, on the backend, this powers the alias templates. Plus, it's not really sustainable; even if we make {{go}} a full alias now, we would still have this problem for any other listing types, since it requires kludgy code in the listing editor. We know this is true because editing {{go}} has never worked with it. But this is a minor point, since adding listing types may be a rare event.
Either way, we need to fix the inconsistency. You say it would be more useful to fix it by making aliases. However, this would leave listing|type as a working method of entry, which we can't fully deprecate. Let's say instead we figure out a way to switch away from the aliases, and only to listing|type (bear with me). That meant we would be able to fully deprecate the aliases in the future, and allow everything and everyone to work with one method of entry. Do I understand things correctly so far?
So, if we can make all the petscans work with listing|type listings, all problems would be solved.
So, here's my proposal, which would take a little bit of work: fix the petscan parameters; allow them to detect listing|type in addition to aliases, with this process:
Edit the listing template, adding a category Category:Has See listing, for listings of the main types (see, do, etc.). This would actually be very simple to add to Module:Map, which gets called for every listing regardless of whether the map is used, and already adds Category:See listing with no coordinates and suchlike.
Edit the petscan parameter scripts to look for this category instead of the alias templates. This would catch both alias listings and template|type listings.
I know this is a departure from the current process, and I don't want to dictate the way we should do things, but I am proposing these changes in good faith and think they would fix some minor problems we have here. Luckily, it's not much work; most of the petscan links are in {{RegionStats}} or {{RegionTasks}}, which is great!
@Traveler100: Great! I've added the category change over at User:ARR8/Module:Map and have tested it with the template sandbox. As far as I can tell, it doesn't create any errors and the categories are added as needed. I'd like this to be implemented before editing those expedition templates, to minimize breakage. As you know, I don't have the permissions to edit Module:Map, so, if the change meets your approval, would you mind copying it over? ARR8 (talk) 23:01, 11 December 2018 (UTC)[reply]
Sure will do. I am travelling at the moment with only occasional internet access so will be a day or two before I can get round to it. But if someone else reading this can do the update please do. --Traveler100 (talk) 04:22, 12 December 2018 (UTC)[reply]
@WOSlinker:. Thanks. If I am reading it correctly though the "do" is missing. @ARR8: do you want to be consider for admin status? If not we can give you edit access to protected templates now without being and administrator. --Traveler100 (talk) 17:14, 12 December 2018 (UTC)[reply]
@WOSlinker: Thanks from me, too. @Traveler100: Thanks for the vote of confidence. Too early for me to consider adminship, I think, but would greatly appreciate template editor status. It would help with this and other changes I have planned. For example, I was asked over at Wikidata to make a tweak to our quickbar module. I wouldn't break functionality without checking with the community first, of course.
"Do" listings were excluded from the other categories (without coordinates) for some reason, but I'll add them in to just these ones. ARR8 (talk) 21:33, 12 December 2018 (UTC)[reply]
@Traveler100: I've now noticed the problem you've noticed, which is that petscan doesn't support "any of" for categories, as it does for templates. I tried a workaround by testing pages that "link to any of" Category:Has see listing || Category:Has do listing, but that returns no results, so we'll, unfortunately, likely have to abandon one. I noticed in your test edit to the sandbox that you replaced (see OR do) with (see). Is that what we should do for all the petscan links? ARR8 (talk) 05:02, 15 December 2018 (UTC)[reply]
That was one of the reasons for the pause in edit. Other was just busy in another domain. I was thinking about creating some parent categories over the existing ones that could somehow simulate or and add lists. Need to think about it a little more. BTW thanks for spotting the problem with the petscan link. I may undo your edits though and add the language parameter globally to the call as is used in a number of other pages too. --Traveler100 (talk) 06:23, 15 December 2018 (UTC)[reply]
@ARR8: I have updated sandbox versions of RegionStats and RegionTasks. Needs to be check to see if I have the logic correct, takes a bit of getting your head around. --Traveler100 (talk) 08:15, 15 December 2018 (UTC)[reply]
Initial checks look good. Main different is now the listings checks also takes in to account markers with relevant types which it did not before. I have also changed the no listing option to be really no listings were as before it ignored drink and buy. --Traveler100 (talk) 14:23, 15 December 2018 (UTC)[reply]
@Traveler100: Looks good to me. A couple nitpicky things I noticed, which I thought I'd bring to your attention:
When filled in, the numbers wouldn't add up, because the green 'check' box looks for see/do, so 'needs only see' and 'needs only do' won't all be accounted for. This is true of the original version of the template, too, though, and could be intentional. Not a major problem, either way.
You changed(?) half of RegionStats to look for article status by Category:Outline cities, and the other half, and RegionTasks, still look for {{outlinecity}}/{{usablecity}}. Either template or category should get the same result here, but, just in case they don't, thought I'd mention it.
Technically, some of the calls, which only look for the region categories, have &comb as a redundant parameter, since there's nothing to combine. I don't think this can adversely affect the calls in any way, though.
Otherwise, seems like we're done. Including markers with the appropriate type would, in retrospect, obviously happen, since we edited the module that controls both, but I hadn't realized. Seems like an unintended beneficial side effect, but we could technically exclude them if needed. ARR8 (talk) 16:04, 15 December 2018 (UTC)[reply]
I just have some assorted comments, mostly visual feedback about the UI.
If it's going to be columnar, it should have better or more obvious labels for the columns. The labels for "Wikidata" and "Wikivoyage" don't really stand out to me, which makes it a bit hard to understand at first glance.
Rather than radio buttons on the far outside, what if they were adjacent to each other on the inside, between the two text columns? You could then add a third radio button in the middle for "no change", and get rid of the "clear" link/button. I think that would be a lot easier to comprehend: each row would look like
<data from Wikidata> ( ) (*) ( ) <data from Wikivoyage>
and you choose the the left radio button to choose WD, the right radio button to choose WV, or the middle one to choose "no action".
While I'm thinking of it, it's unclear which direction the data will go. When you select a radio button, are you choosing to keep that data, or to replace it?
The explanation at the top mentions that sometimes WV intentionally keeps different data than WD. If that's the case, shouldn't we have some way of marking that? Maybe a flag (or better yet a date) in the listing that indicates "someone has already looked at this listing's coords/website/image/whatever [on xxx date] and confirmed that we shouldn't sync it to WD or vice versa", and the editor would no longer ask about it unless the data on one or the other changes.
Wikidata has a field for "directions"? Weird. Seems like a strange thing to put there.
Good idea. I'll look into making a version with the inner radio buttons for comparison, sometime over the next few days. If anyone else is following this thread: would you prefer the current or the suggested layout?
I'm not sure how to make this clearer. It's already written at the top, and I think it's probably more intuitive, to select the data to keep.
That would be a good change, but it would require editing {{listing}} to accept a new field. I'm trying to avoid doing that in this round of changes, but maybe in the future.
It's a very underused field. It's probably only good for keeping that kind of info in sync between WV and various monuments projects, but I've already used it to copy directions from a listing which was (unbeknownst to me) in two destinations. ARR8 (talk) 00:32, 18 December 2018 (UTC)[reply]
@Bigpeteb: It occurs to me that I didn't inform you when I implemented your suggested UI changes a short while ago. Have you seen them, and, if so, do you have any further thoughts or suggestions? They are part of the Listing Editor Beta gadget. I have kept the old UI disabled in the code but I will very likely remove it and keep this one. ARR8 (talk | contribs) 17:00, 27 January 2019 (UTC)[reply]
More proposed changes based on the Hebrew Wikivoyage's Editor
In hewikivoyage, we made several additions to the editor, and I thought you might want to adopt them as well:
Automatic text direction for "name", "alt" and "address" fields (changes from LTR to RTL as the user types). (Example 2 in Red)
ClockPicker for checkin & checkout fields. (Example 4 in Red)
Related color sample for the type fields (based on dewikivoyage version). (Example 1 in Red)
Checkboxs for Additional Features according to the listing type: (Example 3 in Red)
UNESCO World Heritage Sites checkbox for see & do listings.
Kosher, Vegetarian and Halal for eat listings.
Gay Friendly for drink listings.
Campfire for do listings.
Accessibility, WiFi and Tripadvisor's featured for all the types.
@DL3222: Thanks a lot for the suggestions! The checkboxes would require edits to the {{listing}} template, unfortunately, and so couldn't be part of this set of changes. The RTL text conversion is also probably not applicable to en.voy. However, the clockpicker and color preview for type are very interesting for me, and I'll look into those.
I also want to add - I hope you guys over at hevoy will implement the listing editor changes from here, once they go through. Part of the benefit for increased Wikidata sync is that it's a way to share info across all language editions of WV. If you end up having any questions about the changes, please do let me know. ARR8 (talk) 01:35, 20 December 2018 (UTC)[reply]
@DL3222: I've implemented the color sample in my development version here. It gets the color for each type dynamically, by invoking Module:TypeToColor with an AJAX call, rather than having the colors predefined. You may want to take a look at it for your listing editor, if you're interested. Best, ARR8 (talk | contribs) 19:30, 21 December 2018 (UTC)[reply]
@ARR8:Thank for your feedback! We will sure implement the new editor changes once they go through. I think he-voy is the only edition that uses version 2.1 of the editor properly except the en=voy and de-voy. Thanks for implementing the color sample in your development version. However, it seems that it takes about a second for my computer to switch between colors when I'm changing the type of the listing. Is there a possibility to make it work faster?
About the auto-direcion text converting (LTR to RTL), I think it may be useful to en-voy for the alt field. For example, as you can see here, there are a lot of see listings that consist arabic or hebrew alternative name, and it seems a little bit strange and annoying for those who understand the languages when the text is LTR instead of RTL. Best Regards, DL3222 (talk) 21:26, 21 December 2018 (UTC)[reply]
@DL3222: Great! The color lookups are pretty quick for me; it should only take as long as refreshing the preview does. It may technically be possible to cache the results; I'll look into it.
Done. Slightly more complicated than the original version, but has the benefit of dynamically getting colors and should be just as fast. Note to self: all that's left is to look at the clock picker, which will need some cooperation from the interface admins, and, overall, trying out the interface suggestions above and whatever Andree will suggest, and that should be it for implementation. ARR8 (talk | contribs) 07:41, 22 December 2018 (UTC)[reply]
To any admin: I've requested that the changes be linked to the Listing Editor Beta gadget, which is currently useless, prior to discussion, so that others could test the new editor without creating JS files. Hopefully this can be done; since the gadget currently doesn't do anything, I can't think of a reason not to do it. ARR8 (talk) 04:34, 24 November 2018 (UTC)[reply]
You can't put P inside BDI, otherwise you get document structuring issues, and LintErrors, the Listing template cannot cope with multi-line content unless it's been substantially updated since I last used it.
Can someone repair the Listings Editor so it doesn't generate "badly structured" HTML, which the contributor claims is the output from the Listings editor?
ShakespeareFan00 (talk) 09:58, 27 November 2018 (UTC)[reply]
I do not really understand the problem. HTML makes a difference between two levels of elements: you cannot put a <div> in a paragraph, but have to use <span> instead – and you cannot have a paragraph in a paragraph. Our listings are formatted as paragraphs, so it is natural they cannot contain paragraphs. Newlines (<br>) in the "content" are a workaround that works most of the time. Where you really want several paragraphs, our style guide recommends a subsection instead of trying to shoehorn them into a listing. Are there some problems with those solutions? --LPfi (talk) 14:01, 28 November 2018 (UTC)[reply]
I know that, in the edit above the contributor concerned reverted my conversion of P tags to BR claiming that was the "editor default". Perhaps you can convince them just because it's the editor default doesn't make it the correct approach? ShakespeareFan00 (talk) 20:47, 28 November 2018 (UTC)[reply]
So the editor treats a double newline as <P>? That should be fixed, yes. People entering <P> by hand probably understand the issue by your just telling about it (and with the "editor default" changed, there should be no conflict). --LPfi (talk) 11:56, 30 November 2018 (UTC)[reply]
I think it's that they are using the listing editor, which is generating <P> automatically, and not understanding why these where converted to <br /><br />, Perhaps you could explain it to them better than I could? ShakespeareFan00 (talk) 15:06, 30 November 2018 (UTC)[reply]
Unless they take the time to answer (or ask for more information) I suppose it is not worth trying to explain more than what we have written here. --LPfi (talk) 20:02, 30 November 2018 (UTC)[reply]
It's only entries they have which are now holding up mainspace being relatively free from LintErrors.. I am not going to attempt to fix talk pages as I lack the skill to handle that. ShakespeareFan00 (talk) 20:08, 30 November 2018 (UTC)[reply]
in my userspace listing editor, per your request. I'm currently holding a discussion on changes to the listing editor over at Wikivoyage talk:Listing editor, which I mentioned above. This particular change is currently in my userspace, like I said, but it will be part of the ListingEditor Beta gadget, where many other changes already are, pretty soon. After a period of testing, it will hopefully be the new default, along with the rest of the changes made so far.
If you have any other suggestions for or thoughts on the listing editor, please post them there. This applies to everyone reading this. ARR8 (talk) 00:36, 4 December 2018 (UTC)[reply]
It's occurred to me that I haven't actually announced here that the changes to the listing editor can be tested with the Listing Editor2 Beta gadget. So, the listing editor changes can be tested with the Listing Editor2 Beta gadget, in the WV preferences.
Feedback, especially complaints or inconveniences, would be critical now, because, unless anyone complains, in two weeks, I will request it to be set as the new sitewide default. Since I have implemented, in some form, everything that has been suggested to me for the editor, and some things that haven't, and have received no further feedback, that should mean that either the changes are perfect and no one would have any reason to oppose them, or they're not perfect and some people haven't looked at it it.
Since I'm not enough of an egotist to think my work is perfect, I'll put out another call here for people, in addition to the three of you who enabled the gadget, to test the changes and leave some feedback. Even a quick statement of "sure, looks fine" would be helpful for me to get a picture of whether people implicitly support the changes or just don't know about them. Thanks, ARR8 (talk) 21:17, 4 December 2018 (UTC)[reply]
@ARR8: Let me say, if I haven't already, that everything looks fine to me. Since generally it's all fairly similar in design, etc. to the original, with additions but really nothing removed, I would be standing in the way to oppose.
One thing I believe is new is the color that shows next to "type"; there is a minor design issue where if you select "listing", it barely fits into the space given to it. "Sleep" is similar. Otherwise, looks fine. --Comment by Selfie City (talk | contributions) 19:53, 2 February 2019 (UTC)[reply]
Yes, as I said in the pub, I'm fine with the version going live, and this issue is a very minor one. If nothing was changed, it certainly would not be the end of the world. --Comment by Selfie City (talk | contributions) 20:12, 2 February 2019 (UTC)[reply]
I have posted several times about the changes to the listing editor, discussed here and testable through the ListingEditor2 Beta gadget. There are several improvements, which are described at the link. However, the screenshot there is outdated, and I encourage everyone who hasn't seen the last iteration to try the gadget for themselves.
I have made several calls for feedback and have received many helpful comments. Many of the suggestions were implemented, though some are planned for future iterations, and every bug or problem pointed out has been fixed. Due to this, and wide discussion on many aspects of the changes, especially as they apply to other parts of the site, I am concluding that there is a consensus to implement the changes into the default listing editor for all users.
Is anyone opposed? Particularly, there are some new changes that may merit discussion. One change is that images in listings, when they match the image in Wikidata, are, upon sync by a contributor, removed from the source and left to auto-acquire. This is behavior I added relatively recently, due to instances when listing images were nominated for deletion and had to be replaced, while the ones on Wikidata were fine. It may also be of interest to some that I have reinstated the old behavior of putting }} on its own line, due to a discussion above.
Other than that, if nobody has any problems with the new editor, I will remove debug code and request that an interface administrator copy over the changes soon. ARR8 (talk | contribs) 00:26, 28 January 2019 (UTC)[reply]
I really don't yet know how it would look and work. Personally, I'd like to see a one-month trial period so I can see how it is. Probably, that would convince me to support it. --Comment by Selfie City (talk | contributions) 00:52, 28 January 2019 (UTC)[reply]
I have just tried the beta ListingEditor2, and I got a "no data from wikidata" error when I tried it on Corgarff Castle in Ballater, but going back to the old listing editor worked ok.
It did work with another listing but there was a message about the directions differing from Wikidata - as directions are text, and depend on where you are starting from I don't see how they belong in WD - if we are going to have then there must be a link to a help page which defines what WD expect directions to be.
I am not keen on removing the images from listings. Unless there are full explanation popups this is going to confuse occasional users. If we are doing anything with the images, my preference would be for displaying a small thumbnail of the image (75px?). When it goes live we should have a one month trial period, because it will only be clear what the problems are when new users try it, unless a "conference room pilot" can be set up where 20 people are invited off the street to use it. AlasdairW (talk) 15:42, 28 January 2019 (UTC)[reply]
That's no error; it means the data is already up-to-date. I guess I should make the message clearer.
Eh, I don't really see how they belong, either, but that's more a question for the Wikidata community. I've found it useful in some cases already. For most listings, unambiguously located in one location, the usage is pretty clear.
It shouldn't be too confusing; when you sync the image it displays the name of the image in the field.
By the way - no reason to switch back to the old one. The old behavior is still available as "quick fetch," and I won't be removing it, for editors who preferred it. ARR8 (talk | contribs) 17:37, 28 January 2019 (UTC)[reply]
Fine, maybe something like "No update required, listing matches Wikidata"
As they are text, directions will be different in other languages. Also directions often assume a starting point - "10 miles north of the city centre" only makes sense if you know what city the listing is in. I think that in this case the pop-up should suggest that no change is the preferred option if you are unsure.
The "images in listings ...are... removed from the source and left to auto-acquire" suggests that the image is removed from the listing and that the image box in the editor will become empty. Please explain if something different happens.
I changed it after your first message to "No differences found between local and Wikidata values." The change hasn't been pushed to the beta yet, though.
The directions property stores each language individually, so no need to worry there. See this item, which has directions in English, Portuguese, and Esperanto. Regarding instructions, I used to provide considerations for individual fields, but was advised to shorten the text, because people might not read it. I guess not uploading that text for listings accessible from multiple destinations is common sense. If you think it's very important to have instructions per field, I can probably find a way to put it in a tooltip.
They are removed from the wikicode, but the filename stays in the editor, grayed out, until the changes are submitted. Try it yourself: modify the text in the image field for any listing which has a wikidata image and sync the values; you'll see what I mean.
Is it fair to assume that "one-month trial" in these comments means "Let's turn it on now, and in a month (or later), we'll talk about whether we think we should turn it off again"? WhatamIdoing (talk) 18:49, 28 January 2019 (UTC)[reply]
@WOSlinker: Yes, let's! I won't take the debug code out quite yet; if there are any problems, I may ask for console logs. It can be taken out later. Also, please copy over the userspace version; I've changed a minor aspect of the table appearance over there by request. Glad to be wrapping this up (hopefully). ARR8 (talk | contribs) 19:51, 2 February 2019 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘When I look in the "Gadgets" section, though, it still shows up as "Experimental". Does it perhaps take a while to update? --Comment by Selfie City (talk | contributions) 20:13, 2 February 2019 (UTC)[reply]
@SelfieCity: It's been copied in place of the other one, so the experimental and non-experimental versions are currently identical. You can switch to whichever one you want. If there are to be more changes, they would be tested as part of the experimental one first. It's up to every editor whether they'd want to test those changes if and when they come. ARR8 (talk | contribs) 21:08, 2 February 2019 (UTC)[reply]
@Traveler100: This is intentional, and something I just changed. The Wikipedia link is auto-acquired in the listing template, and no longer necessary to specify. When syncing, a message appears saying "wikipedia synchronized." I'll work on making this more apparent; any suggestions? ARR8 (talk | contribs) 14:54, 25 May 2019 (UTC)[reply]
Depends... the feature is still not useful for exported GPX etc., because there the auto-generated stuff isn't "used". -- andree.sk(talk) 05:30, 26 May 2019 (UTC)[reply]
True in the case of coords, but it doesn't seem the Wikipedia field is used in the GPX output either way.
cannot say I like the idea. First on edit of a listing it looks like no data is available people will think need to fill it in again. But I also do not like the idea of the information not being in the source of the article. I think the information should be there as bots checking wiki source will not see that this data is available. Also the case when editing source in basic mode. --Traveler100 (talk) 06:44, 26 May 2019 (UTC)[reply]
We already do this for |image= because of the various upsides. The upside here is that doing this protects us from having an outdated link due to page movies/merges/deletions. I think we should have the same approach; if remotely syncing a field causes problems, we should fix those. I'm working on the first; currently, running a sync will show the remote value of the Wikipedia link on the field. For the second, we could have the listing editor hide the Wikipedia field in source, like we do for the fax field, so people aren't tempted to fill it in. Regarding bots, there is an automated way to see if the Wikipedia link is being remotely fetched: in the page information on the sidebar, it can be seen which Wikidata items are using sitelinks, and this information is available with the API. ARR8 (talk | contribs) 14:21, 26 May 2019 (UTC)[reply]
Listing editor showing currencies instead of content
The relatively new OV-chipkaart article is generating the following message in bold red letters:
The ID "(no element found)" is unknown to the system. Please use a valid entity ID.
Clicking on the message provides the messages "script error" and "No further details are available." The problem occurs for both IE and Chrome browsers. Removing the page banner tag causes the message to disappear. No other page having a banner seems to have this problem. I think this problem arose a few days after adding a banner. Would anyone have a solution? Thanks. TheTrolleyPole (talk) 21:12, 29 October 2019 (UTC)[reply]
@Andyrom75: can you explain what CountryData is intended to do? I think the error is because the code assumes the article has a wikidata record, that is not always the case. (I have now added OV-chipkaart to wikidata, but you can still see the error in newly created articles). I cannot find anywhere explanation of an edit that changes every mainpage article. --Traveler100 (talk) 22:15, 29 October 2019 (UTC)[reply]
@Traveler100: is for a new release of Listing Editor currently in beta version of both en:voy and it:voy. When available, it stores data inside the page that will be used afterwards. I thought to have already manage the case of new page, but I'll check again. --Andyrom75 (talk) 23:21, 29 October 2019 (UTC)[reply]
As said is something that I've already managed in it:voy but I forgot to tell WOSlinker to update this module here as well. Sorry for the inconvenience. --Andyrom75 (talk) 07:07, 30 October 2019 (UTC)[reply]
I've just updated the Listing Editor Beta (that can be found in the Gadgets tab of the personal Preferences) with the latest version of the script that is already available for any user in it:voy.
I've adapted it for en:voy and I've already personally tested the script, but before injecting the code in Listing Editor (the main version not the beta) for any user, I would prefer to have a broader test/feedback.
Since no other issue has been spotted, I've implemented the v2.4 for all users. In this way I'll be available for few more days before leaving, in case of need. --Andyrom75 (talk) 05:19, 28 July 2020 (UTC)[reply]
@Wrh2: highlighted me a Decembre 5th conversation in Wikivoyage talk:Listing editor#New changes between @ARR8: and @Mx. Granger: where they briefly discussed about it. ARR8, unfortunately miss from en:voy since 1 year ago, and since March 2020 from any wiki, so I don't know if he can provide further background information.
From my point of view the only benefit I see is to create potentially an endless series of listings without creating the relevant templates, because type is just a parameter, but since the set of listing is almost constant over the time, I think that this advantage do not compensate this more "verbose title".
Which is the preferred approach that the en:voy would like to follow?
Furthermore another note. I've noticed that the buttons on top of the standard editor pages (e.g. ) generate the following listing code:
I strongly discourage to propose the "wikipedia" parameter because it expose the listing to have an inconsistent link to Wikipedia when the page is move without any redirect in Wikipedia itself. This information should be obtained transparently providing the "wikidata" parameter. That's the way the Listing Editor works during sync phase (i.e. deleting "wikipedia" and "image" information from the listing). Note that when also "wikidata" is present, a category can find and list these errors, but when is missing only a bot can find and list them.
I think I understand your reason for excluding the Wikipedia and Image parameters from the generated template, but does that also result in the corresponding fields vanishing from the listing editor? It's not a huge thing, but it does require an extra step or two of edits if the Wikipedia article is incorrect or the image hosted on Wikidata is not suitable for Wikivoyage, or if there isn't an image hosted on Wikidata at all. There is also the occasion (not that often, but it happens) where there is no Wikidata item, but there is a Wikipedia article.--ThunderingTyphoons! (talk) 12:31, 29 July 2020 (UTC)[reply]
ThunderingTyphoons!, the modification of the template will not affect anything else so all the mechanism will remain unchanged. For example, any editor will be still free to add it manually overriding the value stored in Wikidata (although is possibile, generally is not a good approach, but in few cases it could make sense), and also listing editor will still have the wikipedia field that can be sync with Wikidata or manually customized.
Think about the image parameter; it's not currently present in the generated template but everything works.
Regarding the existence of a Wikipedia page without a Wikidata instance, well, this is an error that should be corrected creating a new Wikidata instance or connecting it to the right existing one. Take a look at this en:voy special page that tracks all the en:voy articles that have the same issue.
Since today is my last day in front of a laptop, I've applied the above two changes but in case the community would decide differently is enough to rollback the followings:
I suppose it is not too uncommon that there is a Wikipedia article that touches the subject while the Wikidata item is more precise but lacks article in English. How should one handle that situation? --LPfi (talk) 14:22, 30 July 2020 (UTC)[reply]
(edit conflict)SelfieCity, as far as I recall, Template:marker has born this way. No "type" means generic listing, while when "type" is present, the nature of the listing is changed accordingly.
Without a "good idea" or a real need I would leave it as it is. Using the same template (e.g. {{marker|type=city| -> {{marker|city|) we would get a neglectable benefit, and changing template or (e.g. {{marker|type=city ->{{city) we would force editor to learn & use a new one.
Maybe (I repeat maybe), if it's easy to recognize if a toponym is a city (or village, town, metropolis, etc.) we could avoid to specify the type parameter at all, but this would require an analysis of Wikidata and to build an easy tool to put anyone in the condition to fix the hopefully few cases where this specification is missing, without relying only on Wikidata expert. --Andyrom75 (talk) 14:32, 30 July 2020 (UTC)[reply]
SelfieCity, sorry, my fault. Are you talking of showing the Wikipedia link when the Wikivoyage article is missing? In the affirmative case I think is a good and useful idea, because readers can find information within "Wiki-world" and editors can find a first source of information to develop a Wikivoyage article. Showing Wikipedia link, is only possible if it's present a Wikidata parameter, that for sure is an optional parameter.
LPfi, as anticipated, if you want to specify a different Wikipedia article you can anytime, nothing from this point of view has changed. Changing the preset template is just a "mental approach", that suggest to provide Wikidata instance instead of Wikipedia article. I don't if I've answered to your doubt. --Andyrom75 (talk) 14:48, 30 July 2020 (UTC)[reply]
Yes, I understand. I suppose we think that those who are able to make a judgement call on using a WP article different from that of the WD item also know how to do it manually. I have no problem with that. --LPfi (talk) 10:29, 31 July 2020 (UTC)[reply]
I prefer the listing|type format as it is easier to fit new types into this as needed and probably it is easier to maintain one template than several... Hobbitschuster (talk) 15:09, 28 August 2020 (UTC)[reply]
Granger, I've just applied the patch. Once the previous cached script will be replaced by the new one (within few minutes I suppose) you can try to update a couple of listings (customized and standard). Please let me know if now everything works or not. Thanks, --Andyrom75 (talk) 17:43, 1 September 2020 (UTC)[reply]
Granger, initially I've updated only the main Listing Editor, now I've aligned also the beta version. Could you confirm me that you are using the main one (see your preferences)? In few minutes also the beta one will behave in the same way, but the main one should already work. In any case, try again :-) --Andyrom75 (talk) 18:57, 1 September 2020 (UTC)[reply]
@Andyrom75: Was this discussed before? Unfortunately, <br/> twice makes the text of the following paragraph look like it does not belong to the listing anymore and nowhere else in the article are gaps generally that large.
Cheers Ceever (talk) 14:06, 13 September 2020 (UTC)[reply]
Ups, sorry, my explanation was more than tight. :-D If you insert a break (by hitting ENTER) in the content field of the listing editor, it actually adds <br/><br/>. This can be seen when going into the Source Editor afterwards. However, this <br/><br/> is breaking structure and readability. Cheers Ceever (talk) 14:35, 13 September 2020 (UTC)[reply]
Ceever, no problem, the important is to understand each other before the end of the discussion :-)
Coming back to the point, I've noticed time ago that in en:voy has been decided to add this rule (new line->BR tag ...one or two I have no idea). This is something not used in it:voy. We use another a different approach (we use ":" before each new line) but since it has other downsides I've never proposed here.
Time by time, I try to find the solution that will reach the following goals:
no lint error generation
use the same wikicode inside listing editor and inside standard editor
no use of HTML
show the content with the correct indentation based on where the listing is used (in a bulleted/numbered list or inline)
Aaahhh, I didn't know there were issues. Otherwise, I can just stick with correcting it manually. But if you come up with something, I am open to hear it. Cheers Ceever (talk) 15:42, 13 September 2020 (UTC)[reply]
FYI 3 years ago I've opened a ticket on Phabricator hoping to solve this issue on server side but I got zero replies.
I've just inserted a new comment hoping that someone would be interested on working on it. If other from en:voy would be interested on adding more comments to this ticket maybe the priority would increase. --Andyrom75 (talk) 15:49, 13 September 2020 (UTC)[reply]
Many thanks. Could it be a temporary fix to fire a replace of <br/><br/> by <br/> after the update by the Listing editor? Cheers Ceever (talk) 17:20, 13 September 2020 (UTC)[reply]
Ceever, just to avoid misunderstanding, I've created two listings with few lines separated by 1 and 2 BR tags. Before apply any change, could you tell me what do you mean exactly with "look like it does not belong to the listing anymore"?
@Andyrom75: I believe they are the same listing, they look the same, and both content fields contain the same text, right? Was this intended. The double breaks just create an amount of space that is larger than anz other space, e.g. between two listings itself or between paragraphs. See gfx: https://pasteboard.co/JrybvnB.jpg Cheers Ceever (talk) 20:52, 17 September 2020 (UTC)[reply]
@Andyrom75: Well, this is actually the point, "the text seems 'outside' the listing" ... when reading the article. This is inconsistent to the rest of the article, meaning in a way it is not adherent to the manual of style. 🤷♂️ Cheers Ceever (talk) 05:33, 19 September 2020 (UTC)[reply]
Bug: Name not fetched from WD label when enwiki is missing
Hi, I suggest we fill the name with the en:label from WD if it is empty. I get an error for e.g. Q96463309 saying "Please enter a name or adress", but the item already has an en:label. I tested adding a name-property but that did not help, so this is a bug IMO. WDYT?--So9q (talk) 17:34, 23 September 2020 (UTC)[reply]
I took a look at he code and it seems we already do use the label somehow, not sure why I get the annoying alertbox then. I'm using the palemoon browser:
<code>
// parse the wikidata display label from the wikidata response
var _wikidataLabel = function(jsonObj, value) {
var entityObj = _wikidataEntity(jsonObj, value);
if (!entityObj || !entityObj.labels || !entityObj.labels.en) {
return null;
}
return entityObj.labels.en.value;
};
</code>
If I understand correctly, you're suggesting that the listing editor should allow users to import the name of the POI from Wikidata when they click the "Sync shared fields to/from Wikidata" link. Is that right? —Granger (talk·contribs) 18:23, 23 September 2020 (UTC)[reply]
I can not edit by Listing Editor. It says, "Error: An unknown error has been encountered while attempting to save the listing, please try again: invalidsection". What should I do? It happened on multiplr pages.-Nizil Shah (talk) 07:01, 10 October 2020 (UTC)[reply]
Nizil Shah, sorry for late answer but you haven't pinged me. See history of that page. I've added a new "test listing" and deleted it. Both action with listing editor without any issue.
If your problem persist, you have to provide me also all the data that you insert in any listing editor field. I need to replicate exactly your action. --Andyrom75 (talk) 09:09, 28 October 2020 (UTC)[reply]
@Andyrom75: It again happened on Junagadh. I clicked [add listing] in Go section. Than added Name=Girnar ropeway; Price=₹700 normal, ₹400 concessional, ₹350 children; Selected Wikipedia=Girnar ropeway, Content=Opened in 2020 to go from Girnar foothill to Ambaji temple above the hill in 8 minutes. Than Submit. The error says: "Error: An unknown error has been encountered while attempting to save the listing, please try again: invalidsection". I don't know what is happening but I am unable to contribute to Wikivoyage for this reason. Please do something about it.-Nizil Shah (talk) 14:21, 28 October 2020 (UTC)[reply]
It also happens when I try to do changes in listing via edit button on the end of each entry. There must be some bug in Listing Editor. It used to work perfectly in past.-Nizil Shah (talk) 14:24, 28 October 2020 (UTC)[reply]
I don't see a "Go" section in Junagadh. I edited a listing in Do with the new listing editor and added the described one in Get around (was that your Go?) with the default one. No problems. –LPfi (talk) 14:45, 28 October 2020 (UTC)[reply]
Nizil Shah, as said by LPfi, there is no "Go" section on Junagadh. Notwithstanding this, I've assumed that you were talking of "Do" section and I've added the new listing as per your description on that section and on its "Religious festivals" subsection, then I've deleted them. All managed correctly through the listing editor (see article history).
Could you check which is the correct section and if there is something missing in what you described? Please let me know also the browser that you are using. FYI I've used Chrome.
Even if I change a typo in See section using listing editor, it shows the same error. "Go" section is not there but same issues happen even if I try to edit anywhere with listing editor. I am using Google Chrome.-Nizil Shah (talk) 04:38, 29 October 2020 (UTC)[reply]
I'm afraid I'm not able to help you because I use the same browser and I did all the changes you mention and I had no problem. I suppose that you may have issue with your browser version, with you computer or with your internet connection (I exclude your account, but to test it you can be anonymous). Try to change one of this item at time in order to find the issue. Good luck! --Andyrom75 (talk) 07:55, 30 October 2020 (UTC)[reply]
I'm trying to convert the sentence I had written previously about the Starved Rock Lodge and Cabins into a listing, but each time I press submit it says "An unknown error has been encountered while attempting to save the listing, please try again: invalidsection" Does anyone else have problems editing? SewChicago (talk) 22:13, 29 May 2021 (UTC)[reply]
You are not the first one having it. The last mention I found is in Wikivoyage talk:Listing editor#Editing by Listing Editor. The error couldn't be reproduced by others, but persisted at least for some time for those affected. It might be something with your setup or connection. If you can make it go away and return with some specific action, somebody might be able to figure out some possible cause. –LPfi (talk) 23:42, 29 May 2021 (UTC)[reply]
I remember a problem, long time ago, with the equivalent of a but not coded that way. That equivalent came from an external text editor and was not visible because you could not see a . Could that be the case? --FredTC (talk) 10:47, 30 May 2021 (UTC)[reply]
Done. Slightly more complicated than the original version, but has the benefit of dynamically getting colors and should be just as fast. Note to self: all that's left is to look at the clock picker, which will need some cooperation from the interface admins, and, overall, trying out the interface suggestions above and whatever Andree will suggest, and that should be it for implementation. ARR8 (talk | contribs) 07:41, 22 December 2018 (UTC)
) generate the following listing code:
