My assumption is that because wikipedia has a known plaintext and a known link graph it's plausible to identify pages with some accuracy and either block them or monitor who's reading what.
I also assume that the traffic profile of editing looks different from viewing.
At least in theory, the latest versions of TLS should not be vulnerable to a known plaintext attack. TLS also is capable of length-padding, which would reduce the attack surface here as well for an eavesdropper.
My understanding is that HTTP/2 makes it even more difficult to construct an attack on this basis, because HTTP/2 means multiple requests can get rolled into one.
Of course, all this is assuming an eavesdropper without the ability to intercept and modify traffic. In practice, governments will probably just MITM the connection - we have precedent for governments abusing CAs like this in the past - and unless Wikipedia uses HPKP and we trust the initial connection and we trust that the HPKP reporting endpoint isn't blocked, then it's still possible to censor pages, without anybody else knowing[0].
[0] ie, the government censors will know, and the person who attempted to access the page will know, but neither Wikipedia nor the browser vendor would be able to detect the censorship automatically.
TLS1.3, which is still a draft, does have support for record-level padding, but I haven't seen any of the experimental deployments using it.
HTTP/2 does have support for padding, but again, it's not common to see it being used, at least not in the kind of sizes it would take to obscure content fingerprints.
Wikipedia is a particularly hard case for traffic analysis fingerprinting. First, the combination of page size and image sizes are just highly unique, even modulo large block/padding sizes. But more importantly, anyone can edit a wikipedia page, so if the size of a target page isn't unique, it's very easy to go ahead and edit it to make it so. It would take very large amounts of padding to defeat this.
So it's definitely possible to fingerprint which wikipedia someone is browsing. But it's probably not easy to block it; the fingerprint is only detectable after the page has been downloaded. So it's not very useful for censorship.
Well, it's detectable after the request has been made and Wikipedia sends the response. Assuming that a government has the capabilities to block delivery of that response (which they do), they can still implement censorship at this level, before the page reaches the end user.
If they routinely MITM connections they will quickly be found out, and the CA would be removed from browsers.
E.g. if every wikipedia page, plus all of the content it includes, came to exactly 10K, 20K, 30K, ... in size, then you could obscure what the user is reading.
In the event this was even tried, it would presumably be trivial to defeat with injection of random content somewhere in the server responses anyway. This of course all assumes we can trust the root certificate authority though :P
Though you shouldn't be compressing things over TLS. I think the only proper solution is to pad out all articles (and images) to the nearest 2kB or something so that you can't figure out the length (randomness can be thwarted by forcing refreshes).
Certificate pinning in the HTTPS client would mitigate TLS MITM (HPKP).