Wikivoyage:Travellers' pub
The travellers' pub is for general discussion on Wikivoyage, and the place to ask questions when you're confused, lost, afraid, tired, annoyed, thoughtful, or helpful. To start a new topic, click the "Add topic" tab, so that it gets added at the bottom of the page, and sign your post by appending four tildes (~~~~)
Before asking a question or making a comment:
- Have a look at our Help, FAQ and Policies pages.
- If you are a new user and you have any questions about using the website, try the Arrivals lounge.
- If you have a question or suggestion about a particular article, use the article's talk page to keep the discussion associated with that article.
- If you'd like to draw attention to a comment to get feedback from other Wikivoyagers, try Requests for comment.
- If you are wanting travel advice on a specific matter see the tourist office.
- If you have an issue you need to bring to the attention of an administrator, try Vandalism in progress.
- If you are having a problem that you think has to do with the MediaWiki software, please post that on Phabricator instead.
- If you want to celebrate a significant contribution to Wikivoyage by yourself or others, hold a party at Celebrate a contribution.
- Discuss issues related to more than one language version of Wikivoyage in the Wikivoyage Lounge on Meta.
- Anything that is Nigeria-related is now meant to go in the Nigeria café instead. Anything that is Kosovo or Albania related is now meant to go in the Kosovo and Albania café instead. This includes announcements, initiatives, celebrations, and issues with certain articles.
You can review old Pub discussions in the Wikivoyage:Travellers' pub/Archives.
Pull up a chair and join in the conversation!
Significant problems with the listing editor
[edit]I've noticed two new, significant bugs in the listing editor. If I edit a listing and don't add latitude and longitude coordinates, it automatically saves the incorrect coordinates 0, 0. And it adds an unnecessary period (full stop) to the end of the description. Examples: . Has there been a recent change that created these bugs? —Granger (talk · contribs) 23:24, 27 May 2024 (UTC)
- Hey all. The listing editor should now be fixed for the adding period and coordinates bugs.
- The beta has a potential fix for Wikidata sync. If you use it, please enable the beta mode and let me know if it's working for you!
- Thanks in advance! Jdlrobson (talk) 02:20, 2 June 2024 (UTC)
I think the problem started within the past 24 hours – I don't see evidence of it in edits from before that. —Granger (talk · contribs) 23:31, 27 May 2024 (UTC)
- I've rolled back for now. But i really really really need some beta testers for the beta version of the gadget as the existing gadget will completely break in the next week due to some upstream changes in the software and we need to make this change in the next 7 days. This version has been available beta since January so bugs shouldnt be occurring at this stage.
- Any volunteers for helping me test it and reporting bugs like this? Jdlrobson (talk) 06:05, 28 May 2024 (UTC)
- I can't speak for the former issue, but the full stop/period issue is something I've known for quite a while – I thought it was the standard, but I may indeed be wrong (and will appreciate if that "feature" was removed). --SHB2000 (t | c | m) 09:51, 28 May 2024 (UTC)
- It hasn't been adding the period for me. For hours etc., the template adds periods, but the editor doesn't, and for content (as in the examples), it's up to you to add it. If the editor is to help with that, it should at least check whether the last (non-blank) character already is a period. –LPfi (talk) 10:04, 28 May 2024 (UTC)
- @Jdlrobson: Thanks. For some reason, the beta version wasn't on my radar until now. I've just enabled it. —Granger (talk · contribs) 15:03, 28 May 2024 (UTC)
- While we're on the topic, I'm finding that the "Sync shared fields to/from Wikidata" doesn't seem to work in either version of the editor. When I click the link, nothing happens. I'm using Firefox on a Mac. —Granger (talk · contribs) 15:11, 28 May 2024 (UTC)
- I'm hoping to have a look at this by the end of the week. I'll make sure the "." is no longer added and will investigate the coordinates issue.
- Just to check I fully understand, are these bugs present in both the beta and the normal version or just the beta? Jdlrobson (talk) 02:10, 29 May 2024 (UTC)
- They seem to be present in both versions. —Granger (talk · contribs) 15:01, 29 May 2024 (UTC)
- I can confirm that "Sync shared fields to/from Wikidata" is also broken on my side (desktop, Firefox browser). OhanaUnitedTalk page 15:58, 29 May 2024 (UTC)
- Wikidata sync doesn't work for me either. --Renek78 (talk) 21:38, 29 May 2024 (UTC)
- The beta has a potential fix for Wikidata sync. If you use it, please enable the beta mode and let me know if it's working for you! Thanks in advance! Jdlrobson (talk) 02:21, 2 June 2024 (UTC)
- Thanks for fixing the periods and coordinates! I'm using the beta version, and I'll try syncing with Wikidata next time I have an opportunity. —Granger (talk · contribs) 02:38, 2 June 2024 (UTC)
- Hi Jdlrobson, Wikidata syncing seems to be working in beta mode. —Granger (talk · contribs) 13:33, 5 June 2024 (UTC)
- Okay I'm going to sync the two versions now! Thanks for letting me know! Jdlrobson (talk) 16:15, 7 June 2024 (UTC)
- Hi Jdlrobson, Wikidata syncing seems to be working in beta mode. —Granger (talk · contribs) 13:33, 5 June 2024 (UTC)
- Thanks for fixing the periods and coordinates! I'm using the beta version, and I'll try syncing with Wikidata next time I have an opportunity. —Granger (talk · contribs) 02:38, 2 June 2024 (UTC)
- The beta has a potential fix for Wikidata sync. If you use it, please enable the beta mode and let me know if it's working for you! Thanks in advance! Jdlrobson (talk) 02:21, 2 June 2024 (UTC)
- Wikidata sync doesn't work for me either. --Renek78 (talk) 21:38, 29 May 2024 (UTC)
- I can confirm that "Sync shared fields to/from Wikidata" is also broken on my side (desktop, Firefox browser). OhanaUnitedTalk page 15:58, 29 May 2024 (UTC)
- They seem to be present in both versions. —Granger (talk · contribs) 15:01, 29 May 2024 (UTC)
- While we're on the topic, I'm finding that the "Sync shared fields to/from Wikidata" doesn't seem to work in either version of the editor. When I click the link, nothing happens. I'm using Firefox on a Mac. —Granger (talk · contribs) 15:11, 28 May 2024 (UTC)
- @Jdlrobson: Thanks. For some reason, the beta version wasn't on my radar until now. I've just enabled it. —Granger (talk · contribs) 15:03, 28 May 2024 (UTC)
- It hasn't been adding the period for me. For hours etc., the template adds periods, but the editor doesn't, and for content (as in the examples), it's up to you to add it. If the editor is to help with that, it should at least check whether the last (non-blank) character already is a period. –LPfi (talk) 10:04, 28 May 2024 (UTC)
- I can't speak for the former issue, but the full stop/period issue is something I've known for quite a while – I thought it was the standard, but I may indeed be wrong (and will appreciate if that "feature" was removed). --SHB2000 (t | c | m) 09:51, 28 May 2024 (UTC)
There’s another problem now. For some reason, whenever I add a new listing using the listing editor, the listing appears at the top of the article instead of in the section I was trying to put it in (see my recent edits on Tangshan). STW932 (talk) 16:20, 9 June 2024 (UTC)
- I’ve also noticed that nothing seems to happen when I press the ‘edit’ button for individual listings. Is anyone else experiencing that problem? STW932 (talk) 16:38, 9 June 2024 (UTC)
- Are you using Vector classic, Monobook, Timeless or Modern skin by any chance? Jdlrobson (talk) 20:37, 9 June 2024 (UTC)
- (and if so.. could you see if the bug occurs in Vector 2022? There was an upstream change to MediaWiki that I want to rule out as the source of this bug!) Thanks in advance! Jdlrobson (talk) 20:42, 9 June 2024 (UTC)
- (It should hopefully be fixed now if that was the use case!) Jdlrobson (talk) 21:14, 9 June 2024 (UTC)
- I’m not actually familiar with any of those skins. I’m just using whatever the default settings happen to be on my Safari browser. But the problem is now fixed. Thank you. STW932 (talk) 07:28, 10 June 2024 (UTC)
- (It should hopefully be fixed now if that was the use case!) Jdlrobson (talk) 21:14, 9 June 2024 (UTC)
- (and if so.. could you see if the bug occurs in Vector 2022? There was an upstream change to MediaWiki that I want to rule out as the source of this bug!) Thanks in advance! Jdlrobson (talk) 20:42, 9 June 2024 (UTC)
@Jdlrobson: During my demonstration in today's Toronto meetup, I wasn't able to demonstrate "sync shared fields to/from Wikidata" button in the listing editor to new WV users. It appears to be broken again. On the other hand, the "quick fetch" produced the pop-up box which tells me that the code is partially working. OhanaUnitedTalk page 02:22, 8 July 2024 (UTC)
Enabling the block feature on the abuse filter
[edit]The abuse filter has many wonders, and one of them is the block feature. However, unlike many other wikis, the English Wikivoyage has yet to enable this feature (can only be done if there is community consensus – see phab:T31483 as an example for a wiki smaller than ours).
Like many other wikis, the English Wikivoyage suffers a good deal of LTA activity and I know I'm about to open a can of worms by saying this but...as a matter of fact, we have very few active users between 00:00 and 07:00 UTC. We are a GS wiki, but even then, there aren't that many global sysops or stewards active during this time either. Letting the abuse filter handle the blocks for obvious cases would help this a bit. Ideally, I'd set the default block time to 30 minutes (which is enough time for a sysop to come and review the block), but this can be worked out later.
What's the drawback? Pretty much next to none. Just because there is the option to use the block feature doesn't mean it has to be used, it just makes anti-vandalism slightly easier. As a smaller wiki, the case for using the abuse filter to block is even more than some larger wikis.
--SHB2000 (t | c | m) 11:07, 19 June 2024 (UTC)
- Unless we want to use it without further public discussion we shouldn't enable it. Enabling the feature implicitly more or less approves its use, and regardless, an enabled feature will be used sooner or later.
- Usually false positives can be appealed, and editing articles that don't need the triggering URL (or whatever) can continue straight away. This isn't the case with blocks. Having a short block time (such as the suggested 30 min) limits the damage – given that the editor isn't scared away – but is not without consequences. Thus filters with the block option enabled need to have no or very few false positives. I also hope that we monitor the filter logs closely enough.
- That said, the block option is effective against a user trying ways to get around a filter, such as by varying spellings.
- –LPfi (talk) 14:08, 19 June 2024 (UTC)
- Support. If we want to be extra careful, we can exempt user talk pages from the block, though that will mostly result in a lot of manual deletions. Ikan Kekek (talk) 18:50, 19 June 2024 (UTC)
- Yes, on Meta, we rarely restrict TPA (in the rare case of false positives), but the impacts of a 30-minute block isn't that different to our formal "cooldown" blocks either. (LPfi, FTR, we have to have further public discussion since there must be community consensus to enable this) SHB2000 (t | c | m) 21:35, 19 June 2024 (UTC)
- We need the discussion to enable it, but that's the discussion where we should decide on whether and how to use it. The "we don't need to use it, so we can as well enable it" is not the way to have a good public discussion. And please don't use acronyms like "TPA", which make the discussion hard to follow for the general community. –LPfi (talk) 06:33, 20 June 2024 (UTC)
- Well, I've already made my argument for enabling it, but I'll state it again: there are many LTAs that lurk during times when both local and GSs tend to be occupied with other things (often between 00:00–07:00 UTC). A short (probably 30 minutes) cooldown block is enough to stop the vandalism and enough time for an admin to review the block and that's how the feature is intended to be used. SHB2000 (t | c | m) 10:35, 20 June 2024 (UTC)
- TPA=talk page access, presumably, but means that a user can edit their user talk page. LTAs=long-term abusers (that is, vandals who use one username or IP address after another). I myself don't know what GSs are. Ikan Kekek (talk) 17:56, 20 June 2024 (UTC)
- I'm a 18-year wiki veteran and even I don't know what GS stands for. OhanaUnitedTalk page 18:08, 20 June 2024 (UTC)
- @Ikan Kekek, OhanaUnited: GS means global sysop. I've never actually heard anyone use "global sysop wiki" (only GS wiki), but I think that's because nobody spells m:GSR in full – I'll wikilink the abbreviations next time. --SHB2000 (t | c | m) 21:42, 20 June 2024 (UTC)
- I'm a 18-year wiki veteran and even I don't know what GS stands for. OhanaUnitedTalk page 18:08, 20 June 2024 (UTC)
- TPA=talk page access, presumably, but means that a user can edit their user talk page. LTAs=long-term abusers (that is, vandals who use one username or IP address after another). I myself don't know what GSs are. Ikan Kekek (talk) 17:56, 20 June 2024 (UTC)
- Well, I've already made my argument for enabling it, but I'll state it again: there are many LTAs that lurk during times when both local and GSs tend to be occupied with other things (often between 00:00–07:00 UTC). A short (probably 30 minutes) cooldown block is enough to stop the vandalism and enough time for an admin to review the block and that's how the feature is intended to be used. SHB2000 (t | c | m) 10:35, 20 June 2024 (UTC)
- We need the discussion to enable it, but that's the discussion where we should decide on whether and how to use it. The "we don't need to use it, so we can as well enable it" is not the way to have a good public discussion. And please don't use acronyms like "TPA", which make the discussion hard to follow for the general community. –LPfi (talk) 06:33, 20 June 2024 (UTC)
- Yes, on Meta, we rarely restrict TPA (in the rare case of false positives), but the impacts of a 30-minute block isn't that different to our formal "cooldown" blocks either. (LPfi, FTR, we have to have further public discussion since there must be community consensus to enable this) SHB2000 (t | c | m) 21:35, 19 June 2024 (UTC)
- Support. If we want to be extra careful, we can exempt user talk pages from the block, though that will mostly result in a lot of manual deletions. Ikan Kekek (talk) 18:50, 19 June 2024 (UTC)
- Support -Lionel Cristiano (talk) 22:46, 19 June 2024 (UTC)
- I think we already have a tendency to be so heavy-handed with blocks that we unnecessarily risk driving good-faith contributors away from the site. I worry enabling this feature could make that tendency worse. We've sometimes had abuse filters with high false positive rates, and it would be very unfortunate for a good-faith contributor to be blocked by an automated process like this. I don't really see the need to enable this, but if we do, I think we need clear guidelines limiting its use. The suggestions above (blocks of no more than 30 minutes, and never restricting talk page access) are a good starting point. Maybe another guideline would be that blocking can only be enabled if an abuse filter has been active for some period of time (six months? a year?) with no false positives, and that no changes can be made to the filter's logic when blocking is enabled. But again, I don't really see the need for this – I often edit between 00:00 and 07:00 UTC, and when I check recent changes I don't notice unmanageable levels of vandalism. —Granger (talk · contribs) 15:14, 20 June 2024 (UTC)
- @Mx. Granger: I actually share your concern about being very heavy-handed with newbies which includes blocking. My main concern is that we do have egregious vandalism from known LTAs that often go on red for a significant amount of time (particularly ACV or BMX) and other wikis such as meta, enwikibooks or enwikinews already do this without significant issues (though I wouldn't follow the enwikinews approach of using indef blocks). I think 1 week with 100% accuracy should suffice, because it takes quite a bit for a new user to trigger the filters that disallow edits. --SHB2000 (t | c | m) 21:54, 20 June 2024 (UTC)
- And ACV and BMX are? Ikan Kekek (talk) 04:28, 21 June 2024 (UTC)
- I'll keep this short per our principle of DENY, but you're probably already familiar with these two LTAs. --SHB2000 (t | c | m) 04:34, 21 June 2024 (UTC)
- Right. Ikan Kekek (talk) 04:48, 21 June 2024 (UTC)
- I'm still in the midst of creating a draft proposal, but just to highlight another case of admins being very inactive at certain times, ACV was out and about for 30 minutes (their edits were reverted by Leaderboard, but they aren't a GS or a steward) before they were finally locked. Would have helped had an edit filter blocked them. --SHB2000 (t | c | m) 09:39, 23 June 2024 (UTC)
- Right. Ikan Kekek (talk) 04:48, 21 June 2024 (UTC)
- I'll keep this short per our principle of DENY, but you're probably already familiar with these two LTAs. --SHB2000 (t | c | m) 04:34, 21 June 2024 (UTC)
- How flexible are the block options in the filters? Do you have access to all options you can choose for a manual block? I assume the filter edit restriction would require changes to the software, so we will have somebody do a silly typo now and then, when they think they are doing some innocent tweak.
- A week of checking the filter log does not help much. It helps against typos that catch a lot of innocent edits, but it doesn't prevent the Scunthorpe problem. Instead, the logs need to be monitored, so that any false positive gets addressed, both in correcting the filter and in explaining for the unlucky user.
- –LPfi (talk) 06:16, 21 June 2024 (UTC)
- And ACV and BMX are? Ikan Kekek (talk) 04:28, 21 June 2024 (UTC)
- @Mx. Granger: I actually share your concern about being very heavy-handed with newbies which includes blocking. My main concern is that we do have egregious vandalism from known LTAs that often go on red for a significant amount of time (particularly ACV or BMX) and other wikis such as meta, enwikibooks or enwikinews already do this without significant issues (though I wouldn't follow the enwikinews approach of using indef blocks). I think 1 week with 100% accuracy should suffice, because it takes quite a bit for a new user to trigger the filters that disallow edits. --SHB2000 (t | c | m) 21:54, 20 June 2024 (UTC)
Reviving this old discussion, after some thought, how about adding the following on Wikivoyage:Abuse filters (if we're all good with this compromise/wording)?
Since July 2024, the English Wikivoyage has opted in to use the "block" feature on abuse filters. Despite the ability to use the "block" feature, it should primarily be used as a last-resort. Blocks by default are 30 minutes with email and talk-page access open and the description of the block clearly stated. Any filter with longer or more restrictive block settings must be discussed with clear community consensus before being implemented. Additionally, before using the block feature, a filter must have a clear history of 15 hits and be in use for 1 week of having no false positives (unless the filter was imported from another wiki where it has been similarly successful, in which case, the block feature may be used without discussion).
Does this sound good with everyone? @Ikan Kekek, Lionel Cristiano, LPfi, Mx. Granger, OhanaUnited: --SHB2000 (t | c | m) 02:27, 4 July 2024 (UTC)
- I never used abuse filters so I can't comment on its suitability and scope. OhanaUnitedTalk page 05:39, 4 July 2024 (UTC)
- That's understandable. --SHB2000 (t | c | m) 05:52, 4 July 2024 (UTC)
- This sounds sensible, though I think you can't always discuss filters (even in the context of deciding block durations) with non-admins. Leaderboard (talk) 09:20, 4 July 2024 (UTC)
- I think we should not leave the option of longer or more severe blocking. If the need turns up we can change the guideline after that discussion with clear community consensus (I don't see the need as of now). If we need flexibility, then replace "by default" by "at most"
- I would also want some guarantee that the abuse logs get monitored well-enough to quickly note false positives. I myself mostly forget to check them. Should we introduce a page that should have an entry every week from somebody who have done the checking (entries every time may tell vandals too much)?
- I also think that enabling a block on some filter need to be told explicitly in the filter notes, to ease following up the use.
- –LPfi (talk) 10:55, 4 July 2024 (UTC)
- I agree with LPfi's points, especially about the "by default" language. I also think 1 week and 15 hits are not enough to achieve a low enough risk of false-positive blocks. A false-positive block is a severe cost, as it can very easily drive away a good-faith user. I would suggest this should "only" (not "primarily") be used as a last resort, but even that is a little vague – a last resort against what? I disagree with the idea of giving carte blanche for "similarly successful" filters from other wikis. Different wikis have different types of content, and it's easy to imagine a filter that never gets false positives on, say, Wiktionary or Wikispecies might get false positives here. I also think we should specify that changes to the filter's logic cannot be made if blocking functionality is enabled, to avoid the risk of accidentally making false positives more likely. In general I don't see the benefits as outweighing the costs here.
- It might help if the supporters of this proposal could give examples of what filters they want to use this for. That might help convince us skeptics of the value of the proposal, and could help us work together to craft a version of the policy that allows those use cases while limiting the risk of problems. —Granger (talk · contribs) 01:04, 5 July 2024 (UTC)
- ...without revealing too much here, think filter 52 as an example (0 false positives so far, FTR). SHB2000 (t | c | m) 05:04, 5 July 2024 (UTC)
- The obvious issue is a long-term vandal who tries how to get around our filters. It is not unusual with several tries in a short timeframe. If they got their IP address blocked with each try, they might soon run out of addresses (assuming range blocks for IPv6 addresses – range discussions should probably be held in secret, trusting admins to keep them reasonable). –LPfi (talk) 08:20, 5 July 2024 (UTC)
- I agree with a new trial period after a filter change. It can be done through testing the filter on edits already made, so no waiting period necessarily needed. I don't think whether to test a few days, a week or more is essential: typos like matching the empty string are caught with a short test, while the Scunthorpe problem typically turns up unexpectedly even after very long testing periods (there: when the internet domain name was taken into use). What's essential is to do the changes carefully, with full understanding of how the filter works and with some peer review – and to catch the false positives quickly. –LPfi (talk) 08:33, 5 July 2024 (UTC)
- ...without revealing too much here, think filter 52 as an example (0 false positives so far, FTR). SHB2000 (t | c | m) 05:04, 5 July 2024 (UTC)
RFC: When should we use Huge city templates?
[edit]Over at Wikivoyage talk:Geographical hierarchy#"Huge cities" that are actually rural areas, ChubbyWimbus and I have been having an extended debate on when "huge city" templates should be applied. To mildly caricature, CW's opinion is that we should use them for anything called a city even when it looks like this, whereas I'm of the equally firm opinion that if it's not a big gray blob on a satellite image, it's not an actual Huge City.
I have proposed the following strawman as a Wikivoyage guideline: A huge city should be a single cohesive whole from the traveller's point of view. Administrative "cities" spanning thousands of square kilometers, with multiple disconnected urban areas, are better off as regions. If you have thoughts either way, please chime in: → Wikivoyage talk:Geographical hierarchy#"Huge cities" that are actually rural areas Jpatokal (talk) 00:46, 24 June 2024 (UTC)
- I agree with the general sentiment, but then again, there are also areas with multiple cities forming a contiguous urban area. Malaysia's Klang Valley is an example, where the capital Kuala Lumpur is located, is an example. And you can argue that Tokyo-Osaka is one single urban area. The dog2 (talk) 02:08, 24 June 2024 (UTC)
- True, and these contiguous urban areas are not necessarily large. For instance, the county seat of Yulong forms a contiguous urban area with Lijiang's Gucheng District. Hence I have argued against having a separate article for Yulong (See Talk:Yulong). STW932 (talk) 06:57, 11 July 2024 (UTC)
- This reminds me of some of the discussions that have been had in relation to China's prefecture-level cities (most of which are what you call 'administrative cities'). See especially Talk:Fuzhou and Talk:Suzhou. Personally I prefer the Jiangmen model whereby all the administrative divisions of the city are kept together in a single region (and are not put together with the administrative divisions of other prefecture-level cities). User: Pashley, however, has strongly argued in favour of the status quo for both Fuzhou and Suzhou. STW932 (talk) 04:26, 24 June 2024 (UTC)
- That discussion died a month a go – some revival would be good. --SHB2000 (t | c | m) 12:04, 24 June 2024 (UTC)
- See also Wikivoyage:Travellers' pub#When should the "Huge city" template be used? above. It appears that using the word city in the template name is distracting editors. I still believe that renaming these would help resolve these disputes. Perhaps city becomes destination? And huge becomes high-content (because huge is meant to be a measure of how much content we have, not how many people live at the destination or how many square kilometers the destination claims)?
- I wonder whether the problem here is not whether Template:Hugecity skeleton or Template:Ruralarea skeleton was chosen. The difference between the two is just whether you need ==Districts==, ==Learn==, ==Work==, or ==Cope==, and any article can have those added or removed as needed. I wonder if the issue might more specifically sound like "I don't want the article title to be Miyoshi (Tokushima)/Ikeda. I want the article title to be Ikeda (Tokushima) instead." WhatamIdoing (talk) 15:07, 24 June 2024 (UTC)
- I'm getting similar feelings too. The latter title is better for SEO purposes, but that delves into a whole new question of how we want to name our city districts. (FWIW, frwikivoyage and itwikivoyage abandoned this naming structure a long time ago) --SHB2000 (t | c | m) 22:01, 24 June 2024 (UTC)
- I think "high-content destination" sounds reasonable. That's the point of having districts. While all current "huge cities" are cities, I don't see there being any major problems in rural areas, parks or dive sites getting districts if an active editor wants to create (useful) such sub-articles – the probability of which I feel is mostly low.
- Such a naming change would solve one out of three issues, the others being the mentioned district article titles and the text created by the templates (where "high-content destination" also fits). I think the three are mostly independent.
- –LPfi (talk) 07:01, 25 June 2024 (UTC)
- (SHB2000, do we really care whether anything in the Template: namespace has favorable SEO qualities?) WhatamIdoing (talk) 21:05, 25 June 2024 (UTC)
- @WhatamIdoing: When I was referring to SEO, I'm talking about how a title like, say East Amsterdam would be favorable over Amsterdam/East. --SHB2000 (t | c | m) 21:34, 25 June 2024 (UTC)
- I understand now. I agree with you. WhatamIdoing (talk) 03:48, 27 June 2024 (UTC)
- Glad we're on the same page. --SHB2000 (t | c | m) 04:01, 27 June 2024 (UTC)
- I understand now. I agree with you. WhatamIdoing (talk) 03:48, 27 June 2024 (UTC)
- @WhatamIdoing: When I was referring to SEO, I'm talking about how a title like, say East Amsterdam would be favorable over Amsterdam/East. --SHB2000 (t | c | m) 21:34, 25 June 2024 (UTC)
- I'm getting similar feelings too. The latter title is better for SEO purposes, but that delves into a whole new question of how we want to name our city districts. (FWIW, frwikivoyage and itwikivoyage abandoned this naming structure a long time ago) --SHB2000 (t | c | m) 22:01, 24 June 2024 (UTC)
(undent) I've never been a fan of the City/District naming convention and in my earlier poking around was unable to find a convincing justification for why we needed them in the first place. Any thoughts? If none can be found, I'd be up for following fr/it's lead and abandoning them entirely. Jpatokal (talk) 22:32, 25 June 2024 (UTC)
- The format enables some automatic features (as the software can see them as sub-articles), but I assume any needed functionality can be had through normal links and templates. The format may affect statistics, but that is hardly important.
- One thing is common names: "Somecity/North" may get a less elegant name also without the dash, such as "Somecity's north" or "North (Somecity)". In the search box, you get all the districts when looking for Somecity/, while for other name forms you don't, but that should mean just one click and a few seconds more.
- –LPfi (talk) 06:28, 26 June 2024 (UTC)
- I support changing this convention. In some cases even fairly generic names would become more elegant (I'd be happy renaming Shenzhen/West to Western Shenzhen). Even when we still need a parenthetical disambiguator, I think "District (City)" is easier to understand for most readers than "City/District". For instance I'd guess SoHo (Manhattan) and Soho (London) would be more intuitive for most readers than the current Manhattan/SoHo and London/Soho.
- For "Somecity/North" type districts, some care is needed to choose the most idiomatic title with the new convention – "North Somecity", "Northern Somecity", "North (Somecity)", etc. For Boston/Downtown, Downtown Boston is probably a better title than Downtown (Boston). If we do make this change, we should keep redirects from the old titles, to avoid breaking incoming links from other websites. —Granger (talk · contribs) 03:06, 27 June 2024 (UTC)
- I'm positively surprised to see the level of support here: do we have anybody opposed? Regarding naming, I don't think the X/North problem is a big deal in practice, most of those can be turned into simply "North X" and we've already got a lot of belt-and-suspenders redundant names like Canberra/North Canberra. IMHO parentheses should be avoided unless absolutely necessary, eg. for the Sohos there's probably no way out since "London Soho" sounds terrible. Jpatokal (talk) 03:29, 28 June 2024 (UTC)
- I'm not a fan. It's a lot of work for very little (if any) benefit. And it might break things we aren't thinking of right now. And the proposal is buried in a thread that started off about a different proposal. Powers (talk) 22:47, 29 June 2024 (UTC)
- I'm positively surprised to see the level of support here: do we have anybody opposed? Regarding naming, I don't think the X/North problem is a big deal in practice, most of those can be turned into simply "North X" and we've already got a lot of belt-and-suspenders redundant names like Canberra/North Canberra. IMHO parentheses should be avoided unless absolutely necessary, eg. for the Sohos there's probably no way out since "London Soho" sounds terrible. Jpatokal (talk) 03:29, 28 June 2024 (UTC)
As mentioned above, the huge city/high-content destination article template is chosen based on the amount of content and not on the basis of the physical size of the city/destination. It seems to me therefore that the region template may be ideal for cities/destinations that cover a very large geographical space but do not have enough content to be considered huge cities or high-content destinations. STW932 (talk) 06:12, 11 July 2024 (UTC)
On a side note, I find it somewhat curious that Wikivoyage:Geographical hierarchy cites Lubbock as an example of a city that is geographically large but lacking sufficient content to be considered a huge city (or high-content destination). Lubbock only has an area of 324 km². There are many ‘low-content’ cities that are much larger than that, for example Hulunbuir (in Eastern Inner Mongolia) covers an area of approximately 253,000 km² and Ordos City has a an area of about 87,000 km². Interestingly, Hulunbuir is treated as a region whereas Ordos is treated as a city. STW932 (talk) 06:12, 11 July 2024 (UTC)
- It is common on Wikivoyage to include the surrounding countryside in the scope of a city article. Ordos City is oddly named, but a region article would require splitting the article up, and with population centres with 100,000+ inhabitants, this is hardly well handled as a "rural area". –LPfi (talk) 10:41, 11 July 2024 (UTC)
- I support renaming City/District articles to "District (City)" "North City" or whatever is more appropriate and used by the rest of the world apart from Wikivoyage currently. The unintuitive things we do here, such as having our own district naming system not used anywhere else, hamper our growth for the purposes of SEO and acquiring new editors and readers who can get confused by our quirks and intricacies. Gizza (roam) 00:00, 15 July 2024 (UTC)
- I don't think that works well if you're searching for an article. If you want North London and you put "London" in the search box, you'll see London but not the page that is currently titled (and appearing in that search as) London/North. If we make this change, and you put "North" in the search box, you'll get a list that includes North Baltimore, North Beach (Miami Beach), North Canberra, North Central Rome, North Dallas, North East Leeds, North-East Brussels, North Edmonton, North Jakarta, North Hyderabad, North Lincoln (Chicago), and more, and you'll have no idea whether you can't find North London in the list because we don't have a separate article for it, or if you just haven't found it in the list yet. There are 500+ pages with "North" in the name, and almost a hundred of them are subpages titled "North" that could be affected by this.
- I don't mind the subpage style, but if we change it, we should keep the "big endian" style. That means that everything in London needs to have London as the first word, and the qualifiers come second. At the moment, that means London/North, but if we want to copy Wikipedia's love for parenthetical disambiguation, then we could try London (North). North London is just impractical for readers and editors who are looking for articles about a high-content destination. WhatamIdoing (talk) 18:27, 15 July 2024 (UTC)
- I oppose the switch. Subpage style makes it easier to expand and add more pages in a city or region the future (and we know some huge cities have gaps that need to be filled in in the future). OhanaUnitedTalk page 19:40, 15 July 2024 (UTC)
- @OhanaUnited: I don't understand what you mean. How does using a title like "London/North" as opposed to "North London" make it easier to add more pages in the future? —Granger (talk · contribs) 13:23, 16 July 2024 (UTC)
- For the record, the French and Italian Wikivoyages abolished the style we use years ago and have had no issues with adding new districts – if anything I think it's better for the sake of search engine optimization. SHB2000 (t | c | m) 12:50, 17 July 2024 (UTC)
- @OhanaUnited: I don't understand what you mean. How does using a title like "London/North" as opposed to "North London" make it easier to add more pages in the future? —Granger (talk · contribs) 13:23, 16 July 2024 (UTC)
- I oppose the switch. Subpage style makes it easier to expand and add more pages in a city or region the future (and we know some huge cities have gaps that need to be filled in in the future). OhanaUnitedTalk page 19:40, 15 July 2024 (UTC)
- I support renaming City/District articles to "District (City)" "North City" or whatever is more appropriate and used by the rest of the world apart from Wikivoyage currently. The unintuitive things we do here, such as having our own district naming system not used anywhere else, hamper our growth for the purposes of SEO and acquiring new editors and readers who can get confused by our quirks and intricacies. Gizza (roam) 00:00, 15 July 2024 (UTC)
- Basically, I agree with @Jpatokal:. If it is not actually a huge city (to me, a cohesive urban area with population over 10 million), then we should not call it one. Should we rename the template to "City with districts" or some such. e.g. I would not call Toronto "huge" (6 million or so) but it has districts & certainly needs them. Pashley (talk) 16:13, 17 July 2024 (UTC)
- The only problem with "City with districts" is that the same thought process that leads to "the city itself is not really huge, so we can't use the
huge city template
– that's only for places like Tokyo and Delhi" will, if we rename to "City with districts" reappear as "that destination has districts, but it's not really a city, so we can't use thecity with districts template
". - I suggest preventing all such future discussions by calling it a destination instead of a city. This could be "destination with districts" or a "high-content destination". WhatamIdoing (talk) 17:25, 17 July 2024 (UTC)
- I was going to agree with you then, but then I realized that technically parks are also "destinations" (though then again, how many parks with districts do we have?). --SHB2000 (t | c | m) 22:39, 17 July 2024 (UTC)
- We're really spending all of this time arguing about Wikivoyage nomenclature? Why does it matter what we call it? Ikan Kekek (talk) 22:43, 17 July 2024 (UTC)
- It matters because contributors (not readers) are finding the nomenclature confusing, and then incorrectly believe that other contributors are making mistakes because they have used the "wrong" format. WhatamIdoing (talk) 19:29, 18 July 2024 (UTC)
- Yes. And I think "high-content destination" makes obvious what kinds of articles we are talking about. The question about what text to use at the top of the page (the content of the template) and what destinations should have districts and what destinations should be regions are separate from this. For the text, I don't think we should mention the template name or indeed say anything about why the place has districts, just say that it is divided into district articles (and that listings are to be found there). For the region vs. huge city/high-content destination, we haven't had that discussion yet, but we might need to have it. –LPfi (talk) 06:52, 22 July 2024 (UTC)
- "High-content destination" is a wishy-washy term that sounds like bureaucrat-ese. At least "huge city" is UNDERSTANDABLE to casual readers. It is a '''MUCH''' better phrase than the pompous sounding, nebulous "high-content destination". Mrkstvns (talk) 18:08, 22 July 2024 (UTC)
- Whatever we call the template, the name should never be seen by casual readers. And calling some of our "huge cities" huge is simply a lie, which we shouldn't tell up front in the article. –LPfi (talk) 18:36, 22 July 2024 (UTC)
- Something that seems understandable but actually means something else is no good. It is better to have a wishy-washy term than a misleading one. If the suggested one is too bureaucratese-sounding, then we should of course try to find a better one, but not one that perpetuates the problem. –LPfi (talk) 18:43, 22 July 2024 (UTC)
- "High-content destination" is a wishy-washy term that sounds like bureaucrat-ese. At least "huge city" is UNDERSTANDABLE to casual readers. It is a '''MUCH''' better phrase than the pompous sounding, nebulous "high-content destination". Mrkstvns (talk) 18:08, 22 July 2024 (UTC)
- Yes. And I think "high-content destination" makes obvious what kinds of articles we are talking about. The question about what text to use at the top of the page (the content of the template) and what destinations should have districts and what destinations should be regions are separate from this. For the text, I don't think we should mention the template name or indeed say anything about why the place has districts, just say that it is divided into district articles (and that listings are to be found there). For the region vs. huge city/high-content destination, we haven't had that discussion yet, but we might need to have it. –LPfi (talk) 06:52, 22 July 2024 (UTC)
- It matters because contributors (not readers) are finding the nomenclature confusing, and then incorrectly believe that other contributors are making mistakes because they have used the "wrong" format. WhatamIdoing (talk) 19:29, 18 July 2024 (UTC)
- We're really spending all of this time arguing about Wikivoyage nomenclature? Why does it matter what we call it? Ikan Kekek (talk) 22:43, 17 July 2024 (UTC)
- I was going to agree with you then, but then I realized that technically parks are also "destinations" (though then again, how many parks with districts do we have?). --SHB2000 (t | c | m) 22:39, 17 July 2024 (UTC)
- The only problem with "City with districts" is that the same thought process that leads to "the city itself is not really huge, so we can't use the
Free SVG Vector City Maps for all (CC-0 license)
[edit]Hello there))) Published vector maps of my production on WIKIMEDIA Maps of cities (streets, roads, water bodies), names - only cities and districts, road signboards.
LIST OF THE FREE CITY MAPS in SVG EDITABLE
https://commons.wikimedia.org/wiki/File:Aarhus_Denmark_Street_Map_vector_svg_free.svg
https://commons.wikimedia.org/wiki/File:Adelaide_Australia_Street_Map_SVG_free.svg
https://commons.wikimedia.org/wiki/File:Albany_New_York_US_Street_Map.svg
https://commons.wikimedia.org/wiki/File:Albuquerque_New_Mexico_US_Street_Map_SVG.svg
https://commons.wikimedia.org/wiki/File:Allentown_and_Easton_Pennsylvania_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Amsterdam_Netherlands_street_map.svg
https://commons.wikimedia.org/wiki/File:Antwerpen_Belgium_street_map.svg
https://commons.wikimedia.org/wiki/File:Athens_Greece_street_map_vector_gvl13_svg_free.svg
https://commons.wikimedia.org/wiki/File:Auburn_and_Lewiston_Maine_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Auckland_New_Zealand_street_map.svg
https://commons.wikimedia.org/wiki/File:Austin_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Baku_Azerbaijan_street_map.svg
https://commons.wikimedia.org/wiki/File:Baltimore_Maryland_US_Street_map.svg
https://commons.wikimedia.org/wiki/File:Bangkok_Thailand_street_map.svg
https://commons.wikimedia.org/wiki/File:Basel_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Baton_Rouge_Louisiana_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Beijing_China_street_map.svg
https://commons.wikimedia.org/wiki/File:Belfast_Northern_Ireland_UK_street_map.svg
https://commons.wikimedia.org/wiki/File:Berlin_Germany_street_map.svg
https://commons.wikimedia.org/wiki/File:Bern_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Bismarck_North_Dakota_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Boston_Center_Massachusetts_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Boston_Massachusetts_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Boston_Massachusetts_US_Metro_Area_street_road_map.svg
https://commons.wikimedia.org/wiki/File:Brisbane_Australia_street_map.svg
https://commons.wikimedia.org/wiki/File:Burlington_Vermont_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Calgary_Alberta_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Canberra_Australia_street_map.svg
https://commons.wikimedia.org/wiki/File:Charleston_South_Carolina_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Chicago_Illinois_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Cincinnati_Ohio_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Cleveland_Ohio_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Cologne_Germany_street_map.svg
https://commons.wikimedia.org/wiki/File:Columbus_Ohio_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Copenhagen_Denmark_street_map.svg
https://commons.wikimedia.org/wiki/File:Dallas_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Darmstadt_Germany_street_map.svg
https://commons.wikimedia.org/wiki/File:Dayton_and_Springfield_Ohio_US_street_road_map.svg
https://commons.wikimedia.org/wiki/File:Delhi_India_street_map.svg
https://commons.wikimedia.org/wiki/File:Delray_Beach_Florida_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Denver_and_Boulder_Colorado_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Detroit_Michigan_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Dresden_Germany_street_map.svg
https://commons.wikimedia.org/wiki/File:Dublin_Ireland_street_map.svg
https://commons.wikimedia.org/wiki/File:Edmonton_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Essen_Germany_street_map.svg
https://commons.wikimedia.org/wiki/File:Fargo_North_Dakota_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Fort_Worth_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Fresno_California_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Gatineau_Quebec_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Gisborne_New_Zealand_street_map.svg
https://commons.wikimedia.org/wiki/File:Hawaii_US_road_map.svg
https://commons.wikimedia.org/wiki/File:Heathrow_Airport_London_UK_street_road_map.svg
https://commons.wikimedia.org/wiki/File:Helsinki_Espoo_Vantaa_Finland_street_map.svg
https://commons.wikimedia.org/wiki/File:Hong_Kong_China_street_map.svg
https://commons.wikimedia.org/wiki/File:Honolulu_Hawaii_US_street_road_map.svg
https://commons.wikimedia.org/wiki/File:Houston_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Iceland_road_map.svg
https://commons.wikimedia.org/wiki/File:Indianapolis_Indiana_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Islamabad_and_Rawalpindi_Pakistan_street_map.svg
https://commons.wikimedia.org/wiki/File:Istanbul_Turkey_street_map.svg
https://commons.wikimedia.org/wiki/File:Jakarta_Indonesia_street_map.svg
https://commons.wikimedia.org/wiki/File:Kansas_City_Missouri_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Karachi_Pakistan_street_map.svg
https://commons.wikimedia.org/wiki/File:Kelowna_British_Columbia_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Kemi_and_Tornio_Finland_street_map.svg
https://commons.wikimedia.org/wiki/File:Kiev_Ukraine_street_map.svg
https://commons.wikimedia.org/wiki/File:Kuala_Lumpur_Malaysia_street_map.svg
https://commons.wikimedia.org/wiki/File:Kyoto_Japan_street_map.svg
https://commons.wikimedia.org/wiki/File:La_Paz_and_El_Alto_Bolivia_street_map.svg
https://commons.wikimedia.org/wiki/File:Lahore_Pakistan_street_map.svg
https://commons.wikimedia.org/wiki/File:Lakewood_Ohio_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Lancaster_Pennsylvania_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Las_Vegas_Nevada_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Lausanne_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Laval_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Liege_Belgium_street_map.svg
https://commons.wikimedia.org/wiki/File:Lille_France_street_map.svg
https://commons.wikimedia.org/wiki/File:Lincoln_Nebraska_US_street_map.svg
https://commons.wikimedia.org/wiki/File:London_Center_UK_street_map.svg
https://commons.wikimedia.org/wiki/File:London_Greater_UK_street_map.svg
https://commons.wikimedia.org/wiki/File:Los_Angeles_California_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Louisville_Kentucky_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Lugano_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Luxembourg_street_map.svg
https://commons.wikimedia.org/wiki/File:Luzern_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Lviv_Ukraine_street_map.svg
https://commons.wikimedia.org/wiki/File:Lyon_France_street_map.svg
https://commons.wikimedia.org/wiki/File:Macon_Georgia_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Manila_Philippines_street_map.svg
https://commons.wikimedia.org/wiki/File:Martha's_Vineyard_Massachusetts_US_street_road_map.svg
https://commons.wikimedia.org/wiki/File:Mashhad_Iran_street_map.svg
https://commons.wikimedia.org/wiki/File:Medellin_Colombia_street_map.svg
https://commons.wikimedia.org/wiki/File:Melbourne_Australia_street_map.svg
https://commons.wikimedia.org/wiki/File:Memphis_Tennessee_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Mexico_City_Mexico_street_map.svg
https://commons.wikimedia.org/wiki/File:Miami_Florida_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Milwaukee_Wisconsin_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Minneapolis_and_Sent_Paul_Minnesota_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Minsk_Belarus_street_map.svg
https://commons.wikimedia.org/wiki/File:Montpelier_Vermont_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Montreal_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Moscow_Russia_street_map.svg
https://commons.wikimedia.org/wiki/File:Mountain_View_California_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Napier_New_Zealand_street_map.svg
https://commons.wikimedia.org/wiki/File:New_Braunfels_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:New_Orleans_Louisiana_US_street_map.svg
https://commons.wikimedia.org/wiki/File:New_York_City_Greater_NY_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Olympia_Washington_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Orlando_Florida_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Osaka_Japan_street_map.svg
https://commons.wikimedia.org/wiki/File:Ottawa_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Paris_France_street_map.svg
https://commons.wikimedia.org/wiki/File:Perth_Australia_street_map.svg
https://commons.wikimedia.org/wiki/File:Philadelphia_Pennsylvania_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Phoenix_Arizona_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Pierre_South_Dakota_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Pittsburgh_Pennsylvania_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Port_Arthur_Texas_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Portland_Maine_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Portland_Oregon_and_Vancouver_Washington_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Porto_Portugal_street_map.svg
https://commons.wikimedia.org/wiki/File:Prague_Czech_Republic_street_map.svg
https://commons.wikimedia.org/wiki/File:Quebec_City_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Reading_Pennsylvania_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Reno_Nevada_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Reykjavik_Iceland_street_map.svg
https://commons.wikimedia.org/wiki/File:Richmond_Virginia_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Rio_de_Janeiro_Brazil_street_map.svg
https://commons.wikimedia.org/wiki/File:Rome_Italy_street_map.svg
https://commons.wikimedia.org/wiki/File:Rotterdam_Netherlands_street_map.svg
https://commons.wikimedia.org/wiki/File:Sacramento_California_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Saint_Petersburg_Russia_street_map.svg
https://commons.wikimedia.org/wiki/File:Salem_Oregon_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Salt_Lake_City_Utah_US_street_map.svg
https://commons.wikimedia.org/wiki/File:San_Francisco_and_Oakland_California_US_street_map.svg
https://commons.wikimedia.org/wiki/File:San_Juan_Puerto_Rico_street_map.svg
https://commons.wikimedia.org/wiki/File:São_Paulo_Brazil_street_map.svg
https://commons.wikimedia.org/wiki/File:Seattle_and_Bellevue_Washington_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Shanghai_China_street_map.svg
https://commons.wikimedia.org/wiki/File:Sioux_Falls_South_Dakota_US_street_map.svg
https://commons.wikimedia.org/wiki/File:St._Gallen_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Sydney_Australia_street_map.svg
https://commons.wikimedia.org/wiki/File:Tampa_Bay_Florida_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Tampere_Finland_street_map.svg
https://commons.wikimedia.org/wiki/File:Tauranga_New_Zealand_street_map.svg
https://commons.wikimedia.org/wiki/File:Tehran_Iran_street_map.svg
https://commons.wikimedia.org/wiki/File:Tel_Aviv_Yafo_Israel_street_map.svg
https://commons.wikimedia.org/wiki/File:Tokyo_Japan_street_map.svg
https://commons.wikimedia.org/wiki/File:Toronto_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Tulsa_Oklahoma_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Turku_Finland_street_map.svg
https://commons.wikimedia.org/wiki/File:Vancouver_Canada_street_map.svg
https://commons.wikimedia.org/wiki/File:Warsaw_Poland_street_map.svg
https://commons.wikimedia.org/wiki/File:Washington_DC_and_Baltimore_MD_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Washington_DC_US_street_map.svg
https://commons.wikimedia.org/wiki/File:Wellington_New_Zealand_street_map.svg
https://commons.wikimedia.org/wiki/File:Winterthur_Switzerland_street_map.svg
https://commons.wikimedia.org/wiki/File:Yokohama_Japan_street_map.svg
https://commons.wikimedia.org/wiki/File:Zurich_Switzerland_street_map.svg
Only SVG is listed here In all other formats - Illustrator, PDF, in layers - HERE: free vector city maps in Illustrator and PDF
Vectormapper (talk) 23:51, 27 June 2024 (UTC)
- Perhaps you will be interested.
- I tried to publish my maps in regular Wikipedia, in an article about cities. City maps were instantly demolished.
- Short:
- 1. I'm bad because I have a nickname that speaks about my profession.
- 2. I'm bad because my maps have a tiny signature of my logo.
- 3. I'm bad because on my user page it says what I do - cartography. And it’s not written that I love cats and scuba diving.
- 4. Free vector maps of cities are not needed in articles about cities, because (sorry, I can’t think of a reason for this), and also because “most users don’t need them.”
- Vectormapper (talk) 02:55, 28 June 2024 (UTC)
- @Vectormapper: These are some great maps and with some modification, I can see how this would be of great use to travellers. One thing, though: are you able to remove the watermarks? --SHB2000 (t | c | m) 04:43, 28 June 2024 (UTC)
- This is a vector SVG file, it can be easily edited in any vector editor - Illustrator, Corel, Inkscape))) In two clicks you can delete my logo (signature) Vectormapper (talk) 05:13, 28 June 2024 (UTC)
- Sure. If you don't mind me asking, what application did you use to create these maps? --SHB2000 (t | c | m) 08:49, 30 June 2024 (UTC)
- Adobe Illustrator Vectormapper (talk) 18:04, 30 June 2024 (UTC)
- Sure. If you don't mind me asking, what application did you use to create these maps? --SHB2000 (t | c | m) 08:49, 30 June 2024 (UTC)
- This is a vector SVG file, it can be easily edited in any vector editor - Illustrator, Corel, Inkscape))) In two clicks you can delete my logo (signature) Vectormapper (talk) 05:13, 28 June 2024 (UTC)
- These maps look very cool and I've been looking for an excuse to dive into creating maps (like district maps for some of our cities). I can use one of these files as a starting point on my learning trail.....thanks! Mrkstvns (talk) 15:49, 28 June 2024 (UTC)
- Thank you for your kind words. I am very glad that my cards were useful to you Vectormapper (talk) 18:16, 28 June 2024 (UTC)
- I'm so glad you are here. We really need more people who understand maps.
- You might also be interested in these pages, too:
- For these pages and their talk pages (separately), if you look in the "More" menu, you should see a "Subscribe" link. If you click that, any time someone posts a signed comment on these pages, you'll get a notification, even if you're at Wikipedia instead of here. WhatamIdoing (talk) 04:58, 30 June 2024 (UTC)
- Thanks))) It's so interesting))) I hope, I can help somebody with maps))) Vectormapper (talk) 05:35, 30 June 2024 (UTC)
- I went to this link Wikivoyage:Requests for maps - I have almost all of these cards that are requested here in more or less finished form. Something is ready and published on Wikimedia (for example, Zurich, Canberra, Edmonton). I did not understand how to answer the request on this page. My answer should probably just be a link to a Wikimedia-published map of a city or region? But there is no "reply" button on the page? Or did I misunderstand something? Vectormapper (talk) 05:51, 30 June 2024 (UTC)
- It looks like most of the requests are unsigned. Feel free to use the [Edit] or [Edit source] button for each section. You'll have to manually add a signature by typing
~~~~
at the end of your message. - Or (I think) you can add the maps directly to the listed articles, and then remove the request from the page. WhatamIdoing (talk) 22:40, 30 June 2024 (UTC)
- Hmmm I will try Vectormapper (talk) 02:48, 1 July 2024 (UTC)
- It looks like most of the requests are unsigned. Feel free to use the [Edit] or [Edit source] button for each section. You'll have to manually add a signature by typing
- Thank you for your kind words. I am very glad that my cards were useful to you Vectormapper (talk) 18:16, 28 June 2024 (UTC)
- @Vectormapper: These are some great maps and with some modification, I can see how this would be of great use to travellers. One thing, though: are you able to remove the watermarks? --SHB2000 (t | c | m) 04:43, 28 June 2024 (UTC)
- https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg Vectormapper (talk) 21:35, 28 June 2024 (UTC)
- Saint Petersburg, Russia street map https://commons.wikimedia.org/wiki/File:Saint_Petersburg_Russia_street_map.svg Vectormapper (talk) 05:31, 3 July 2024 (UTC)
Banner images
[edit]Hi. I'm new to Wikivoyage and have a quick question: is consensus required to change the banner image of an article, or can I simply change the value of the property on Wikidata? Thanks. '''[[User:CanonNi]]''' (talk • contribs) 00:50, 29 June 2024 (UTC)
- I'm glad you asked. Yes, the procedure is to propose a new pagebanner on the relevant article's talk page and see how discussion goes. Of course, if there's no existing pagebanner, please add one! Ikan Kekek (talk) 01:03, 29 June 2024 (UTC)
- I understand. Thanks for the quick reply! '''[[User:CanonNi]]''' (talk • contribs) 01:10, 29 June 2024 (UTC)
- Is it typical for an editor to change the property on Wikidata? I would never have thought to change a banner that way, I simply edit the first line of the topic (which typically pagebanner....)
- What do most of y'all do? Any reason to do anything with wikidata? Mrkstvns (talk) 05:05, 30 June 2024 (UTC)
- No, I don't think so. I understand that whatever pagebanner image is at Wikidata is the pagebanner by default for every language version of Wikivoyage, unless overriden locally. I don't think we should try to control what happens at other Wikivoyages. Ikan Kekek (talk) 05:15, 30 June 2024 (UTC)
- If I am adding a banner for the first time, I usually also add it to Wikidata, so it is available for other languages. If I am changing a banner after a discussion, I am more sparing in changing it on Wikidata. I will change the WD value if there is a problem with the existing banner (wrong location or doesn't meet the size requirements), but usually don't otherwise if the banner is already used in other languages. Often other languages have articles that cover vastly different areas, so a picture of something 20 mi (32 km) from the city centre is appropriate in some languages, but belongs in a more local article in others. AlasdairW (talk) 10:44, 30 June 2024 (UTC)
- When I have created banners for Wikivoyage, I use an image from Wikimedia Commons, crop it, and create a new image in Commons using the cropped version. Martinvl (talk) 11:46, 13 July 2024 (UTC)
- If I am adding a banner for the first time, I usually also add it to Wikidata, so it is available for other languages. If I am changing a banner after a discussion, I am more sparing in changing it on Wikidata. I will change the WD value if there is a problem with the existing banner (wrong location or doesn't meet the size requirements), but usually don't otherwise if the banner is already used in other languages. Often other languages have articles that cover vastly different areas, so a picture of something 20 mi (32 km) from the city centre is appropriate in some languages, but belongs in a more local article in others. AlasdairW (talk) 10:44, 30 June 2024 (UTC)
- No, I don't think so. I understand that whatever pagebanner image is at Wikidata is the pagebanner by default for every language version of Wikivoyage, unless overriden locally. I don't think we should try to control what happens at other Wikivoyages. Ikan Kekek (talk) 05:15, 30 June 2024 (UTC)
The time allocated for running scripts has expired.
[edit]When I look at Old Towns, the message "The time allocated for running scripts has expired." replaces all listings with markers from China on downward. Is it like that for everyone else? ChubbyWimbus (talk) 15:15, 30 June 2024 (UTC)
- The problem seems to be that there are way, way, way too many markers for the map to handle. Way too many. It is exceedingly useless. Did I mention that there are way too many markers? Ground Zero (talk) 15:48, 30 June 2024 (UTC)
- [edit conflict] Something needs to be done to the article anyway. The markers reach the limit of 99 before halfway down the destination list. Are all these really "famous old towns" by the definition of "inhabited urban districts of decent size and population, open to the public, that have remained largely intact since around 1850 (or 1900 in the New World), or have been faithfully restored to that state"? They might be, but I think Avoid long lists applies. –LPfi (talk) 15:52, 30 June 2024 (UTC)
- For Paris, Copenhagen and Stockholm there are even separate markers for two districts. And there are descriptions on, eh, less than two dozen of them. Could some of these listings be left for Medieval and Renaissance Italy, Roman Empire & al? –LPfi (talk) 15:57, 30 June 2024 (UTC)
- Checking my area, the only famous Old Town is Plovdiv, though you can also make an argument for Veliko Tarnovo (which, ironically, is not in the list). The rest have scattered old buildings and/or European-style fin-de-siecle buildings that are too new for the definition. I'm going to remove the other cities. Not that it will help much... Daggerstab (talk) 23:15, 2 July 2024 (UTC)
- [edit conflict] Something needs to be done to the article anyway. The markers reach the limit of 99 before halfway down the destination list. Are all these really "famous old towns" by the definition of "inhabited urban districts of decent size and population, open to the public, that have remained largely intact since around 1850 (or 1900 in the New World), or have been faithfully restored to that state"? They might be, but I think Avoid long lists applies. –LPfi (talk) 15:52, 30 June 2024 (UTC)
- I think that's w:en:Wikipedia:Lua error messages#Lua timeout error. Probably sub-dividing/shortening the page is the only near-term fix. WhatamIdoing (talk) 22:38, 30 June 2024 (UTC)
- If we're getting that error, it's a sign that the article violates Wikivoyage:Avoid long lists. --SHB2000 (t | c | m) 22:39, 30 June 2024 (UTC)
- "The 7±2 rule applies to destination articles, but not necessarily to itineraries, phrasebooks and travel topics, where different rules may be more appropriate." This is a travel topic, so the rule does not always apply. AlasdairW (talk) 22:46, 30 June 2024 (UTC)
- Perhaps not, but common sense should still apply, and as Ground Zero has noted, there are "way, way, way too many markers". Mrkstvns (talk) 22:55, 30 June 2024 (UTC)
- Yes, that's what I meant. --SHB2000 (t | c | m) 22:58, 30 June 2024 (UTC)
- Best fix is to remove the markers entirely. There are so many of them (and they are so dense in some areas) that putting them on a map makes no sense. Just list and link them. If a country has more than a few, a separate article with a list and map would be fine. Powers (talk) 17:46, 3 July 2024 (UTC)
- What's the point of such an overview article, if you can't see where the cities are? I'd say the solution is to split the article into per-continent subarticles, or whatever, and keep the markers... -- andree 05:22, 9 July 2024 (UTC)
- The point is the links to our articles. You can't see where the cities are anyway because there are so many of them. Powers (talk) 00:05, 13 July 2024 (UTC)
- The map is interactive, with a zoom function. If you are interested in some area, just zoom in on it. If you don't know where in the world the city mentioned in a listing is, just click the marker to get a map centred on that place. –LPfi (talk) 02:54, 13 July 2024 (UTC)
- The point is the links to our articles. You can't see where the cities are anyway because there are so many of them. Powers (talk) 00:05, 13 July 2024 (UTC)
- What's the point of such an overview article, if you can't see where the cities are? I'd say the solution is to split the article into per-continent subarticles, or whatever, and keep the markers... -- andree 05:22, 9 July 2024 (UTC)
- Best fix is to remove the markers entirely. There are so many of them (and they are so dense in some areas) that putting them on a map makes no sense. Just list and link them. If a country has more than a few, a separate article with a list and map would be fine. Powers (talk) 17:46, 3 July 2024 (UTC)
- Yes, that's what I meant. --SHB2000 (t | c | m) 22:58, 30 June 2024 (UTC)
- Perhaps not, but common sense should still apply, and as Ground Zero has noted, there are "way, way, way too many markers". Mrkstvns (talk) 22:55, 30 June 2024 (UTC)
- "The 7±2 rule applies to destination articles, but not necessarily to itineraries, phrasebooks and travel topics, where different rules may be more appropriate." This is a travel topic, so the rule does not always apply. AlasdairW (talk) 22:46, 30 June 2024 (UTC)
- If we're getting that error, it's a sign that the article violates Wikivoyage:Avoid long lists. --SHB2000 (t | c | m) 22:39, 30 June 2024 (UTC)
- One thing we could try is putting the coordinates directly in the marker templates instead of fetching them from Wikidata. I imagine that would help, though I don't know if it would be enough to get rid of the errors. —Granger (talk · contribs) 14:03, 2 July 2024 (UTC)
- See also Talk:Old_towns#Remove_markers_/_split?. Pashley (talk) 01:25, 4 July 2024 (UTC)
Hi am at SA
[edit]How to use this app to travel
41.114.193.222 18:34, 2 July 2024 (UTC)
- It is a travel guide, so mostly you use it by looking up destinations. These are arranged in a hierarchy & you might look at higher-level articles like France or even Europe when planning a trip, then lower level ones like Paris for details as you go. For most destinations, it is a good idea to at least skim the country article -- which covers things like language & laws -- as well as reading up on your actual destination.
- There are also articles for things that apply at many destinations like altitude sickness or bargaining; see Travel topics for a list.
- There are also Itineraries for particular routes, anything from the Kokoda Track through New Guinea to Literary London. Pashley (talk) 20:29, 2 July 2024 (UTC)
- There is also an offline version. Travel Doc James (talk · contribs · email) 12:22, 15 July 2024 (UTC)
U4C Special Election - Call for Candidates
[edit]
- You can find this message translated into additional languages on Meta-wiki. Universal+Code+of+Conduct%2FCoordinating+Committee%2FElection%2F2024+Special+Election%2FAnnouncement+%E2%80%93+call+for+candidates</span>&language=&action=page&filter="}]]}'>Please help translate to your language
Hello all,
A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.
The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.
In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.
Read more and submit your application on Meta-wiki.
In cooperation with the U4C,
-- Keegan (WMF) (talk) 00:03, 10 July 2024 (UTC)
- I do find it interesting how they've barred anyone from enwiki, dewiki or itwiki as their homewiki from running – interesting to see how this would turn out. --SHB2000 (t | c | m) 00:04, 10 July 2024 (UTC)
- If they didn't have a rule like that, the committee would be 100% from the English Wikipedia.
- I imagine that they'll have two from the French Wikipedia next, because of its size, and then Portuguese and Spanish Wikipedias, if Iberocoop decides to get involved.
- @Keegan (WMF), you've unfortunately got two bad links in the "In this special election" paragraph. They're pointing to the local wiki instead of Meta-Wiki. WhatamIdoing (talk) 16:31, 10 July 2024 (UTC)
- Welp, it looks like I've just made one of the two (as of typing this) candidates ineligible (blocked on Meta-Wiki), for the better or worse. I'm glad they had this rule for the reasons you mention, but I wouldn't be surprised if we had one from the English Wikibooks (Leaderboard). --SHB2000 (t | c | m) 23:12, 10 July 2024 (UTC)
Autoconfirmed user criteria
[edit]Continuing on the discussion from #Vandalism on Template:See also, I've made a proposal to change the criteria at Wikivoyage talk:Autoconfirmed users#Revisiting the criteria for autoconfirmed users – any input would be greatly appreciated. --SHB2000 (t | c | m) 10:40, 10 July 2024 (UTC)
Wikimedia Foundation’s Accreditation to World Intellectual Property Organization Blocked for a Fourth Time by China (WMF news article)
[edit]I think some of you might be interested with this article. --SHB2000 (t | c | m) 23:16, 11 July 2024 (UTC)
Pocket vocabularies in Destinations section
[edit]I added a pocket vocabulary at the start fo the Destinations section of the article Wales giving the Welsh words for river, estuary, castle, caern, church, bridge and ford, thus enabling the user to see that "Abertawe" (Swansea) means "mouth of the [river] Tawe". Should Wikivoyage have such vocabularies (limited to say nine entries)? If so, is the location that I have chosen an appropriate place for such a vocabulary? Comments? Martinvl (talk) 11:53, 13 July 2024 (UTC)
- There is a similar list of words in the talk section of Scotland, which is probably a better place for this. I see that "aber" is on both lists. AlasdairW (talk) 13:15, 13 July 2024 (UTC)
Welsh | English |
---|---|
aber | estuary |
afon | river |
caern | cairn |
castell | castle |
llan | church |
pen-y- | head of [river] |
pont | bridge |
rhyd | ford |
- On a similar note, I noticed that the Cornish word for "Falmouth" is "Aberfal". As regards putting the list in the "Talk" section, there might be a case to split the section regarding lcal language into two - one assocaiated with town names (and hence with getting around) and the other associated with communicating with the local people (pleasantries, food etc). To thi send, an alternative might be to create a template which will generate the table as shown on the right. If this stored as a template, then it can be re-used in Wales, North Wales, Mid Wales and South Wales. Martinvl (talk) 15:25, 13 July 2024 (UTC)
- Aren't the other regions covered by having the list in Wales? For languages that have a phrasebook, the list could be included there – but such vocabulary isn't suggested in the template. The problem, especially in Talk, is that there may be quite a lot of useful words and phrases. As you note, there are also a few different categories of such words. Beside city names and pleasantries, there are at least words useful for drivers ("forbidden", "centre", "station") and words useful for hikers ("ford", "refuge"). Added as infoboxes, these list would crowd out images, which are nicer layout-wise than several infoboxes. –LPfi (talk) 16:26, 13 July 2024 (UTC)
- I like the idea of explaining common place names. Depending, it could fit in a ==Get around== section (if 'anything named ____ is a bridge' is relevant) or a ==See== section (if 'anything named ____ used to have a castle there' is relevant).
- I think I would only create a table like this if there were several such names for the similar topic (e.g., these eight about geographical features). If it's just one, two, or three, I think that it would be better to explain it in lively prose. This could result in 10+ words being explained in prose throughout the article (e.g., common words for drivers in ===By car=== plus common words for food in ==Eat==, etc.) WhatamIdoing (talk) 19:04, 13 July 2024 (UTC)
German | English |
---|---|
Bahnhof | railway station |
Brücke | bridge |
Burg | castle |
Dom | cathedral |
Fluss | river |
Kirche | church |
Platz | city square |
Rathaus | town hall |
Schloß | stately home |
Sraße | street |
I see your point about including such a brief list in the section "Getting around", but I think that the short vocabulary should be close to where one would use it. The words that I chose for the Welsh table that I used earlier are all connected with the names of Welsh towns (or mountains) and so the obvious place to include them would be in the section on towns and cities. However, I see a case for a similar list to be included in the "Getting around" section linking to localities within a city. I would not create such a list for Welsh as in Wales virtually all words in this list occur on bilingual signs. I have therefore created a list in German. Martinvl (talk) 20:40, 13 July 2024 (UTC)
- I think it's most elegant and sensible to keep lists of words in "Talk." Ikan Kekek (talk) 00:16, 14 July 2024 (UTC)
- @Ikan Kekek: What you say is certainly sensible for lists of words that give foreign translations of English words and phrases - for example "How do I say 'Thank you '". But when we are translating a foreign language into English. things are different. For exampe why do so many Welsh towns start with "Aber-"? If this question is answered where the reader comes across the situation, they will realise that "aber" means the mouth of a river. If however this information is located in the "Talk" section, it is unlikely that the reader wil follow it up. That is why I suggest putting it in the "Destinations" section and similarly for localities being put in the "Getting around" or the "See" section.Martinvl (talk) 22:02, 14 July 2024 (UTC)
- I tend to think that dividing things up like that is not elegant, except in dedicated phrasebooks. Ikan Kekek (talk) 22:58, 14 July 2024 (UTC)
- In country articles, we should keep this in Talk. However it may help the reader to add this the meaning of Aber to the Understand section of the relevant cities - Aberporth, Aberdyfi, Abercastle and Aberystwyth. AlasdairW (talk) 23:12, 14 July 2024 (UTC)
- I tend to think that dividing things up like that is not elegant, except in dedicated phrasebooks. Ikan Kekek (talk) 22:58, 14 July 2024 (UTC)
- @Ikan Kekek: What you say is certainly sensible for lists of words that give foreign translations of English words and phrases - for example "How do I say 'Thank you '". But when we are translating a foreign language into English. things are different. For exampe why do so many Welsh towns start with "Aber-"? If this question is answered where the reader comes across the situation, they will realise that "aber" means the mouth of a river. If however this information is located in the "Talk" section, it is unlikely that the reader wil follow it up. That is why I suggest putting it in the "Destinations" section and similarly for localities being put in the "Getting around" or the "See" section.Martinvl (talk) 22:02, 14 July 2024 (UTC)
Video
[edit]Hey All, We at Wiki Project Med have build a tool to create short clips zooming into specific locations in the world, as part of our VideoWiki effort. Not sure if some folks here have an interest in creation videos. Here is an example of one of the videos made with this tool. Additionally we are having a meeting about video at Wikimania 2024. Travel Doc James (talk · contribs · email) 12:20, 15 July 2024 (UTC)
- We have generally thought that videos are too difficult to make well for them to be useful here. For me, I think a video zooming in on a map is less useful than the dynamic map centred on the location, where I can zoom in (and out) at my own pace. Also the tuberculosis video linked as example would work better for me as just audio: I had difficulty following the speech while something was happening in the animation.
- People differ, of course, and one doesn't need to play a video just because there is a link. It would be good to see examples where the videos really are worthwhile for at least some people.
- –LPfi (talk) 12:58, 15 July 2024 (UTC)
- I think one of the big difficulties with videos is providing for a wiki friendly way of editing them. If we have a text guide to a city, it is easy for any editor to make a small change to say that the museum now is closed on Wednesday, but it is much harder to do that with a video without the edit sticking out (different voice?). It is hard to provide an easy way to insert the extra or replacement words at exactly the correct moment. If I look at a city guide, it is not immediately obvious whether I am looking at the work of 3 editors over 1 month or 30 editors over 15 years, but unless there are really great tools to support co-operative editing a video updated by 30 editors will be far too jumpy. How will other editors review changes to see that touts haven't plugged their wares without re-watching the video?
- Very short videos may be useful for some instructional matters, to explain things that are hard to put into to words - maybe how to eat with chopsticks, or open an unusual train door. AlasdairW (talk) 20:41, 15 July 2024 (UTC)
- The videos are compiled with text to speech. Thus one can change a single word and easily create a new version. VideoWiki basically allows easy collaborative video editing within a mediawiki. Travel Doc James (talk · contribs · email) 23:19, 15 July 2024 (UTC)
- I find that video size is the Kryptonite of any videos. Compress the file size too much and the video becomes too blurry to be useful. Keep the video high quality and it takes a long time to buffer (sometimes won't even load in remote places). OhanaUnitedTalk page 15:02, 16 July 2024 (UTC)
- The videos are compiled with text to speech. Thus one can change a single word and easily create a new version. VideoWiki basically allows easy collaborative video editing within a mediawiki. Travel Doc James (talk · contribs · email) 23:19, 15 July 2024 (UTC)
Wikimedia Movement Charter ratification voting results
[edit]
- You can find this message translated into additional languages on Meta-wiki. Movement+Charter%2FDrafting+Committee%2FAnnouncement+-+Results+of+the+ratification+vote</span>&language=&action=page&filter="}]]}'>Please help translate to your language
Hello everyone,
After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.
As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.
The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:
Individual vote:
Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).
Affiliates vote:
Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).
Board of Trustees of the Wikimedia Foundation:
The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.
With this, the Wikimedia Movement Charter in its current revision is not ratified.
We thank you for your participation in this important moment in our movement’s governance.
The Charter Electoral Commission,
Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing
It's error time
[edit]Anybody else getting this error repeatedly for more or less any action on this website?
MediaWiki internal error.
Original exception: [93545f3b-e9b4-4b54-a4c5-4e3e72ec05d7] 2024-07-19 00:27:09: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
Brycehughes (talk) 00:30, 19 July 2024 (UTC)
- Servers I think were down just then – I believe that everything's back up now. --SHB2000 (t | c | m) 01:03, 19 July 2024 (UTC)
- Crowdstrike?? Brycehughes (talk) 11:44, 19 July 2024 (UTC)
- I don't think so – Crowdstrike happened much later in the day whereas this outage happened around midnight UTC. --SHB2000 (t | c | m) 11:57, 19 July 2024 (UTC)
- Fair enough. I went to bed on the above error and woke up to the Crowdstrike error, so was confused about the timelines :) Brycehughes (talk) 12:04, 19 July 2024 (UTC)
- Yeah, diff story for me where I was awake when both outages happened :/. SHB2000 (t | c | m) 13:09, 19 July 2024 (UTC)
- Fair enough. I went to bed on the above error and woke up to the Crowdstrike error, so was confused about the timelines :) Brycehughes (talk) 12:04, 19 July 2024 (UTC)
- I don't think so – Crowdstrike happened much later in the day whereas this outage happened around midnight UTC. --SHB2000 (t | c | m) 11:57, 19 July 2024 (UTC)
- Crowdstrike?? Brycehughes (talk) 11:44, 19 July 2024 (UTC)
- Usually, when you get that error, you want to wait five minutes and try again. Most (but not all) of these clear up within a couple of minutes on their own, as automated systems detect and route around the fault. WhatamIdoing (talk) 15:54, 19 July 2024 (UTC)
- I've gotten the error on the last 2 edits I made. Oddly enough, when I reloaded the page the change ''was'' made, but it doesn't show up on the Recent changes log. Weird.
- I'll take your advice and wait 5 minutes before drying another edit. ~~~!~ Mrkstvns (talk) 01:31, 21 July 2024 (UTC)
- Yeah it's happening a lot these days. Brycehughes (talk) 21:09, 21 July 2024 (UTC)
Getting rid of the huge city language
[edit]I think this is what it would take to get rid of the confusing "huge city" language.
- Page moves
- Rename Template:Hugecity skeleton to Template:High-content destination and update language in it (from "PAGENAME is a huge city with several district articles" to "PAGENAME is a destination with several district articles").
- Rename Wikivoyage:Huge city article template to Wikivoyage:High-content destination template and update language in it.
- Rename Wikivoyage:Quick huge city article template to Wikivoyage:Quick high-content destination article template
- Rename Category:Huge city articles to Category:High-content destination articles
- Rename Category:Huge cities with multi-tier district hierarchy to Category:High-content destinations with multi-tier district hierarchy
- Rename Category:Huge cities with more than 10 districts to Category:High-content destinations with more than 10 districts
- Change the cats in Template:PrintDistricts to the new names
- Simple copyediting (mostly, you just replace the words "huge city" with "high-content destination" or "article divided into districts" or the equivalent)
- Update language in Wikivoyage:Where you can stick it
- Update language and links in Wikivoyage:Article skeleton templates, especially Wikivoyage:Article skeleton templates#What's the difference between a small, big and huge city?
- Update language and links in Wikivoyage:What is an article?
- Update language and links in Wikivoyage:District article template
- Update language and link in Wikivoyage:Plunge forward
- Update language and links in Wikivoyage:Template index
- Update language and links in Wikivoyage:Geographical hierarchy
- Update language in Wikivoyage:Article skeleton templates/Sections
- Update language and links in Wikivoyage:Policies#Structure of travel guide articles
- Update language in Category:Move listings to districts
- Update language in Category:Articles needing the Geo zoom defined
- Templates
- Update language and link in Template:Movetodistrict
- Update language and documentation for Template:PrintDistricts
- More complicated editing
- Update Wikivoyage:District Expedition, including the PetScan links
- Update language, link, and PetScan link in Category:Cities with categories
This all sounds feasible to me. Shall we do this? WhatamIdoing (talk) 17:21, 22 July 2024 (UTC)
- No. Mrkstvns (talk) 18:08, 22 July 2024 (UTC)
- Yeah, I think it's not worth the trouble, either. Ikan Kekek (talk) 22:18, 22 July 2024 (UTC)
- I don't love the fact that "high-content destination" sounds unidiomatic and a bit of a mouthful to say. It's still feasible, though. --SHB2000 (t | c | m) 04:36, 23 July 2024 (UTC)
- Agree, high-content destination sounds even more confusing than huge city. Gizza (roam) 04:44, 23 July 2024 (UTC)
- "Districted article" is purely descriptive, so shouldn't garner the sense of protection that the current naming has, and is easy to understand. "Districted city" was a suggestion I previously made. Regardless of the name, we at least need to specify that any destination can have districts if it has enough "See" content. The size of the city, population, etc are irrelevant in districtification. ChubbyWimbus (talk) 11:22, 23 July 2024 (UTC)
- That would also work. The list of changes that need to be made are the same no matter what the eventual name is. I'm not sure what's involved in moving the cats, but everything else is something I could do. It'd probably take about an hour. WhatamIdoing (talk) 15:38, 23 July 2024 (UTC)
- "Districted article" is OK, but when you say "any destination can have districts if it has enough 'See' content": yes, if by "destination" we are referring only to bottom-level articles in the breadcrumb structure. We don't want to use districts for region articles, state/province articles, etc. I guess that would just be made clear in the longer writeup about the template, as is the case now. Ikan Kekek (talk) 18:40, 23 July 2024 (UTC)
- Template:Districtedcity skeleton would seem to be the simplest, clearest solution. Then it won't be used accidentally for regions. Ground Zero (talk) 21:41, 23 July 2024 (UTC)
- That name is OK for me too (not only for the skeleton though). However, the problem on when to use a region and when a districted city remains, and the associated conflict about whether something that isn't strictly a city, or doesn't look like one, can still use districts. –LPfi (talk) 07:46, 24 July 2024 (UTC)
- Would Multidistrictcity be slightly clearer? Martinvl (talk) 17:30, 24 July 2024 (UTC)
- I like "multi-district", but if we use the word "city" in here, we are going to have more discussions over whether _____ is a True™ City. Please look right up at the top of the page, where the question isn't whether the area has districts; the dispute is specifically over whether the destination is actually a city.
- If you say, "Sure, WhatamIdoing, I know that, and in the future, I actually want to should have lots of discussions about whether it's okay to use this format for places that benefit from having districts but are not legally or practically considered 'cities', because I just love it when people worry about whether this is the right invisible thing to say", then that's fine, but I personally don't want to have any more of these conversations. I'd like to solve both the "Buffalo isn't huge, even though we have a huge amount of content for it" and the "This collection of small towns isn't technically 'a city', even though we've split it into districts" problems. Do you really want to preserve the latter problem? WhatamIdoing (talk) 18:08, 24 July 2024 (UTC)
- How about Conurbation or Metropolitan Area? Martinvl (talk) 21:10, 24 July 2024 (UTC)
- Far too broad. The Buffalo-Niagara Falls metro area (as just one example) comprises Niagara County, Northtowns, Buffalo, and Southtowns. Powers (talk) 23:29, 29 July 2024 (UTC)
- How about Conurbation or Metropolitan Area? Martinvl (talk) 21:10, 24 July 2024 (UTC)
- Would Multidistrictcity be slightly clearer? Martinvl (talk) 17:30, 24 July 2024 (UTC)
- That name is OK for me too (not only for the skeleton though). However, the problem on when to use a region and when a districted city remains, and the associated conflict about whether something that isn't strictly a city, or doesn't look like one, can still use districts. –LPfi (talk) 07:46, 24 July 2024 (UTC)
- Template:Districtedcity skeleton would seem to be the simplest, clearest solution. Then it won't be used accidentally for regions. Ground Zero (talk) 21:41, 23 July 2024 (UTC)
- I assume moving the categories (without redirect) like any page and changing the categorisation in the templates would be enough for moving the categories. Can somebody confirm? The cache updates might take some time. –LPfi (talk) 20:29, 23 July 2024 (UTC)
- I believe so, but I may be wrong. --SHB2000 (t | c | m) 23:31, 23 July 2024 (UTC)
- Yes, that's my understanding, too. WhatamIdoing (talk) 17:55, 24 July 2024 (UTC)
- Just want to remind you that there doesn't seem to be consensus for doing this at all, so how much work it would take or how it should be done is a moot point. Mrkstvns (talk) 18:11, 24 July 2024 (UTC)
- Doesn't matter if there's consensus or not, we need to know it's technically feasible to do so. --SHB2000 (t | c | m) 21:32, 24 July 2024 (UTC)
- Yep, it's good to know that bad ideas can be easily implemented. Mrkstvns (talk) 21:40, 24 July 2024 (UTC)
- Which part do you think is the bad idea? Your comment above suggests that you are concerned that a reader will stumble into the Template: namespace and be confused if {{hugecity skeleton}} has a different name. WhatamIdoing (talk) 15:12, 25 July 2024 (UTC)
- Yep, it's good to know that bad ideas can be easily implemented. Mrkstvns (talk) 21:40, 24 July 2024 (UTC)
- Doesn't matter if there's consensus or not, we need to know it's technically feasible to do so. --SHB2000 (t | c | m) 21:32, 24 July 2024 (UTC)
- Just want to remind you that there doesn't seem to be consensus for doing this at all, so how much work it would take or how it should be done is a moot point. Mrkstvns (talk) 18:11, 24 July 2024 (UTC)
- Yes, that's my understanding, too. WhatamIdoing (talk) 17:55, 24 July 2024 (UTC)
- I believe so, but I may be wrong. --SHB2000 (t | c | m) 23:31, 23 July 2024 (UTC)
- "Districted article" is OK, but when you say "any destination can have districts if it has enough 'See' content": yes, if by "destination" we are referring only to bottom-level articles in the breadcrumb structure. We don't want to use districts for region articles, state/province articles, etc. I guess that would just be made clear in the longer writeup about the template, as is the case now. Ikan Kekek (talk) 18:40, 23 July 2024 (UTC)
- That would also work. The list of changes that need to be made are the same no matter what the eventual name is. I'm not sure what's involved in moving the cats, but everything else is something I could do. It'd probably take about an hour. WhatamIdoing (talk) 15:38, 23 July 2024 (UTC)
- "Districted article" is purely descriptive, so shouldn't garner the sense of protection that the current naming has, and is easy to understand. "Districted city" was a suggestion I previously made. Regardless of the name, we at least need to specify that any destination can have districts if it has enough "See" content. The size of the city, population, etc are irrelevant in districtification. ChubbyWimbus (talk) 11:22, 23 July 2024 (UTC)
- Agree, high-content destination sounds even more confusing than huge city. Gizza (roam) 04:44, 23 July 2024 (UTC)
- I don't love the fact that "high-content destination" sounds unidiomatic and a bit of a mouthful to say. It's still feasible, though. --SHB2000 (t | c | m) 04:36, 23 July 2024 (UTC)
- Yeah, I think it's not worth the trouble, either. Ikan Kekek (talk) 22:18, 22 July 2024 (UTC)
When should Wikivoyage articles acknowledge sources, or be acknowledged as a source?
[edit]Wikivoyage does not have the elaborate reference system of Wikipedia. Itineraries such as walking tours tend to be based on travel literature, as well as guided tours. I started the Haunted Stockholm tour inspired by a book on the topic, with stories paraphrased from other sources, and added waypoints absent from the book to avoid suspicions of plagiarism; the article also acknowledges the book. I was recently on a tour hosted by the Jewish Museum, which added plenty of information for the Jewish Stockholm tour and bought a map useful to expand on the Stockholm labour tour; however I am not sure how to give the proper acknowledgements. Even if we don't violate copyright, we should consider how to be a complement for the hospitality industry, and not a rival. On the other hand, some commercial tours seem to be based on Wikivoyage. This tour guide might have read parts of the Stockholm history tour article; though the gallery shows off some locations absent from this article. Do we need a policy for giving and requesting acknowledgements? /Yvwv (talk) 21:08, 24 July 2024 (UTC)
cswikivoyage
[edit]Looks like per phab:T370905, it might actually be happening – say hello to our 25th(?) Wikivoyage. SHB2000 (t | c | m) 02:51, 25 July 2024 (UTC)
- Congratulations to them! Ikan Kekek (talk) 02:55, 25 July 2024 (UTC)
- Ano, vítejte. But behind this lurks a big question. The current model is of separate WVs for each language. But even WV-EN is an order of magnitude behind the number of contributions needed to keep it relevant, and even relatively well-supported sites like WV-DE and PL are of marginal help to real-world travelers. It's hard to see how Mandarin, Hindi, French or Arabic, let alone the less-spoken languages with interesting destinations at their core, can ever benefit from this model. Grahamsands (talk) 17:46, 25 July 2024 (UTC)
- It's definitely not ideal, but that's not for us to discuss (proposals open at Meta, though). --SHB2000 (t | c | m) 21:41, 25 July 2024 (UTC)
- Indeed it is a concern for smaller wikis. We have plenty of examples of "community capture" by a small group of editors, but that applies to most wiki projects, including Wikipedia. Ideally there should be a single source of information across all Wikivoyage languages so you don't need to update listing in every language. But we're nowhere close to that point. OhanaUnitedTalk page 05:49, 26 July 2024 (UTC)
- I'm not sure that you'd want 100% uniformity. You could imagine that, e.g., German speakers and English speakers would have different ideas about the best choice for a restaurant or hotel in the Grand Est, based on the language spoken by the staff.
- However, a good deal of the information could be duplicated across all wikis. The m:Wikifunctions is hoping to build a set of "functions" so that content could be written once and then re-used (like a template) across different languages. The idea is that you could pick and choose the ones you wanted. Imagine, e.g., adding an automatically translated {{bus fare}} to ==Get around==, but deciding that you'd rather write your own ==Understand== section. Wikivoyages might be a good testing ground for this work. WhatamIdoing (talk) 15:47, 26 July 2024 (UTC)
- Yeah. Restaurants and bars are probably less likely to be shared across language wikis. Hotels might be ok since they are far fewer and less turnover than eateries (or sometimes the only accommodation in town). I definitely envision things like Getting in, bus fare, main attractions to be duplicated and updateable via a single source. However, it also brings the question of how editing across different languages can interlace together under one umbrella. I also edit Chinese Wikivoyage and while the written language is identical, there are different translations for place names due to cultural differences (Chinese Wikipedia currently has page tabs which displays names and terms differently in "Mainland simplified", "Hong Kong traditional", "Macao traditional", "Malaysia simplified", "Singapore simplified" and "Taiwan traditional" according to user preference). Imagine if one editor edits an entry on a page in Spain with English and another editor edits the same entry in French, how will they be merged together? OhanaUnitedTalk page 16:52, 26 July 2024 (UTC)
- That would be a good prototype – it sucks that most language Wikivoyages barring en, de and it suffer from severe out-of-date content, so anything like this would be an improvement. --SHB2000 (t | c | m) 01:12, 27 July 2024 (UTC)
- A problem is that more structure often means harder to edit for mortals – cf the French listing templates. Sometimes it is also hard to tell when an edit is an actual update; sometimes edits may be tweaks of outdated info, which shouldn't be propagated to more up-to-date versions.
- However, there should be tools to ease translation of listings. Perhaps there are?
- –LPfi (talk) 06:22, 27 July 2024 (UTC)
- The structured parts of listings could be generated from Wikidata, thus avoiding parallel work in different languages, but the running text is important for our guides and cannot be generated from data. Automatic processes, probably by help of AI, could be used, but I think it is better to have readers and editors use whatever translation tools there are available, as needed, than our providing machine created or machine translated content.
- I don't think there is any way to get around the problem of too small an editing community. With a Wikivoyage in Czech, there is a chance to attract Czechs (and Slovaks?) who wouldn't use or edit Wikivoyage in English. I think they would use their resources best by concentrating on destinations well-visited by Czechs, perhaps primarily domestic or Central-European ones (and a few global top destinations). Wikivoyage in German can probably be used to quickly write some of the Central European articles, articles on famous destination can be translated from de/en/whatever.
- –LPfi (talk) 06:10, 27 July 2024 (UTC)
- I think Wikifunctions is better described as an anti-AI project, because the idea is to have full human control. Consider the first sentence in Miami: "Miami is a major city in the southeastern United States and the second most populous city in Florida."
- This could be coded as something like [NB: I am completely making up the syntax here]: "
d:Q8652 {copula:simple present third-person singular} {indefinite pronoun} {intensifier:major} d:Q515 {locating preposition} {definite pronoun} d:Q1139046 {conjunction:and} {definite pronoun} {ordinal number:2} {superlative:most} {adjective:d:Q33829} d:Q515 {locating preposition} d:Q812 {terminal punctuation}
" - And if that were placed in an English-language site, the code would look up all the terms and perhaps produce "Miami is a major city in the southeastern United States and the second most populous city in Florida." Or perhaps (especially if the sentence is not coded well) it would produce something dreadful like "Miami is a lot of City with the Southeastern United States and the 2nd very population City for Florida."
- But even if that sentence turns out to be dreadful, the idea is that you could pick and choose the pieces you wanted, see what they were going to actually show, and make your own decision about whether each piece was helpful or broken, throughout the article.
- Obviously, this will require years of work. For example, MediaWiki is already set up to handle gendered language, but if you want, e.g., to get the correct gender for all of the words, then someone needs to go to d:Q515 on Wikidata and make a note that "city" is a feminine word in these languages, masculine in those languages, etc. – times every language and every word. Perhaps for a given language only mathematical calculations would realistically be useful. WhatamIdoing (talk) 16:16, 27 July 2024 (UTC)
- I think the risk of dreadful expressions is too big for this to be realistic in the near future. It can be done for quite elaborate schematic text – cf Lsjbot's articles such as Glansbrosking – but the descriptions of LA, NY, Paris, Kolkata and Heidelberg should have very different articles. Should the scheme be built separately for each? How many authors are equipped to construct a scheme that works across languages and cultures? LPfi (talk) 06:08, 30 July 2024 (UTC)
- I believe the idea is that each article would get its own functions. Of course, just like we copy from one article to another for convenience, I expect a lot of functions to get copied from one to another, swapping out the key words.
- The question isn't just how many are equipped to construct it. The first question is how many are equipped to use a pre-constructed one. On the technical side, using a pre-constructed one could be as simple as typing a code like
{{Glansbrosking bus fare}}
, but you also have to look at it to make sure that it says what you want the article (e.g., good grammar). WhatamIdoing (talk) 17:57, 30 July 2024 (UTC)- One cannot have different functions for each article, as that would require one to learn the set for each article, recognising some of them, but having to do some hard work to grasp and translate the rest. I assume I misunderstand what you mean.
- I think there would need to be a core set of functions that would generate sensible articles, the rest just adding flavour or less critical information, probably with importance levels or other groupings, so that translation into a new language could be done step by step.
- –LPfi (talk) 18:39, 30 July 2024 (UTC)
- I think there will be building blocks. Think about how Template:Mbox works: you use it to build the message you want, but each message has to be customized.
- AIUI the goal isn't "write one boilerplate, have 300 very similar articles about towns in Finland in the English Wikivoyage". The goal is closer to "write one paragraph about one specific town, and offer that one paragraph to all the other language editions of Wikivoyage". WhatamIdoing (talk) 16:31, 31 July 2024 (UTC)
- But in that model, the paragraph has to be translated into all languages. That can be done with no new building blocks, but requires people who do the translations. With the boilerplate version, you translate it once and get those 300 articles in a hundred languages. The problem is that the boilerplate isn't very interesting.
- The compromise would be to have some essential info through the building blocks. That is partly done in listings via Wikidata and could be expanded somewhat, e.g. to tell coordinates of the town, its population, the closest railway station etc.
- A project at sv-wp expanded Lsjbot articles on islands in the Archipelago Sea, adding info on parish, closest ferry pier and cardinal directions and distances to a few locally important places (without Wikidata help), see e.g. Aiviskläppen. This was boilerplate text, but useful and readable. Human-generated location-specific text needs to be added to make the article interesting.
- –LPfi (talk) 18:46, 31 July 2024 (UTC)
- No. In that model, the paragraph has to be translated into code, and the code translates into all of the supported languages.
- We already have auto-writing, auto-translated boilerplates. See https://reasonator.toolforge.org/?q=Q350&lang=en vs https://reasonator.toolforge.org/?q=Q350&lang=fi vs https://reasonator.toolforge.org/?q=Q350&lang=de for one such tool. Some of them are more list-like and some assemble paragraphs. This particular tool is coded to write paragraphs for people but not places (example).
- The goal with Wikifunctions, and later with Abstract Wikipedia, is to be able to hand-code a specific paragraph for a specific subject, so that it can be interesting. It might not be possible for it to be Brilliant Prose™, but it should be able to have a human decide that Aiviskläppen needs a sentence about the nearest coffee shop while waiting for the boat, and provide that in all languages. WhatamIdoing (talk) 17:18, 1 August 2024 (UTC)
- I think the risk of dreadful expressions is too big for this to be realistic in the near future. It can be done for quite elaborate schematic text – cf Lsjbot's articles such as Glansbrosking – but the descriptions of LA, NY, Paris, Kolkata and Heidelberg should have very different articles. Should the scheme be built separately for each? How many authors are equipped to construct a scheme that works across languages and cultures? LPfi (talk) 06:08, 30 July 2024 (UTC)
- Ano, vítejte. But behind this lurks a big question. The current model is of separate WVs for each language. But even WV-EN is an order of magnitude behind the number of contributions needed to keep it relevant, and even relatively well-supported sites like WV-DE and PL are of marginal help to real-world travelers. It's hard to see how Mandarin, Hindi, French or Arabic, let alone the less-spoken languages with interesting destinations at their core, can ever benefit from this model. Grahamsands (talk) 17:46, 25 July 2024 (UTC)
Cannabis
[edit]With cannabis being legalized in numerous states in the US as well as all of Canada, Germany, Israel, etc, is it perhaps high time to have a specific template and subsections in relevant articles? It can be done already with {{buy}} or {{drink}} (see Homer#Cannabis for an example) but maybe we should just lightly modify one of those for cannabis? Just Step Sideways (talk) 18:42, 26 July 2024 (UTC)
- As a general rule, the English Wikivoyage tries to have as few specialized templates as possible. If the existing templates feel too specific, then the generic {{listing}} can be used instead. I would suggest that whatever is already used for tobacconists would be a reasonable option. WhatamIdoing (talk) 02:51, 27 July 2024 (UTC)
- Wycsi has advice on this. It recommends "the Buy section of the City for dispensaries, or the Drink section of the City page for shops that sell for consumption on premises; the Buy or Drink section of the Region or Country page for an overview of such shops". That seems reasonable to me. I don't see the need for a new template. —Granger (talk · contribs) 14:02, 27 July 2024 (UTC)
- I do not think this needs a template. Some articles may need more info on cannabis, though.
- Retiring_abroad/Table used to have columns for the legal status of activities some retirees might indulge in -- cannabis, homosexuality & prostitution -- but those were removed, See Talk:Retiring_abroad/Table#Drugs_and_sex; I think I was the only one who wanted to keep them. Pashley (talk) 15:47, 27 July 2024 (UTC)
- In some jurisdictions, the law on cannabis (and also the way in which the law is applied) seems to change quite regularly. Unless WikiVoyage can keep up to date with what is happening, it is best not to give, what some readers might percieve as "legal" advice. —The preceding comment was added by Martinvl (talk • contribs)
- Any article that mentions cannabis or similar substances should comment on the legal risks or link to an article that does, usually a country or province article or Cannabis. The unstable situation should be noted in the warning. I think a link is much easier than a template, and the template should anyway mostly be the link, perhaps with a very general warning.
- The main thing to warn about is that travelling away from a place were cannabis can be legally bought or consumed can land you in trouble, such as when traces are enough to be a problem, or when travelling between two states where it is legal involves federal law that forbids it.
- –LPfi (talk) 06:19, 30 July 2024 (UTC)
Vote now to fill vacancies of the first U4C
[edit]
- You can find this message translated into additional languages on Meta-wiki. Universal+Code+of+Conduct%2FCoordinating+Committee%2FElection%2F2024+Special+Election%2FAnnouncement+%E2%80%93+voting+opens</span>&language=&action=page&filter="}]]}'>Please help translate to your language
Dear all,
I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.
The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.
Please share this message with members of your community so they can participate as well.
In cooperation with the U4C,
Roll out of Parsoid Read Views on English Wikivoyage this week
[edit]Hello everyone! I am glad to inform you that as part of our continued rollout of Parsoid Read Views, Parsoid is expected to be turned on this week as the default read views renderer on English and Hebrew Wikivoyage. Here's the rationale behind our confidence to roll-out this experimental feature and collect feedback.
This is an opportunity for continued experimentation as we increase the number of wikis using Parsoid for read views.
If this disrupts your workflow, don’t worry you can still opt out through a user preference or turn Parsoid off on the page you’re navigating in the Tools submenu, as described at the Extension:ParserMigration page.
To report bugs and issues, please look at our known issues documentation and if you found a new bug please create a phab ticket and tag the Content Transform Team in Phabricator.
There is more information about our roll-out strategy available.
Best regards, C. Scott Ananian for the Content Transform Team. CAnanian (WMF) (talk) 20:47, 29 July 2024 (UTC)
- Parsoid is cool. It underlies this dumb website (doesn't earn me any money, I haven't bothered marketing, don't freak out) and works really well. Brycehughes (talk) 03:00, 30 July 2024 (UTC)
- Is it somehow more self-contained alternative to https://github.com/wikimedia/mediawiki/blob/master/includes/parser/Parser.php , or what? Interesting that it started as JS, but got converted to PHP back again... full circle :-) -- andree 15:38, 30 July 2024 (UTC)
- It began as an independent wikitext parser which generated HTML with additional information in it to support Visual Editor and users like @Brycehughes which want to extract information from the HTML. Maintaining two parsers in parallel is a waste of effort, though, so we're trying to (eventually) completely replace the old Parser.php with parsoid. Cscott (talk) 17:56, 30 July 2024 (UTC)
- Is it somehow more self-contained alternative to https://github.com/wikimedia/mediawiki/blob/master/includes/parser/Parser.php , or what? Interesting that it started as JS, but got converted to PHP back again... full circle :-) -- andree 15:38, 30 July 2024 (UTC)
- Unfortunately, it doesn't seem sensitive to sections. Click "Add listing" in any section and it *always* creates a generic listing entry whereas it previously knew to make listings "eat", "see" or whatever. So far, this parsoid looks to me like a step backwards. So what are its benefits? Mrkstvns (talk) 22:42, 30 July 2024 (UTC)
- God I wish for once the WM tech team would test a Wikivoyage workflow before deploying. Brycehughes (talk) 22:55, 30 July 2024 (UTC)
- @Jdlrobson: I recall you fixed this bug (generic new listings instead of section-aware listings) a few weeks ago, but I can confirm it seems to be back now, in both the regular and beta listing editors. Do you have any insight? —Granger (talk · contribs) 03:03, 31 July 2024 (UTC)
- There should be a fix in the beta as of now. Jdlrobson (talk) 04:50, 31 July 2024 (UTC)
- They rarely do – we're always an afterthought. --SHB2000 (t | c | m) 04:09, 31 July 2024 (UTC)
- TBF, en.wv has 1000x less of everything (edits, views, editors) than en.wp... basically it's on par with minor language editions of WP, and there is 100 of them. I expect most of them too have similar strange details? Quite a nightmare to test, I imagine. -- andree 12:50, 31 July 2024 (UTC)
- No matter how big or small a wiki is, it's never a good idea to just roll it out site-wide without testing to see if it works. That's a bit like Apple saying they'll roll out iOS 17 automatically on all devices, but they won't test it on the SE Gen 3 because it's one of their least used models. --SHB2000 (t | c | m) 12:56, 31 July 2024 (UTC)
- I suppose there is no need to test (thoroughly) on each project: our issues are Wikivoyage-specific, Wikiversity may have their problems, right-to-left and composed-character languages have theirs. I'd assume that few small wikis have much of wiki-specific features; I assume that if you test on sv-wp, most would-be issues on da-wp and no-wp would be found, even those of e.g. fi-wp. The Wikivoyages having many features of their own should be well-known. –LPfi (talk) 13:49, 31 July 2024 (UTC)
- Iam not show what an alternative would look like? Rolling out to logged in users with an opt out seems like exactly the right way to do this.
- The fact that these issues werent caught beforehand is on us the community. There were emails on wikitech-l about opting it to this previously that we didnt act on. We have had months to flag these issues already. What am I missing? Jdlrobson (talk) 19:02, 31 July 2024 (UTC)
- As I understand it, they did test it beforehand. That's how they knew there was only a .3% variation in text alignment between the two parsers. Powers (talk) 19:58, 31 July 2024 (UTC)
- No matter how big or small a wiki is, it's never a good idea to just roll it out site-wide without testing to see if it works. That's a bit like Apple saying they'll roll out iOS 17 automatically on all devices, but they won't test it on the SE Gen 3 because it's one of their least used models. --SHB2000 (t | c | m) 12:56, 31 July 2024 (UTC)
- Special:Version says we're still on last week's software. How certain are we that we're casting blame in the right direction? WhatamIdoing (talk) 16:33, 31 July 2024 (UTC)
- @Jdlrobson: I recall you fixed this bug (generic new listings instead of section-aware listings) a few weeks ago, but I can confirm it seems to be back now, in both the regular and beta listing editors. Do you have any insight? —Granger (talk · contribs) 03:03, 31 July 2024 (UTC)
- Hey can you check the beta version of the gadge (opt in via gadget preferences)? This bug should only impact the current stable version. I need more testing before promoting it to everyone. The listing editor icons will say add listing (beta) when you are using the beta.
- Changes like this are welcome as they force editors to test things :) Jdlrobson (talk) 18:59, 31 July 2024 (UTC)
- @Jdlrobson: Looks like it's fixed in the beta version. Thank you! —Granger (talk · contribs) 15:14, 1 August 2024 (UTC)
- God I wish for once the WM tech team would test a Wikivoyage workflow before deploying. Brycehughes (talk) 22:55, 30 July 2024 (UTC)
- The full page map, from the icon at the top right of the page (next "Rendered with Parsoid"), is no longer working. The link seems to be missing the co-ordinates (set by the Geo template at the bottom of the article text), and so is showing a map of the sea at 0,0. I assume that this is a consequence of the change, but I don't know exactly when it stopped working as I only use it a few times per month. AlasdairW (talk) 17:41, 4 August 2024 (UTC)
- Whoops, indeed, that's not great, and most probably a consequence of this change. I'll have a look (although it may take a bit more time due to Wikimania this week!). Thanks for reporting! IHurbainPalatin (WMF) (talk) 08:38, 5 August 2024 (UTC)
- This is the same issue as https://phabricator.wikimedia.org/T348722, so we'll track it there. IHurbainPalatin (WMF) (talk) 12:44, 5 August 2024 (UTC)
- Whoops, indeed, that's not great, and most probably a consequence of this change. I'll have a look (although it may take a bit more time due to Wikimania this week!). Thanks for reporting! IHurbainPalatin (WMF) (talk) 08:38, 5 August 2024 (UTC)
- Seems to have a bad "auto corrector" in the editor. It introduces far more errors than it fixes. Doesn't even know about common tags....wants to change "lastedit=" to "lasted it=", Does stupid things like capitalizing the word "budget" when used as the 2nd word in a sentence. Lots more bad "corrections" but I'm too lazy to type 'em all in. Is there a way to set a preference to always shut it off? Mrkstvns (talk) 19:41, 4 August 2024 (UTC)
- I don't think that this issue is related to this change. Could it be a local setting? I don't *think* we have auto-correction in the editor (but I may be missing something!) IHurbainPalatin (WMF) (talk) 08:41, 5 August 2024 (UTC)
- There's no autocorrection in any MediaWiki editing environment. The Editing team has been declining those requests for over a decade. Any autocorrection you're seeing is happening in your web browser. WhatamIdoing (talk) 16:56, 5 August 2024 (UTC)
- There is a preference to turn it off: In the Editing tab of Preferences, it is at the bottom in Developer tools. AlasdairW (talk) 22:34, 7 August 2024 (UTC)
- Special:Preferences#mw-prefsection-editing-developertools is the direct link. WhatamIdoing (talk) 15:32, 8 August 2024 (UTC)
- I don't think that this issue is related to this change. Could it be a local setting? I don't *think* we have auto-correction in the editor (but I may be missing something!) IHurbainPalatin (WMF) (talk) 08:41, 5 August 2024 (UTC)
Share examples of WikiProjects or collaborations that you have worked on
[edit]Hi Wikimedians!
The Campaigns Product and Programs Teams at the Wikimedia Foundation wants to learn more about WikiProjects and other on-wiki collaborations work. We would like to do more work that improves the quality of collaborations onwiki. We especially need examples of WikiProjects and other collaborations that have worked on different Wikimedia projects. Please help us by filling out a short survey on Meta: https://meta.wikimedia.org/wiki/Campaigns/WikiProjects
Never participated in a WikiProject or other collaborations, but have ideas on how we could make collaboration better? You can also share feedback on the talk page: https://meta.wikimedia.org/wiki/Talk:Campaigns/WikiProjects
Please share the survey with anyone you think would help us have valuable insights, we are particularly looking for successful collaborations on non-English wikis. Astinson (WMF) (talk) 21:02, 31 July 2024 (UTC)
- Astinson (WMF) Wikivoyage Spanish could participate? they did not publish anything on our Posada... --Hispano76 (talk) 21:55, 31 July 2024 (UTC)
- Yes! We are looking for examples from any of the wikis, we are working with translators to share the call to action, but you will see the form is translate already, @Hispano76 Astinson (WMF) (talk) 00:38, 1 August 2024 (UTC)
- In just a few hours, I'll be filling out the form! I do want to share that I was a bit disappointed not to have been contacted after offering my expertise during the WikiForHumanRights conversation.
- On a brighter note, to keep things organized on enwikivoyage, how about we compile a list of activities that have taken place between our communities, like Wikivoyage 5 and Wikivoyage 10? It would be great to see us bring together Wikivoyage 12 and make it a regular event! Galahad (sasageyo!)(esvoy) 06:40, 1 August 2024 (UTC)
- Yes! We are looking for examples from any of the wikis, we are working with translators to share the call to action, but you will see the form is translate already, @Hispano76 Astinson (WMF) (talk) 00:38, 1 August 2024 (UTC)
switch to interactive map does not work
[edit]I just discovered that the link "switch to interactive map" of a Regionlist does not show a map, and the static map disappears. FredTC (talk) 11:12, 1 August 2024 (UTC)
- On it:voy still works (e.g. it:Slovacchia), so the problem is only in en:voy. Unfortunately I'm about to go on vacation and I can't debugging it in the short term. The problem is on the new parser (Parsoid), because if you switch on the legacy parser (see link on the left bar), everything works correctly. Andyrom75 (talk) 15:44, 1 August 2024 (UTC)
- @Jdlrobson: Could you perhaps take a look into this when you get the time? Thanks in advance. --SHB2000 (t | c | m) 23:16, 1 August 2024 (UTC)
- I can replicate this, but I'm not familiar with this gadget. What is the gadget that adds that link? Jdlrobson (talk) 02:14, 2 August 2024 (UTC)
- https://en.wikivoyage.org/w/index.php?title=Template:Regionlist&diff=prev&oldid=4073000 ... it's basically using the mw-collapsible , which in turn does some jQuery magic to switch stuff... -- andree 10:46, 2 August 2024 (UTC)
- I can replicate this, but I'm not familiar with this gadget. What is the gadget that adds that link? Jdlrobson (talk) 02:14, 2 August 2024 (UTC)
- @Jdlrobson: Could you perhaps take a look into this when you get the time? Thanks in advance. --SHB2000 (t | c | m) 23:16, 1 August 2024 (UTC)
- Hi @FredTC - could you provide an example of a page where this happens, so that we can investigate and fix? Thanks! IHurbainPalatin (WMF) (talk) 15:58, 1 August 2024 (UTC)
- @IHurbainPalatin (WMF) Slovakia... Andyrom75 (talk) 21:23, 1 August 2024 (UTC)
- I noticed it with Amsterdam, but I also tried other ones with the same result. I also tried it with another browser, not logged in. All with the same result. FredTC (talk) 06:37, 2 August 2024 (UTC)
- After investigation: https://www.mediawiki.org/wiki/Manual:Collapsible_elements#With_custom_toggle_link uses "id" attributes to have remote/custom toggles on elements. This is not going to work out in a Parsoid environment, because the id will be overwritten. Please bear with us while we figure out how we're going to support that! IHurbainPalatin (WMF) (talk) 10:58, 2 August 2024 (UTC)
- I opened https://phabricator.wikimedia.org/T371682 to track this. IHurbainPalatin (WMF) (talk) 11:07, 2 August 2024 (UTC)
- From our perspective, this should be fixed with the following edit on the Regionlist template: https://en.wikivoyage.org/w/index.php?oldid=4826574&diff=4915944
- (I've added it there as well: Template talk:Regionlist#Parsoid compatibility)
- I thought that Parsoid was always overwrite the id attribute of the elements, but it was pointed out to me that it only happens if the ID is not unique. Hence, de-duplicating the ID should do the trick. IHurbainPalatin (WMF) (talk) 15:16, 2 August 2024 (UTC)
- @IHurbainPalatin (WMF), it's good to hear from you again. You should be able to edit that template directly. WhatamIdoing (talk) 16:11, 2 August 2024 (UTC)
- @WhatamIdoing likewise! Let me try that, then (I didn't want to overstep boundaries :D ) IHurbainPalatin (WMF) (talk) 16:19, 2 August 2024 (UTC)
- I don't think this community has ever objected to someone fixing known bugs.
;-)
We are practical here (and one of the nicest editing communities out there. Volunteer-you should drop by and update an article or two again). I'd have implement your change myself, except that I hadn't tried to reproduce the bug, so I wasn't sure that I'd be able to test that it was fixed. WhatamIdoing (talk) 16:37, 2 August 2024 (UTC)
- I don't think this community has ever objected to someone fixing known bugs.
- @WhatamIdoing likewise! Let me try that, then (I didn't want to overstep boundaries :D ) IHurbainPalatin (WMF) (talk) 16:19, 2 August 2024 (UTC)
- @IHurbainPalatin (WMF), it's good to hear from you again. You should be able to edit that template directly. WhatamIdoing (talk) 16:11, 2 August 2024 (UTC)
- I went ahead and edited the template. I believe the issue is fixed. Let me know if there's anything that doesn't look right! Thank you for your report and your patience :) IHurbainPalatin (WMF) (talk) 16:28, 2 August 2024 (UTC)
Reminder! Vote closing soon to fill vacancies of the first U4C
[edit]
- You can find this message translated into additional languages on Meta-wiki. Universal+Code+of+Conduct%2FCoordinating+Committee%2FElection%2F2024+Special+Election%2FAnnouncement+%E2%80%93+reminder+to+vote</span>&language=&action=page&filter="}]]}'>Please help translate to your language
Dear all,
The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.
Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.
Please share this message with members of your community so they can participate as well.
In cooperation with the U4C,
Hey All We are looking at the possibility of launching Content Translation to work between languages of WikiVoyage. What this would mean is that one could use this tool to translate WikiVoyage articles between EN and DE or DE to EN or another other language pairs for that matter. There is the possibility to have this work supported by an initial machine translation layer but the requirement for humans to make a certain amount of improvements. Thoughts or concerns? Travel Doc James (talk · contribs · email) 08:22, 10 August 2024 (UTC)
- I wouldn't support allowing machine-translated listings or sections to be put verbatim on any language version of Wikivoyage. I just think that's a very bad practice. As machine translation improves, maybe someday it will be OK, but the authors have to be credited and it's really better for a thinking person to not only translate but also make decisions about whether edits are needed. Ikan Kekek (talk) 08:59, 10 August 2024 (UTC)
- I would strongly support it. Even on voy/de our community is very active but still too small. Even me, I often start with an en:import. I think have a tool like that could lower the barrier to start new articles, especially in an less active Wikivoyage language version. It would be not limited to de, even Polish Wikivoyager could use German articles to have it translated and start. -- DerFussi 10:40, 10 August 2024 (UTC)
- Yah allowing machine translation without improvement is definitely not something I would support either. Thankfully the tool doesn’t permit this. Travel Doc James (talk · contribs · email) 15:28, 10 August 2024 (UTC)
- I've used it for Wikipedia articles, and I think it's helpful. The percentage of necessary revision to a machine translation is configurable per language pair, as some machine translations are better than others. You might want 5% changed, on average, for Spanish to English, but 15% for German to English.
- In my experience, it's easiest to translate into a language you know very well. People who write well in English don't dump bad translations into the mainspace just because The Computer™ said that was good grammar. Problems with this can usually be resolved with a short partial block to force a discussion. WhatamIdoing (talk) 19:57, 10 August 2024 (UTC)
- For the record, a similar request has been made at m:Community Wishlist/Wishes/ContentTranslation work for Wikivoyage/en (original request is in Spanish). --SHB2000 (t | c | m) 10:59, 10 August 2024 (UTC)
- It's not obvious what this adds, because even with existing tools, translation of most languages is speedy and not a bottleneck to editing. What takes time is engaging brain to produce coherent content. For instance, the North African desert does not have such good skiing as google-translated W/WV-DE would have you believe - Piste in this context means a dirt track. Grahamsands (talk) 20:42, 10 August 2024 (UTC)
- At htwiki, I'm cleaning up machine translations that were apparently accomplished through this method:
- Open French Wikipedia article.
- Copy raw wikitext into Google Translate.
- Paste unedited Google Translate results, including mangled wikitext codes, non-existent parameter names, and translated file names, into the Haitian Creole Wikipedia.
- The ContentTranslation tool doesn't screw up the wikitext. WhatamIdoing (talk) 04:46, 11 August 2024 (UTC)
- @Grahamsands: Nobody said that using the ContentTranslation tool even with machine translation meant you stopped doing copyedits. --SHB2000 (t | c | m) 05:33, 11 August 2024 (UTC)
- What I'm afraid of is the translation tool allowing a workflow where the brain is disengaged. The 15% (or whatever) limit avoids this for most users, but some may come up with strategies to get enough changes without improving anything.
- There is no guarantee that those using the tool have a good enough command of English to avoid problems, neither with grammar, nor with facts. We can have a discussion with established users, and block them if need be, but we might have short-term accounts do problematic translations. I simply do not trust unknown users to behave sensibly with such tools.
- On the other hand, I don't have experience with using the tool for Wikivoyage articles, it might work well with the typically less complicated text here (and it might have improved since I tried it at sv-wp). What's the experience of new users using the tool at Wikipedias? –LPfi (talk) 09:20, 11 August 2024 (UTC)
- If I'm not mistaken some wikis require
extendedconfirmed
permission to use the Content Translation tool – in our case, we could make thatautopatroller
andsysop
. This would make it clear that the tool is primarily for trusted users and using it is a privilege. --SHB2000 (t | c | m) 10:07, 11 August 2024 (UTC)- That would probably solve the main issues. –LPfi (talk) 11:17, 11 August 2024 (UTC)
- Worries like "some may come up with strategies to get enough changes without improving anything" are not grounded in facts. It's pure speculation. It's obvious that you "simply do not trust unknown users", but we could equally say that "There is no guarantee that those using" the existing system can write in English well, and newbies screw up all day long, at all wikis, everywhere. It's part of the learning curve.
- I think the situation breaks down like this:
- Old system: Newbies make mistakes, newbies mangle formatting, newbies use machine translation without any minimum requirements or even reminders to check the results. Sometimes we have to clean up the mess, or delete the page, or block them.
- Proposed system: Newbies will make mistakes, but they'll be less likely to mangle formatting. Newbies will use machine translation, but there will be minimum requirements and reminders to check the results. Still, sometimes – though probably less often – we will have to clean up the mess, or delete the page, or block them.
- Which of these two systems do you want? Remember that the one in which nobody uses machine translation, nobody writes in their second (or third) language, and only people who are fully competent in both technical and language terms get to contribute isn't what we have now, and it won't be what we have then, either. WhatamIdoing (talk) 16:48, 11 August 2024 (UTC)
- Might be that you are right, but I don't think it is a far-fetched a-priori thought that a tool for machine translation increases the usage of machine translation. –LPfi (talk) 17:30, 11 August 2024 (UTC)
- I know that machine translation is a valuable tool in hands that know how to use it. In those cases, the result shouldn't be easily distinguishable from skilful manual translation. We also have users that use machine translation to produce low-quality text and even rubbish. I don't think it is common enough to be a problem. I don't know whether this tool will increase such usage to a point where it is a problem. Personally, I have tried the tool a few times at Wikipedia and found it hard to use as intended (e.g. changing the paragraph structure wasn't supported). It might work better for Wikivoyage. –LPfi (talk) 17:38, 11 August 2024 (UTC)
- One of the classic stories about poor translation is that in the early days of machine translation, somebody entered the text "The spirit was willing but the flesh weak" into an English to Russian translator. The resulting Russian was translated back to English and dave "The vodka was good but the meat was bad". This is an extreme example, but I often use the Google English to Afrikaans translator, mainly to get the correct vocabulary. I invariably have to change something. I therefore counsel that machine translators should be used with care. Martinvl (talk) 19:58, 11 August 2024 (UTC)
- I know that machine translation is a valuable tool in hands that know how to use it. In those cases, the result shouldn't be easily distinguishable from skilful manual translation. We also have users that use machine translation to produce low-quality text and even rubbish. I don't think it is common enough to be a problem. I don't know whether this tool will increase such usage to a point where it is a problem. Personally, I have tried the tool a few times at Wikipedia and found it hard to use as intended (e.g. changing the paragraph structure wasn't supported). It might work better for Wikivoyage. –LPfi (talk) 17:38, 11 August 2024 (UTC)
- At the very least when it's trialled, it should only be for autopatrollers and sysops, LPfi's concerns are pretty much why many wikis require EC (typically 30 days + 500 edits on many Wikipedias) to use this tool. --SHB2000 (t | c | m) 21:58, 11 August 2024 (UTC)
- For sure and those limits can be set at WikiVoyage aswell. We could also set it up for functioning from EN WV to other languages of WV if EN does not wish to have it functional to here. But before I assign this work to a programmer will need consensus from at least a few communities. Travel Doc James (talk · contribs · email) 05:21, 12 August 2024 (UTC)
- I'd probably want to restrict it to autopatrollers, at least at first. Anyone who wants to use the tool can request autopatroller status and be granted it at the discretion of an admin. The documentation on the tool should state that clearly. Ikan Kekek (talk) 07:46, 12 August 2024 (UTC)
- CX can also be turned on without machine translation (obvious problem, seen at other wikis: people just copy/paste paragraphs into Google Translate without any requirement for revision), so that we get only the formatting and attribution benefits, without the translation benefits (e.g., they'll link to the disambiguation page Auburn instead of automatically connecting to Auburn (Alabama)).
- I understand that it's also possible to choose specific language pairs for translation (e.g., from Spanish to English, but not from German to English). WhatamIdoing (talk) 15:05, 12 August 2024 (UTC)
- We could allow autoconfirmed users to do that (formatting and attribution benefits, without the translation benefits). Ikan Kekek (talk) 15:49, 12 August 2024 (UTC)
- I'd probably want to restrict it to autopatrollers, at least at first. Anyone who wants to use the tool can request autopatroller status and be granted it at the discretion of an admin. The documentation on the tool should state that clearly. Ikan Kekek (talk) 07:46, 12 August 2024 (UTC)
- @SHB2000, does your "many wikis" mean "the English Wikipedia only"? WhatamIdoing (talk) 14:55, 12 August 2024 (UTC)
- For sure and those limits can be set at WikiVoyage aswell. We could also set it up for functioning from EN WV to other languages of WV if EN does not wish to have it functional to here. But before I assign this work to a programmer will need consensus from at least a few communities. Travel Doc James (talk · contribs · email) 05:21, 12 August 2024 (UTC)
- Might be that you are right, but I don't think it is a far-fetched a-priori thought that a tool for machine translation increases the usage of machine translation. –LPfi (talk) 17:30, 11 August 2024 (UTC)
- If I'm not mistaken some wikis require
- At htwiki, I'm cleaning up machine translations that were apparently accomplished through this method:
- It's not obvious what this adds, because even with existing tools, translation of most languages is speedy and not a bottleneck to editing. What takes time is engaging brain to produce coherent content. For instance, the North African desert does not have such good skiing as google-translated W/WV-DE would have you believe - Piste in this context means a dirt track. Grahamsands (talk) 20:42, 10 August 2024 (UTC)
FYI: 52 Unexpected Places to Go in the USA
[edit]https://www.afar.com/magazine/incredible-places-to-visit-in-the-u-s
Sadly, American Samoa, Guam, the Northern Mariana Islands, and the United States Virgin Islands were excluded. :/ —Justin (koavf)❤T☮C☺M☯ 21:01, 10 August 2024 (UTC)
- Well, those aren't really states and people living in the lower 48 would have to book a long, and very expensive, flight to get to those places. As a traveler in the USA, I prefer the article's focus on places that *really are* in the USA. Mrkstvns (talk) 16:49, 25 August 2024 (UTC)
Listing editor issue in Emeryville
[edit]I'm finding that when I click the "add listing" button in any section of the Emeryville article except "Get in", I get an error message: "Error occurred loading content for this section." I haven't seen this issue in any other articles. This problem happens with both the regular and beta versions of the listing editor. Does anyone know what the problem might be? @IHurbainPalatin (WMF), Jdlrobson: Pinging in case you have any insight. —Granger (talk · contribs) 01:48, 12 August 2024 (UTC)
- I'll have a look, thanks for reporting! IHurbainPalatin (WMF) (talk) 08:52, 12 August 2024 (UTC)
- As far as I can tell, this is an matter of discrepancy in some cases between section numbering in Parsoid and in core (where the API trying to get the section content lives). We have a couple of issues related to that in Phabricator already; I'll try to have that triaged to the correct one. IHurbainPalatin (WMF) (talk) 12:57, 12 August 2024 (UTC)
- The failure of the listing editor is the result of a severe software bug. The section numbering differs from that of non-Parsoid renderer. The wrong numbering results in getting wrong section texts, and in many cases the listing template is not found. To get an idea please go to the "Get in" section and after this to "By bus". Then the message "Cannot find section" will occur. I added a Phabricator task with high priority. --RolandUnger (talk) 10:37, 13 August 2024 (UTC)
- The Wikitext was invalid, so the parser returned a wrong result. The old parser is much more error-resistant. --RolandUnger (talk) 10:52, 13 August 2024 (UTC)
- Thank you for finding that. I wonder, is there a way to produce a list of all articles that have invalid wikitext like this, so we can go through and fix them all? —Granger (talk · contribs) 14:26, 13 August 2024 (UTC)
- By grepping all the articles, actually only Emeryville seems to have this particular typo. You could probably render all pages with and without Parsoid, and diff the result html's... good luck with that :)) -- andree 07:29, 17 August 2024 (UTC)
- It's possible that the WMF could add it to Special:LintErrors. (I don't know what the minimum requirements are for including something in that system.) WhatamIdoing (talk) 20:12, 17 August 2024 (UTC)
- By grepping all the articles, actually only Emeryville seems to have this particular typo. You could probably render all pages with and without Parsoid, and diff the result html's... good luck with that :)) -- andree 07:29, 17 August 2024 (UTC)
- Thank you for finding that. I wonder, is there a way to produce a list of all articles that have invalid wikitext like this, so we can go through and fix them all? —Granger (talk · contribs) 14:26, 13 August 2024 (UTC)
- I've had listings end up in the lead for years (example). I wonder if that's related at all. WhatamIdoing (talk) 15:03, 13 August 2024 (UTC)
- The Wikitext was invalid, so the parser returned a wrong result. The old parser is much more error-resistant. --RolandUnger (talk) 10:52, 13 August 2024 (UTC)
FYI: When the Best Possible Story is Right Outside Your Door
[edit]https://lithub.com/when-the-best-possible-story-is-right-outside-your-door/ —Justin (koavf)❤T☮C☺M☯ 06:38, 15 August 2024 (UTC)
Coming soon: A new sub-referencing feature – try it!
[edit]
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
- Please try the current state of development on beta wiki and let us know what you think.
- Sign up here to get updates and/or invites to participate in user research activities.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
Please help us spread the message. --Johannes Richter (WMDE) (talk) 10:36, 19 August 2024 (UTC)
- This is irrelevant for this wiki, since we don't use refs, but if you also edit at Wikipedia or other wikis using footnotes, this might be useful to know about. WhatamIdoing (talk) 20:15, 19 August 2024 (UTC)
Interface administrator inactivity requirements
[edit]Just bumping the discussion at Wikivoyage talk:Interface administrators on inactive interface admins. --SHB2000 (t | c | m) 08:27, 20 August 2024 (UTC)
Sign up for the language community meeting on August 30th, 15:00 UTC
[edit]Hi all,
The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.
This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.
Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!
MediaWiki message delivery (talk) 23:20, 22 August 2024 (UTC)
Croptool
[edit]Hey guys, I use croptool to correctly size pagebanner images. Unfortunately, connections have been consistently failing the last couple days. Anyone seen this? Any tips on what I might need to do to get it to work? Mrkstvns (talk) 15:38, 25 August 2024 (UTC)
- I suggest asking at c:Commons:Village pump/Technical. WhatamIdoing (talk) 20:09, 25 August 2024 (UTC)
- Thanks! I'll post there and see if I get a useful reply. Mrkstvns (talk) 21:14, 25 August 2024 (UTC)
- I believe it's a known issue (many others have the same issue), though don't quote me on that. --SHB2000 (t | c | m) 21:26, 25 August 2024 (UTC)
- My understanding is that the tool has been largely the work of one developer or a small team and that person may have stopped updating it. However, the problem has been intermittent so far and I've still been able to crop photos for WP using the tool. --Comment by Selfie City (talk) (contributions) 03:05, 27 August 2024 (UTC)
- "Intermittent" seems an apt description. The tool is connecting properly again and I was able to get some edits done on pagebanners. Got my fingers crossed that it keeps working because it's pretty useful, IMHO. Mrkstvns (talk) 14:31, 27 August 2024 (UTC)
- I was using WikiShootMe!, another toolforge-hosted tools, this past weekend and it also had issues (mainly with loading the page). I suspect it's toolforge-related and not the tool itself. OhanaUnitedTalk page 18:03, 28 August 2024 (UTC)
- "Intermittent" seems an apt description. The tool is connecting properly again and I was able to get some edits done on pagebanners. Got my fingers crossed that it keeps working because it's pretty useful, IMHO. Mrkstvns (talk) 14:31, 27 August 2024 (UTC)
- My understanding is that the tool has been largely the work of one developer or a small team and that person may have stopped updating it. However, the problem has been intermittent so far and I've still been able to crop photos for WP using the tool. --Comment by Selfie City (talk) (contributions) 03:05, 27 August 2024 (UTC)