Logo Voyage

Wikivoyage talk:Abuse filters Voyage Tips and guide

You can check the original Wikivoyage article Here
Archives

Filter 37

[edit]
Swept in from the pub

    Admins and any stewards who might be reading, please go to the discussion thread for that filter. Ikan Kekek (talk) 20:04, 15 January 2024 (UTC)Reply

    This direct link should work for those with the requisite permission. Ikan Kekek (talk) 20:05, 15 January 2024 (UTC)Reply
    Special:AbuseFilter/37 if the above link doesn't work. --SHB2000 (talk | contribs | meta) 22:52, 15 January 2024 (UTC)Reply

    Review of Abuse Filter rules

    [edit]
    Swept in from the pub

    I checked out Abuse filter management – Travel guide at Wikivoyage (not visible to everyone) and can see that:

    1) There are rules picking up false positives and blocking valid edits

    2) There are rules that have not been triggered in many years

    I could go through and clean these up but would like to achieve consensus first. The idea would be to take rules and choose to delete or change action from block to tag.

    It is also difficult to collaborate on the rules since the rules (by design) are hidden. Where would be the best place to progress thus? Andrewssi2 (talk) 23:28, 14 February 2024 (UTC)Reply

    Good initiative. I would recommend Wikivoyage talk:Administrators' handbook for general discussion, where one can point to individual filters by number, hoping that no one will be careless with keeping private information private. The ones with many false positives should be pointed out (by number) without delay and discussion on them continued in their comment field, which is our practice. –LPfi (talk) 07:12, 15 February 2024 (UTC)Reply
    I share your worry that the abuse log isn't patrolled enough. However, I now checked most disallowed edits from this month and found none that would have been useful. A few were just promotional and should perhaps been reverted instead of disallowed, but still not that problematic. Please elaborate. –LPfi (talk) 07:31, 15 February 2024 (UTC)Reply

    Special:AbuseFilter/38

    [edit]
    Swept in from the pub

    Admins please take a look. Cheers. Gizza (roam) 04:03, 19 April 2024 (UTC)Reply

    Filter 52

    [edit]
    Swept in from the pub

    Admins, please take a look at Special:AbuseFilter/52. TIA, --SHB2000 (talk | contribs | meta) 06:57, 20 April 2024 (UTC)Reply

    Enabling the block feature on the abuse filter

    [edit]
    Swept in from the pub

    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)Reply

    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    @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)Reply
    Support -Lionel Cristiano (talk) 22:46, 19 June 2024 (UTC)Reply
    • 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)Reply
      @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)Reply
      And ACV and BMX are? Ikan Kekek (talk) 04:28, 21 June 2024 (UTC)Reply
      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)Reply
      Right. Ikan Kekek (talk) 04:48, 21 June 2024 (UTC)Reply
      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)Reply
      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)Reply

    ──────────────────────────────────────────────────────────────────────────────────────────────────── 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)Reply

    I never used abuse filters so I can't comment on its suitability and scope. OhanaUnitedTalk page 05:39, 4 July 2024 (UTC)Reply
    That's understandable. --SHB2000 (t | c | m) 05:52, 4 July 2024 (UTC)Reply
    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)Reply
    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)Reply
    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)Reply
    ...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)Reply
    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)Reply
    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)Reply

    Filter problem

    [edit]
    Swept in from the pub

    @Hanyangprofessor2: We apparently have a problem with filter 36 ("Article/Wikivoyage blanking by unregistered/new user"), see Special:AbuseLog/75595: A new user creates an article by inserting the appropriate template, saves, and then tries to remove the commentary, which triggers this filter, as the page shrinks a lot. I'm proposing a solution at the filter, but I don't have time to look in to it right now.

    In the meantime, a solution is to insert enough content in the edit that removes the commentary (or newer to save the page before the commentary is removed).

    It seems the last such disallowed edit was on Monday, and I hope the affected editors (just a few, I think) have found their ways around it.

    LPfi (talk) 10:45, 26 September 2024 (UTC)Reply

    Special:AbuseFilter/48

    [edit]
    Swept in from the pub

    A technically savvy admin should please go to Special:AbuseFilter/48. Thanks! Ikan Kekek (talk) 06:50, 12 October 2024 (UTC)Reply

    I've responded, though we should probably discuss this at Special:AbuseFilter/52. --SHB2000 (t | c | m) 07:21, 12 October 2024 (UTC)Reply

    Attempting to revert vandalism; keep getting prevented by filters

    [edit]
    Swept in from the pub

    Hello all, when I attempted to revert vandalism on User talk:Count Count, it was blocked by the filters.This has happened to me on multiple occasions, such as trying to revert cross-wiki vandalism on Wuhan and getting prevented by the filters when reporting someone at WV:VIP. Can something be done about this to where I stop getting prevented by the filters when I do counter-vandalism? Thank you. ChrisWx (talk) 03:03, 14 November 2024 (UTC)Reply

    Generally most cross-wiki patrollers lack this issue due to the fact that global rollbackers have autopatrol globally, but since I notice your edit matrix x-wiki isn't super extensive (for GR), your best course of action is to just let an admin know for now until we figure out a workaround with the filters. --SHB2000 (t | c | m) 03:09, 14 November 2024 (UTC)Reply
    I know this isn't the subject of your question, but I want to again object to VIP standing for something other than the obvious Very Important Person. That said, I don't think the filter should have tripped you up, and I'm confident one of our technical people will fix it, but we wouldn't have known there was a problem if you hadn't told us, so thanks for doing that, and sorry. Ikan Kekek (talk) 03:11, 14 November 2024 (UTC)Reply
    Yeah I hate the name of VIP – I'll make a proposal on the talk page. SHB2000 (t | c | m) 03:13, 14 November 2024 (UTC)Reply
    Thank you both for the responses! I'll remember to take this approach until the filters are fixed. I hope that the filters can be fixed soon, and will let admins like y'all know about the vandalism if you aren't taking care of it already for the time being. :) ChrisWx (talk) 03:15, 14 November 2024 (UTC)Reply
    Sure thing – and in the meantime I've given you autopatroller perms since your primary work here is cross-wiki patrolling (meaning you shouldn't be caught up in such filters anymore). --SHB2000 (t | c | m) 03:17, 14 November 2024 (UTC)Reply
    Awesome, thank you very much! ChrisWx (talk) 03:18, 14 November 2024 (UTC)Reply
    There were multiple issues, some of which really cannot be resolved other than by giving such rights. I fixed one filter. When disallowing your revert of a talk page edit, the filter was doing exactly what it should do – the filter had no way of knowing it wasn't vandalism. You were also caught by a global filter that seems like very easily causing false positives, with autopatroller no recourse (we cannot edit those filters, just ask for changes, and I couldn't spot the offending expression in it). –LPfi (talk) 10:54, 14 November 2024 (UTC)Reply
    See Meta:Talk:Global AbuseFilter#Filter 214. Doing some more edits could help. –LPfi (talk) 11:13, 14 November 2024 (UTC)Reply
    The global filter was updated to use the global edit count, so Wikipedians coming here for such edits won't be disallowed by it any more. –LPfi (talk) 21:34, 14 November 2024 (UTC)Reply
    That's much better than using local edit count, IMO (and my bad for not noticing and fixing it earlier). --SHB2000 (t | c | m) 21:41, 14 November 2024 (UTC)Reply
    We might want to do the same change in some of our own filters, see Special:AbuseFilter/2 for discussion on details. –LPfi (talk) 09:30, 15 November 2024 (UTC)Reply

    Filter 48

    [edit]
    Swept in from the pub

    Admins, please read my comments in Filter 48 and reply there, and thanks! Ikan Kekek (talk) 18:08, 4 February 2025 (UTC)Reply

    Suggested changes to abuse filter 36

    [edit]

    I am here to make some fixes to filter 36. In addition that this filter (and some other filters) should only be set to disallow, I have some other fixes:

    • Instead of (page_namespace == 0 | page_namespace == 4), I used the equals_to_any check which saves a condition.
    • I placed the edit count checks below the page namespace check and added global_user_editcount < 100 to prevent false positives such as Special:AbuseLog/78378. For that same reason, instead of rlike in the redirect condition, I switched it to irlike.
    • Instead of using the current summary exclusion condition, I switched to a reversion summary check which excludes users reverting blanking vandalism with some specific summaries.
    • I removed a condition that excludes DannyS712 bot, now that I used a user_rights check that excludes bots and users with the autopatrol and patrol user rights.
    • I placed the page_first_contributor condition as the last check because it's expensive in terms of performance.
    equals_to_any(page_namespace, 0, 4) &
    user_editcount < 25 &
    global_user_editcount < 100 &
    old_size > 250 &
    (new_size < 75 | edit_delta < -3000) &
    /* Exclude if the page was converted into a redirect */
    !(added_lines irlike "^\s*#\s*redirect\s*\[\[") &
    /*
     * Exclude if the text from the article templates was removed or edited;
     * note that this matches only some such cases, though.
     */
    !(removed_lines irlike "does not have a heading|List attractions|things that travellers will do|Mention any local specialties|between this section and others") &
    /*
     * Allow edits where among the edited content are strings longer than 100 chars
     * with no lowercase ASCII letters (this is to allow reverts of mistakenly saved
     * foreign-script translations).
     */
    !(removed_lines rlike "[^a-z]{100,}") &
    /* Allow users to revert blanking vandalism using reversion summaries */
    !(summary irlike "^(?:und(?:id|o)|restore|revert|rv[vt]?)") &
    /* Exclude bots and user groups that have the 'autopatrol' and 'patrol' user rights */
    !("patrol" in user_rights) &
    /* Exclude the Graffiti wall test page */
    page_prefixedtitle != "Wikivoyage:Graffiti wall" &
    /* Allow drastic size reduction of self-created page, if the user is a first contributor */
    user_name != page_first_contributor

    Thank you. Codename Noreste (talk) 02:17, 24 March 2025 (UTC)Reply

    Yes Done //shb (t | c | m) 02:32, 24 March 2025 (UTC)Reply

    Filters that should just be set to disallow and suggestion to MediaWiki:Abusefilter-warning

    [edit]

    I am adding a small list of abuse filters that should only be set to disallow, because having the warn or tag action along with disallowing is redundant.

    In addition, because MediaWiki:Abusefilter-disallowed is modified to be less bitey, I suggest we should do the same with the warning message. But I would like to suggest the addition to the warning message, with replacing [Insert custom warning message here].

    {{abuse filter warning
    | action = warn
    | friendly = yes
    | text = <big>'''Alert'''</big>: Please take the opportunity to consider whether this action reflects community expectation. When in doubt, please ask for advice, either on the [[{{TALKPAGENAME}}|talk page]] or at the [[Wikivoyage:Travellers' pub|travellers' pub]]. If you are certain what you are about to do is appropriate, please press "{{int:Publishchanges}}" again to continue with the action, and report this error at the pub.<br>A brief description of the abuse rule which your action matched is: $1
    }}

    Thoughts? Codename Noreste (talk) 03:27, 24 March 2025 (UTC)Reply

    @Codename Noreste: Yes Done the first bit. I too am in support of changing the wording on MediaWiki:Abusefilter-disallowed, but I'll wait for a third opinion. //shb (t | c | m) 03:55, 10 April 2025 (UTC)Reply
    Apologies for the confusion, but I noted that the warning message is MediaWiki:Abusefilter-warning. Codename Noreste (talk) 04:01, 10 April 2025 (UTC)Reply
    Whoops; FTR, I support modifying the warning message on that page. //shb (t | c | m) 04:04, 10 April 2025 (UTC)Reply
    Maybe no one has objections (I obviously do not object), and I think the current warning message is bitey since others are trying to help this project and could use an ambox with an editnotice type. Codename Noreste (talk) 04:06, 10 April 2025 (UTC)Reply
    Could you suggest a different wording? Ikan Kekek (talk) 04:42, 10 April 2025 (UTC)Reply
    For the warning message, I believe that we should borrow an idea from enwikibooks' abusefilter-warning message. Codename Noreste (talk) 04:50, 10 April 2025 (UTC)Reply
    b:en:MediaWiki:Abusefilter-warning for context. //shb (t | c | m) 04:51, 10 April 2025 (UTC)Reply
    Maybe I'd reword it to "Alert: Please take the opportunity to consider whether this action reflects community expectation. When in doubt, please ask for advice, either on the talk page or at the travellers' pub. If you are certain what you are about to do is appropriate, please press "Save page" again to continue with the action, and report this error at the pub." //shb (t | c | m) 04:53, 10 April 2025 (UTC)Reply
    Modified accordingly. Should we also include A brief description of the abuse rule which your action matched is: $1? Codename Noreste (talk) 05:01, 10 April 2025 (UTC)Reply
    Yeah I'd include that too. //shb (t | c | m) 05:03, 10 April 2025 (UTC)Reply
    I do not object to this, but I am noting here that for some reason, when an fmbox include one line of text, it always centers the text and the image, which is not what we want. Also, does anyone object if I import the abuse filter warning template to this project? Codename Noreste (talk) 05:04, 10 April 2025 (UTC)Reply
    I'm fine with the changed language. I don't know enough to have an opinion on whether it would be better or worse to import a new template. Ikan Kekek (talk) 06:53, 10 April 2025 (UTC)Reply
    I'm good with it because a lot of our box templates aren't maintained properly and this one (hopefully) should be up to date. //shb (t | c | m) 07:04, 10 April 2025 (UTC)Reply
    I'll get started with importing the template from Meta-Wiki, but be warned that the image and the text will look off-center. Codename Noreste (talk) 15:48, 10 April 2025 (UTC)Reply
    If it depends on other templates that we don't have, it might be better to write our own. –LPfi (talk) 20:17, 10 April 2025 (UTC)Reply
    It uses the {{Fmbox}}, {{Notice}}, and {{Documentation}} templates, but I would probably suggest leaving the notice template out, since we don't have many filters as other projects do. Codename Noreste (talk) 01:09, 11 April 2025 (UTC)Reply
    And the template was recently imported to here, by me. :) Codename Noreste (talk) 02:32, 12 April 2025 (UTC)Reply
    Yes Done – replaced the language. Cheers for importing the abuse filter warning template, CN. :) //shb (t | c | m) 06:32, 12 April 2025 (UTC)Reply

    Filter 63

    [edit]
    Swept in from the pub

    To admins, please go to Special:AbuseFilter/63. Thanks, //shb (t | c | m) 11:14, 3 March 2025 (UTC)Reply

    A question about two abuse filter messages

    [edit]
    Swept in from the pub

    Why do we have both MediaWiki:Abusefilter-warning-telstra and MediaWiki:Abusefilter-warning-telstra-not-declined? Codename Noreste (talk) 15:02, 12 April 2025 (UTC)Reply

    I had an edit flagged as destructive because my account isn't very old

    [edit]
    Swept in from the pub

    I was trying to remove information related to crossing the border into Azerbaijan from the Baku page (it's been closed since 2020 and the only way in is via air), but trying to delete a lot of content on a new account flagged me as a vandal.

    If someone has permissions to view the changes, and would be willing to check on those changes, thank you very much :) MagnumDahng (talk) 09:32, 9 June 2025 (UTC)Reply

    @MagnumDahng: Can you try removing the outdated content once again? I've temporarily disabled the filters; let me know once you've removed everything that you intended to. Sorry for the extra inconvenience. //shb (t | c | m) 10:04, 9 June 2025 (UTC)Reply
    It worked.
    No worries. I understand why it's there :) MagnumDahng (talk) 10:15, 9 June 2025 (UTC)Reply
    Perfect, I've re-enabled the filters; thanks again for the updates! :) //shb (t | c | m) 10:36, 9 June 2025 (UTC)Reply


    Discover



    Powered by GetYourGuide