unspecified "required" encoding/escaping in [[Wikimedia:Pageviews-url-structure-massviews-target/en]] and others
unspecified "required" encoding/escaping in Wikimedia:Pageviews-url-structure-massviews-target/en and others
This message to be translated does indicates that the question mark must be encoded, but it does not explicit which form should be used.
In my opinion, we should not have to reencode the URL in the application and should be able to post the exact URL as it works, it should be up to the application to reencode it if it wants to encapsulate it into another URL or document format (other wise the result for any URL is unpredictable, notably for other characters like %, <, >, &, #
Note that a non-encoded URL may contain a fragment identifier, but if the URL has to be encapsulated into another URL for example in a query string parameter, that hash character will also need to be encoded, and all percent characters; whitespaces may also be present in non-encoded wiki page titles, and are normally reencoded in the URL form, but the default in browsers is to rencode them as +, whilst MediaWiki reencodes them as _ for page titles. Mediawiki also has special handling for + or ? and some other punctuations, allowed in page titles, that also need to be encoded for URLs, to avoid their interpretation as whitespaces remapped to '_' or as a question string delimiter. For URLs to some "Special:" pages there are other restrictions or different behavior for whitespaces.
So at least first explicit how to encode the question mark; but in fine please change the application's code to handle itself any needed reencoding, so that we won't ever need any such manual unpredictable tweak; in that later case, drop this statement from the message.
Note that there are various messages asking to the final users (reading these translated messages) to use an escaped form for some parameters or values to provide in the final app. This is generally not clear when there's no link to explin how to safely escape these parameters, and as well this exposes server-side or client-side security issues, or unexpected side-effects (which may be desastrous, either for theses users themselves, or site-wide or application-wide for all their users): those messages should be updated to reflect a change in the code of Mediawiki or its extensions: it's up to these applications to handle the proper escaping. Translators should not bothezr about this internal technical trick.