Wikivoyage:Roadmap/Form-based editing of listings

Older discussion

Moved some no longer relevant early discussion just to make this page easier to follow WtTech:Form-based_editing_of_listings/Archive

Round Four

I just put up a new version on review. I also had to update the software to 1.11 to make it work, so if there's anything weird about it, let me know.

Notes

I added the alt and directions fields.
I hid the extra fields people didn't like. If the consensus is that these aren't necessary I'll remove them from the tag model entirely on the next release.
There is now an Add Listing tag on the appropriate sections. This adds the listing to the top of the section (if you want it someplace else you'll need to edit the page to move it)
I looked at historical pages and getting that working sanely is going to be too hard. As a result I've removed all of the listing edit links from historical pages. Note that section editing is disabled in the core mediawiki application for much the same reason.

(WT-shared) KevinSours 12:46, 4 December 2007 (EST)

Is there an option to show the hidden fields? In any rate, I've never used them, so I don't know whether such an option would be important. Also, why was it necessary to also disable section editing for historical pages? Those questions aside, the editor itself looks great.

There is nothing stopping a user from editing the tag markup directly. Anything we do with the editor needs to be done with that in mind. We also intend to put some of the less important fields in a secondary panel. As noted above, though, having an "extra" field that doesn't display with the main field at all times is just asking for trouble. (WT-shared) KevinSours 12:52, 6 December 2007 (EST)

More importantly, though, we try to keep listings in alphabetical order by section (often subsections of "see," "do," "eat," etc.), but the "add listing" option automatically drops new listings at the top of the top-level sections. Would it be possible to

a). automatically add an "add listing" tag for all subsections of the sections that use listings, and

I really, really wanted to do this. But the section handling in media wiki makes it difficult. In particular, there is no straightforward way of determining parent/child relationships between sections (or even an efficient way to get all of the sections in the document). Its also important to keep the adding of these links fast, because its a cost we pay on every page generation, even if the user has no intention of editing. (WT-shared) KevinSours 12:41, 6 December 2007 (EST)

b). auto-sort all listings alphabetically within their individual sections by the name tags?

I'll look into this, but its probably going to be difficult. Dealing with free form text is hard because there is lots of potential for users to do weird things and screw you up. Doing the replacement on the html side is going to be even less fun. (WT-shared) KevinSours 12:41, 6 December 2007 (EST)

Otherwise, cleaning up newly added listings by hand will be a major time-waster. --(WT-shared) Peter 22:31, 4 December 2007 (EST)

Getting better and better, but still not quite there.

The fields remain incomprehensible to the non-expert. They should use descriptive titles ("Opening hours", "Alternative name", "Website"), not tags ("hours", "alt", "url"), and there should be context help with longer explanations -- mouseovers? help icons?

This is still on the radar.

Fields for "phone", "url", "directions" and "hours" are all too small. Bumping eg. hours and price to the next line would help.

I can extend those fields. (WT-shared) KevinSours 12:41, 6 December 2007 (EST)

Regarding the New Listing button, at the very least new listings should be added to the end of each section, not the top.

I should be able to manage (WT-shared) KevinSours 12:41, 6 December 2007 (EST)

I don't think historical editing is an issue, as people shouldn't be (and aren't) working on old versions anyway. (WT-shared) Jpatokal 23:21, 4 December 2007 (EST)

Just a note to let you know that this is still very much on our radar at Internet Brands. As you all know, we've been busy working on site performance. Thanks for your patience.(WT-shared) JuCo 13:49, 5 March 2008 (EST)

Round Five

This feature is now up! The tech team has worked to listen to your suggestions and recommendations, but some issues have not been resolved (placement of the "add listing" tag on sections). This is still a challenge that we're wrangling with. Looking forward to your feedback! (WT-shared) JuCo 21:06, 17 April 2008 (EDT)

Yay! Please do fix WtTech:Wizard creating first listing breaks section header ASAP.

Should be fixed now (WT-shared) KevinSours 14:28, 21 April 2008 (EDT)

But is this up only on the English version? I'm not seeing it on eg. fi. In case you do enable it elsewhere, please skip Japanese and Chinese (ja, zh) for the moment, because English-style listings don't work in either language. (WT-shared) Jpatokal 23:22, 17 April 2008 (EDT)

It is... but there are some things that Mediawiki didn't make easy on this one, so there is a lot of string matching and other sorts of dodgy manipulations going on on the backend that could make it not show up on the different language versions. I've added logic to allow me to turn off the editor portion for language versions where it is causing problems, but I'd rather not invoke that until we see signs of actual problems. (WT-shared) KevinSours 14:28, 21 April 2008 (EDT)

Hooray! This is superfantasmagorically awesome... Evan, thanks for a brilliant idea, and IB thanks for helping it on it's last steps to fruition – (WT-shared) cacahuate ^talk 00:54, 20 April 2008 (EDT)

Only thing that is a slight drawback is not being able to leave a custom edit summary describing what you're doing, but the default "editing listing xxxx" is good enough for now... would it be crazy difficult to incorporate a customizable one? – (WT-shared) cacahuate ^talk 02:16, 20 April 2008 (EDT)

I actually kind of like that default edit summary—most of our contributors don't leave edit summaries, so it's an improvement in that regard. And more experienced editors can always just edit the tags directly through the section, and leave their edit summaries that way. --(WT-shared) Peter ^Talk 18:50, 20 April 2008 (EDT)

Can we remove the "[add listing]" links from all region, country, continent, and continental section pages (which should all be identifiable by the {{regionguide}}, {{countryguide}}, {{continentguide}}, and {{continentalsectionguide}} tags). As a general rule, we don't want to encourage contributors to add listings to these articles. --(WT-shared) Peter ^Talk 18:50, 20 April 2008 (EDT)

What I would find useful is some sort of command like {{nosleep}} (I have no idea what the syntax should be), etc. that we could put in the {{regionguide}}s and so on. That way, we could put the tag on huge cities, for example, and we could fix this for other guides ({{stateguide}}) without having to petition IB. (WT-shared) Jonboy 12:09, 21 April 2008 (EDT)

I haven't looked into this in any depth, but I'm worried that it will prove difficult. We're literally adding the "add listing" links while the parse cycle is happening so its likely that the logic is triggering before the kinds of tags you are taking about get rendered. When I get a chance I'll try to look into it and see what can be done. (WT-shared) KevinSours 19:05, 22 August 2008 (EDT)

Russian version

Another fundamental issue, one of the biggest potential benefits of the form-based listings editor is that it potentially allows the different language versions to take advantage of the listings tags. But that, of course, hinges upon the editor display being localized for each version. I've created a quick list of the term translations needed for the Russian version (WT-shared) here. Abbreviated translations (in case the translation is too long) appear in parentheses following the actual translation.

And a bug: the "Listing has been changed by somebody else. Please reload the page and reedit. [dismiss]" error message occurs pretty much whenever you do anything to any listing (e.g., clicking the edit button on the listing editor & then cancelling). Reloading does not solve this problem—the only way to get to edit another listing using the form-based editor is to purge the page cache manually, and then reload the page. This does not occur on the English version, only on the Russian. --(WT-shared) Peter ^Talk 18:11, 21 April 2008 (EDT)

Can you give me an example of a page on the Russian site that has a listing? I'm having trouble navigating the site. 207.212.173.2 19:37, 25 April 2008 (EDT)

Sure, the Rome page is pretty much all "listingified." --(WT-shared) Peter ^Talk 20:07, 25 April 2008 (EDT)

Okay, here we go with the dreaded "unable to reproduce". I was able to click edit and cancel on a listing with no problem. I also managed to edit and save (without making changes I'm way out of my depth on the Russian version). Can you point to a specific listing where you are having this problem? Ideally, you could set up a sandbox page that exhibits the problem that I can totally destroy without bothering anybody? (WT-shared) KevinSours 14:38, 21 August 2008 (EDT)

Sadly, this problem is not tied to any particular instance—I now get it often on :en as well, albeit no longer every time I work on a listing on :ru. It seems to happen at random, but I'm guessing it has to do with an outdated cache of the page (since purging the page cache does fix it). It makes the editor pretty useless when this happens, since you might as well just edit the code directly, rather than jump through the several purge cache hoops. --(WT-shared) Peter ^Talk 16:37, 21 August 2008 (EDT)

And how is a progress about localization a editing form? Piter gave User:(WT-shared) Peterfitzgerald/Listings editor translations as early as april (see above)... -- (WT-shared) Sergey kudryavtsev 02:18, 22 August 2008 (EDT)

I just put a new version on review that has basic localization. If you edit the system messages (I don't know who has access rights to the system messages on review) you can change the labels of the attributes on the popup form. Most of the error messages are already translatable. I'm still figuring out how to handle the tag name and attributes in the wiki text itself. The problem is not so much translating them (which has been more or less done for a while) but the fact that if the values change it will break existing tags. I need to alter the code to accept both the current default english values and the localized versions. Note that while we should be able to translate these, this is something we need to get right the first time because changing them is going to be a lot of work after the fact (since all of the existing tags using a particular value will need to be updated).

Strings

listing-{tagname}-tag = wikitext tag name
listing-{tagname}-taglabel = display label (should match section header text *exactly*)
listing-{attrname}-attr = wikitext attribute name
listing-{attrname}-attrlabel = display names for listing form (these are the one you can currently play with)
listing-{some name} = Various messages for the listing system, mostly error messages. Should be editable presently.

(WT-shared) KevinSours 19:05, 22 August 2008 (EDT)

I think it's fair to consider the list of translations I provided definitive (since Sergey proofed them). The only thing that should hold them up is if they are too long to display properly (let me know if that's the case). I don't believe that any non-IB/non-Evan&Maj folks have sysop status on review, and therefore won't be able to edit system messages there. --(WT-shared) Peter ^Talk 19:40, 22 August 2008 (EDT)

Actually we're all admins there too – (WT-shared) cacahuate ^talk 00:42, 23 August 2008 (EDT)

I was register my self at Wikitravel Preview a few minutes ago and put together a listing related Mediawiki items on my personal page. But i cannot edit Mediawiki items, since i am not admin on Preview. Piter, please translate Mediawiki items. -- (WT-shared) Sergey kudryavtsev 05:55, 23 August 2008 (EDT)

I strongly advise against putting things of importance on review. Its really a sandbox for testing new features. I may want or need to refresh the database at some point with a recent copy from :en and there is no good way to preserve (or even know to preserve) specific articles when that happens. (WT-shared) KevinSours 11:00, 25 August 2008 (EDT)

I'm a little confused—do you still want me to translate the mediawiki files on review? --(WT-shared) Peter ^Talk 22:22, 25 August 2008 (EDT)

That's probably because I'm being confusing. I put the new features out so that you can play with them a little as admins (I was hoping the admins elsewhere had admin privs on review -- I'm still not 100% sure if that's the case). Filling in some system messages to test the new functionality is useful so we can fix any major problems before I push it live (note that only the attribute labels and general messages are likely to work properly at this point). Going through a formal "offline" translation exercise on review is probably overkill. At some point such an exercise may be useful, but the results should be captured somewhere a little more permanent (Sergey's document looks nice, but I worry that its going to get inadvertently overwritten at some point). I'm still working on some thing regarding the localization and I'll do some of my own hammering on it when its done. Sorry for the confusion. 69.229.11.253 22:42, 25 August 2008 (EDT)

OK, I tried translating a couple terms there, and that worked well except for the fact that the font being used displays some Russian characters poorly. "Ы" appears like "Ь I", which clearly looks wrong. We usually use en:Template:Lang for problems like this, but that does not work in a mediawiki file. And I'm not sure which font is default here for Russian (which looks great in-article), but that is probably what we should aim to use on the listings editor? --(WT-shared) Peter ^Talk 01:26, 26 August 2008 (EDT)

Unindenting because this is getting ridiculous :). Looks like its an artifact of bolding the font -- at a guess the bold font lacks the combined character (the spacing is also more obvious at the smaller point sizes). I removed the style (didn't make enough of a difference to my eye to matter) and it appears to be better. BTW, while you can't apply the template to the language translations you can add html (which I fixed the form render for the listing to work with). The template just does something like <span lang='ru'>some russian text</span>. Though in this case it didn't help. (WT-shared) KevinSours 15:57, 26 August 2008 (EDT)

I used a font tag to switch to Arial (Verdana look ghastly in Cyrillic), but now the edit tags aren't working. When I click on the San Diego's "Harbor Seals" edit button, it simply moves the page to "San_Diego#Harbor_seals," rather than opening the listings editor. --(WT-shared) Peter ^Talk 19:29, 26

Yeah I noticed that. In order to get these translations in the javascript I have to dump a bunch of strings out as JS literals. My code couldn't deal with the newline you put in the new text... I fixed it.

BTW: are there any language specific style includes. I didn't see anything like that from the backend, but if that exists it would be a better place to do some of this stuff.(WT-shared) KevinSours 19:59, 26 August 2008 (EDT)

Looks good now. Re: "language specific style includes," I don't know, and am not familiar with the term ;) --(WT-shared) Peter ^Talk 11:45, 27 August 2008 (EDT)

css stylesheets. You mentioned the font used on the Russian version, but I'm not seeing any mechanism that would make it different from any other version (and I didn't see were we set the font differently on the listing form, but I may have missed something there). If there is a way to set version specific css already in the system, we can use that to tweak the listing form for specific versions without having to put markup in the mediawiki strings.

Understood, I'm not familiar with css. I switched from verdana, which the form editor uses by default, to times (size=1).

Last hitch: is it possible to localize the "save" and "cancel" buttons at the bottom of the form? Also the "add new listing" text at the top of the form after clicking the "add new listing" button. I think that's all that's left. --(WT-shared) Peter ^Talk 12:55, 27 August 2008 (EDT)

Bugs

I just did a test on the en:Mandarmani page, which sees a lot of spamming... the page is currently protected against anonymous edits, but the listings editor doesn't seem to acknowledge page protection. Can we fix this? The spammers on that particular page have been using the listings editor. I did another test by protecting the page against all but sysops, and that seemed to work... under that level of protection the "edit" buttons don't even appear for sections or for the listings editor... so it's only the protection against anonymous edits that needs fixing – (WT-shared) cacahuate ^talk 17:02, 6 May 2008 (EDT)

Hmmm... update... now the "edit" buttons are gone even now that I've lowered protection back to anon again... I purged the cache somewhere in there, which could be why... maybe I was only able to click an edit button the first time since it was before cache was cleared? – (WT-shared) cacahuate ^talk 17:12, 6 May 2008 (EDT)

WtTech:Listing location and line feeds

New listings are always inserted at the very top of a section. They should be placed at the end instead (or, in an ideal world, alphabetized), so they don't go on top of any introduction text in the section. (WT-shared) Jpatokal 08:18, 20 May 2008 (EDT)

This should be done on review (WT-shared) KevinSours 14:40, 21 August 2008 (EDT)

Agree with this, basically when adding a new listing right now you almost always have to go in and rearrange things manually... that also may be the case if it goes at the bottom, but it's certainly the better of the two. Alphabetically would of course be ideal, and also ideal would be adding the "add listing" button to each of the subsections as well, like budget/mid-range/splurge, so that you can add listings to specific sections – (WT-shared) cacahuate ^talk 13:56, 8 June 2008 (EDT)

At end exactly. But no аutomatic sort of any kind! There are many sort may be used: a impotance, a price, a landmarks along some street etc. Moreover, a images sort most likely should be correspond with a listing item sort. Automatic sort will jam a ton of manual work. -- (WT-shared) Sergey kudryavtsev 09:26, 9 June 2008 (EDT)

I've always ordered them by price. -- (WT-shared) Mark 03:35, 23 August 2008 (EDT)

Round six

~~This is implemented on review. I want to push it live tomorrow if possible, but I wanted to give people a chance to poke it first and see if there are any further problems that need fixing.~~

This is now live. Let me know if anything turns up.

Improvements this round

Fixed a number of reported bugs
Implemented partial localization
New items are added at the bottom of the main section text instead of right under the header.

Localization

The localization strings for the listing extention are Strings

listing-{tagname}-tag = wikitext tag name
listing-{tagname}-taglabel = display label (should match section header text *exactly*)
listing-{attrname}-attr = wikitext attribute name
listing-{attrname}-attrlabel = display names for listing form (these are the one you can currently play with)
listing-{some name} = Various messages for the listing system, mostly error messages. Should be editable presently.

Localization is not fully implemented and changing either listing-{tagname}-tag or listing-{attrname}-attr (which correspond to the values in the tag text in the wiki document itself) will cause existing tags to break and will likely cause problems with the form base editor. The listing-{tagname}-taglabel and listing-{attrname}-attrlabel and the misc messages should now work properly and should affect the display in the editor form itself. The tag labels should match the section headers used in the documents *exactly* as the "add listing" links won't show if they don't. (WT-shared) KevinSours 20:54, 26 August 2008 (EDT)

That is, the only non-localized text will be the tags that only show in the wiki markup (e.g., <sleep></sleep>? If so, that's not a problem at all in my opinion. Just so long as the display in the form-based editor itself can be localized. --(WT-shared) Peter ^Talk 11:49, 27 August 2008 (EDT)

Pretty much, there are probably a couple of messages/string that didn't get localized, but handling the display only stuff is pretty straightforward. Its the stuff (like the tag text) that needs to be machine readable that gets tricky. I'd like to get the tag text done since its supposed to be human readable/editable directly, but its good to know its not critical because I don't think I'm going to be able to get to it this time around 172.16.2.144 12:08, 27 August 2008 (EDT)

Yeah, round 6 is looking pretty great to me--I can't find anything wrong with it. --(WT-shared) Peter ^Talk 12:49, 27 August 2008 (EDT)

I don't know if I specifically mentioned it, but all of the strings on the listing editor form should now be translatable. It should be pretty obvious which ones need to be set, but if not then drop me a line and I'll post some details (WT-shared) KevinSours 12:57, 29 August 2008 (EDT)

Including the "save" and "cancel" buttons? I coulding find MediaWiki messages control that display. --(WT-shared) Peter ^Talk 13:05, 29 August 2008 (EDT)

When did you look? I added a bunch after I finished the main attribute stuff. It wasn't that hard and I wanted to just get it done :) In any case ru:MediaWiki:Listing-save (WT-shared) KevinSours 13:27, 29 August 2008 (EDT)

Отлично! I checked last afternoon, but they are here today. I think we can consider this tech finished until/unless other concerns arise? --(WT-shared) Peter ^Talk 14:12, 29 August 2008 (EDT)

Bugs again

Still to be fully addressed

Space before price display

There should be a space right before the price output. Right now, the listings are causing displays like: "restaurant is good, definitely go here.$5-8." instead of "restaurant is good, definitely go here. $5-8." --(WT-shared) Peter ^Talk 23:50, 31 August 2008 (EDT)

This still hasn't been fixed... can a space be added after the description, or before the price? – (WT-shared) cacahuate ^talk 14:52, 22 September 2008 (EDT)

A space before price is trimmed. A space at end of description is preserved and may be a good workaround for this bug. -- (WT-shared) Sergey kudryavtsev 03:06, 23 September 2008 (EDT)

Should be fixed now (WT-shared) KevinSours 17:12, 23 September 2008 (EDT)

Indeed, thanks Kevin – (WT-shared) cacahuate ^talk 20:53, 23 September 2008 (EDT)

Thanks, this is fixed now. -- (WT-shared) Sergey kudryavtsev 02:10, 24 September 2008 (EDT)