"URI must be ascii only" failures in bang healthcheck

[dumbmoron]

Opening this issue for some discussion regarding the periodically executing bang health check.

I noticed that a lot of the failures are due to the fact that some URLs contain UTF-8 characters, which results in the "URI must be ascii only" error thrown by Ruby's URI parser.

On one hand, they are indeed technically invalid as per RFC 3986; on the other hand though, any reasonable URL consumer nowadays supports parsing URLs containing direct unencoded UTF-8 characters, despite it being unsupported by the spec, so I don't see them containing UTF-8 characters as a huge problem.

@nobodywasishere What are your thoughts on this? Do you think this check could be worked around/ignored, or rather that all the URLs containing UTF-8 characters should be percent-encoded?

[nobodywasishere]

We have run into issues due to bangs not being URI encoded (such as #), so maybe it'd be a good idea for the templates to be URI-encoded with updated specs to make sure they are. We decided at one point to standardize on not URI-encoding them, but that may have been the wrong direction to go

#122

[dumbmoron]

We have run into issues due to bangs not being URI encoded (such as #)

If you mean urls such as https://translate.google.com/#cy/en/{{{s}}} (!cyen), i'm afraid those are unfixable since they rely on passing the parameter via the URI fragment. Some sites have a query parameter equivalent, but it's not guaranteed.

so maybe it'd be a good idea for the templates to be URI-encoded with updated specs to make sure they are. We decided at one point to standardize on not URI-encoding them, but that may have been the wrong direction to go

I would be okay with either direction, as long as it's consistent -- either the spec allowing encoded URLs, or the health check not complaining about UTF-8 characters

[nobodywasishere]

If you mean urls such as https://translate.google.com/#cy/en/{{{s}}} (!cyen), i'm afraid those are unfixable since they rely on passing the parameter via the URI fragment. Some sites have a query parameter equivalent, but it's not guaranteed.

I mean the current tests enforce that # cannot be URI encoded, and so if you want to pass one that's not a URI fragment, you can't. Enforcing URI encoding shouldn't impact when intending to use a URI fragment.