Wikivoyage:Travellers' pub

From Wikivoyage
(Redirected from Wikivoyage:Pub)
Jump to navigation Jump to search
Welcome to the pub
QA icon clr.svg

The Travellers' Pub is for general discussion on Wikivoyage, and the place to ask questions when you're confused, lost, afraid, tired, annoyed, thoughtful, or helpful. To start a new topic, click the "Add topic" tab, so that it gets added at the bottom of the page, and sign your post by appending four tildes (~~~~)

Before asking a question or making a comment:

  • Have a look at our Help, FAQ and Policies pages.
  • If you are a new user and you have any questions about using the website, try the Arrivals lounge.
  • If you have a question or suggestion about a particular article, use the article's talk page to keep the discussion associated with that article.
  • If you'd like to draw attention to a comment to get feedback from other Wikivoyagers, try Requests for comment.
  • If you are wanting travel advice on a specific matter see the Tourist Office.
  • If you have an issue you need to bring to the attention of an administrator, try Vandalism in progress.
  • If you are having a problem that you think has to do with the MediaWiki software, please post that on Phabricator instead.
  • If you want to celebrate a significant contribution to Wikivoyage by yourself or others, hold a party at Celebrate a contribution.
  • Discuss issues related to more than one language version of Wikivoyage in the Wikivoyage Lounge on Meta.
  • Anything that is Nigeria-related is now meant to go in the Nigeria café instead. This includes announcements, initiatives and celebrations as well as issues with certain articles.
  • Anything that is Kosovo or Albania related is now meant to go in the Kosovo and Albania café instead. This includes announcements, initiatives and celebrations as well as issues with certain articles.

Pull up a chair and join in the conversation!

Click here to start a new thread

Wikivoyage sysop.svg

Experienced users: Please sweep the pub

Keeping the pub clean is a group effort. If we have too many conversations on this page, it gets too noisy and hard to read. If you see an old conversation (i.e. a month dormant) that could be moved to a talk page, please do so, and add "{{swept}}" there, to note that it has been swept in from the pub. Try to place it on the discussion page roughly in chronological order.
  • A question regarding a destination article should be swept to the article discussion page.
  • A discussion regarding a policy or the subject of an expedition can be swept to the policy or expedition discussion page.
  • A simple question asked by a user can be swept to that user's talk page, but consider if the documentation needs a quick update to make it clearer for the next user with the same question.
  • A pointer to a discussion going on elsewhere, such as a notice of a star nomination or a request to comment on another talk page, can be removed when it is old. Any discussion that occurred in the pub can be swept to where the main discussion took place.
Any discussions that do not fall into any of these categories, and are not of any special importance for posterity, should be archived to Wikivoyage:Travellers' pub/Archives and removed from here. If you are not sure where to put a discussion, let it be—better to spend your efforts on those that you do know where to place.

Feature suggestion: Time needed for an activity[edit]

The idea would be to display, on the page of each destination, an indication of a reasonable or typical duration (or duration range) that a traveller could allocate to a visit. Indeed, it is very useful to have at least a rough idea of how much time a visit one intends to do will take.

It seems more appropriate and easier to define such a duration per visit/activity (e.g. for a specific museum) instead of per destination. The travellers could themselves estimate the total time needed for a destination by adding up the times for each visit they intend to do.

Difficulty: The time needed ("minimum time") for a visit is very subjective, as well as a possible sufficient time ("maximum time") for a visit.

Idea: Make an average over user-input estimated time spent for an activity (how to do it in practice needs be to define). Any other ideas would be very much welcome! OttoRuth (talk) 15:26, 13 August 2022 (UTC)Reply[reply]

Averages are seldom informative, and they rely critically on the population measured – and we don't have access to any measurements at all. Thus this needs to be the editors subjective guess on typical duration. The information is useful, but I think trying to condense it into a range is difficult and might be counterproductive: "The trail is 2 km, and can be walked in half an hour. However, most visitors come for the bird watching tower, and may dwell there for hours." –LPfi (talk) 15:38, 13 August 2022 (UTC)Reply[reply]
I think that some hint about "time needed" could be very useful. Google Maps used to provide a note about how long people spent in different places, and I sometimes found it useful.
I think the best way to handle it is in a text-based description. For example, I was in a small museum for the first time this summer. IMO the "time needed" is about an hour. (I stayed about 30 minutes. Others, especially if they were in a group, might stay longer. I doubt that anyone except the paid staff stay there 3+ hours.) It therefore needs a description like "This three-room museum in the historic Teacher's House is a good way to spend an hour when you're in the neighborhood."
You'd write something quite different in other cases, such as:
  • "Most people will want to spend the whole day. The museum's café is limited to pre-made cold sandwiches, pastries, and coffee, but you can get a re-entry bracelet at the front door, go out for lunch, and come back to tackle the rest of the building", or
  • "This museum is the perfect place for staying cool on a hot afternoon", or
  • "Devotees of the art might plan a multi-day pilgrimage to take full advantage of everything on offer".
I think that we will provide more information this way than just writing "____ hours". For example, to go back to the museum I saw: I'm telling you something about the size (it's just three rooms, and it used to be a house. Even if you're super-interested in the subject, it's a small place). I'm telling you something about how long it might take (an hour. You can then think about whether you're quicker or slower than most, and thus decide whether that might be closer to 30 minutes or two hours for you). I'm also telling you that it's not worth a special trip ("when you're in the neighborhood"). "One hour" doesn't covey as much. WhatamIdoing (talk) 17:09, 13 August 2022 (UTC)Reply[reply]

Template for approval: Template:In5[edit]

@Twsabin: created this template on Friday and per our ridiculous template policy, it sadly needs consensus. I strongly support using this template; the purpose of the template is pretty self-explanatory. --SHB2000 (talk | contribs | meta) 10:21, 22 August 2022 (UTC)Reply[reply]

I'd prefer your not calling our policies ridiculous, as it shows little respect for consensus, and such respect is needed for our working together. I think it is very good that this template, like other ones, needs consensus. It might be useful, but where to use it needs to be discussed, as it adds a formatting option not previously available (without using bad or complicated markup). The purpose is obviously to make that formatting option easily available, but the intended use is not documented, nor self-explanatory. Were in our guides should be put 45 consecutive spaces (as in the example)?
I saw it used in multi-paragraph listings. We should probably adjust the listing template to accommodate multiple paragraphs in the content parameter, create a template for that specific use, or discourage multi-paragraph listings. If a listing needs more than one paragraph, it should perhaps be changed into a subsection.
Are there other use cases (not counting templates)?
LPfi (talk) 11:17, 22 August 2022 (UTC)Reply[reply]
LPfi, this discussion is specifically about the use of {{In5}}, not my opinion regarding templates. In5 is self-explanatory, at least to me because In5 = 5 indents by default. {{In5|8}} might seem a bit confusing but it's an easy-to-use template. SHB2000 (talk | contribs | meta) 11:53, 22 August 2022 (UTC)Reply[reply]
So it is, but your comment prompted a reply. The template may be easy to use, but its intended use is not documented nor self-explanatory. Where is it intended to be used? I discussed one use case and asked whether there are other ones. Is its use to be recommended wherever an editor thinks it fits? If it is used instead of semantic markup, it may degrade the accessibility of the site. I don't see where indentation is needed other than at paragraph breaks, where it should be handled by the wikitext line breaks being converted to HTML paragraph breaks (with associated CSS) as appropriate. –LPfi (talk) 13:11, 22 August 2022 (UTC)Reply[reply]
Why does the name not follow wikipedia:Template:Indent, which has also been adopted on five other Wikimedian wikis? "In5" is a lot more ambiguous than "Indent". I also looked at a few places where it is used on Wikipedia and from the small sample it was used to indent footnotes/references and words in infoboxes, neither of which are really applicable here. Gizza (roam) 13:21, 22 August 2022 (UTC)Reply[reply]
It could be used on routeboxes so the names of cardinal points are in line. Regarding the template name, I'd support your proposal to move it to {{indent}}, though I do realise that Wikipedia has both w:Template:Indent and w:Template:In5. SHB2000 (talk | contribs | meta) 13:33, 22 August 2022 (UTC)Reply[reply]
I don't think it is appropriate to use it in routeboxes or similar templates in that way. Now the road sign image and the cardinal point names on each side are centred as a unit. If the images on each row are of equal size, then the names will be neatly on each side. If not, then the   is much too course to align anything. And we don't want people to tweak the layout of templates on each page were they are used, the logic of the template should handle that (for consistency, ease of editing and conservation of labour). –LPfi (talk) 16:49, 22 August 2022 (UTC)Reply[reply]
All this template does is add five plain old spaces. It could be replaced in practice by "     " (that's a series of five spaces, alternating between regular and non-breaking spaces so that the parser won't collapse them into a single space). It doesn't give you paragraph breaks, so it will not solve the multi-paragraph listings problem. It is currently used in Nordic countries#Understand, inside the blue box, to change the location of Template:See also. The importer also documented this use at Wikivoyage:Information boxes.
I'm not convinced that we should be using {{see also}} inside the information boxes (IMO the links should be inline), but if we are going to, then it is reasonable enough for editors to want some method of producing the expected visual appearance, whether that's through spaces or a template.
SHB2000, as a side note, I would like you (and every editor at all of the wikis) to consider adopting the ethical stance of not personally enforcing any consensus that you happen to disagree with. That is, please don't violate the agreement yourself, but if someone else does (or might have), you can let its actual supporters address the (potential) problem themselves. WhatamIdoing (talk) 15:43, 22 August 2022 (UTC)Reply[reply]
If we want a see also in the information boxes, then let's add a parameter "seealso=" and put the indentation logic in the infobox template, with in5 as a helper template if needed, but I assume CSS is the better solution. –LPfi (talk) 16:53, 22 August 2022 (UTC)Reply[reply]
Why is this linked to Template:Indent (Q5618727), not Template:In5 (Q8129687)? The link suggests that it has the wrong name. If we must have this, I would prefer the name of "indent". I don't see why indenting by 5 would be so common as to be the default. "In" is a word and I wouldn't automatically think of it as an abbreviation. Conversationally "in 5" means "in 5 minutes" - so an editor might expect this to give a 5 minute break! AlasdairW (talk) 21:03, 22 August 2022 (UTC)Reply[reply]
Fixed. I'll also add that even the German Wikivoyage also uses this template, and has no issues with this template. SHB2000 (talk | contribs | meta) 21:37, 22 August 2022 (UTC)Reply[reply]
Still, where is it to be used? Three uses have been proposed: fake paragraph breaks, adjusting centring in a template and adding seealso or footnotes to infoboxes. All involve trying to add functionality or fix style issues in templates in an ad hoc manner. Those templates or the usage should be fixed instead. We could keep the template and tell that it is to be used as a temporary fix where needed, and that any such use should be noted on the "fixed" template's talk page, for a discussion on whether it is the template or the usage that should be fixed. –LPfi (talk) 06:41, 23 August 2022 (UTC)Reply[reply]
I think it's also quite convenient for tweaking table spacing/padding (less use of direct markup makes it easier to follow the table in wikitext); example: Special:Diff/4506969. I'm sorry I hadn't started this discussion myself, as soon as creating (via copying) the template—and included at least several use cases in the proposal. I wasn't fully cognizant of the template policy, although I remember seeing if not quite absorbing that page (I got that templates are used much less than on a certain sister project, but the basic idea that prior consensus is required for every template didn't stick). I think that this template is technically well implemented and documented, unobtrusive, and has highly varying niche uses which don't have to be seen negatively as ad hoc solutions, and support that it be kept. Twsabin (talk) 17:05, 23 August 2022 (UTC)Reply[reply]

Twsabin, that brings us back to what LPfi has been saying about doing it properly in the first place. In that diff, you saw this:

°C °F
40 104 sweltering

and you thought it would be nice to have a little visual space separating the color coding from the text, so you added this template:

°C °F   
40 104       sweltering

which results in five copy-able spaces being added to either side of that red border, which will cause problems for anyone who wants to copy and paste that into a Word doc or Excel spreadsheet. It looks okay on wiki, but why didn't you just fix the table's formatting directly, like this?

°C °F
40 104 sweltering

That doesn't introduce any superfluous spaces, it's guaranteed to work, and it will never cause funny line wrapping (which might look fine on your screen but be broken on someone else's screen, due to differences in screen sizes, zoom sizes, and font sizes). Have you heard the saying "If all you have is a hammer, all you will see is a nail"? If all you have is a template that inserts spaces, then you might not realize that the solution you really need is in w:en:Help:Table. WhatamIdoing (talk) 19:04, 23 August 2022 (UTC)Reply[reply]

I am familiar with wikitable formatting and understand what you're saying very well (I did say less use of direct markup makes it easier to follow the table in wikitext). What prompted me to try out this example of usage is that it's mentioned in the documentation (meaning it was presumably an accepted practice from where it originated). In this specific instance I am pretty sure the spaces could never produce any rendering problems, but I haven't considered the issue of copying the table to MS Word etc., which is a good point. All in all I agree that it's a bad example, and I take it back. Twsabin (talk) 08:01, 24 August 2022 (UTC)Reply[reply]
FWIW, I don't expect Twsabin to fully follow the template policy when it literally violates WV:PF, especially when no other wiki has such a restrictive template policy (but thankfully m:IAR can be used here). But back to the template, what if you were to insert 32 spaces? Surely it would be a pain clicking the space button 32 times, wouldn't it? SHB2000 (talk | contribs | meta) 08:45, 24 August 2022 (UTC)Reply[reply]
Any policy can be seen as violating Wikivoyage:Plunge forward (which is what WV:PF refers to). That's the wrong way to look at it. Plunge forward says [more or less] that you don't have to check policy or do it the right way, somebody will improve or revert your edit if it was faulty (this discussion is totally in line with that). Meta:Ignore all rules (m:IAR), the status of which is unclear, says: "If a rule prevents you from improving or maintaining a project, ignore it", but e.g. en-wp, from which the principle is counted refers to the fifth pillar, says "guidelines [...] are not carved in stone; their content and interpretation can evolve over time". Guidelines still play a role, they shouldn't be ignored just because you think you know better than the community. Nowhere do the pages tell you to ignore consensus. –LPfi (talk) 09:18, 24 August 2022 (UTC)Reply[reply]
Yeah, but a policy telling that every single edit needs prior consensus is; that's why IAR can be used here. But this is not a discussion about Wikivoyage's template policy – I simply brought that up because Twsabin simply wasn't aware of it. SHB2000 (talk | contribs | meta) 09:39, 24 August 2022 (UTC)Reply[reply]
> what if you were to insert 32 spaces?
Why would you want to insert 32 spaces? WhatamIdoing (talk) 21:08, 24 August 2022 (UTC)Reply[reply]
Okay, so maybe there won't be a situation where you'll need to insert 32 spaces, but I will add that some autocorrect softwares will automatically remove those extra spaces as superfluous. I have one that does that, but I've disabled it on all English-language Wikimedia sites. SHB2000 (talk | contribs | meta) 10:37, 30 August 2022 (UTC)Reply[reply]
Do you ever need to insert any more than the usual one or two spaces? (Two spaces seems to be preferred by people who learned to type in English on an actual typewriter, which is no longer common.) WhatamIdoing (talk) 14:55, 30 August 2022 (UTC)Reply[reply]
Re: "Do you ever need to insert any more than the usual one or two spaces?" The reason why this template was created – in tables like the one in Metric and Imperial equivalents. SHB2000 (talk | contribs | meta) 00:44, 3 September 2022 (UTC)Reply[reply]
It's not used in any of those templates, and I don't see any place where it would be appropriate.
Keeping in mind the difference between "I need extra spaces" and "I need bigger visual gaps between elements in a table", when do you actually need spaces? WhatamIdoing (talk) 19:47, 3 September 2022 (UTC)Reply[reply]

Images[edit]

Hello, all. Work-me is here with a suggestion that some of the Wikivoyages volunteer to be a "test wiki" for one of the dev teams.

Background: Web browsers don't "speak" wikitext. They speak HTML. So we write in wikitext, but it gets transformed ("parsed") into HTML. What we see, except inside the wikitext editor itself, is the parsed HTML. The old parser is very, very old (in software terms), and it's being replaced with a new-ish parser. The old parser doesn't formally have a name, but it has traditionally been called "the PHP parser" (after the software language it was written in). The newer parser is called "Parsoid". The new one does basically the same thing, plus some extra bells and whistles, and minus a few old bugs (and presumably plus a few new bugs, but those technically aren't part of the plan ;-)).

The project: Eventually, the old PHP parser will be deleted, and Parsoid will take its place. They've been working on how it handles images recently (main Phab task: T314318). The image part is already running at mw:, and it seems to be okay. I've done some fairly complex stuff there (e.g., galleries in translated pages) with zero problems. In fact, I never noticed that they switched the parser. It is supposed to be a seamless transition, and that's how I experienced it there. They want to try it out on a few more wikis.

My thinking: I think we should volunteer. First, this is going to end up here eventually, so it'd be better if if worked for us from the very beginning. I don't want Wikivoyage, which does a few unusual things with images (e.g., page banners), to be an after-thought. Second, if something goes wrong now, we'd be at the top of the list for fixes, with a team of devs available to help (or to instantly revert us back to the old parser if it can't be fixed right away). That level of hands-on support can happen if we are, say, #3 on the deployment list, and unlikely to happen if we are in the usual deployment process when they think the work is done. Just as a practical matter, if you deploy software to 500 wikis on the same day, they can't all be the #1 priority if something goes wrong. But if you're the only one this week, then you automatically are the top priority. Third, this team is very careful with their work. They have a system that can identify changes of just a single pixel(!) out of an entire page. So I think we'll be in good hands.

So I'm asking you: Are you willing to have us at the front of the line? If you all think it's okay, then I can officially ask the team to consider us. Whatamidoing (WMF) (talk) 04:49, 24 August 2022 (UTC)Reply[reply]

Support. We don't generally use many images per WV:IP, so a significant change wouldn't really many pages. It's nice that the developers put this wiki as a priority, and given you've convinced me that, I'm all in favour of this. SHB2000 (talk | contribs | meta) 08:15, 24 August 2022 (UTC)Reply[reply]
Despite the "minimal use of images", we do have images on virtually every page of the travel guide, so if anything major went wrong it would affect a lot of pages. But if it does, better to have the developers' full attention, right? Since it's coming for us regardless, it makes sense to support the proposal to be a guinea pig.--ThunderingTyphoons! (talk) 08:36, 24 August 2022 (UTC)Reply[reply]
@ThunderingTyphoons!: Sadly most outline articles lack images (and sadly most of en.voy's articles are outlines) but agree that it'll affect a lot of pages. Maybe we should all go and add heaps of images to every single article to make the travel guide more colourful... ;-) SHB2000 (talk | contribs | meta) 09:16, 24 August 2022 (UTC)Reply[reply]
I agree that it is probably better to get the problems now than to get them later. Anything major affecting all wikis will probably be noticed by the devs before rolling out the change, while what will affect us are probably minor glitches or pagebanner related stuff, things that either won't be a catastrophe or won't be noticed before it is turned on for Wikivoyage. But I don't support heaps of images on every article, we have enough for noticing problems, unless it is about unusual use of images, which I think the Wikipedias or Wikibooks will take care of. –LPfi (talk) 09:32, 24 August 2022 (UTC)Reply[reply]
Every article with a pagebanner (so, basically all articles, including those with non-custom banners) has at least one image, so I stand by my statement. But any issue with images is unlikely to compromise the body of an article, so is a 'risk' worth taking.--ThunderingTyphoons! (talk) 09:43, 24 August 2022 (UTC)Reply[reply]
Oh yes, how could I forget the pagebanner. SHB2000 (talk | contribs | meta) 09:44, 24 August 2022 (UTC)Reply[reply]
@LPfi: I said "Maybe we should all go and add heaps of images to every single article to make the travel guide more colourful... " as a joke to lighten up this discussion – it was supposed to be sarcastic. Did you actually think I was being serious when I said that? SHB2000 (talk | contribs | meta) 09:44, 24 August 2022 (UTC)Reply[reply]
No, not really. Sorry. I have just developed an allergy to the actual building of image heaps in short articles (by some on wp-sv), so couldn't take the joke. –LPfi (talk) 10:15, 24 August 2022 (UTC)Reply[reply]
No need to apologise. Rereading my earlier comment, it does seem a bit satirical in some ways, but I too have been fed up with one user who thinks filling up entire articles full of images is a good thing or galleries that don't add a lot of meaning. SHB2000 (talk | contribs | meta) 10:19, 24 August 2022 (UTC)Reply[reply]
Support. Whatamidoing's argument is very convincing. Vidimian (talk) 22:39, 24 August 2022 (UTC)Reply[reply]

Requesting changes[edit]

Thanks for the support. It might be helpful / expedient if I had the privileges necessary to edit any interfaces that may be broken by the change. For example, I've requested the following change in preparation, Template_talk:Banner#Prepare_for_T314318. But I'm happy to work with any editors who can facilitate the changes. Arlolra (talk) 21:54, 13 September 2022 (UTC)Reply[reply]

Arlolra is Arlo Breault from the mw:Parsoid team. I say this without exaggeration: These are the folks who know, better than anyone else in the world, how wikitext gets turned into what readers see on their screens. We really ought to take him up on his offer to fix things for us. I think admin rights will be enough, but it's possible that interface_admin will be needed at some point. WhatamIdoing (talk) 15:46, 14 September 2022 (UTC)Reply[reply]
Thanks, WhatamIdoing for the much-needed introduction. Would you like to nominate Arlo at WV:URN? --ThunderingTyphoons! (talk) 20:06, 14 September 2022 (UTC)Reply[reply]
Does that feel like it would be a conflict of interest? WhatamIdoing (talk) 23:44, 15 September 2022 (UTC)Reply[reply]
Since there were no further comments, I have posted Wikivoyage:User rights nominations#Arlolra. WhatamIdoing (talk) 02:07, 21 September 2022 (UTC)Reply[reply]

Deployed[edit]

The change was deployed and is now live on wiki https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/830707 Please let us know if it causes any disruption. Thank you Arlolra (talk) 13:24, 21 September 2022 (UTC)Reply[reply]

IsPartOf ?[edit]

The results of the "IsPartOf" template in top of the articles looks strange now. But I did not see changes made to the template. What happened? FredTC (talk) 10:44, 24 August 2022 (UTC)Reply[reply]

I just noticed that in North-Eastern India, and not sure what is causing this. @Andyrom75:, should a phab task be filed? SHB2000 (talk | contribs | meta) 10:53, 24 August 2022 (UTC)Reply[reply]
I have already filed a task for this at phab:T316108. Should be fixed soon. Jon Harald Søby (talk) 13:13, 24 August 2022 (UTC)Reply[reply]
Thanks for filing in the phab task :-). Much appreciated. SHB2000 (talk | contribs | meta) 13:21, 24 August 2022 (UTC)Reply[reply]
Indeed. It was merged with T316085, which was closed as done in the evening of 24 August. –LPfi (talk) 06:34, 21 September 2022 (UTC)Reply[reply]

Entries for individual historic buildings and sites[edit]

Concerning articles such as Sopron with many historic buildings listed, we don't seem to have a guideline for when an individual historic building, site or work of public art deserves an entry on its own. I drafted a guideline at Wikivoyage:Listings#Historic buildings, sites and monuments. What do you think? /Yvwv (talk) 18:06, 25 August 2022 (UTC)Reply[reply]

Sopron#See is quite overwhelming. Looks like a cool place to visit, though. Your draft reads well and on a first look seems thorough. Have you been thinking about writing that for a while, or was it Sopron that gave you the idea? --ThunderingTyphoons! (talk) 19:17, 25 August 2022 (UTC)Reply[reply]
Sophron has 25 See listings with the marker 99! I think we should say not to have more than 95 of any type of listing without discussing it first. Special techniques (see Roman Empire) are required to handle more than 99 listings, but we should first agree that this is really wanted, rather than trimming the list or splitting the article. I think that any of the Sophron listings would be worth having in an article on a small village, but many are not worth seeing when there are more impressive sights nearby.
Also see Wikivoyage:Destination_of_the_month_candidates/Slush_pile#Sopron as Sophron was recently slushed as DOTM. AlasdairW (talk) 22:15, 25 August 2022 (UTC)Reply[reply]
Sites that are widely known but whose location may not be are handled by having a redirect from the location article to a destination article, e.g. Taj Mahal, Alhambra. That can be done even when people will know the city but perhaps not the district, e.g. Smithsonian, British Museum. I think that is a good precedent, but we need some care not to apply it too often. Pashley (talk) 01:37, 26 August 2022 (UTC)Reply[reply]
I think the advice in Wikivoyage:Listings is reasonable, but I don't think that 50+ "See" listings is good for any city article. Perhaps some of Sopron#Downtown street by street could become a walking itinerary, with only a few key museums and landmarks remaining in the city article. WhatamIdoing (talk) 15:06, 26 August 2022 (UTC)Reply[reply]
Buildings and monuments without organized hospitality could be worth mentioning in an itinerary, but not always in the city article. A case study would be Stockholm history tour and Stockholm quay palace tour which describe many such sites. /Yvwv (talk) 10:25, 30 August 2022 (UTC)Reply[reply]

The 2022 Board of Trustees election Community Voting is about to Close[edit]

Hello,

The Community Voting period of the 2022 Board of Trustees election started on August 23, 2022, and will close on September 6, 2022 23:59 UTC. There’s still a chance to participate in this election. If you did not vote, please visit the SecurePoll voting page to vote now. To see about your voter eligibility, please visit the voter eligibility page. If you need help in making your decision, here are some helpful links:

Best,

Movement Strategy and Governance

Zuz (WMF) (talk) 12:22, 30 August 2022 (UTC)Reply[reply]

Articles for complex train stations?[edit]

It has been in the news that Howrah and Kolkata railway stations in India will be upgraded with an airport-like experience, and Howrah railway station is already the largest train complex in India. This means that very large and complex train stations might get its own articles just like very large and complex airports within the foreseeable future. Sbb1413 (he) (talkcontribs) 08:17, 1 September 2022 (UTC)Reply[reply]

That would require a discussion. So far, neither train nor bus stations can have their own articles. Ikan Kekek (talk) 08:29, 1 September 2022 (UTC)Reply[reply]
Until such articles are warranted, I'll list stuff in the respective city articles instead and see whether they will overload the existing listings. Sbb1413 (he) (talkcontribs) 08:32, 1 September 2022 (UTC)Reply[reply]
I a little bit wish we could have articles like Public Transit in $CITY_OR_REGION_NAME. Often the main page goes into too much detail on this topic for my tastes. I'm a city person so I just want to read the barest of essentials, and folks who need more help can dig in to the details. Agree with Sbb, we should wait until there is content to support the creation of these pages, like in London for example. ButteBag (talk) 13:35, 1 September 2022 (UTC)Reply[reply]
Wasn't there a discussion about creating station articles a few weeks ago? --ThunderingTyphoons! (talk) 13:56, 1 September 2022 (UTC)Reply[reply]
Yes. It didn't focus on stations, though.--ThunderingTyphoons! (talk) 14:00, 1 September 2022 (UTC)Reply[reply]
Linking Wikivoyage talk:Airport Expedition#Metropolitan airport, train and bus station articles if the former doesn't work. --SHB2000 (talk | contribs | meta) 14:02, 1 September 2022 (UTC)Reply[reply]
I have no objection in principle to having articles about complex train stations. I could see such articles being useful for travellers to countries like China or Japan, where stations some stations can be a really complex maze with many different lines. If you've been to the train stations in Tokyo or Shanghai, you'll find that some of them can be as complex to navigate as airports. The dog2 (talk) 15:36, 1 September 2022 (UTC)Reply[reply]
+1 to ButteBag's suggestion of more articles like Public transit in the Bay Area and Public transit in Israel. Unlike city folk, though, I sometimes wish for step-by-step walkthroughs (do you just need to buy your ticket, or do you also have to do something with it after you board the bus?), maybe with pictures (e.g., maps of train stations, what the ticket machines look like). WhatamIdoing (talk) 15:55, 1 September 2022 (UTC)Reply[reply]
Oh, huh, so theses articles do exist! I thought they were banned or at the very least frowned upon. Getting back to the original question, I thought airport articles were allowed because they often include hotels or a place to sleep. (I am a low information contributor, so please take this with a grain of salt.) So following that logic, if a rail station includes a hotel it should be OK? But for me... the whole "sleep" thing turns the Bay Area Transit article into something we should delete, which I don't agree with. I'd like to see something like:
  • "Transit options of sufficient complexity (and with plentiful existing content), may be treated like the district of a city or any other bottom level destination page."
I don't know, just throwing it out there. ButteBag (talk) 18:06, 1 September 2022 (UTC)Reply[reply]
I think you'd want to start with a slightly more general article, and build a single-station article only if we needed it. For example, we have Rail travel in India and we have Kolkata#By train, but why not write something in between the two? Public transit in Kolkata could be a very good travel topic, if you wanted to focus on travel within the city and its suburbs. The Rail travel article is more about rail service between cities. From what @Sbb1413 says, it would not be reasonable for it to have a solid section on Kolkata's main train station on some page. WhatamIdoing (talk) 15:34, 2 September 2022 (UTC)Reply[reply]
WhatamIdoing thank you for your input. I've created an article on public transport in Kolkata and all I have to do is to link this article to the main Kolkata article. Sbb1413 (he) (talkcontribs) 05:33, 14 September 2022 (UTC)Reply[reply]
If you have two hours between trains, it is usually straightforward to walk out of the station and explore the surrounding area. This is rarely possible with at an airport. The shops in a railway station are usually available to non-travellers. Thus railway stations are much more part of the city that they are in. They may be a few railway stations which are more isolated from the city, like stations where you go through immigration and customs before entering a sealed waiting area.
We do have Rail travel in India which is a guide article which has been featured on the main page, but still has scope for improvement. AlasdairW (talk) 22:04, 1 September 2022 (UTC)Reply[reply]
That's true for many parts of the world, but it's not universal. In China, for example, train stations are much more similar to airports in that you'll have to show your passport and go through security when you enter the building. If you have two hours between trains there, you'll spend them inside ... El Grafo (talk) 07:43, 2 September 2022 (UTC)Reply[reply]
For stations like that, it may well be necessary to split the info off into a separate article, but these should be the exception rather than the rule, and it should be first demonstrated that the travel-relevant info is overwhelming the city/district article, not just that it could. If we do allow this, we're going to have to be quite strict on the requirements, because I really don't think that even stations like London St Pancras and Paris Gare du Nord (which do have sealed-off areas behind passport control) need separate articles, but the temptation might be there to create those once we have others.--ThunderingTyphoons! (talk) 09:27, 2 September 2022 (UTC)Reply[reply]
Public transit in London and Public transit in Paris would both make useful travel topics. WhatamIdoing (talk) 15:35, 2 September 2022 (UTC)Reply[reply]
And naturally, Public transit in Tokyo too. The dog2 (talk) 16:38, 2 September 2022 (UTC)Reply[reply]
We also have Public transport in Sydney, Public transport in Stockholm and Trams in Melbourne as well. SHB2000 (talk | contribs | meta) 20:55, 2 September 2022 (UTC)Reply[reply]
London Underground was a topic that existed previously before being redirected. I would have no objections to some of the Lengthy Get around material in London being moved to it's own topic page, with a summarised version in the main Lodnon article. ShakespeareFan00 (talk) 08:32, 4 September 2022 (UTC)Reply[reply]
It even had a banner that could be re-used - File:London_Underground_banner.jpg , although a Red London Bus or black cab might be more representative of the topic. ShakespeareFan00 (talk) 08:35, 4 September 2022 (UTC)Reply[reply]
Since an underground expansion in 2017, Stockholm's central station is notoriously complex, but it is not really a destination in its own right. The station could most suitably be described in the Public transportation in Stockholm County article. /Yvwv (talk) 11:49, 4 September 2022 (UTC)Reply[reply]

────────────────────────────────────────────────────────────────────────────────────────────────────So what was the outcome of this?

Creating pages for complex train & bus stations is permissible, however it's a very high bar to clear. Before creating a new station article, it should first be decided that there is an "overwhelming" amount of pre-existing content. Generally speaking, it would be preferable to create a new travel topic page Public transit in $LOCATION, before any individual station pages.

Does that sound about right? --ButteBag (talk) 19:35, 7 September 2022 (UTC)Reply[reply]

I doubt it. How about:
This site does not have pages for complex train & bus stations. Before starting one, you must demonstrate that there is an overwhelming amount of pre-existing content and attain a consensus behind your proposal. Generally speaking, it would be preferable to create a new travel topic page Public transit in $LOCATION, before any individual station pages.
Ikan Kekek (talk) 19:55, 7 September 2022 (UTC)Reply[reply]
We might suggest Rail travel in $LOCATION as another useful name.
The points of difference between these two appear to be:
  • whether it's "permissible" or "hasn't happened yet" (Ikan, I assume you're trying to make a statement of fact, rather than prohibiting them? The wording will be interpreted both ways.)
  • whether you need to get written permission in advance.
Are there any other key points? WhatamIdoing (talk) 16:01, 8 September 2022 (UTC)Reply[reply]
It is currently prohibited. Permitting it would require a discussion. That accounts for the phrasing I propose. The default answer is "No", and to get to "Yes", there would need to be a convincing argument. Ikan Kekek (talk) 18:53, 8 September 2022 (UTC)Reply[reply]

Is it time to drop the COVID-19 banner from the Main Page?[edit]

Please join the discussion here. Ground Zero (talk) 12:41, 1 September 2022 (UTC)Reply[reply]

I would also propose that we drop all article top COVID banners unless the country still has significant COVID restrictions (quarantine and/or mandatory testing) impacting vaccinated travellers in place. "No restrictions" boxes can go under Get in. Jpatokal (talk) 23:51, 5 September 2022 (UTC)Reply[reply]
That makes sense. Or perhaps in some other extreme situations beyond what's now happening in places like the U.S. (which though hardly safe is largely "normal" now except for those getting severely ill and dying). Ikan Kekek (talk) 01:10, 6 September 2022 (UTC)Reply[reply]

Article in 'Itineraries' about longest continuous train journey?[edit]

The recent opening of a new railway section between Laos and China will give the theoretical opportunity for the longest continuous train journey on Earth, starting in Portugal and ending in Singapore. Maybe it could be worth it to create an article about it? Gpalombi (talk) 16:35, 1 September 2022 (UTC)Reply[reply]

Go ahead and start an itinerary article if you like! Ikan Kekek (talk) 18:01, 1 September 2022 (UTC)Reply[reply]
Nit: the stations for services to Thailand and China in Vientiane are different, and there's no rail connection between the two, so it's not quite continuous! Jpatokal (talk) 23:53, 5 September 2022 (UTC)Reply[reply]
That said, a new high-speed railway line from Bangkok to Nong Khai is now under construction, and there is a plan for a new bridge to connect Nong Khai to Vientiane, so a continuous connection is not too far a way. Negotiations are probably complicated given that it will require a trilateral agreement between China, Laos and Thailand, but progress is being made. The dog2 (talk) 15:58, 7 September 2022 (UTC)Reply[reply]
Even before the connection is realised, an itinerary on getting from Portugal to Singapore by rail is useful – it's certainly thrilling for rail fans. A need to travel between two stations in one city on the route spoils it for Guinness, but not as an itinerary. –LPfi (talk) 12:21, 8 September 2022 (UTC)Reply[reply]
Agreed, it's not as though there's a single train that does the entire Portugal to Laos stretch in one fluid journey, and then there's an annoying little break in Vientiane. There'd be lots of changes of trains and waiting in central stations and at borders, probably a few metro connections as well.
The bigger problem at the moment is the journey goes through countries that are increasingly difficult to visit - most obviously Russia and China.--ThunderingTyphoons! (talk) 13:33, 8 September 2022 (UTC)Reply[reply]
That said, China has reopened to international students (and before just COVID, China was the third most popular destination for international students after the US and UK, perhaps surprisingly ahead of Australia and Canada) and business travellers (who hold a valid APEC business travel card), so let's hope the reopening for tourism is not too far away. As of now freight trains do cross the China-Laos border regularly, but let's hope we will have passenger trains doing the same soon too.
Speaking of Vientiane, there is no metro system, so you will have to travel between the two railway stations on the opposite sides of town by taxi. Laos is a very poor country, and there's no way they would have been able to afford the new railway without China financing it. And even the very short rail connection to Thailand was financed by Australia. The dog2 (talk) 15:50, 8 September 2022 (UTC)Reply[reply]
Indeed, that was Jani's nit-pick point. But you'd need to use the metro to get between the termini in Moscow and possibly several times in Europe, depending on the route taken.--ThunderingTyphoons! (talk) 16:12, 8 September 2022 (UTC)Reply[reply]
Could be a very interesting itinerary, provided that the borders will open and all trains part of the route start running again some day. A travel Youtuber made the longest possible rail trip from Portugal to Vietnam in 2019. --Ypsilon (talk) 16:40, 8 September 2022 (UTC)Reply[reply]

Revised Enforcement Draft Guidelines for the Universal Code of Conduct[edit]

Hello everyone,

The Universal Code of Conduct Enforcement Guidelines Revisions committee is requesting comments regarding the Revised Enforcement Draft Guidelines for the Universal Code of Conduct (UCoC). This review period will be open from 8 September 2022 until 8 October 2022.

The Committee collaborated to revise these draft guidelines based on input gathered from the community discussion period from May through July, as well as the community vote that concluded in March 2022. The revisions are focused on the following four areas:

  1. To identify the type, purpose, and applicability of the UCoC training;
  2. To simplify the language for more accessible translation and comprehension by non-experts;
  3. To explore the concept of affirmation, including its pros and cons;
  4. To review the balancing of the privacy of the accuser and the accused

The Committee requests comments and suggestions about these revisions by 8 October 2022. From there, the Revisions Committee anticipates further revising the guidelines based on community input.

Find the Revised Guidelines on Meta, and a comparison page in some languages.

Everyone may share comments in a number of places. Facilitators welcome comments in any language on the Revisions Guideline Talk Page. Comments can also be shared on talk pages of translations, at local discussions, or during conversation hours. There are planned live discussions about the UCoC enforcement draft guidelines; please see Meta times and details: Conversation hours

The facilitation team supporting this review period hopes to reach a large number of communities. If you do not see a conversation happening in your community, please organize a discussion. Facilitators can assist you in setting up the conversations. Discussions will be summarized and presented to the drafting committee every two weeks. The summaries will be published here.

Zuz (WMF) (talk) 13:53, 8 September 2022 (UTC)Reply[reply]

Would you like to test the “show nearby articles” feature in Kartographer?[edit]

Hello!

Artikel in der Nähe (runde Marker) auf einer Kartographer Karte II.jpg

The Technical Wishes team from Wikimedia Germany is deploying an additional feature to Kartographer: soon it will be possible to automatically show nearby articles on a map in an article page.

Would English Wikivoyage like to be among the first wikis to test the show nearby feature?

It will be available on the first wikis presumably at the end of September or beginning of October. More information, also regarding Wikivoyage’s similar “Show nearby destinations” feature can be found on the project page, questions and discussions are welcome here.

Please let me know here if you are in favour.

Thanks a lot,

Timur for the TechWishes team Timur Vorkul (WMDE) (talk) 15:22, 8 September 2022 (UTC)Reply[reply]

Who might be interested in this? FredTC and Renek78 were asking about map problems a while ago, but who else? WhatamIdoing (talk) 16:06, 8 September 2022 (UTC)Reply[reply]
Ooh that seems fancy and useful. I'm definitely in favour of this new feature. SHB2000 (talk | contribs | meta) 00:45, 10 September 2022 (UTC)Reply[reply]
We already have this, see: here. But it seems that they will improve it. Right now it needs manual updating of a list/table somewhere (I don't know where). In the Venice article you can see that it needs to be updated, the sestieri San Marco and Castello have no markers using this function now. --FredTC (talk) 08:19, 13 September 2022 (UTC)Reply[reply]
Thanks for your reactions!
So I interpret the positive responses and the general excitement as a yes and have included enWikivoyage into the deployment ticket . I will let you know the exact deployment date when it's set.
Thanks also for providing the example of Venice so we can keep an eye on once the new feature is available. Timur Vorkul (WMDE) (talk) 11:24, 14 September 2022 (UTC)Reply[reply]
@WhatamIdoing @FredTC @Renek78@SHB2000 @Matroc
The deployment of the feature is going to happen next week. The question now is how to proceed with the already existing “show nearby destinations feature”. Technically, both are not in conflict with each other and can exist in parallel for testing purposes.
  • Should the existing feature already be turned off or should the old and the new co-exist during the testing?
  • If turned off, would you like to do it or should the Technical Wishes team?
Thanks again for you input. Timur Vorkul (WMDE) (talk) 17:19, 27 September 2022 (UTC)Reply[reply]

InternetArchiveBot[edit]

InternetArchiveBot has started editing pages here. I think that some of this is useful, but in many cases the dead link may be of more use to readers than an archive page. A dead link for a restaurant warns that the place might of closed, and I expect most readers would make other checks before visiting, but if they don't notice the archive banner, they will see last year's menu and assume that the place is open.

It probably is worth archiving links in Understand and similar background information, but not those in Eat or Sleep. It might also be useful to provide the archive page after the dead link, with an explanation: eg: timetable (dead link, archived page). AlasdairW (talk) 22:30, 11 September 2022 (UTC)Reply[reply]

Alasdair, I agree with you about the risks, and I've disabled the bot for now. Ocaasi, Cyberpower678, Harej, why are you running User:InternetArchiveBot here? Are you running it on any other Wikivoyages? See Wikivoyage:Welcome, Wikipedians#Style differences: "Wikivoyage articles use no references." There are consequently no sources for the bot to rescue on this wiki. I don't think that the bot should be adding archive.org links at any of the Wikivoyages.
If, on the other hand, you were willing to add {{dead link}} (which places the article in Category:Articles with dead external links), then I imagine that some editors might think that was useful. WhatamIdoing (talk) 05:30, 12 September 2022 (UTC)Reply[reply]
I went through the first five edits by the bot. All of them were suboptimal. Some needed removal (e.g., ferry service that appears to have shut down); some needed a correct link (e.g., new domain name or re-arranged website). None of them were edits that the bot could have made correctly. WhatamIdoing (talk) 05:42, 12 September 2022 (UTC)Reply[reply]
I've indefinitely blocked the bot as an unauthorized bot and will rollback all the bot's edits. The bottom line is, there's simply no need to run a bot like that on a travel guide. SHB2000 (talk | contribs | meta) 08:12, 12 September 2022 (UTC)Reply[reply]
Reverted all. I will also add that this bot has also been removing dead link tags and supposedly replacing them with archive.org urls which is worse than nothing. SHB2000 (talk | contribs | meta) 08:29, 12 September 2022 (UTC)Reply[reply]
It's not necessary for the bot to be blocked. It has a built-in system for disabling it on any wiki. You don't even need to be an admin to do this. WhatamIdoing (talk) 17:46, 12 September 2022 (UTC)Reply[reply]
@WhatamIdoing: We didn't realize that the act of adding archive URLs was actually doing Wikivoyage a disservice. Since the bot is approved as a global bot and enwikivoyage is listed among the wikis that allow them, we simply deployed to this wiki. This of course is in contrast to what SHB2000 (talk · contribs) is claiming, since they blocked the bot as unauthorized. Either way it seems the act of marking links as dead is much preferred over adding archives to them. We can modify the bot to accommodate this.—CYBERPOWER (Chat) 12:49, 12 September 2022 (UTC)Reply[reply]
@WhatamIdoing: I thought Wrh2's bot already did the same thing (though it's not currently running). SHB2000 (talk | contribs | meta) 08:30, 12 September 2022 (UTC)Reply[reply]
I agree that these edits are not appropriate. Thank you for reverting them, SHB2000. It's useful for a bot to tag dead links for human review, but automatically replacing them with archived copies allows out-of-date information to remain unnoticed. This is a big difference between a travel guide (full of practical advice that needs to be updated often) and an encyclopedia (full of factual exposition that is often historical in nature). —Granger (talk · contribs) 09:34, 12 September 2022 (UTC)Reply[reply]
If Ryan's bot isn't currently running, and IABot could do this now, I think we should unblock the bot and let them tag dead links for us. And to forestall any potential confusion, I mention now that if a website is down for an hour, then anyone (bot or human) might mistakenly believe that it was a dead link. We should always expect a small percentage of false positives in this kind of work.
@Cyberpower678, I think you'll want to use tag-only mode at all the Wikivoyages, and be careful about the namespace for Wikisources. Also, I don't think the local template technically supports the |date= parameter, but I think it would be a good idea to include a date anyway. I believe that's how the bot is already set up anyway. WhatamIdoing (talk) 15:55, 12 September 2022 (UTC)Reply[reply]
The bot is generally very flexible with how it should behave. The only thing I need to do is actually add an option to reconfigure the bot to do tag-only work, since the bot was designed around the principle that archives are better than dead links. This shouldn't take very long to implement. I have opened a phabricator ticket to track this work at phab:T317553. —CYBERPOWER (Chat) 17:00, 12 September 2022 (UTC)Reply[reply]
Thanks. I think that would be helpful. WhatamIdoing (talk) 17:36, 12 September 2022 (UTC)Reply[reply]
Yes: thank you. –LPfi (talk) 11:12, 13 September 2022 (UTC)Reply[reply]

We are back (student assignment in Asia)[edit]

Hello Wikitravellers! After a few years break, I am back to unleash a bunch of students (mostly Korean and Chinese) on some topics (you can find some old annoucements of mine and accompanying discussions in the pub's archives). Interested editors may also want to check our syllabus (tinyurl.com/wikivoydata) and/or dashboard (tinyurl.com/dashwikivoydata2022). The student list in the dashboard as well (account names). I expect most activity to be concentrated in the topics related to South Korea and China; I'll do my best as usual to ensure the editing is constructive and so on, and I apologize in advance for any extra work. Hopefully, just like in the past, we will end up with several new or improved articles for those regions. For results of past projects see the list I maintain at https://en.wikipedia.org/wiki/User:Piotrus/Educational_project_results (CTRL+F Wikivoyage). Thanks for hosting us :) Piotrus (talk) 10:44, 15 September 2022 (UTC)Reply[reply]

Ooh another expedition – that sounds nice. I'm willing to do any cleanups if necessary, but thanks for hosting this expedition :-). SHB2000 (talk | contribs | meta) 11:53, 15 September 2022 (UTC)Reply[reply]
Welcome back, Piotrus, and welcome to your students! Is there any type of editing you'd like us to hold off on for a particular period of time while your students work? Ikan Kekek (talk) 00:02, 16 September 2022 (UTC)Reply[reply]
@Ikan Kekek @SHB2000 Thanks! No, carry on as usual :) Ideally, when reverting students, it would be best to leave them explanation on their talk page or edit summar AND ping me so I can notice this and provide my own explanation of the problem, in class or otherwise. My past experience is that most students don't expect constructive, or any feedback from wiki volunteers, so some don't even realize they've been reverted, and if they do, they don't know why (particularly, please note, most students won't notice comments in edit summaries, not until I individally point that feature out, or show it in class numerous times). On a side note, do note that most of my students will have issues with English proficiency (despite taking an English-language university class, which is what I am teaching), so expect that some edits will need routine copyediting for grammar/vocabulary (more than if I was teaching the class in a country of native English speakers). Piotrus (talk) 03:06, 16 September 2022 (UTC)Reply[reply]
Sure thing. I usually try to abstain reverting edits made during an expedition unless it’s a serious copyvio and/or if it’s out of scope. I’m willing to try making the text more idiomatic if needed. ——SHB2000 (talk | contribs | meta) 05:38, 16 September 2022 (UTC)Reply[reply]
@Piotrus: you make a good point, not just with your students but newbies more generally, that communicating with them via edit summaries is often a pointless exercise. I've seen experienced editors do this on all wikis and they often link to policies using jargon and acronyms, which a new editor would have no clue about. It won't make them learn about the rules and policies here if 1. they don't know what edit summaries are and where to find them and 2. the policies aren't explained more clearly and simply (e.g. even if a new editor reads the edit summary, reverting an edit and typing WV:MOS is not going to make the editor read the manual of style). It's something I try to avoid to do when I copyedit a newbie's edits. Best of luck to your students! Gizza (roam) 06:12, 16 September 2022 (UTC)Reply[reply]
@DaGizza Indeed. Whatever we write in an edit summary is a message to other experienced editors, but expecting a new editor to notice it is futile. If one wants to communicate with a newbie, leaving them a message on their talkpage is the only reasonable approach. In other news, students are startign to select their topics. 1/3 of the expected list (2/3 haven't decided yet) is Jeju, Sokcho, Daegu, Jiaxing, Damyang, Gunpo (will need to be created, see :wikipedia:Gunpo), Xishuangbanna....if anyone feels like watchlisting them early until the end of the year :) I'll report other topics in a week or so. Piotrus (talk) 08:49, 16 September 2022 (UTC)Reply[reply]
Nice. Just a heads-up, your tinyurl link (tinyurl.com/wikivoydata) is broken. Would be interesting if they wish to expand Korean and Chinese Wikivoyage articles after the course is over. I know it's out of the scope of your class, but those wikis are in worse shape than English. OhanaUnitedTalk page 06:07, 17 September 2022 (UTC)Reply[reply]
@OhanaUnited My bad, it shoul be tinyurl.com/wikivoydata2022 (I can't link url as tinyurl and google docs are blacklisted as spam links or such at media wiki level, sigh). Note there is no live Korean Wikivoyage project. In my Wikipedia classes, I have students edit Korean and Chinese Wikipedia, but due to no Korean WIkivoyage, we just focus on English Wikivoyage for the WV class. I'd love to see Korean WV started one day, maybe by one of my students, but so far it hasn't happened yet... Piotrus (talk) 08:57, 19 September 2022 (UTC)Reply[reply]
@Piotrus: btw, there's a Korean Wikivoyage currently in the Wikimedia Incubator – see incubator:Wy/ko/위키여행:대문. It still needs quite a lot of expansion, though. SHB2000 (talk | contribs | meta) 11:09, 19 September 2022 (UTC)Reply[reply]
@SBH2000 Right, I did find it before, but incubator is not "live"; I gave up trying to explain to my students how to use it (I don't think pages there can be connected to wikidata, for example). Frankly, I think we are doing a disservice to everyone keeping stuff hidden there - it should be live and then it could grow (for example, with the help of my students, whom I could get to write or translate a dozen+ articles every year). Piotrus (talk) 12:32, 19 September 2022 (UTC)Reply[reply]
@SHB2000 Ooops, pinged a wrong user... Piotrus (talk) 12:32, 19 September 2022 (UTC)Reply[reply]
URL shorteners are blocked everywhere because they tend to be favored by spammers. I thought you could like directly to full URLs for Google docs, though. Yours is https://docs.google.com/document/d/1tdHX3H7_fQZSthOXGAXYWbVlVBPbkIyorXvjIa1rgaQ/edit. WhatamIdoing (talk) 16:06, 19 September 2022 (UTC)Reply[reply]

Oh yeah, I almost forgot - some of you may find it fun to check out my Prezis about Wikivoyage (see https://en.wikipedia.org/wiki/User:Piotrus/Sociology_course_prezis#Wikivoyage_and_Wikidata). I may develop some more (ideas are welcome!). --Piotrus (talk) 13:58, 19 September 2022 (UTC)Reply[reply]

Gadau[edit]

Gadau is a real place in Nigeria. It was an article but it was redirected to Itas/Gadau. Now that article has been deleted (as of April). Should this redirect also be deleted, or should it be restored to an article? See Talk:Gadau for brief discussion. Powers (talk) 13:33, 16 September 2022 (UTC)Reply[reply]

Incubator links[edit]

Hello. I noticed the existence of {{Incubator}} template. Documentation is rather contradictory as it first states it's for linking another language Wikivoyage like interwiki does, but for Incubator test Wikivoyage instead, and then the rest of the documentation says default project is Wikipedia and Wikivoyage isn't even listed at all. I began my question at Template talk:Incubator if that is intended or somebody wasn't quite paying attention while copying template over from Wikipedia I guess. It's rather confusing and I don't know if that template is even needed. However it seems like it would be quite useful template to raise awareness of newly developed languages of Wikivoyage (just a side note, we're building a Czech Wikivoyage over on Incubator), but that would be only possible if Wikivoyage was even supported (yes, I have tried it on Wikivoyage:Graffiti wall, didn't save the changes, only displayed a preview, which is enough). I intended to come here and use that template to link up newly developed article over on the Czech Wikivoyage that's still in Incubator, to kind of bring more people into it, hopefully fellow Czech people living abroad or knowing English enough they are active here. But there are more languages of Wikivoyage currently developed, and I can see the template isn't actually used anywhere. What is the true purpose of the template then? Polda18 (discussioncontributions) 06:36, 20 September 2022 (UTC)Reply[reply]

@Congariel:, as you evidently imported it. —Justin (koavf)TCM 06:41, 20 September 2022 (UTC)Reply[reply]
Seems like it's intended to be at phrasebooks, which seems sensible enough. —Justin (koavf)TCM 06:48, 20 September 2022 (UTC)Reply[reply]
I see. It does specify a language article, which may indeed mean a phrasebook. I didn't quite notice that at first. Polda18 (discussioncontributions) 07:22, 20 September 2022 (UTC)Reply[reply]

Listings in travel topic articles[edit]

I noted that some listings in Public transportation#Museums covering urban rail include phone numbers, opening hours or other details that are prone to change, and none of them link to the listing in the relevant destination article. All instead link to the venue's web site. This means that readers might miss the description in the primary listing and that any updates have to be done in two places or one will be outdated, probably this one.

I think we have kind of consensus that listings should foremost be in the destination article, and a listing elsewhere "would probably just duplicate content that should instead be placed in the main [destination] articles". Should something be written into some guideline, such as (the yet to be created) Wikivoyage:Travel topics?

A listing in an article can be linked using the name of the venue as given in the listing: Brooklyn/Downtown#New York Transit Museum will take you to the listing as long as the name parameter isn't changed. Using the Wikidata ID as in Brooklyn/Downtown#Q6886122 is more reliable as Wikidata IDs don't change, but less obvious (and the listing may still be moved to another page).

Should we start linking the primary listings in secondary listings, such as in travel topic articles: "name=[[Brooklyn/Downtown#Q6886122|New York Transit Museum]]" (or "name=...#New York Transit Museum|...")? I think listings in the travel topic articles should contain just the information needed for the reader to decide whether they are interested in the place listed. If the URL of the place(which often is very relevant to that decision) isn't shown, two clicks would be needed to reach the site, but I think that is less of an issue than that you might have a listing with a dead link, updated in an article you perhaps cannot easily find.

In some articles the link to the main listing is in the directions parameter, leading to the article where the listing is assumed to be. Consistently linking the listing would more or less ensure that editors find the article which really contains the listing, and have them create the listing there if not already present.

(Links in itineraries should probably be discussed separately, as their listings aren't always relevant in other contexts.)

LPfi (talk) 07:51, 21 September 2022 (UTC)Reply[reply]

I would support writing this into the guidelines if it isn't already.--ThunderingTyphoons! (talk) 08:22, 21 September 2022 (UTC)Reply[reply]
I would mostly support this. The only exceptions should be if a travel topic covers a listing that does not have a city or park article, or if it's listed in a topic article but would fail WV:WORSHIP. SHB2000 (talk | contribs | meta) 08:32, 21 September 2022 (UTC)Reply[reply]
Support. I think the guideline should be: only provide the name of the attraction, tell why it would be interesting to the readers of the topic article in question and give an internal link (could be in various forms; I don't have a specific preference and usually copy the style the previous editors of an article overwhelmingly used) to the destination article, the lowest in the geographical hierarchy possible, where it is (or is expected to be, if not already) listed or otherwise mentioned (e.g. the region articles), and leave the further details to that article. As an aside, I've found the topic articles to be very helpful in catching what listings are missing in the linked destination articles. Vidimian (talk) 10:16, 21 September 2022 (UTC)Reply[reply]
Though before we proceed to rounds of edits removing the extra details discussed here from the topic articles, I'd recommend checking the destination articles to see if they are already provided there, and if not, moving them, so we don't get rid of valuable information once and for all from anywhere at Wikivoyage. Vidimian (talk) 10:21, 21 September 2022 (UTC)Reply[reply]
I'd hesitate to try to require users to use Wikidata links. There's a learning curve and a hassle factor to finding them. Ikan Kekek (talk) 17:37, 21 September 2022 (UTC)Reply[reply]
No, we shouldn't. I think we should either just recommend copying the name from the listing (and checking that the link works) or additionally point out the Wikidata option, to be used at editors' discretion when the name might be unstable. –LPfi (talk) 19:20, 21 September 2022 (UTC)Reply[reply]
Generally I support adding this to the guidelines. In most cases I think it is sufficient to just link to the city article without linking to the individual listing - in some cases a topic may have one listing and the city article has two or more (e.g. some cities linked from Art Deco architecture). Many listings don't have Wikidata values and we shouldn't suggest that these need to be created. There are very few cases where a listing belongs in a topic, and so a specialist reader might make an international journey to see it, and yet not in the city article for a general reader who is walking past; an exception might be for very local travel topics.
I prefer to keep the URL in the topic article, as this can point to a topic relevant part of the site for complex attractions and for ease of tracking things as an editor - if I edit the topic, it gets added to my watchlist and then I know if a bot flags the link as dead, but I am probably not watching the city article. AlasdairW (talk) 22:21, 21 September 2022 (UTC)Reply[reply]

The Vector 2022 skin as the default in two weeks?[edit]

The slides for our presentation at Wikimania 2022

Hello. I'm writing on behalf of the Wikimedia Foundation Web team. In two weeks, we would like to make the Vector 2022 skin the default on this wiki.

We have been working on it for the past three years. So far, it has been the default on more than 30 wikis, including sister projects, all accounting for more than 1 billion pageviews per month. On average 87% of active logged-in users of those wikis use Vector 2022.

It would become the default for all logged-out users, and also all logged-in users who currently use Vector legacy. Logged-in users can at any time switch to any other skins. No changes are expected for users of these skins.

About the skin[edit]

[Why is a change necessary] The current default skin meets the needs of the readers and editors as these were 13 years ago. Since then, new users have begun using Wikimedia projects. The old Vector doesn't meet their needs.

[Objective] The objective for the new skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It draws inspiration from previous requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in Wikimedia deployed skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes and test results] The skin introduces a series of changes that improve readability and usability. The new skin does not remove any functionality currently available on the Vector skin.

  • The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
  • The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents. It also looks a bit different on talk pages.
  • The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
  • The skin does not negatively affect pageviews, edit rates, or account creation. There is evidence of increases in pageviews and account creation across partner communities.

[Try it out] Try out the new skin by going to the appearance tab in your preferences and selecting Vector 2022 from the list of skins.

How can editors change and customize this skin?[edit]

It's possible to configure and personalize our changes. We support volunteers who create new gadgets and user scripts. Check out our repository for a list of currently available customizations, or add your own.

Our plan[edit]

If no large concerns are raised, we plan on deploying in the week of October 3, 2022. If your community would like to request more time to discuss the changes, hit the button and write to us. We can adjust the calendar.

Request for more time to discuss the change

Also, if you'd like ask our team anything, if you have questions, concerns, or additional thoughts, please ping me here or write on the talk page of the project. We will also gladly answer! See our FAQ. Thank you! SGrabarczuk (WMF) (talk) 03:19, 22 September 2022 (UTC)Reply[reply]

Questions for the devs[edit]

@SGrabarczuk (WMF): Thank you for the presentation of the new skin, and for this period of consultation. There's a lot to take in.

I have a question: on most desktop versions of Wikivoyage (though not the one you tested on - de.voy), the table of contents of all mainspace articles appears in the pagebanner (Template:Pagebanner) at the top of the page. As I crudely understand it, the presence of a pagebanner on a WV page overrides the current default table of contents. Will this feature still work with the new, 'sticky' TOC? Your FAQs suggest they might not be compatible. (mw:Reading/Web/Desktop Improvements/Frequently asked questions#How can I get both the old and the new table of contents?). As far as I know (I'm not active on every project), the Wikivoyages are the only wikis to use pagebanners in this way. Have you tested the new skin on a wiki with pagebanners? --ThunderingTyphoons! (talk) 07:38, 22 September 2022 (UTC)Reply[reply]

I switched to the new skin and it looks like both the pagebanner and sidebar TOCs work under the new skin. I do have a few observations:
  • The new TOC can be hidden but I can't find a way to unhide it without reloading the page.
  • The "sticky header" doesn't seem to work here -- the screenshot shows the search icon, page title, and other icons remaining at the top of the screen, but I don't see that here on Wikivoyage. Possibly because our page titles appear superimposed on our pagebanners?
  • The reduced content width negatively affects the appearance of our pagebanners. In particular, the TOC text on them is now too small, but the banners themselves also appear too short (vertically); aesthetically they would look better taller.
  • If there is *any* way we could get the pagebanners to stay at the top of the page as people scroll (the way the new TOC does) it would be awesome. If that could be done we could hide the new TOC by default.
  • The new skin doesn't play well with the experimental Mobile Sidebar Preview gadget.
-- Powers (talk) 13:10, 23 September 2022 (UTC)Reply[reply]
I gave it a quick try and I think that I generally prefer the old skin.
  • The larger left margin and some extra stuff at the top results in the page (at first) displaying less of the article - I prefer the old width of margin.
  • I liked the way that the left margin disappeared (into a button) when I reduced the browser window size.
  • I didn't like the language links now appearing as a drop down at the top of the page - this take up space and I have to click on the link to see what languages are available.
  • The Wiki Love Monuments banner now displays across the full width of the page.
  • The pub TOC (this page's TOC) now has a scroll bar. Many entries which were one line in the old skin now spill into two.
  • When I scroll down in the pub, "Add Topic" is displayed on the static bar at the top, but not other editing tools. I wonder if this might result in new editors adding new topics when they just wanted to add to an exiting one.
I note that some other wikis have very high opt-out rates of active editors. Has any investiagtion been done as to why it is so high (90%) on viwikibooks? AlasdairW (talk) 14:40, 23 September 2022 (UTC)Reply[reply]
I've been using the 2022 for awhile and generally find it a vast improvement.
  • 2022 Header is "sticky" on the pub, but not on article pages. Would be great to have it working everywhere.
  • 2022 ToC is missing an "unhide" option as powers mentioned, but for me it's not a big deal.
  • WV pagebanners have some display issues with the new theme which I have addressed for myself here and here. I got consensus to make some of these changes awhile ago, but not permission to edit the global CSS file. I'd be happy to apply any updates people want. Let me know if interested.
  • The "stickyness" of pagebanners isn't important to me. The new ToC handles it well and takes up less screen real estate.
  • Thank you for all the hard work putting vector 2022 together!
ButteBag (talk) 15:01, 23 September 2022 (UTC)Reply[reply]
@ThunderingTyphoons!, @LtPowers, @AlasdairW, @ButteBag, thank you for your comments. You've shared a lot of good feedback to address! I very much respect that. It's a pleasure to see this much constructiveness. 🙇 Allow me to only address some points now, though.
  • "Can't find a way to unhide it" - that may be a problem indeed. There are different situations:
    • In some namespaces, like Wikivoyage or Talk - there is the sticky header; when you collapse the ToC, the ToC icon appears next to the page title or in the sticky header.
    • In some namespaces, like main - there's no sticky header; the icon appears next to the page title or in the bar where the page title would be. So you need to go all the way to the top of the page. But if there's no page title, the icon is on the right side of the screen, next to the language switcher. Right now, I'm not sure if this is the best solution. I'll be happy to talk about that more.
  • The appearance of our pagebanners - that's an interesting point. Any ideas what could improve this?
  • Get the pagebanners to stay at the top of the page as people scroll - this is a bit beyond the skin itself, but let's keep talking.
  • Mobile Sidebar Preview and other gadgets - we provide support to adjust gadgets, update their compatibility with API, and make them more future-proof.
  • Banners being displayed at the full width - while limiting the content width helps readability, banners are "consumed" differently. There seemed to be no reason to change their width.
  • High opt-out rate - we haven't done that. The results are relatively new, so we haven't had the opportunity to do that yet.
SGrabarczuk (WMF) (talk) 21:29, 23 September 2022 (UTC)Reply[reply]
So part of the issue is that we hide the page title and then use it superimposed on our pagebanners. So the fancy "keep the page title at the top" magic of Vector 2022 doesn't work right. Is there any way to identify the breadcrumb trail and pagebanner as parts of the page that should be kept at the top? I'd even be fine dropping the TOC from our pagebanners since the new TOC is off to the left, out of the way. Powers (talk) 22:45, 23 September 2022 (UTC)Reply[reply]

Discussion[edit]

Meanwhile the wikis are burning in my eyes to to the white background, because most software and systems support a dark mode nowadays, just the wiki world does not. As a workaround I wrote some dark mode styles which works almost fine on the most wikis here especially my home wiki voy/de. You can take a look there. If somebody is interested, there.., but your system has to be set to dark mode. My styles use a media query - and I use the nice timeless skin.

But anyway, I would recommend to you to remove all color and designs statements from your templates and use classes instead. we did it on voy/de and besides we use a voy- Prefix to avoid crashes with other classes. So you are prepared for future developments and the user have a better chance to create some own styles. I got the message here recently with color statements in the box and had no chance to read it. Drop me a line, if you need some help. Winter is coming and maybe I have some time. -- DerFussi 18:51, 24 September 2022 (UTC)Reply[reply]

Announcing the preliminary results of the 2022 Board of Trustees election Community Voting period[edit]

You can find this message translated into additional languages on Meta-wiki.
More languagesPlease help translate to your language

Hi everyone,

Thank you to everyone who participated in the 2022 Board of Trustees election process. Your participation helps seat the trustees the community seeks on the Wikimedia Foundation Board of Trustees.

These are the preliminary results of the 2022 Board of Trustees election:

You may see more information about the Results and Statistics of this Board election.

The Board will complete their review of the most voted candidates, including conducting background checks. The Board plans to appoint new trustees at their meeting in December.

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee.

Zuz (WMF) (talk) 08:52, 22 September 2022 (UTC)Reply[reply]