Discussioni utente:Torty3

Benvenuto

Ciao Torty3! Benvenuta/o su Wikivoyage in lingua italiana! Stiamo realizzando un'attendibile guida turistica mondiale libera e aggiornabile. Aiutaci anche tu! Se hai appena conosciuto Wikivoyage e non sai come funziona e in che modo puoi aiutarci, poni le tue domande nella Lounge, il punto d'incontro dei wikiviaggiatori, oppure consulta le nostre pagine di aiuto. Potrai trovare risposte ai tuoi dubbi anche nelle pagine delle domande frequenti e dei consigli per i nuovi arrivati. Ricordati soprattutto che è vietato copiare testi protetti da copyright. Il nostro obiettivo non è proporre contenuti copiati da altri siti, ma scrivere una nuova guida turistica di nostro pugno.

--Andyrom bot (discussioni) 22:51, 28 mar 2013 (CET)

MediaWiki:ListingEditor.js

Hi Torty, I've tried to cusomized for it:voy the script in the subject. It almost works, but there's still something that needs to be fixed. I'm not sure if it's because of my bad customization or because it's faulty since the beginning.

Let me list the first things I've noticed:

1. when I modify an existing listing, in the pop-up windows it's not shown the right type
2. when it saves the changes, it delete the parameter "numero verde". I suppose it's because of the "blank space" between the two words
3. the modification link it's not shown at the end of the listing but near the listing name
4. fax field is not shown in the input mask Fax now is shown but it's misaligned because of the previous long label
5. when I click to add a sleep type it doesn't show check in/out field. The same when I change an existing popup (for example) from see to sleep

PS Please give a general look at the script, just to be sure that everything it's ok or if it needs any patch.

Let me know, --Andyrom75 (discussioni) 23:27, 17 ago 2013 (CEST)

N°3 solved - The issue was on Template:Listing. --Andyrom75 (discussioni) 23:50, 17 ago 2013 (CEST)

Maybe you have already seen it, but just to avoid misunderstanding, the file I'm using for the test is the one stored as MediaWiki:ListingEditor.js.

PS I've saved also MediaWiki:ListingEditor.css, but I'm not sure if it's necessary.... let me know. --Andyrom75 (discussioni) 14:37, 19 ago 2013 (CEST)

I've modified youe common.js to keep the translation of the error message. After that I've copied it into Mediawiki to test it. I'll let you know. --Andyrom75 (discussioni) 15:12, 19 ago 2013 (CEST)

I've updated the #3 with the current behaviour. I've tryed to use this label: "Numeronbsp;verde" but unfortunately it doens't treat it as an escaping sequence and it's shown as it is. Furthermore the width of the window is fixed and the label go below the input element. If the width could be flexible it will allow to have all the labels and input boxes perfectly aligned, and at least this point could be closed. --Andyrom75 (discussioni) 15:41, 19 ago 2013 (CEST)

Some quick words, window width is automatic, it is the label width that is controlled by ListingEditor.css, because the labels are forced to align right. Have to play around with the settings. 1, the type parameter was English version and I've changed it. Do you really want to show fax/checkin/checkout though? They are hidden because the people on en.voy wanted it so. -- Torty3 (discussioni) 14:43, 20 ago 2013 (CEST)

  #listing-editor .input-text label {
    width: 5em;
    float: left;
    text-align: right;
    margin-right: 0.5em;
    margin-top:0.2em;
  }

Ok, working I think? I changed the CSS to Utente:Torty3/common.css as example. -- Torty3 (discussioni) 15:31, 20 ago 2013 (CEST)

I've noticed in Firenze that it saves "| checkin= | checkout= | prezzo=" instead of "| prezzo= | checkin= | checkout=" as per our template. Could you adjust it in order to keep the same order?

Regarding fax, check-in/out, yes they have to be shown (when needed) because we have to allow people to change entirely the listing. --Andyrom75 (discussioni) 15:35, 20 ago 2013 (CEST)

Now, I'm going to install & test it to see how the rest works. --Andyrom75 (discussioni) 15:41, 20 ago 2013 (CEST)

Switch the allFields around. So it will be 'price', 'checkin', 'checkout', instead of 'checkin', 'checkout', 'price'. Thanks for being patient, needed to iron out kinks for languages other than English. -- Torty3 (discussioni) 15:51, 20 ago 2013 (CEST)

Don't worry, and thanks for YOUR patience to support me/us. PS I've few minutes more to test it. By now I've just installed it. --Andyrom75 (discussioni) 15:59, 20 ago 2013 (CEST)

I've updated the bug list above. Regardin the missing one I think the script miss just one onChange event, but it's a minor bug, because it's unusual to change the type of a listing, in fact you can also consider on modification phase to not allow its change. While regarding the tip you gave me about the order I confirm you that it works, but only modifing accordingly the "newline" status of the three cells. Now I'll go to have a look on the other bug listed in en:voy page. --Andyrom75 (discussioni) 16:13, 20 ago 2013 (CEST)

Add Listing

Hi Torty, I need a modification on the code, because in our templates each section ends with a {{-}}, so the new listing shouldn't go always at the very end, but if it's present that "string", the new listing should be inserted just before it. can you patch it? --Andyrom75 (discussioni) 22:09, 26 ago 2013 (CEST)

Edit the function formToText, specifically:

            if ( index > 0 ){
                sectionText = sectionText.substr(0, index) + '* ' + text + '\n' + sectionText.substr(index) + '\n{{-}}';
            }
            else {
                sectionText += '\n'+ '* ' +text + '\n{{-}}';
            }

This should work, but it depends on when you use that template? Is there only one such template in each section? -- Torty3 (discussioni)

Right question. There could be more than one string {{-}}. In the equivalent of the en:voy see section, several users use this string to separate the various images. So the new listing should be add or in the very last line of the section, or in the previous one, if the last line is a {{-}}. Is the above code working this way or it needs to be patched? I'm a little bit in doubt because it seems that you add {{-}} in any case instead of checking it's presence and changing the behaviour accordingly. --Andyrom75 (discussioni) 14:49, 28 ago 2013 (CEST)

I'm still not very sure when exactly you use that template, so yeah the code isn't working the way you want it to. If there is an example page to check? Or you can try and modify the function formToText in some manner. Probably needs another regex or findIndex? -- Torty3 (discussioni) 11:13, 29 ago 2013 (CEST)

Take a look at Stoccolma#Cosa_vedere. --Andyrom75 (discussioni) 14:47, 29 ago 2013 (CEST)

I've seen that you have reached version 1.3.5. There's any relevant patch that should worth to be implemented? Furthermore, I've tried to add the code to managed the string {{-}}. Theoretically works but not in practice :-) Could you check it? --Andyrom75 (discussioni) 11:36, 2 set 2013 (CEST)

Hi, have been busy with that. There are a few small bugfixes, and I added the ability to mark and immediately remove a listing. There's actually a huge oversight about external links which will soon be fixed in 1.4 and which may also lead to a bigger structural change that I anticipated, so probably better to wait for that, maybe in the next few days.

Looks OK, except that the condition for {{-}} should be checked regardless of whether there is a third level heading or not. Is that the problem? -- Torty3 (discussioni) 12:16, 2 set 2013 (CEST)

So you suggest me to wait for 1.4 instead of get the lastest 1.3.5 patch?

Regarding the "string" you are right. It should be present (and preserved) at the end of the H2. The potential others are custom and it's correct to add the new listing below the "string". However, the last try I've made it doesn't work (you can see the log), and I can't understand where's the problem. Could you give a look at it? --Andyrom75 (discussioni) 12:24, 2 set 2013 (CEST)

It's a little clunky but it works. Also decided to just update to 1.3.5. I will update to 1.4 soon enough and will let you know. -- Torty3 (discussioni) 15:08, 2 set 2013 (CEST)

Thanks a lot! I'm going to update the central script. --Andyrom75 (discussioni) 15:13, 2 set 2013 (CEST)

I've seen that you have implemented a way to delete the inserted listing. I'm ok with the idea, but I don't think that a checkbox it's the more intuitive way. Have you consider to add a third button (named Delete)? And maybe a pop-up that ask to confirm the deletion? --Andyrom75 (discussioni) 18:45, 2 set 2013 (CEST)

On top on the previous consideration I would like to ask you if you can help me with the debug of the script, because I've added another patch for it:voy (and it works this time :-)) but the JS engine catch a couple of similar error. The first one is "Cannot read property 'textContent' of null" and the second is "Cannot read property 'w' of null ". Discussing with another user, he suppose that is because of local installed plug-in on Chrome, but I've tried to disable them all and the problem persist. Let me know your thought, --Andyrom75 (discussioni) 22:12, 3 set 2013 (CEST)

Other thing, could you add on the error list the one related to the black listed URL? Curretly goes into the generic error group. --Andyrom75 (discussioni) 11:05, 11 set 2013 (CEST)

The error code should already be included as - code: spamdetected, info: Your edit was refused because it contained a spam fragment: wikitext. Not sure why it goes to the generic unknown error. Let me see. Still have minor fixes for version 1.4, give me a couple of hours. Do you want the closed/remove checkbox then? -- Torty3 (discussioni) 14:31, 11 set 2013 (CEST)

With the current code, the blacklisted item was recognize as a generic API error, and after pressing ok the saving windows has remained there until I've pressed ESC (no other button were available). Now I can't use those sites as a test because I've inserted them in the local whitelist. But if you need, we can find another globally blocked site. When I was adding the URL I haven't touched anything else so I don't think the wiki-spam was the cause, but give me more details to understand what do you mean, just for future prevention.

Regarding the delete procedure I think that it would be better to have button instead of a checkbox, however I'd like to keep (if possible) the same en:voy interface. What do you think about this change? --Andyrom75 (discussioni) 14:46, 11 set 2013 (CEST)

I would have expected behaviour to be - Error: API returned error code "spamdetected": Your edit was refused because it contained a spam fragment: xinjiangtravel.com. That URL is locally blacklisted on en.voy, but it returns the generic API error. The URL itself should be considered as the wiki-spam that is caught by the filter. I need to find the AJAX response to troubleshoot it more clearly, which is taking a tad long.

Tough break then :) I still prefer the check box although admittedly a little purposely unintuitive. -- Torty3 (discussioni) 15:52, 11 set 2013 (CEST)

Ah OK I see my expectation was wrong. edit.spamblacklist is returned. -- Torty3 (discussioni) 16:06, 11 set 2013 (CEST)

I've just tested with novogate.com and the returned message is:

La pagina all'indirizzo https://it.wikivoayge.org dice:

Errore: Risultato sconosciuto dell'API.

It's seems a quite generic message

Regarding the checkbox Vs. button, if you don't like the button, I don't want to bear you of this "nice to have" requirement :-)

....on the other hand.... I need some help to add a couple enhancements :-P

The first one would be useful for all the voy versions. When we click add on the equivalent of eat/sleep, should be good to be able to specify the price category, because our templates assume that we divide resturant/hotel according to their prices. Once specified, the new listing will go directly under the proper section. In it:voy our template include the commented title of the sub-section, so we just need to uncomment.

The second one is specific for it:voy to improve the cleaness of our wikitext. Each section of our template starts with a commented listing template used as an example for those who edit manually. During the add we should check the presence of this commented listing and when found the new listing should replace this one.

Let me know, --Andyrom75 (discussioni) 17:01, 11 set 2013 (CEST)

Settled with version 1.4.1, both the Javascript and CSS have changed, and now the blacklist error message is there. Should return to the filled out form, but I must have destroyed it somewhere, now it just loses the whole edit. Price category would be nice, but I think at least en.voy has articles where they are split by hostels/motels/hotels, not only by price. For the second, easy enough, just need to find and replace the commented listing as usual. Sorry if this is a little low priority for me right now, there are other support requests and well, I don't want to spend all my time doing this :) -- Torty3 (discussioni) 18:31, 11 set 2013 (CEST)

I think that this one should be the right classification en:Wikivoyage:Quick big city article template (for price) but a lot of articles (in all the interlingual version) have exceptions, but I think that Listing Editor should suggest the right one.

I can imagine that you are really busy, don't worry. I'll try to work on the second point. Could you only update us to the 1.4.1? --Andyrom75 (discussioni) 19:20, 11 set 2013 (CEST)

Done. Both JS and CSS, and have to translate the error message. -- Torty3 (discussioni) 16:13, 13 set 2013 (CEST)

Thanks a lot, I'll go to translate and implement it. One thing, yesterday from a friend's PC I've seen that IE shows a bad alignment on the second field on the right column both in it:voy and en:voy. I can't check on my PC with IE (long story). Could you verify if this issue is with all the IEs or it has been just an isolated case? --Andyrom75 (discussioni) 16:56, 13 set 2013 (CEST)

Bah IE, and confirmed only IE. Didn't check again after I added the 'Closed?'. Hmm. -- Torty3 (discussioni) 17:41, 13 set 2013 (CEST)

Another user has just contacted me saying that he has some issue with safari on Mac OSX see here. It seems that we have to enlarge the window. Which is the right CSS parameter to play with, textarea? --Andyrom75 (discussioni) 18:36, 13 set 2013 (CEST)

It's the label being too long again. -- Torty3 (discussioni) 18:51, 13 set 2013 (CEST)

  #listing-editor .input-text label {
    width: 7.5em;
    float: left;
    text-align: right;
    margin-right: 0.5em;
    margin-top:0.2em;
  }

Done, thanks. Later I'll check with this user. It seems that all the added space goes on the left side. Can the whole content be cetered instead of being right aligned? --Andyrom75 (discussioni) 19:32, 13 set 2013 (CEST)

In this paragraph I've noticed the bad position of the "modifica"-link. As you may see from the wikitext this has occurred because of a white line left to insert go on a new line. I think that this is a case that could occur frequently, so I think it worth to be patched. What do you think? --Andyrom75 (discussioni) 19:01, 13 set 2013 (CEST)

testing the patch of the commented listing (that I've mentioned above) I've noticed in this diff that after fax it introduce a white space. Any idea of the reason? --Andyrom75 (discussioni) 02:13, 14 set 2013 (CEST)

Trivial bug, won't fix. It happens because there is a hidden image parameter after the fax parameter, which only shows up if there is an image link for the listing used by the dynamic maps.

For the extra line spacing, it's actually a problem with the listing template and Mediawiki formatting rather than anything to do with the listing editor. The listing template is a span - only works inline. Add that to the fact that Mediawiki always automatically inserts a paragraph when there is a newline. So the listing breaks out of the specified container. What I did was replace the newlines with <br>, which is also not a great solution, but works in the edge cases.

Also change the CSS code again for the labels. -- Torty3 (discussioni) 14:06, 15 set 2013 (CEST)

  #listing-editor .input-text label {
    width: 6em;
    float: left;
    text-align: right;
    margin-right: 0.5em;
    margin-top:0.2em;
  }

  #right-fields .input-text label {
    width: 8em;
  }

I agree that the white space is a minor bug, but with no real changes if we press save, it actually changes the wikitext. I've noticed because this was one test that I did the first time, and the editor correctly haven't saved anything. Can't this map goes inside an if clause? By the way, which is the code that add that space? If it's the final saveStr += ' '; we can add (at least temporary) an exception on the else clause that would execute the instruction only when it's not a fax. What do you think?

BR patch works but I agree with you, it's not properly elegant :-) I'm not an expert, as per you knowledge, this Mediawiki behaviour is normal (and necessary for other stuff) or is something that can be patched?

In case it can't be patched, what do you think to back translate BR into \n when visualized inside the editor?

I've applied the above CSS code and the only thing I've seen from my Chrome browser is that is descreased the space on the left side. What is supposed to patch? To center the content or to align the field that I've seen in a bed position on IE? --Andyrom75 (discussioni) 16:53, 15 set 2013 (CEST)

Even if that fax space is removed, there are other edits like removing double spaces, although that can also be disabled. After hundreds of edits, still no one has submitted the exact same listing, until yours. No harm done anyway. Do patch it if you wish.

The Mediawiki behaviour is normal, and fundamental to the entire structure, so probably wouldn't be patched. It would be possible change BR back to newline, but in some cases, people have knowingly put in the HTML code, then it would be unexpected behaviour to them. I suppose making it easier for newbies is the priority.

IE not fixed yet, but the CSS removes the left side padding as you saw. -- Torty3 (discussioni) 17:01, 20 set 2013 (CEST)

Mobile home page

Do you know why in https://it.m.wikivoyage.org/wiki/Pagina_principale (differently from https://en.m.wikivoyage.org/wiki/Main_Page) it shows near the titles the edit link (i.e. Modifica)? It seems that the wikicode/css are the same, but for sure I'm missing something. --Andyrom75 (discussioni) 08:04, 29 ago 2013 (CEST)

Hi, you need the magic word __NOEDITSECTION__. It removes the edit section buttons. I checked with the other languages home pages, only it.voy has it missing. -- Torty3 (discussioni) 11:07, 29 ago 2013 (CEST)

Thanks for the fix. Easier than what I've thought :-) --Andyrom75 (discussioni) 11:40, 29 ago 2013 (CEST)

Strange behaviour

Any idea on why has this occurred? --Andyrom75 (discussioni) 19:53, 18 set 2013 (CEST)

en.voy and it.voy format listings very differently. It's not strange behaviour if it was intended ;) This is really why there cannot be a central listing editor unless all languages standardise their look. Implications for a plugin? Most listings in en.voy are meant to be indented and have all the fields, and the inline listings like will only have the non-empty fields that are filled out. Just fiddle with the function right at the bottom - listingToStr, particularly when it tests for inlineListing. -- Torty3 (discussioni) 16:47, 20 set 2013 (CEST)

Yes, I've just test it few minutes ago (maybe hours ....times fly :-D). As per my understanding the discriminating is the presence of the asterisk. Anyway, now I've understood it... and it sounds reasonable. I've just to discuss about it within the community to understand their preference about it. --Andyrom75 (discussioni) 18:20, 20 set 2013 (CEST)

Listing Editor & Newline

Torty, have you any idea on why during this update all the newlines have been removed? --Andyrom75 (discussioni) 19:52, 8 dic 2013 (CET)

Someone was complaining about inserting breaklines into the wikicode in en.voy, so I removed it. If there are no complaints here, then go ahead and change it back. -- Torty3 (discussioni) 01:38, 9 dic 2013 (CET)

I'm not talking of the BR, I'm talking of the \n at the end of line of the listing template (check it again). --Andyrom75 (discussioni) 09:21, 9 dic 2013 (CET)

Look also at this modification. It has the same problem of the previous one, but I can't understand why it happens only on certain update. Can you explain? --Andyrom75 (discussioni) 20:56, 16 dic 2013 (CET)

Finally I think I've understood which would be the logic of these kind of changes (e.g. this one). Correct me, if I'm wrong. If the listing is in a bullet list, it keeps the "vertical structure" showing all the parameters, including the empty ones. Otherwise, if it's not in a bullet list, it will be converted in an "horizontal structure" showing only the parameters that have a value. Is it correct? In the affirmative case, can it be managed differently?

The ideal way to manage it is to check the current structure (regardless of the bullet point) and keep it as it is. Let me know, --Andyrom75 (discussioni) 09:22, 31 gen 2014 (CET)