I'm open to other suggestions - as changing URLs isn't the most fun thing to do...

But my opinion would be to remove all subsub-domains. I do like the idea of having language based subdomains, but it seems to make life a lot harder.

This should be a community discussion...

I'll throw in my favorite solution, which Skizzerz proposed the last time I spoke to him about this: Let's Encrypt SSL certificates for <lang code>.*.shoutwiki.com, i.e. fi.*.shoutwiki.com (possibly relevant: this StackOverflow question). Looking at /trunk/languages/i18n/, there are currently 371 files in there so it would mean about the same amount of SSL certificates, which admittedly is somewhat of an ops nightmare, but the renewal of Let's Encrypt certificates can be automated and I'm sure someone already made a script for that.
I would imagine that this is a solution that'll be painful to implement initially but which wouldn't need too much maintenance after that and it would allow us to keep the current URL structure.

If, for some reason, it's outright impossible to keep the current URLs, I guess my preference would be topic.shoutwiki.com/lang/Page_name, i.e. 24.shoutwiki.com/fi/Jack_Bauer for the page currently located at http://fi.24.shoutwiki.com/wiki/Jack_Bauer , but before going down this route I'd really want us to explore all the possibilities that allow us to keep the current URLs, because, to quote Tim Berners-Lee, "good URIs don't change". (Unlike a lot of sites, I think we'd be able to implement proper redirects, but let's be real, it'd still be pretty obnoxious, to say the very least.)

In T131#1828, @jack wrote:

I'll throw in my favorite solution, which Skizzerz proposed the last time I spoke to him about this: Let's Encrypt SSL certificates for <lang code>.*.shoutwiki.com, i.e. fi.*.shoutwiki.com (possibly relevant: this StackOverflow question). Looking at /trunk/languages/i18n/, there are currently 371 files in there so it would mean about the same amount of SSL certificates, which admittedly is somewhat of an ops nightmare, but the renewal of Let's Encrypt certificates can be automated and I'm sure someone already made a script for that.
I would imagine that this is a solution that'll be painful to implement initially but which wouldn't need too much maintenance after that and it would allow us to keep the current URL structure.

Let's Encrypt doesn't do wildcards currently. Additionally, one of the major problems we had with switching to Nginx was that our code (somewhere in LocalSettings) meant that the first domain in Nginx's server_name had to be shoutwiki.com, then followed by the wildcard. Multiple shoutwiki.com's are, from memory, going to conflict. Nginx only allows one certificate per server block, so I don't think this solution is physically possible. You're also right; it's an ops nightmare.

Although thinking about it... we might be able to do it at terminator level, assuming we had all the right wildcards. Not something I'd imagine is ever normally done, certainly not easy to do, but may just be technically feasible. Although our terminator still needs a lot of work.

If, for some reason, it's outright impossible to keep the current URLs, I guess my preference would be topic.shoutwiki.com/lang/Page_name, i.e. 24.shoutwiki.com/fi/Jack_Bauer for the page currently located at http://fi.24.shoutwiki.com/wiki/Jack_Bauer , but before going down this route I'd really want us to explore all the possibilities that allow us to keep the current URLs, because, to quote Tim Berners-Lee, "good URIs don't change". (Unlike a lot of sites, I think we'd be able to implement proper redirects, but let's be real, it'd still be pretty obnoxious, to say the very least.)

This makes short URL a nightmare. You know, I'm not sure how we'd even do this from an HTTPd point of view... it'd be easier with a server block for each language, but as noted in the previous solution, I don't think that's possible.

So I'm going to target this for February 2018... it'll give us a bit of prep time after LetsEncrypt launches wildcard certificates in January.

Where does this stand currently?

I updated our Discord on this recently, so I'll provide a copy of that.

[00:35] Lcawte: LetsEncrypt isn't offering the type of wildcard we thought it would so it's going to require more work and URL changes than we wanted.
[00:36] Lcawte: Admittedly, we were poorly advised on it because as I've now found out, the certificates we want are against some standard or something.
[00:37] Lcawte: We need to do it, and hopefully I'll get chance to do it over the Christmas break, not quite done digging myself out of the pile of real life commitments I've had to deal with this year.
[00:37] Lcawte: Or at least, making the initial technical steps and announcements.
[00:37] Lcawte: I'm sure I put that on Phabricator ... somewhere?
[00:54] Lcawte: Lack of SSL hammers search rankings these days, mobile is also sort of depending on some of those URL changes to be fair.
[00:54] Lcawte: It's just going to be... not very fun... to actually put in place.
[01:18] k6ka: At the very least, I'd like for my login details to not be sent over plain old HTTP...
[11:38] Lcawte: Well if you're following the best practices, at the very most all they'll get is access to your ShoutWiki account 😉 But yes, it's pretty much at the top of the ShoutWiki TODO list in terms of major projects. It only gets bumped for MediaWiki releases...

The discussion then goes on to comment on how fast this year has disappeared. We're currently discussing what in particular these URL changes are going to be, because even programmatically creating a new certificate for every site is a bit of a nightmare (mainly because it needs to be installed on the SSL terminator (T132) to enable us to have frontend caching.

Wikia (ahem, "Fandom") has gotten rid of the sub-subdomains for HTTPS on different language wikis and instead place the language code after the domain name. For example, https://sims.fandom.com/es/wiki/Portada is used instead of https://es.sims.wikia.com/wiki/Portada. Typing in the sub-subdomain URL will still redirect to the correct page, but it's not used to serve content over HTTPS.

This I think is similar to @jack's preferred solution, but it makes life an absolute nightmare in terms of actually setting up that short URL...