Wikivoyage:Travellers' pub

From Wikivoyage
(Redirected from Wikivoyage:TP)
Jump to navigation Jump to search
Welcome to the Pub

The Travellers' Pub is 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 ask a new question
QA icon clr.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 Project: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.
Wikivoyage sysop.svg

New template: Template:Formatbox[edit]


New template here, it's been sitting for a while, but I've got everything fixed which has got me waiting. But anyway, in a nutshell, the template is just to replace the existing format box, but in a much more consistent, cleaner way, with also some key differences for each of the spelling variations for that aren't sure and are learning English as a second or third language, more for those who have a scale of en-1 or en-2, but even for the minority spoken dialects like New Zealand english which LPfi brought up at talk:Ireland which for the most part, are known by few outside the home country of the dialect.

Formatting and language conventions

For articles about Travellers' pub, please use the 24-hour clock to show times, e.g. 09:00-12:00 and 18:00-00:00.

Please show prices in this format: $100 and not A$100, AUD 100 or AU$100.

Please use Canadian spelling (colour, centre, travelled, realize, analyze, program).

Phone numbers should be formatted as +64 XXXX XXXX.

I've rather put it into a template, for a couple of reasons, like less chance for spelling errors, errors overall, and rather more cleaner, and more, phone number formats which were said to be done, but eventually left hanging on a cliff. You can see some of them at Talk:Malaysia or Talk:Saudi Arabia. It's pretty clear, and when something changes, it can quickly be changed (so if some spelling in British english changes, then all of them will change at once). Most of the features can be found in the doc, but as a demo, here's one of them, which you can see on the right. This affects newbies in no way (or infact, help them in some cases, because it is the outcome that they would need to know), and only really is just for maintenance purposes, as well as using categories to keep track of where these are used (these can be removed if the community does not wish for these categories).

Formatting and language conventions

For articles about Canada, please use the 12-hour clock to show times, e.g. 9AM-noon and 6PM-midnight except for articles about Quebec in which the 24-hour clock should be used to show times, e.g. 09:00-12:00 and 18:00-00:00.

Please show prices in this format: $100 and not C$100, CAD 100 or CA$100.

Please use Canadian spelling (colour, centre, travelled, realize, analyze, program).

Phone numbers should be formatted as +1 YYY-XXX-XXXX..

Oh, and for exceptions like with Quebec and Scotland, there's another one for those so it produced what again you see on the right. (have used Canada here)

There's no downsides here with this template, and the problems are only transferring the old template to the new, which, a few errors have come up, but can easily be resolved.

--SHB2000 (talk | contribs | meta.wikimedia) 10:06, 17 August 2021 (UTC)[]

Community discussion[edit]

As things stand, I support this, though reserve the right to change my mind if someone puts forward a compelling argument against.

I just tried out making my own box by following the guidance on the template page, and here's some notes:

  • Each field that produces a sentence should ensure that sentence ends with a full stop. For example, if you add a time cmt, the sentence currently runs on awkwardly. From my test: "For articles about Syldavia, please use the 24-hour clock to show times, e.g. 09:00-12:00 and 18:00-00:00 Syldavians don't understand the 12-hour clock."
  • The 'reason' and 'extraprice' fields don't really make any sense, perhaps because the examples are missing or not very clear. What are they for?
  • In my example, I tried inputting Maltese to the spelling field, and the result says "Use British spelling". If we're going to allow Maltese as an input, it should probably give you "Use Maltese spelling". If Maltese spelling isn't a thing, we shouldn't have Maltese as an input.
  • The phone field should probably have an example format of a number, just so people know what to write.

Also, a slight quibble with the spelling examples. Firstly, I'm not sure they're needed at all given the existence of Wikivoyage:Spelling and English language varieties, but secondly if they are to be used then two examples ought to be reconsidered: "fjord" is not a widely-used word in most dialects of English, so I'd suggest it only be used on the New Zealand version of the box, where the spelling is "fiord" and the word is in reasonably common use due to the country's geography; "kilogram(me)" is usually written as "kg" in our articles per Wikivoyage:Measurements, so a better example would be "program(me)".--ThunderingTyphoons! (talk) 11:09, 17 August 2021 (UTC)[]

Thanks for the feedback. Regarding the full stops, it was deliberately not included for the following reason. If I want to get the output ...24-hour clock despite how aurally the 12 hour clock is used, but enter the code:
|timecmt=despite how aurally the 12 hour clock is used.
I get what I initially wanted, but otherwise, there is that random unwanted fullstop in between.
Regarding Maltese spelling, while we decided on Talk:Malta that en-GB was to be used, we only had four people participate, and none of us were certain on what the difference is, so if somebody figures it out, then it will automatically change to Maltese spelling.
Those extraprice and reason is for examples like Talk:Mexico. Will do the phone number in a sec. SHB2000 (talk | contribs | meta.wikimedia) 11:19, 17 August 2021 (UTC)[]
WRT the full stop, "...24-hour clock to show times, e.g. 09:00-12:00 and 18:00-00:00 despite how aurally, the 12 hour clock is used" is a much less clear way of saying ".....24-hour clock to show times, e.g. 09:00-12:00 and 18:00-00:00. In speech, the 12-hour clock is used." Most people writing an additional comment would assume they were writing a new sentence, not continuing the already lengthy previous one.--ThunderingTyphoons! (talk) 11:25, 17 August 2021 (UTC)[]
It would be a good idea to use Mexico as an example in the documentation, because as I said, the notes weren't clear when I was trying to follow them.--ThunderingTyphoons! (talk) 11:28, 17 August 2021 (UTC)[]
Yes Added. Since Canada and the UK has its own section, on top of 12 and 24, there is no other need for the full stop to be gone. I still can't find why I added them, but possibly because I did something to the price. SHB2000 (talk | contribs | meta.wikimedia) 11:41, 17 August 2021 (UTC)[]
Oh, it's for examples like Talk:Falkland Islands or Talk:United Kingdom where certain templates can be used. SHB2000 (talk | contribs | meta.wikimedia) 11:43, 17 August 2021 (UTC)[]

On Maltese: I don't like the idea of a template enforcing policy. If we don't want to use Maltese English, then somebody can revert the edit, instead of having odd magic replace it with something else.

A more thorough discussion on the variant used is needed, and the place for that discussion is Wikivoyage:Spelling, English language varieties or some similar page, which can be linked from the template (I'd like it to be in the Wikivoyage namespace, as most details are irrelevant to travellers). If we have it there, it is kind of redundant to have the word examples, but I see no big harm in having them.

Some of the parameters are a bit hard to grasp. The problem can probably not be solved entirely, but there might be ways to improve the template on this point.

LPfi (talk) 12:03, 17 August 2021 (UTC)[]

So... @LPfi, ThunderingTyphoons!: Do we accept the use of this template? SHB2000 (talk | contribs | meta.wikimedia) 05:14, 10 September 2021 (UTC)[]

I think there might still be a bug or two, as in my try-out box linked from my first comment, I still have |spelling=Maltese, but the sentence "Use Maltese spelling." isn't displaying; in the documentation it says Maltese is an accepted value. But overall I haven't stopped supporting this template.--ThunderingTyphoons! (talk) 08:45, 10 September 2021 (UTC)[]
That's because I removed Maltese after the controversy (which we've decided to use British spelling for Maltese). I'll remove it from the doc though. SHB2000 (talk | contribs | meta.wikimedia) 09:52, 10 September 2021 (UTC)[]
I think some discussion, contemplation and work are still needed. The Maltese shows that the template is trying to enforce policy, which is confusing (such as with Maltese) and requires that policy changes are implemented in the template, which is non-obvious and might go unnoticed (or implemented without change in the documentation). Whether or not we want this hasn't been discussed. I would appreciate comments on the other concerns (fixed/won'tfix/needsreview/needsdiscussion). –LPfi (talk) 10:26, 10 September 2021 (UTC)[]
The Maltese has since been removed and has been updated in the documentation. SHB2000 (talk | contribs | meta.wikimedia) 10:31, 10 September 2021 (UTC)[]
But the decision made was never discussed here, despite my commenting on it. Does removing Maltese answer the concern expressed in my previous comment?
I now changed the intro to actually explain what the template is for. Looking at the documentation I saw a sentence I do not understand:
"All except for time are optional, however the spelling, not and price are necessary."
The sentence should be clarified; what is an optional but necessary parameter? Formally optional but necessary in practice? Why are not and price treated differently from the time?
LPfi (talk) 10:49, 10 September 2021 (UTC)[]
The answer on why those weren't necessary, I tried to make all of them optional, but the coding was too much to wrap my head around for time. TO clarify, leaving all of them blank would work, except for time, although as per all fmt boxes, you can't leave out the spelling and price. SHB2000 (talk | contribs | meta.wikimedia) 10:53, 10 September 2021 (UTC)[]

──────────────────────────────────────────────────────────────────────────────────────────────────── @LPfi, ThunderingTyphoons!: so can I start implementing this template? SHB2000 (talk | contribs | meta.wikimedia) 12:23, 15 September 2021 (UTC)[]

I'd like to have the concerns listed and answered, e.g. with fixed/wontfix etc. as I suggested below, and any clarifying comments in addition to that. Concerns (mostly mentioned above) include:
  1. Punctuation (might have been fixed). Is the behaviour documented?
  2. Some parameter names are not self-explanatory.
  3. The template tries to enforce policy. Is this what we want? Are there procedures in place to ensure that the policy enforced isn't an outdated one?
  4. Are the descriptions of languages needed and sufficient? Are the examples well-chosen?
  5. Has the "optional but necessary parameter" issue been solved? Seems no parameters are required now, although an empty formatbox is kind of silly.
  6. Does the template work as intended with the visual editor?
If there is help needed to make something work, then I think we should try to solve the problems together. Some concerns might need discussion. If something is believed to be solved, then it can be tested, but while it is not yet, testing is frustrating (trying to figure out why it does not work for me, while it doesn't work at all). I think we need consensus on all the points (or on that they can be solved later) before we go on to decide whether the template should be put in wide use.
LPfi (talk) 15:06, 15 September 2021 (UTC)[]

Introduce PCP?[edit]


PCP = Pending changes protection for those unaware, similar to how it works on the English Wikipedia.

I'm proposing to introduce PCP to Wikivoyage for a couple of reasons, and here they are:

  1. We are, after all, the travel guide that anyone can edit. Often if there is disruption, we'd just semi protect the page and do nothing about it.
  2. Currently, when a page is protected, there's often no mentoring on how to improve the page. PCP would allow them to improve the page. Good enough, accept it, if not, then leave it.
  3. For such talk pages affected (a good recent example is Talk:Go, where it seems Ljupco seems to randomly blabber on about Backgammon), newbies can still post messages. They'll just need to be reviewed. If it's vandalism or spam, rollback it with a single click.
  4. For indef protected mainspace pages (like North Korea or the Yoga article), this will not prevent the article from ever growing from IPs.

On who can review these changes, I'd not say a new group should be created, but should rather be integrated into the user rights of patrollers and sysops. Just because that's what patrollers and sysops would be doing with rollback anyway.

Just to wrap it up, this is just a new protection level to loosen up our already loosened up restrictions on the travel guide anyone can edit (except for spambots, vandals and LTAs).

--SHB2000 (talk | contribs | meta.wikimedia) 11:07, 21 August 2021 (UTC)[]

PCP discussion[edit]

I am for it, as per the “Welcome feedback” comments I had posted on my Talk when joining WV. However, the regular editors would need to review the pending changes: e.g. in plwiki they are sometimes left hanging for months on end. Zezen (talk) 14:58, 21 August 2021 (UTC)[]
I think this is unnecessary. Mentoring can (and does) happen now, so this isn't necessary for mentoring. Also, the scale of the problem is small. There are only 17 pages under semi-protection right now. (Several of those will expire during the next week.) Most of those are protected because of one person/situation. We don't have articles that draw negative attention from many people over extended time periods.
Also, it creates some extra work and extra complexity for editors. Instead of just checking Special:RecentChanges, you will have to learn the new system (a fixed cost for each patroller, even if only one article is ever placed under this protection), and then you have to actively click the button to accept the edit each time someone edits that page.
Assuming we're just as human as all the other communities, adding a "lesser" protection option is likely to slowly lead to more pages being protected. If we want to be "the travel guide anyone can edit", we might be best off staying away from any potentially slippery slopes.
Finally, the changes that you want require config changes on the server side, and I don't know whether the WMF would agree to that. That software is getting pretty old and creaky, and expanding the use of potentially unstable software usually produces some hesitation from the devs. WhatamIdoing (talk) 16:28, 21 August 2021 (UTC)[]
Can you please explain what "Pending changes protection" is and how it works? Don't assume we all know how something that's used on Wikipedia and not here works. Ikan Kekek (talk) 17:36, 21 August 2021 (UTC)[]
Here's what I could find: mw:Help:Pending_changes, w:Wikipedia:Pending changes, w:Wikipedia:Flagged revisions, w:Wikipedia:Reviewing pending changes Nelson Ricardo 2500 (talk) 19:58, 21 August 2021 (UTC)[]
Thanks. Key point: "On a pending changes protected page, edits by unregistered (or new) users are not shown to readers until reviewed by a pending changes reviewer." I don't favor this currently. Ikan Kekek (talk) 01:49, 22 August 2021 (UTC)[]
I don't really see the need for this. —Granger (talk · contribs) 07:59, 22 August 2021 (UTC)[]
I also don't think we're at the point where we need to implement pending changes. Those editors who have their edits queued will wonder why their edits didn't go through to the live version. They will also wonder how long it'll take to go live. You also need a pool of reviewers to go through these pending changes. If the incoming pending changes outpace the reviewers, you will start to have a backlog. Plus I don't think it's the best use of the editors' limited time on the site. Overall, I oppose this proposal. OhanaUnitedTalk page 18:41, 22 August 2021 (UTC)[]
This may also be of interest: in 2020-10 the Portuguese Wiki blocked the IP edits (the unregistered users) after a vote. Discussion (partly in English), the vote (ptwiki, so Portuguese only), Results, the key graphs only.
Ptwiki admin’s summary:
We also wanted to improve communication with newbies and newbie retention, which was next to impossible with IPs. So far, it has been a success, and the vast majority of editors is quite happy with that decision. New users have increased as well, since the IPs are gone, and the project is seen from outside as more reliable (it was a problem before)...
Zezen (talk) 06:54, 23 August 2021 (UTC)[]
I am very interested in seeing how this plays out over time. Having fewer inexperienced editors always makes editors happy ...for a little while. But eventually, we realize that none of us are immortal, and losing the next generation of editors could doom the whole project. It seems likely to me that the correct answer will be that the largest Wikipedias can withstand the loss, at least in the near-term, and that the smaller wikis would not. We need more research to find out. (The WMF is planning to run this as an experiment with two other Wikipedias. It might be necessary to try it at more than just two more.)
Also, there is that awkward contrast between the anti-IP-masking folks, who insist that they must know the full IP address for thousands of editors to protect the wikis, and the IP-banners, who insist that nobody (except the overloaded CheckUsers) must be allowed to see any part of anyone's IP address, because everyone must be registered to protect the wikis. It is not possible for both of these views to be correct. Either we actually need to see IP addresses for new and occasional editors, or we don't. WhatamIdoing (talk) 15:50, 23 August 2021 (UTC)[]
  • I am opposed to the subheadings, but they should not have been removed unilaterally. I don’t support the proposal, but then I don’t fully (at all?) understand it. I might give the reading list a chance at some point. --Comment by Selfie City (talk | contributions) 02:29, 23 August 2021 (UTC)[]
Thanks Nelson Ricardo 2500, the first link explained it well. I’m opposed to this as I’m sure it would discourage new users, particularly if pending changes aren’t reviewed quickly. Recent changes patrol is an effective mechanism for this wiki. --Comment by Selfie City (talk | contributions) 02:32, 23 August 2021 (UTC)[]
Maybe a Wikipedia could afford to turn away IP users. I don't think we can or should. Many of us started as IP users. I was an IP user for years before I registered. Ikan Kekek (talk) 07:26, 23 August 2021 (UTC)[]
@SelfieCity: I thought the subheading discussion was at Wikivoyage talk:Travellers' pub? Were you going to put it there and ended up accidentally adding it here? SHB2000 (talk | contribs | meta.wikimedia) 13:11, 23 August 2021 (UTC)[]
  • Comment: I'd support having pending changes protection here, but only as something that is applied to a limited number of articles, like semi-protection and full-protection. This is used on, for example, the English Wikipedia. The English Wikibooks makes pending changes the default for edits from any users with less than 100 edits; I would be completely opposed to a universal pending changes approach like that here, as it would likely result in a backlog. It can take years for edits to be reviewed on enwikibooks. I see no harm in having pending changes protection on a handful of articles, though. Rubbish computer (Talk: Contribs) 18:09, 25 August 2021 (UTC)[]

template for requesting that the local copy of a file be kept?[edit]

I've been informed that banners for destinations of the month are kept locally because it would break the page if a banner is deleted on Commons. This gives me an idea: would it be useful to create a template like {{keep local}} on Wikipedia? --Ixfd64 (talk) 00:04, 24 August 2021 (UTC)[]

We don't usually move files to Commons. Anyone doing that should think carefully about our practice, guidelines and the possible consequences. No need to have a template for that, I think. The situation on en-wp is different, as there are lots of images uploaded locally, as people have continued to do like they did before Commons was created. Thus many images are uploaded to en-wp with no good reason, and there is a need to mark files that indeed are local for a reason. –LPfi (talk) 05:46, 24 August 2021 (UTC)[]
Unlike Wikipedia, Wikivoyage came after commons so we don't have those people as what LPfi mentioned. SHB2000 (talk | contribs | meta.wikimedia) 05:56, 24 August 2021 (UTC)[]

Spoken version of Wikivoyage articles[edit]

Hi, everyone! I don't believe we have any spoken versions of any of these articles so far. User:GK tramrunner RU asked whether we need any. Seems like a great idea! What do you all think? Ikan Kekek (talk) 01:41, 25 August 2021 (UTC)[]

  • I do it the best in Russian, since I have an accent in English.GK tramrunner RU (talk) 01:45, 25 August 2021 (UTC)[]
  • Support in the name of accessibility and inclusivity. I would recommend starting with Star articles and some of our new user and help type pages, but of course contributors are free to create spoken versions of whichever articles they desire, once this proposal meets community consensus. --Nelson Ricardo 2500 (talk) 02:04, 25 August 2021 (UTC)[]
    Comment. If approved this will strongly relate to Wikivoyage:Accessibility. It may be worthwhile restarting Wikivoyage:Access Expedition or a new project akin to w:Wikipedia:WikiProject Spoken Wikipedia. Nelson Ricardo 2500 (talk) 02:41, 25 August 2021 (UTC)[]
  • Strong support. This would be a great step forward for WikiBlind, where some people who are vision impaired do not have access to page reading technologies, whether due to lack of accessibility or cost, someone reading out the page does not require much apart from a computer. @Graham87: have any thoughts for this? SHB2000 (talk | contribs | meta.wikimedia) 02:18, 25 August 2021 (UTC)[]
    @Pigsonthewing created w:en:Wikipedia:Voice intro project, and is likely to have some practical advice. WhatamIdoing (talk) 03:36, 25 August 2021 (UTC)[]
    Thanks for the ping. My fist thought would be "Do users with visual disabilities want this?" Wouldn't people with a visual impairment prefer to access pages using assistive technology such as screen readers, which they are used to using, and which let them more easily navigate around a page - the most recent version of a page - in a non-linear fashion, and to follow links?" If there is a demand for audio files, then I'm sure there is plenty of advice from the people making the equivalent in Wikipedia, who know more about such things than I do. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:01, 25 August 2021 (UTC)[]
  • User:GK tramrunner RU, just in case you didn't know, there is also a Russian Wikivoyage. I don't know what their needs are in terms of spoken versions of articles, but you could certainly ask them, too. Ikan Kekek (talk) 03:16, 25 August 2021 (UTC)e[]
  • Support. SewChicago (talk) 04:05, 25 August 2021 (UTC)[]
It wouldn't do that much good for most visually impaired people. There are free screen readers these days for every major platform and most visually impaired or blind people would just prefer to use those. There is probably an audience for this but it's not people like me ... except those who can't use screen readers well, who probably wouldn't be able to get to the pages and play the files easily anyway. Graham87 (talk) 07:38, 25 August 2021 (UTC)[]
  • Partial Support :- Spoken articles would be useful (assuming there's an effort made to keep them accurate. Even better would be well researched audio tours or walks to support existing material.
    • "... At the traffic lights take a right, proceeding along the pedestrianised precinct, note the brutalist apartments on the right... These were built in the late 1960's as a regeneration project. ...". Is there a mechanism for linking waypoint and audio clips? ShakespeareFan00 (talk) 07:41, 28 August 2021 (UTC)[]
    • I'd also have no objections to appropriate video content being added. Whilst the Time-life travelouge style of video probably would not be something to show on Wikivoyage, There are various travel vlogs on YouTube that could be used as a guide.

ShakespeareFan00 (talk) 07:41, 28 August 2021 (UTC)[]

Videos are not allowed on this site. If you'd like to change that, please read existing discussions that are archived at Wikivoyage talk:Image policy. Ikan Kekek (talk) 00:29, 29 August 2021 (UTC)[]

Edit-a-thon for one or more Spanish-speaking countries?[edit]

Let's discuss which Spanish-speaking countries could use the most help on this site. Here's some background behind why I'm asking:

In User talk:Ikan Kekek#WikiSP Annual Plan, Galahad, who coordinates Wikimedia Small Projects in Spanish on Meta, approached me for suggestions on non-Spanish speaking projects the group could support. Some of you might want to participate at Meta and suggest your own ideas there, and that would be great, but I think a good alternative would be for us to figure out what is likely to be most useful to this site, and I'd be happy to present those ideas to the group as a consensus of en.wikivoyage and have a discussion there.

I haven't checked figures, but my feeling is that the Spanish-speaking countries that get the most visits are probably Spain, Mexico and Argentina, followed by Costa Rica, Chile and Peru, in some order, and then maybe the Dominican Republic and Cuba. (I'm excluding the U.S. as a Spanish-speaking country in this context, for what should be obvious reasons.) My guess is that Mexico could use more help than Spain, and that seems to be borne out in that Spain is a usable article and Mexico is an outline. Bumping both up a level (or better yet, both to guide) is a worthy goal, though, and I could also see the possibility of edit-a-thons on larger geographical areas, such as the Caribbean, Central America, even South America, though perhaps that starts to get too fuzzy in its focus. What do you all think? Ikan Kekek (talk) 13:18, 28 August 2021 (UTC)[]

  • Support Our Latin American articles are long neglected so this would be a great way to lift them up. SHB2000 (talk | contribs | meta.wikimedia) 13:34, 28 August 2021 (UTC)[]
  • Support. Would it make sense to start an expedition? If so, what would be its title? --Comment by Selfie City (talk | contributions) 14:37, 28 August 2021 (UTC)[]
This is the kind of topic I really want to discuss, but mainly the scope, not the title, which can be easily decided on later. I wasn't really asking for support votes (though thanks for those), because I am asking for feedback and suggestions. So to make things (hopefully) clearer:
If we can have two edit-a-thons during the next year related to Spanish-speaking countries, what scope should we have for each one and why? Ikan Kekek (talk) 18:16, 28 August 2021 (UTC)[]
I think your thought to focus on the hispanophone countries that are of most interest to travellers is a good one. I think Mexico would geothermal be the obvious first choice, followed by Spain. But if Spain already in good shape, then Peru would be my second choice. Ground Zero (talk) 18:47, 28 August 2021 (UTC)[]
Weird autocorrect alert.--ThunderingTyphoons! (talk) 19:02, 28 August 2021 (UTC)[]
  • If Spain needs the least attention as a country, it would be strange to dedicate a whole editathon to that, IMO. But equally, even a Peru editathon might be too narrow to attract a large slew of edits. How about an all-Latin America editathon, which even though it would leave Spain and Equatorial Guinea out in the cold, could also include Brazil, Belize etc.? Yes, the scope would be huge, but the potential pool of knowledgable editors that much greater.--ThunderingTyphoons! (talk) 19:02, 28 August 2021 (UTC)[]
I really think that scope is way too wide. Maybe an "Andean countries expedition" that covers Bolivia, Peru, Ecuador and maybe Colombia and/or Chile could be reasonable? Ikan Kekek (talk) 19:25, 28 August 2021 (UTC)[]
Following the discussion, I think some options stand out: Mexico is clearly in need of some attention (it has received some lately). Argentina hasn't been mentioned much here, but it and Uruguay merit some attention as tourist destinations. Perhaps we can divide the Spanish-speaking countries into a few expeditions. If we start with the Americas, Mexico, Central America, and South America (with the obvious exceptions) could be one way to organize the expeditions in preparation for upcoming edit-a-thons, which seem currently like the best way to grow our content beyond our editor base. --Comment by Selfie City (talk | contributions) 19:30, 28 August 2021 (UTC)[]
"Too wide" for what? We had an editathon back in 2018 that covered the whole world, and that attracted loads of edits from loads of editors, because it was broad in focus. If the goal is to improve coverage of Spanish-speaking countries, then launch an editathon that covers the region of the world with the most Spanish speakers. Having an editathon for e.g. Peru may attract loads of edits to Peru articles, but all the other Hispanophone countries will be broadly left as they are. Even splitting Latin America into three separate editathons, as I think SC is suggesting, may result in diminishing returns for the second and third editathons, unless they were held one a year.--ThunderingTyphoons! (talk) 19:47, 28 August 2021 (UTC)[]
[Edit conflict] Thanks for your thoughts. I think that when I post on Meta, I'll link to this thread and mention everyone's suggestions while making proposals. We could certainly propose 3 edit-a-thons, although I think 2 are more likely. Argentina, or maybe Argentina, Chile and Uruguay are good ideas. I think South America is too wide a scope, but I could be wrong. I'm in no rush to post at Meta and would love more opinions or suggestions. I'm thinking, if we have 3 edit-a-thons, Mexico, Bolivia/Peru/Ecuador/Colombia and Argentina/Chile/Uruguay might be possible. On Central America, we should keep in mind that several of those countries are high-crime and suffering from droughts and other global warming-related climate devastation. Costa Rica is a popular destination, and Guatemala has great Mayan attractions though it suffers from the problems I mentioned above.
That said, Thundering, I can present your thoughts and suggest either a single editathon for the entire Spanish-speaking world or some alternatives and see what they think. Ikan Kekek (talk) 19:52, 28 August 2021 (UTC)[]
Picking specific countries might discourage participation by people who are unfamiliar with those countries. What do you think about recommending that one editing event focus on a theme, rather than a geographical location? Food is a popular and accessible topic, so maybe all Spanish-speaking destinations could have their ==Eat== sections improved, and travel topics like Mexican cuisine could be expanded (or created) for each country/region.
Another broadly applicable theme is national parks or other opportunities for outdoor recreation. WhatamIdoing (talk) 01:17, 29 August 2021 (UTC)[]
The theme idea sounds like a much better idea (particularly with parks). As mentioned on User:DaGizza, Countries that are Anglophone or developed (if not both) obviously and inevitably have better coverage than countries that are neither. Sometimes obscure, middle-of-nowhere destinations of the former have an article while the destination containing the most prominent attraction of a latter country doesn't yet exist., but in this case, even for some Anglophone countries, parks are so poorly covered, I can only imagine those for Spanish speaking countries. SHB2000 (talk | contribs | meta.wikimedia) 01:23, 29 August 2021 (UTC)[]
My question ("Too wide" for what?) still stands, but I agree with the idea of putting all the different ideas to a group of users who may wish to take part, as logically the proposal(s) that receive the most interest should attract the most participation. For an editathon, I think we should prioritise chasing after a high volume of edits, so getting an idea of which proposed topics appeal to the most people is a great idea.
A well-chosen theme could certainly be an 'in' to pique the interests of lots of people. But even with a theme, you've got the question of how wide or narrow to define your geographical scope: macro (e.g. Latin American cuisines), or relatively micro (e.g. national parks in Mexico)? --ThunderingTyphoons! (talk) 10:37, 29 August 2021 (UTC)[]
I suppose many of the participants get thrills from seeing results. Concentrating on a few countries and getting them to usable (or whatever) would mean there is a clear result. With a more broad focus, we might need to develop (or choose) some metric to show the advancement. Created park articles are of course easy to count, and counting usable ones we encourage doing a good work on one before creating the next. Some system to show were work is needed would be good to have, for the parks idea, a "please check this article for things still missing" might help. –LPfi (talk) 11:31, 29 August 2021 (UTC)[]
That's a good point I hadn't considered. If the results are good (and tangible) it might encourage some user retention, which I think the last editathon, popular as it was, struggled with.--ThunderingTyphoons! (talk) 16:00, 29 August 2021 (UTC)[]

Template for approval: ETHtime[edit]


Currently we use the 24 hour clock for Ethiopia, and I think this is one of the few exceptions to where Wikivoyage is using 24 hour time in a country that uses 12 hour notation. But for those that don't know, reading this article (which Nurg used to explain on Talk:Ethiopia two years back), Ethiopia's 12 hour clock is drastically different to how some other countries that use 12 hour time use, where the day (12:00 day) starts at (06:00 EAT) and at 18:00 EAT (12:00 night) would be noon.

We currently only use the format which is used by nearly the rest of the world, but I presume that locals would be seeing the time based on the Ethiopian way and not the way that the rest of the world uses, so here's a template that shows how that can be fixed. Feel free to modify the template but how it works is quite simple:

{{ethtime|21|30}} would produce 21:30 (3:30 night), and thus shows both formats. SHB2000 (talk | contribs | meta.wikimedia) 00:29, 29 August 2021 (UTC)[]

ETHtime discussion[edit]

Looking at the English Wikipedia article, it sounds like "Monday" starts an hour after sunrise (what I would call 7:00 a.m. Monday). Did I understand that correctly? WhatamIdoing (talk) 01:22, 29 August 2021 (UTC)[]

The Wikipedia article says "The daytime cycle begins at dawn 12:00 (6:00:00 AM EAT) and ends at dusk 11:59:59 (5:59:59 PM EAT)", so I presume that it also is the same for Monday. SHB2000 (talk | contribs | meta.wikimedia) 01:27, 29 August 2021 (UTC)[]
This system was used also e.g. in ancient Egypt. There the daytime hours were stretch out in summer to match the sunset, as they were not at the equator – try to construct a watch! I think a template is a good idea, to avoid bad times due to arithmetic mistakes. But I think the template should allow giving the time either in 24 hr notation or as Ethiopian time, and it should support intervals. And it should be easy to grasp. Not easy. Could a {{ethtime|10|30|21|30}} be made to work in parallel with {{eth|4|30|day|3|30|night}}? Would those be easy enough to grasp? Is there a need for other variations? –LPfi (talk) 11:52, 29 August 2021 (UTC)[]
It could be possible, although there'd need to be a different coding method to get around that. I'm not too familiar with that type of method, and I've never attempted it, but I suppose I could give it a try. SHB2000 (talk | contribs | meta.wikimedia) 11:57, 29 August 2021 (UTC)[]
We do explain the alternative system in the Understand section of Ethiopia:
"In Ethiopia, the 12-hour clock cycles do not begin at midnight and noon, but instead are offset six hours. Thus, Ethiopians refer to midnight (or noon) as 6 o'clock. Airline timetables are based on the 24-hour clock and use the Gregorian calendar. To avoid confusion, we use the 24-hour format in all our Ethiopian listings."
Is this sufficient? Are travellers actually going to encounter this often enough that we want to put alternative tines in every listing? Ground Zero (talk) 13:10, 29 August 2021 (UTC)[]
I'd think so, although I've never visited Ethiopia. If that is how time is displayed in Ethiopia, why would they even think of using the format that every other country uses? (a similar question when dealing with metrics and imperials except that this is much rather on a country that is lesser known) SHB2000 (talk | contribs | meta.wikimedia) 13:20, 29 August 2021 (UTC)[]
If I've understood this system correctly, it's not just the time, it's also the day of the week. Imagine a sunrise church service. If it were in most of the world, you might write something like "The sunrise service begins at 6:00 a.m. every Sunday. Arrive half an hour early if you want a seat, and plan to stay until 7:30 a.m." There, the equivalent would be "The sunrise service begins at 11:00 p.m. every Saturday. Arrive half an hour early if you want a seat, and plan to stay until 12:30 a.m. Sunday." (Or something like that; I'm still not confident that I've got this right. It doesn't feel intuitive to me that when the sun comes up, it's still yesterday.) WhatamIdoing (talk) 16:09, 29 August 2021 (UTC)[]
Could we get some input from someone familiar with Ethiopia? I think it would be a bad idea for people who don't know the local situation to go around changing this. —Granger (talk · contribs) 18:10, 29 August 2021 (UTC)[]
I spent 2 and a half weeks in Ethiopia, so I'm not a complete stranger to it. I suspect that virtually all locals who can read the English WV can already switch comfortably between the Ethiopian and Western time systems themselves. In that regard, I suspect they don't need to see local times here. If I'm right, then local times are unnecessary, and the question is whether there would be disadvantages to adding them. I can think of two possible disadvantages. Perhaps it would make listings a bit unnecessarily cluttered. The other would be if the expectation of using a template created a bit of a hurdle for infrequent editors - we get precious little editing of Ethiopia articles as it is. I'm undecided, and I don't like to be negative about a technically nifty little innovation. Nurg (talk) 06:04, 30 August 2021 (UTC)[]
I think the Ethiopian times are very useful for foreigners, who can get puzzled while reading our articles instead of when having arrived. At that point they are hopefully already accustomed to them, if we use them. The other reason I think they are useful is that the traveller easily sees the opening hours on the door are the same as in our guide, and thus up to date. Otherwise they need to do their own calculations for knowing when to show up, if they don't blindly trust us. They are also less likely to make mistakes, if they can see the Ethiopian version after having added an entry and compare it to what is said locally. –LPfi (talk) 17:23, 31 August 2021 (UTC)[]
Hi LPfi. Your comments are interesting and I can see that theoretically, at least, it could be a problem. Are you able to provide any references that show that the use of Western time only is a problem in practice for visiting foreigners? Nurg (talk) 23:03, 31 August 2021 (UTC)[]
Not from travellers, but the quote from this article you mentioned in Talk:Ethiopia, this bit is a perfect example on how it can get confusing:

Once, for example, he and his colleagues set up a meeting for 6 o’clock. Oznoyan thought, “6 p.m., no problem.” But a bit after noon he got a call from the guy he was meeting. “He calls, 'Where are you? I'm waiting in the downstairs.'” Oznayan says. “[I ask him] 'Why?'”

It turns out, Oznayan’s colleague meant 6:00 in Ethiopian time, which is noon by Oznoyan’s clock.

And what more, travellers are much more likely to get confused than businessman because, who knows how the time works there unless you read about it? SHB2000 (talk | contribs | meta.wikimedia) 23:12, 31 August 2021 (UTC)[]
We're using the 24-hour nn:nn format though, not the "o'clock" format, so a problem exactly like that would not occur. Nurg (talk) 08:38, 1 September 2021 (UTC)[]
We are using the 24 hr clock, yes. But your local friend is not, nor is the shopkeeper. If your friend suggests to meet at the bar at 3 o'clock, then you have the problem. –LPfi (talk) 16:16, 1 September 2021 (UTC)[]
Perhaps the most useful advice will be to recommend confirming the time of day: "Six o'clock, just before sunset?" or "Six o'clock, around lunch time?" WhatamIdoing (talk) 15:18, 2 September 2021 (UTC)[]
(Replying to LPfi) I don't see how ambiguous conversations outside of WV, using a format that WV doesn't use, apply to how we write WV. Nurg (talk) 07:44, 5 September 2021 (UTC)[]
I have a friend who worked in Ethiopia for several years. I pointed out this discussion & asked for comment. Her reply was:
Good explanation. The date is different, too. It's 2013 according to the Ethiopian calendar. And there are 13 months. New Year is 9/11 on our calendar.
Pashley (talk) 03:00, 31 August 2021 (UTC)[]
OK, I guess that presents a challenge to our events calendar. How many people go by the same system as the U.S.? --Comment by Selfie City (talk | contributions) 12:26, 31 August 2021 (UTC)[]
Most of the world, but not quite everyone. For example, I believe that the Hebrew calendar is still in general use in Israel. However, I think that all of our readers and most people who have any business dealings at all are familiar with the Gregorian calendar (=the one used in the US). WhatamIdoing (talk) 19:34, 31 August 2021 (UTC)[]
Okay. Maybe we should show both times and calendars, though I’m not sure how much work that would require to implement. --Comment by Selfie City (talk | contributions) 23:53, 31 August 2021 (UTC)[]

How to color a map[edit]

At Florida Panhandle there is a map of the region which is supposed to be colored as stated at Florida Panhandle#Regions. However, the Emerald Coast and Forgotten Coast are miscolored, one being colored in gray and the other not being colored at all -- and, for that matter, I can't even tell from this which subregion is which. Could someone point out a help page or guide which explains how we color maps like this? --Metropolitan90 (talk) 04:18, 29 August 2021 (UTC)[]

I believe SelfieCity might know more about coloured maps, but I think this also has something to do with Wikidata. I think hex colours are also used, but not too sure. SHB2000 (talk | contribs | meta.wikimedia) 04:27, 29 August 2021 (UTC)[]
On my screen the colors look fine. However, I’m aware that regions on dynamic maps intermittently don’t show, which is why we like static maps. I could do more to distinguish between the two purple colors, but I’m not sure how to fix the intermittent problem. --Comment by Selfie City (talk | contributions) 11:25, 29 August 2021 (UTC)[]
(edit conflict) @Metropolitan90: Dynamic maps expedition and How to use dynamic maps seem to be the pages you're looking for.
That said, I see no miscolouring myself by looking at the source code for #Regions. All of them use the same standard colours in the dynamic map template ({{mapshape}}) as they do in {{Regionlist}}. That said, mapshapes are printed with an opacity of what I believe is 50%, so that the underlying map can still be seen and used. This can mess with colours a bit. That said, have a look at {{StdColor}} and pick out alternative standard colours that would be more distinguishable from each other, and then enter those codes (T##) into the mapshape and regionlist templates. For maps with only a handful of regions I usually stick with T2, T5, T7, T9 and T10 myself, but legibility of the colours can also be improved by not letting regions with similar colours border each other. -- Wauteurz (talk) 11:33, 29 August 2021 (UTC)[]
I'm not sure what's changed since I started this thread, since I don't see any edits to the page since then, but now I can see four different colors for the four regions on the map. (Previously, it had not been clear to me that one of the regions was noncontiguous.) So if someone solved the problem, thank you to that person. Thank you to Wauteurz for providing some additional links as well. --Metropolitan90 (talk) 16:11, 29 August 2021 (UTC)[]
Yes. As I noted in my previous comment, it’s an intermittent problem. --Comment by Selfie City (talk | contributions) 16:20, 29 August 2021 (UTC)[]
I wonder if there's anything that can be done about it. I see it all the time on the Portugal articles. Even the country article uses a dynamic map, because the regions changed not long ago, and I have zero static map skills. I suspect that OpenStreetMap is throttling us. Wikidata could also be the culprit, but that's unlikely; I think they're just a part of the chain of events between OSM and WV. Nelson Ricardo 2500 (talk) 20:14, 29 August 2021 (UTC)[]
Do the regions fall on government boundaries? If so, making a static map isn’t hard. However, if they don’t follow political boundaries, I’m not sure how to convert to a Wikivoyage-style static map. --Comment by Selfie City (talk | contributions) 12:28, 31 August 2021 (UTC)[]
I know I will swerve off-topic, as I have some fairly strong opinions about maps here, but I'll try to steer away from those.
@Nelson Ricardo 2500: There is indeed a fix and it is a relatively easy fix, though it is a different approach altogether: Make a dynamic map with static regions instead of relying on the Wikidata/OSM link. What does that mean? It means creating a GeoJSON file through one of several online tools such as and/or, exporting those files, and uploading them to Commons, to then use them in the dynamic map directly. This is already done for quite a few districts, such as those for Amsterdam. If Wikidata proves to be unreliable over time, which in this case would apply, I'd suggest we cut out that middleman and call the regions from Commons directly. The bonus advantage being that GeoJSONs take a lot less time to create than static maps, meaning that they're easier to update and easier to make. Honestly, I think that Wikivoyage would benefit from making this the standard for countries and everything above it, as it is by far more reliable. It feels to me as if most of the problems we experience with dynamic maps is with Wikidata, OSM or the link between those two.
@SelfieCity: Boundaries don't matter that much on static maps. I personally take screenshots of OSM, stitch them together, and build static maps on top of them. Lousy stitching makes a few alignment errors here and there, but nothing that would matter in the long run. If you have enough detail on those screenshots, the political boundaries don't matter that much at all, as you can often find the features on the map that the boundaries-to-be-drawn are based upon. The problem with static maps is moreso that if you want to do them well, they take an awfully long time to make. I've got maps in the works that are 80% done, with just infrastructure to add, but that is tedious work, and I am a bit of a perfectionist myself. Regardless, I have maps for Wales and Brussels that are in that phase, with about 20 hours of work on both, but finishing them is annoying work that I keep on putting off. Updating maps is even less enjoyable.
Here's something I wonder though: Would more people be interested in creating maps (in general) if the information was less all-over the place. For dynamic maps specifically, information is spread between expeditions, WV namespace and templates. For static maps, there's a sizeable learning curve to overcome. Also, do we still see static maps as a necessity? I would argue that they're not. A well-made dynamic map does the same as a static map would, but a lot better. For one, it is zoom-able, scrollable and browse-able, whereas a static map is just a JPEG or PNG and needs additional information written in text to back it up. This is definitely off-topic from this discussion though, but I am still wondering about this.
-- Wauteurz (talk) 15:15, 31 August 2021 (UTC)[]
I've always felt that static maps are outside of my skill set, and that makes it more difficult to consider improvements in regional organization of articles, as I mentioned in Talk:Northern Ontario recently. A "how to" guide would get me started on trying to create maps. Ground Zero (talk) 16:32, 31 August 2021 (UTC)[]

──────────────────────────────────────────────────────────────────────────────────────────────────── I like static maps due to their reliability, but the info about GeoJSON does shift my opinion toward dynamic maps. Wauteurz, what program do you use to import static map layers? I’d be interested in trying but question whether the info at our tutorial is up to date. And do you use Inkscape? --Comment by Selfie City (talk | contributions) 21:05, 31 August 2021 (UTC)[]

@SelfieCity: Following GZ's response above, I've gone ahead and compiled the pages I know of into a single place with a bit of context so it's at least a bit easier to find for now. If you'll look at the comments I added in the source text, then yes, you would find that I tend to agree that the information we supply is in most cases outdated, superfluous, or just unnecessary and causing more confusion than needed. For example, some of the services/tools listed aren't working any more due to mergers or changes of hosts - heck, even OSM itself only allows for exporting XML data. That's hardly useful for static maps. Giving half a dozen different methods doesn't make troubleshooting that easy either. Regardless, my process uses:
  • The equipment I use is Inkscape indeed (v0.98 because I don't like 1.x, but that's because of personal preference);
  • The Windows Snippet Tool or a similar program that lets you capture what is displayed in a single active window;
  • Firefox, but any modern browser should work.
The process then is as follows:
  • Boot up Inkscape, and create a layer for the background material. I often name it "src" or "map". Names don't matter though, it's whatever works for you.
  • Open up OpenStreetMap in your browser, and using Inspect Element (Shortcut: F12), remove the headers and adjust the window. This would need more explanation in a real manual for sure, but the elements are transparent anyway, so it's not an essential step, merely a convenient one. The only element I leave is the scale bar in the bottom left for the one our map needs. You should be able to mouse-over elements on the page to see what's what and then be able to disable those elements. If you pick the wrong thing, then simply undo with Ctrl+Z. It doesn't require a lot of knowledge, but you need to know what to remove.
  • Scroll to a scale that you want, and start making screenshots with some overlap on each other, then paste these into Inkscape lining them up properly as you go. This will create some error margin, but if you take your time, it'll be acceptable for a static map.
    Sidenote, there may be free-to-use source material available that's easier to work with than OSM screenshots. The Netherlands, for example, has OpenTopo. Also, tools exist for automatic stitching, Photoshop is one of them. I don't like working with Adobe programs though, so I avoid it myself.
  • Once the map is done, lock it in your layers menu so you can't accidentally move things about, and start adding the other layers. They should, from top to bottom, be something along the lines of: Frame (Map edges and elements such as the title and scale bar), Annotation (labels and markers), Infrastructure (rail, then highway and national routes), Water (seas, rivers, streams and lakes), Borders (optionally sublayers for the lines and fill, but you can combine both into one shape. Whatever works best for you), after that the previously mentioned map layer, and at the very bottom a background layer with a solid colour for "Other regions" or open water, whichever one is more numerous.
  • From there, you can add things in whatever order you want. Pretty much everything is done with the Bézier tool. I personally do waterways before borders, as borders can be defined by waterways, and I don't like having the borders overlap with waterways.
    Also a sidenote, I colour water a bit different from the templates. Open water becomes  #abd4e0  for me. It looks more vibrant and attractive. I can't reliably apply the pattern in the templates myself, and besides, that pattern makes things like ferry routes difficult to make out.
If you want to have some reference maps from me, I consider my maps for Sydfynske Øhav and Luxembourg to be my best. For static layers on dynamic maps, I will be making a proper manual someday once I've figured it out myself. I'm working on expanding Rotterdam to have districts, so I am working on a map for it in that context. As another note, I am also working on making a better palette for region colours, since, well, {{StdColor}} isn't close to perfect, and being colourblind myself, there's three colours in there that I avoid at all cost. All that considered, perhaps a discussion on the future of maps is in place. Going all-in on dynamic would make switching palettes a lot easier, and would uncomplicate the entire mapmaking process a tonne.
Also, a final thought, when updating/rewriting the manuals, would it perhaps be easier to link to YouTube for Inkscape tutorials? I guess it depends a lot on the person, but I hardly have patience to sit down and read the Inkscape written manual, and seeing someone do something similar before your own eyes makes the process easier to replicate. That's all personal experience though. I'm not even sure the spam filter will accept YouTube links to be made in the first place...
-- Wauteurz (talk) 22:12, 31 August 2021 (UTC)[]
Would it be OK to link to YouTube, considering what's stated in what not to link to? Avoid linking to secondary sources. For example, avoid links to: Personal image galleries and photo/video sharing websites (Flickr, Webshots, YouTube, etc). We'd have to agree on an exception or change the guidelines (which are also under discussion in relation to London on foot‎‎). Ikan Kekek (talk) 00:53, 1 September 2021 (UTC)[]
Hmm. Does that policy apply outside the main/article namespace? Nelson Ricardo 2500 (talk) 01:49, 1 September 2021 (UTC)[]
Do you mean on talk pages? No, it doesn't apply to talk pages. Ikan Kekek (talk) 02:54, 1 September 2021 (UTC)[]
No, anywhere outside travel pages (aka mainspace). So does it apply to pages in the Wikivoyage space? (eg WV:$). SHB2000 (talk | contribs | meta.wikimedia) 04:41, 1 September 2021 (UTC)[]
External links doesn't give that exception, right? If you'd like to propose that, please start a thread at Wikivoyage talk:External links. Ikan Kekek (talk) 05:18, 1 September 2021 (UTC)[]
It's not worth generalizing everything on YouTube into the trash, because specifically for Inkscape tutorials, there are ones out there that are considerably more useful and more accessible than Inkscape's own manual. Logos By Nick comes to mind. Nevertheless, YouTube is globally blacklisted, and whitelisting it here likely causes more damage than needed, as I don't think a specific namespace can get an exception. I don't see a need for discussion as many of the tutorials I would want to link are also available through these creators' own websites, which can be linked instead. External links does not seem to cover Wikivoyage namespace, so it seems that we're fine on that front, but correct me if I am wrong.
-- Wauteurz (talk) 11:29, 1 September 2021 (UTC)[]
@Wauteurz: Thanks for the very detailed explanation. I’m inferring that you trace the OSM map rather than import its data? --Comment by Selfie City (talk | contributions) 10:23, 1 September 2021 (UTC)[]
@SelfieCity: Correct. My method more or less fits in under "2. Maps drawn by hand" in the manual. 1 isn't supported by OSM any more while 3 and 4 require the creator to review the map on what to include (not every road is necessary). I personally find it better practise to rely more on myself in that case and to just draw the entire thing from scratch. It perhaps makes the process somewhat longer, but I don't mind that much.
-- Wauteurz (talk) 11:08, 1 September 2021 (UTC)[]
Google isn't blacklisted on this site; it's just not supposed to be linked in articles. Therefore, this proposed exception is worth a discussion. The object of a discussion isn't to hinder but to make sure decisions are made collectively. Ikan Kekek (talk) 14:47, 1 September 2021 (UTC)[]
Wauteurz, thanks for the information. I might have some time to work on this during the Labor Day weekend. --Comment by Selfie City (talk | contributions) 11:25, 4 September 2021 (UTC)[]

Proposal to allow Flow in beta features[edit]

For those not aware of Flow, see mw:Flow.

I'm proposing to allow flow in beta features, because it makes discussions more cleaner. It is currently used on the French Wikivoyage, however to only user talk pages, and only for those wishing to use it, and I should make it clear that using this gadget is completely optional. What was some of the arguments given in the original proposal on fr.voy definitely applies everywhere, including here:

The main goals of the Flow project are to:

  1. Make the wiki discussion system more accessible to new users.
  2. Making it more efficient for experienced users.
  3. Encourage more constructive conversations that promote collaboration.

Now of course, I'm not proposing that we fully abolish the current talk page system, I'm just asking it if we could enable it on this wiki for the small minority who wish to use this tool. It is not mandatory to use this, as is on the French Wikivoyage. SHB2000 (talk | contribs | meta.wikimedia) 10:15, 1 September 2021 (UTC)[]

I don't know its present incarnation, but the original Flow had several drawbacks. The main showstopper is that it isn't compatible with normal talk pages, so once you start using Flow, you cannot revert it, only move the page away to the archive and start from scratch. It is a second system to learn, so not easier for beginners, who need to learn using normal talk pages anyway (and get confused by the differences), and a big frustration for seasoned editors (old dogs ...). Search and archives work in a different way (at some point they didn't work at all, do they now?). I usually end up not following discussions on Flow pages, as I don't get the normal overview. And it is not about some choosing to use the tool. If a page is converted to Flow, everybody visiting that page needs to use Flow. I contest Flow making for "more constructive conversations that promote collaboration" – it might have been a design goal, but is there any evidence? –LPfi (talk) 16:38, 1 September 2021 (UTC)[]
Ah, and Flow pages cannot be moved away to revert them to normal talk pages. Even if the Flow discussion is deleted, the page remains a flow page, if I understand correctly. –LPfi (talk) 16:54, 1 September 2021 (UTC)[]
The WMF has been declining all requests to add Flow to additional wikis for at least two years now. (Work-me uses Flow every day. It can be turned off, but you have to be an admin to do it. I find that following discussions is easy, but search is "limited", or maybe "non-existent" would be fairer.)
To see an alternative that I'm excited about, go to Special:Preferences#mw-prefsection-betafeatures and turn on the "Discussion tools" item. The latest feature isn't visible yet; it allows you to subscribe to a single discussion thread, without having to put the whole page on your watchlist. If you want to see that, click on'_pub?dtenable=1 and look for the new [subscribe] buttons. (This will also show you the features that are currently available via the Beta Feature in Special:Preferences, such as the [reply] button.) @PPelberg (WMF), could we prioritize the English Wikivoyage for the Reply tool? WhatamIdoing (talk) 15:26, 2 September 2021 (UTC)[]
Agreed, although I’m not familiar with Flow. It sounds as though the alternative has fewer drawbacks than the Flow program. --Comment by Selfie City (talk | contributions) 19:05, 2 September 2021 (UTC)[]
I did a quick test on voy:fr:Discussion utilisateur:SHB2000 and I haven't had much of a problem with disabling it. All it did was unarchive my old talk page and it was easily restored. Here's a quick quote from there though:

Enables a new structured discussion system on your user talk page. Structured Discussions simplifies talk page discussions with clear places to write and reply, and allows conversation-level notifications. This feature is not auto-enabled; users will have to enable it separately.

Existing wikitext discussions are moved to an archive. Disabling this feature will move the Structured Discussion board to a subpage and un-archive the previous talkpage. Learn more about activation.

Doesn't seem to have too many drawbacks. The drawback for me with the reply tool is the autosignature, and the only reason why I've disabled it is because of that very reason. SHB2000 (talk | contribs | meta.wikimedia) 09:12, 5 September 2021 (UTC)[]
I just tested on your FR user talk. It does seem like a cleaner, better organized, easier-to-use, modern interface. Nesting could be improved, but maybe it just can't deal with me talking to myself. If we're voting, that's a thumbs up and a Support from me. --Nelson Ricardo (talk) 17:21, 5 September 2021 (UTC)[]
Seems like it worked when I replied. Maybe it just doesn't allow you to talk to yourself. SHB2000 (talk | contribs | meta.wikimedia) 01:41, 6 September 2021 (UTC)[]
They stopped working on Flow before they sorted out the "indentation" model. If you reply to the last comment, yours goes at the end, full width. If you reply to a comment that isn't the last, then it sticks yours in the middle. This helps identify comments that are out of chronological order, but if you expect a talk-page thread to look like one side of an upside-down pyramid, then you will be surprised. WhatamIdoing (talk) 20:42, 6 September 2021 (UTC)[]

I have to ask - how come transliteration templates aren't used on Wikivoyage?[edit]

I'm a Wikipedian who occasionally hops over to edit a few interest-related articles here, which are generally those covering Japanese-language or -culture related topics. I've noticed that {{lang}} is in use here, but that there's no corresponding transliteration template.

This puzzles me, I have to say. I know the language templates at Wikipedia are a mess - there's no real standardisation, because why can you throw the zh parameters around the place in any old order, but rearranging nihongo means using three separate different versions of the same template - but they still serve a purpose. My main contribution to this wiki is the Purchasing a kimono guide, where all of the foreign-language terms are transliterated; I've made similar contributions to the Wikipedia page on Kimono in general. The only difference is that on Wikipedia, all of those transliterated terms will be pronounced correctly by a screenreader, and on Wikivoyage, to the best of my knowledge, they won't be.

I'm not a code monkey, so I've no clue as to how implementing templates really works. All I know is that words outside of Merriam-Webster need the right information surrounding them for a screenreader to know what language to pick from to work, I think. It's boring work to add language tags, but it is worth it, and once it's done, additions don't take much effort. If anyone could clue me in as to why the transl template isn't used here, I'd be grateful - thanks! --Ineffablebookkeeper (talk) 14:27, 1 September 2021 (UTC)[]

We try to minimize template use, to accommodate pass by edits by non-regulars. It seems the lang template is straight-forward, and so should the transl template be, if imported. The straight-forwardness needs to apply at least to grasping what it does when seen in wikitext or in the visual editor, and being able to remove it or correct parameters by both methods. It being easy to import or add to a phrase is a minor issue, as that can be done by those that understand it, at least if we don't make it seem mandatory. –LPfi (talk) 17:01, 1 September 2021 (UTC)[]
As LPfi already said, we try to minimize template use, and more, I don't even understand how {{lang}} works in the first place SHB2000 (talk | contribs | meta.wikimedia) 22:40, 2 September 2021 (UTC)[]
It tells the browser what language the phrase is in. This is important for browsers that speak the text (pronouncing French in French, not in English), and might help other browsers to render the text in as good a way as possible (I suppose there might be differences between Arabic and Farsi, or Japanese and Chinese, and there was between Rumanian and Turkish, I think). –LPfi (talk) 06:07, 3 September 2021 (UTC)[]
LPfi - exactly right; lang and transl both send, technically, the same information to the browser ("this string of text should be read in X language"), but transl is there for rendering terms in the correct font when transliterated into the Latin alphabet. For some browsers, simply using the lang template will render transliterated terms in a different font; I've seen editors remove lang|ISO-latn tags from text for not rendering correctly. More than that, I'm not certain Latin alphabet text placed with a language tag for a non-Latin alphabet language - say, Japanese - renders or encodes correctly. The transl function smooths over these issues.
I don't think wikivoyage necessarily needs the unholy mess of language templates wikipedia uses, but a combo of lang and transl should cover all the bases, really. I'd be happy to write up a do's-and-don'ts guide for each, if necessary. Usage is quite clear and straightforward once grasped, even for the drive-by editor. --Ineffablebookkeeper (talk) 11:40, 4 September 2021 (UTC)[]
You can do the same in the visual editor, without remembering any templates at all. Select the text, go to the character formatting menu, find the "Language" item, and put in the ISO language code (e.g., ja for Japanese) and you're done. It's not much harder than underlining text, and if someone copies the article to another wiki, it's guaranteed to work there, even if the other wiki has no templates. WhatamIdoing (talk) 21:09, 4 September 2021 (UTC)[]
So what does it do? Places the Japanese text inside a span: <span lang=ja>Japanese phrase</span>? I think, as we try to avoid HTML, that {{lang|ja|Japanese text}} is cleaner and easier to grasp, as you don't introduce a strange "span" and a non-obvious closing tag (closing brackets are a no-brainer). –LPfi (talk) 16:20, 5 September 2021 (UTC)[]
I'm not a huge fan of the limited-template policy, and accessibility concerns should certainly override it. --Nelson Ricardo (talk) 17:25, 5 September 2021 (UTC)[]
Same. I guess we're the exact opposite of the French Wikivoyage... SHB2000 (talk | contribs | meta.wikimedia) 09:09, 6 September 2021 (UTC)[]
Yes, that's pretty much exactly what it does (plus setting reading direction via dir="ltr"), and I agree that a template would be the better choice here. Keeping the source code clear of too many unnecessary templates is a good idea, but it shouldn't turn into a fetish. --El Grafo (talk) 08:54, 6 September 2021 (UTC)[]
Compared to clicking a couple of buttons and having the software do everything for you in the background, templates could only cleaner and easier to grasp if (a) you already know how templates work here, and (b) you are looking at the wikitext. WhatamIdoing (talk) 20:23, 6 September 2021 (UTC)[]

How would a phrase in {{transl}} be supposed to be pronounced? Usually we give the transliterated version only as complement to the English and native spellings. The English phrase is pronounced in English, the native phrase in the native language, what third pronunciation is there to present? Should the transliteration be read out al all? Or told letter by letter, as it is of interest mostly to those who want to spell it? When there is no English version, the transliterated version is used instead, but should it then be pronounced like an Englishman (or somebody speaking the language from the browser preferences) would pronounce it given the spelling, or given the native pronunciation? Or like a native trying to make it intelligible to the Englishman? How do you get at that? –LPfi (talk) 14:51, 6 September 2021 (UTC)[]

LPfi - apologies for the late reply - as a sighted editor who doesn't use a screenreader, this isn't a question I could answer. I'd imagine it'd be much the same as the lang function in terms of pronunciation; though it may seem like a question of "why introduce the transl template at all" due to this, it does avoid display problems across a number of browsers displaying lang tag text in the wrong font.
Additionally, looking on the Wikipedia transl template, it apparently adds a tooltip label, identifying, I would assume, the language transliterated from. It also states that "This template is kept separate from {lang} to address formatting issues (via css classes) and identification of transliteration schemes used" amd that it's "intended to unify all "transliteration" templates, such as {IAST} and {ISOtranslit}", thus cleaning up the language template mess a bit.
Again, even though it may seem a bit pointless, it does have reason for existence, and probably avoids a number of articles switching font mid-text because of how a reader's browser interprets the css. --Ineffablebookkeeper (talk) 09:56, 12 September 2021 (UTC)[]
Yes. Thanks Ineffablebookkeeper for the explanation. It might be that repeating the same name thrice is less of an issue than having some of the three have deficient markup. My comment was mostly about what we do want to happen, not what it does at the moment. I suppose we should change some CSS to have screen readers skip some of those, but adding a parameter to an existing template (and possibly by bot where it is used) and adjusting CSS is much easier than finding strings that need to have the markup. Neither I know how screen readers behave, so at the first step we should probably trust the work done elsewhere. We just need to keep the templatedata as shown by VE and the inline wikicode simple and easy to grasp. –LPfi (talk) 11:46, 12 September 2021 (UTC)[]

Reasons to travel[edit]

The super-topic reasons to travel has a very heterogenous collection of subtopics, and there is nothing in general to say about the topic. Should we scrap the topic, and direct the subtopics to other topics, such as prepare, concerns, talk, activities and cultural attractions? /Yvwv (talk) 21:13, 6 September 2021 (UTC)[]

I still think it is a logical group, and the articles fit badly in the mentioned alternative groups. Some of these others are much more messy, and adding one more category to them will not help. I think the topics structure should be reorganised, but I don't have any idea of how it should be done – other than piecemeal solutions do not seem to work. –LPfi (talk) 05:07, 7 September 2021 (UTC)[]

The 2022 Community Wishlist Survey will happen in January[edit]

SGrabarczuk (WMF) (talk) 00:23, 7 September 2021 (UTC)[]

Bodies of water not showing on dynamic maps[edit]

When looking at the dynamic map of Two Harbors (Minnesota), I'm not seeing blue on the right side of the map for Lake Superior, as I should. Am I the only one experiencing this problem, or do others find this glitch as well? It's true when I'm zoomed in, but not when zoomed out. I've also noticed it to be the case of the Intracoastal Waterway in Florida. --Comment by Selfie City (talk | contributions) 00:52, 7 September 2021 (UTC)[]

Not showing altogether for me. SHB2000 (talk | contribs | meta.wikimedia) 01:03, 7 September 2021 (UTC)[]
I'm not seeing water at Two Harbors until after clicking the zoom out button 4 times. --Nelson Ricardo (talk) 01:17, 7 September 2021 (UTC)[]
Same. --Comment by Selfie City (talk | contributions) 02:01, 7 September 2021 (UTC)[]
It's a rendering error that has been happening for a longer time. I'm not sure where that error originates, but I've seen it happen before with the IJsselmeer (Netherlands), which is now mended, though a similar thing is happening with the Markermeer (between Lelystad and Hoorn) and with the waters in Stockholm, inland from the Slussbron (Gamla Stan). -- Wauteurz (talk) 10:14, 7 September 2021 (UTC)[]

──────────────────────────────────────────────────────────────────────────────────────────────────── There is now a similar issue with Zakynthos except when you zoom out about thrice, it glitches. SHB2000 (talk | contribs | meta.wikimedia) 12:14, 7 September 2021 (UTC)[]

I reported the bug on phabricator and two other map-related bugs (for instance missing geoline objects). --RolandUnger (talk) 14:18, 7 September 2021 (UTC)[]
Thank you. --Comment by Selfie City (talk | contributions) 10:57, 8 September 2021 (UTC)[]
  • If I remember correctly Sydney had similar problem with water area - a tiling issue? - Matroc (talk) 04:25, 9 September 2021 (UTC)[]
Maybe it's a tiling issue. I observed names on maps that are cut and not continued on neighboring tile. But I have no tools to decide this. --RolandUnger (talk) 05:02, 10 September 2021 (UTC)[]

2021 Wikimedia Board of Trustees Election Result[edit]

Thank you to everyone who participated in the 2021 Board election. The Elections Committee has reviewed the votes of the 2021 Wikimedia Foundation Board of Trustees election, organized to select four new trustees. A record 6,873 people from across 214 projects cast their valid votes. The following four candidates received the most support:

  • Rosie Stephenson-Goodknight
  • Victoria Doronina
  • Dariusz Jemielniak
  • Lorenzo Losa

While these candidates have been ranked through the community vote, they are not yet appointed to the Board of Trustees. They still need to pass a successful background check and meet the qualifications outlined in the Bylaws. The Board has set a tentative date to appoint new trustees at the end of this month. Read the full announcement here. Best, Zuz (WMF) (talk) 10:22, 8 September 2021 (UTC)[]

Call for Candidates for the Movement Charter Drafting Committee ending 14 September 2021[edit]

Movement Strategy announces the Call for Candidates for the Movement Charter Drafting Committee. The Call opens August 2, 2021 and closes September 14, 2021.

The Committee is expected to represent diversity in the Movement. Diversity includes gender, language, geography, and experience. This comprises participation in projects, affiliates, and the Wikimedia Foundation.

English fluency is not required to become a member. If needed, translation and interpretation support is provided. Members will receive an allowance to offset participation costs. It is US$100 every two months.

We are looking for people who have some of the following skills:

  • Know how to write collaboratively. (demonstrated experience is a plus)
  • Are ready to find compromises.
  • Focus on inclusion and diversity.
  • Have knowledge of community consultations.
  • Have intercultural communication experience.
  • Have governance or organization experience in non-profits or communities.
  • Have experience negotiating with different parties.

The Committee is expected to start with 15 people. If there are 20 or more candidates, a mixed election and selection process will happen. If there are 19 or fewer candidates, then the process of selection without election takes place.

Will you help move Wikimedia forward in this important role? Submit your candidacy here. Please contact strategy2030(_AT_) with questions.

This message may have been sent previously - please note that the deadline for candidate submissions was extended and candidacies are still being accepted until 14 September 2021. Xeno (WMF) 17:16, 10 September 2021 (UTC)[]

Server switch[edit]

SGrabarczuk (WMF) (talk) 00:46, 11 September 2021 (UTC)[]

Talk to the Community Tech[edit]


Read this message in another languagePlease help translate to your language


As we have recently announced, we, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on September 15th, 23:00 UTC on Zoom, and will last an hour. Click here to join.



The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (first three points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

See you! SGrabarczuk (WMF) (talk) 03:04, 11 September 2021 (UTC)[]

Speedy template approval request[edit]

Hello everyone. For those that have watched my contributions closely these days, you'd have noticed me working on maps on itineraries. But for some time, if the lines were added, those markers wouldn't show up, until LPfi and I figured it out on why that was happening. But if anything were to happen in the future with markers on dynamic maps, we'd have togo to each and every single itinerary where the |show= parameter is used. So to simplify things, I created {{show}} and that basically unifies the use of having markers show up. But because this needs to be used on all itineraries where the marker should show up, I'd like this speedily approved.

Pages that currently use {{show}}

--SHB2000 (talk | contribs | meta.wikimedia) 12:17, 15 September 2021 (UTC)[]

Why not, but the template name should be "AllListingTypes" or something similar, to have a semantically meaningful name... Also, it's probably about time to add "show" parameter doc into {{mapframe}}, it bothers me every 1/2year I need to use it... :-D PS: I (still) think rather than request for approval, RFC would be enough for the templates... -- andree 13:44, 16 September 2021 (UTC)[]
  • Support — route lines on maps without markers aren't very useful. Ground Zero (talk) 13:50, 16 September 2021 (UTC)[]
I should mention that I did do a little test yesterday (I'm writing this at 00:01 AEST) on {{maplayers}}, and that issue had largely fixed most of the map issue. However, it seems that that still hasn't solved the issues with Turku riverside walk, although that has more .json elements which I'm not too familiar with. SHB2000 (talk | contribs | meta.wikimedia) 14:01, 16 September 2021 (UTC)[], Ground Zero: I hereby withdraw this template request as I've handled the issue with markers not popping up. See E8 through Finland and Norway as an example (which I've just done). SHB2000 (talk | contribs | meta.wikimedia) 13:34, 17 September 2021 (UTC)[]

In that example article the template is still used. How should the issue be handled? Is there proper documentation for the "show" parameter somewhere? It isn't even mentioned in the list of optional parameters in the template documentation, nor included in the parameter table. –LPfi (talk) 08:40, 21 September 2021 (UTC)[]
I worked it out through {{maplayers}} which largely resolved the issue. But I do have to say that the documentation for {{mapframe}} is confusing. SHB2000 (talk | contribs | meta.wikimedia) 08:48, 21 September 2021 (UTC)[]
See Special:Diff/4294242 which largely resolved that issue. SHB2000 (talk | contribs | meta.wikimedia) 10:41, 21 September 2021 (UTC)[]
OK. Not too robust a solution, and not well documented, but yes, that seems the way to do it. I'd include only markers and routes that are commonly used. Those introduced in a single article should be handled there, and if that requires it being mentioned in many places, we need better mechanisms. –LPfi (talk) 14:14, 21 September 2021 (UTC)[]


If anyone's interested in participating in this discussion on a new Latin Wikivoyage, here it is. SHB2000 (talk | contribs | meta.wikimedia) 23:00, 15 September 2021 (UTC)[]

No use to start the project with a non-existent editor base. In 2013, there were two active editors, at least one of which remains at la-wp. In 2013 they tried to engage people from la-wp, without success. I think the target group (Latin-proficient travellers) is quite small, so there is little practical benefit of such a project for the time being. If la-voy could catch all the target group, then it could be useful, but until Wikivoyage as a whole has a larger audience, I think chances of succeeding are too small for an effort being worthwhile. The potential contributors spend their time better at la-wp and the bigger wikivoyages. –LPfi (talk) 14:13, 16 September 2021 (UTC)[]
+1. Projects without active editors attract vandalism and spam. WhatamIdoing (talk) 16:59, 16 September 2021 (UTC)[]
But isn't that the job of the SWMT? SHB2000 (talk | contribs | meta.wikimedia) 23:59, 16 September 2021 (UTC)[]
Do you suppose a Latin Wikivoyage would have an English phrasebook? ;-) Ikan Kekek (talk) 00:10, 17 September 2021 (UTC)[]
lol ;). Although I do wonder if there is one on the Esperanto Wikivoyage. SHB2000 (talk | contribs | meta.wikimedia) 00:12, 17 September 2021 (UTC)[]
It's not kind to knowingly create extra work for global sysops and the Small Wiki Monitoring Team. WhatamIdoing (talk) 16:28, 17 September 2021 (UTC)[]

An idea[edit]

Hi. I don't edit here and I am not involved in your community, but I wanted to give a little feedback. As a person who plans on travelling to a few countries to say the least, it is often difficult for me to find good language learning resources for those countries. For example, I see that you have Tagalog phrasebook, but I think it would be useful if there were also a list of websites/communities/apps/Wikibooks/etc. that are recommended for learning the language, and explaining some things about how effective they are. For popular languages like French or Spanish this isn't such a big deal, but some languages are obscure and thus there are very few resources available for learners. So, having them listed here would be useful, because sometimes they can be hard to find and assess.

I have no idea if you have ever discussed this issue or if there is a consensus for this, but I just came to slip this idea in. Take it as you will. Thanks for all your hard work here, your travel guides have been helpful to me. PseudoSkull (talk) 03:01, 17 September 2021 (UTC)[]

I know a couple of phrasebooks like Japanese feature a learn more section with other sources and other sites where one could learn, if you know of any good Tagalog sources you should add them Tai123.123 (talk) 03:31, 17 September 2021 (UTC)[]
I agree that this is useful – please do add "Learn more" sections to phrasebooks if you have resources to share. —Granger (talk · contribs) 16:56, 17 September 2021 (UTC)[]

Temp closures[edit]

There are many places that are still closed due to COVID-19. Some are scheduled to reopen and some are not. How should I handle it? L. Challenger (talk) 01:50, 21 September 2021 (UTC)[]

I'd trust your judgment on this, but I'd say if they're not scheduled to reopen at all, the listings should be deleted or hidden unless they're worth keeping up just for people to see a building's facade or something. Ikan Kekek (talk) 03:51, 21 September 2021 (UTC)[]

"Few" and "a few"[edit]

An editors note: in many articles about Finland and Sweden, "few" is used instead of the intended "a few", probably either because Finnish editors have problems with articles (the Finnish language doesn't even have definite and indefinite forms), or because it is confused with other words, especially Swedish några ("a few"). The mistake seems to be common enough that I think copy editors should be watching for it in these articles. –LPfi (talk) 08:13, 21 September 2021 (UTC)[]

Thanks for the notice. I'll try and keep a look for this. SHB2000 (talk | contribs | meta.wikimedia) 08:20, 21 September 2021 (UTC)[]

Movement Charter Drafting Committee - Community Elections to take place October 11 - 24[edit]

This is a short message with an update from the Movement Charter process. The call for candidates for the Drafting Committee closed September 14, and we got a diverse range of candidates. The committee will consist of 15 members, and those will be (s)elected via three different ways.

The 15 member committee will be selected with a 3-step process:

  • Election process for project communities to elect 7 members of the committee.
  • Selection process for affiliates to select 6 members of the committee.
  • Wikimedia Foundation process to appoint 2 members of the committee.

The community elections will take place between October 11 and October 24. The other process will take place in parallel, so that all processes will be concluded by November 1.

We are very happy about the wide range of diverse Wikimedians that are running for the election and selection processes for the drafting committee of the Movement Charter! As the number of candidates is quite large and thus informing yourself about them might be a bit more complicated, we want to try something different this time: We want to organize a so-called “Voting Advice Application (or “Election Compass) with statements related to the Movement Charter. All candidates can propose their statements here.

For the full context of the Movement Charter, its role, as well the process for its creation, please have a look at Meta. You can also contact us at any time on Telegram or via email ( Best, Zuz (WMF) (talk) 10:38, 21 September 2021 (UTC)[]

New template: Template:Routebox2[edit]

New template time again, but here it is.

For a long time, not being able to use Templates in routeboxes has been quite a problem. Given that we're shifting from images for roads and transports, to templates in particular note {{rint}} and the future RINTroad, it kinda sucks for routebox to not be able to accept templates. So here it is. Used it on the French Wikivoyage (infact I made a similar template there before coming and making the same here), and used the concept of voy:fr:Modèle:Routes and made this templates.

I'm still in the proposal of creating the documentation, but it's half done. This template can accept images if needed, just now the usual way of adding an image ([[File:qwerty|20px]] ) instead of the former way of using routebox.

Any feedback for this template is greatly appreciated :). SHB2000 (talk | contribs | meta.wikimedia) 13:50, 21 September 2021 (UTC)[]

Coming soon: Template dialog improvements for VisualEditor and new wiktext mode[edit]

/ Apologies for writing in English. It would be great if you could help translate this message. /

Hello! Here is more news from the focus area “Make working with templates easier” by Wikimedia Germany’s Technical Wishes project:

Your wiki will soon receive an overall improved interface for editing templates in VisualEditor and in the new wikitext mode (beta feature). This includes several improvements:

  • general redesign (more spacing, bigger window for better usability),
  • a better overview of parameters that are available for a template,
  • an easier way to add parameters via checkboxes and search filters,
  • better visibility of important information,
  • added links to documentation and help pages.

More in-depth information can be found on the project page on Meta. The planned deployment date for these changes is October 6.

Please note: The official VisualEditor help page on will only be changed later this year, when all wikis have received the feature. If you have a local help page about the feature, you can update it based on information on this page, which we will fill with content in late September.

We would be very happy to hear what you think of these changes. Please let us know on this talk page. -- Johanna Strodt (WMDE) (talk) 14:09, 22 September 2021 (UTC)[]

Template for obsolete info[edit]

I just created a template to mark articles with obsolete information. Hopefully it might be useful for marking up information which does more harm than good. Tried out in the article Public transport in Stockholm County, which was extracted from Stockholm County and intended to get updated. /Yvwv (talk) 00:29, 24 September 2021 (UTC) []

I would support this template, just like what I do with every other template. LGTM SHB2000 (talk | contribs | meta.wikimedia) 00:35, 24 September 2021 (UTC)[]
I think {{obsolete}} is useful. However, if information does more harm than good, it should be removed (or commented out, or moved to the talk page, if there still are bits that would be good if adjusted). A parameter for clarifying the problem is sometimes needed, and perhaps a hidden one, for editors (for tips on how to update), could be useful.
I was going to suggest also a {{best before}}, which is in effect the same one, but with a date. For example, I know the railway through Turku will be reworked next year, disrupting traffic, but the specific arrangements are not yet known, and there is no use already telling people that they have to take a connecting bus. I'd like to put in a best before 2021-06, to remind myself and others to update when details are known and people might be planning their transfers.
Then we have {{dubious}}. I suppose there is useful stuff in Brussels#Stay safe, but I wouldn't trust it to be entirely correct.
LPfi (talk) 05:26, 24 September 2021 (UTC)[]
I worry that {{obsolete}} will encourage editors to post notes telling other editors to remove information rather than removing it themselves. I don't understand why some people do that, but that tendency is strong in this wiki. This template could add clutter in our articles.
{{best before}} would be very useful. Ground Zero (talk) 08:55, 24 September 2021 (UTC)[]
I think it is essemtial that we give readers a clue why the information may be obsolete. "Local businesses may have closed since the closure of the steelworks in 2020" or "public transport in the area may have changed after the high speed rail line opened in 2021". The template should show the date it was added as it doesn't apply to any listings with later last edit dates. AlasdairW (talk) 09:36, 24 September 2021 (UTC)[]

New template for banner discussions[edit]

I just created a template, {{newbanner}}, which its purpose is similar to that of {{Districts discussion}}. I've tested this out at Riga region to see how it looks (and it's still there if anyone wants to have a look). SHB2000 (talk | contribs | meta.wikimedia) 13:04, 24 September 2021 (UTC)[]