Sidebar Translation Module!

Summary:

Shiny! New!

Sidebar Translation Module!

RJB_R 18 Sep 2017 04:30

Hello dear reader! You may have noticed a new block at the bottom of our sidebar. It's a translation module which links to works adapted to our international community of sister sites. Should work across all pages, allowing authors to see where their works have been adapted and for international users to discover our esteemed partners. Pretty cool stuff.

If you have any comments on the module, or encounter any issues, leave a note here. I personally think it's terrific. Credit to the SCP-RU team and Resure for making it possible.

---

Whether you like it or not, history is on our side. We will bury you!

Re: Sidebar Translation Module!

GreenWolf 19 Oct 2017 23:25

Just going to note this here.

Because of the way the module is implemented (as an iframe loading code from offsite), it is impossible to touch the contents of the box with CSS stylesheets, meaning that none of the CSS themes used by various canons and tale series will work with this. I personally just spent two to three hours attempting to find a way to apply CSS to the interior of the iframe, before just giving up and shrinking the div wrapper to 0 width.

As far as I can tell, the only way to properly implement themes is by applying the CSS styling on the backend side, on the site where the iframe is being generated (which obviously can't be done by on-site stylesheets, but could be done by editing the off-site code to inherit its color schema from the page).

Re: Sidebar Translation Module!

Zyn 20 Oct 2017 02:28

none of the CSS themes used by various canons and tale series will work with this.

Could we get some example links for this? I know next to nothing about CSS themes, so I'm not sure which pages to be looking at to see where the translation module breaks.

Last edited on 20 Oct 2017 02:28 by Zyn Show more

Re: Sidebar Translation Module!

GreenWolf 23 Oct 2017 19:26

I already "fixed" this on the Third Law CSS (by setting the width of the wrapper for the iframe to 0, which effectively makes it invisible. Not the best solution, but the only one I can come up with for the moment.) Here are some images though from various pages with the CSS.

Third Law Desktop Appearance (prior to fix)

You can see that the translation box does not get its colors or styles changed with the rest of the sidebar, which makes it stick out like a sore thumb.

Straight on Till Morning Desktop Appearance

Here's another one for SOTM (hub link) which shows how the border outline doesn't get applied. SOTM doesn't apply color changes to the background of the sidebar boxes, so it doesn't stick out as badly.

Mobile Appearance

Here's a couple shots of what it looks like on mobile (or when you shrink the screen width on desktop past a certain point). You can see that the translation box doesn't use the same adaptive CSS as the rest of the sidebar, which makes it overflow the sidebar menu.

Now, the reason why this is all happening is because the only part of the translation box CSS that is actually on the mainsite (and thus can be edited by on-site CSS stylesheets) is the invisible "wrapper" that is placed around the iframe. Everything else is loaded by the iframe from off-site. The content of the box is determined procedurally based on the page title, and then all the CSS styling is applied by the external site. What gets supplied to the iframe (and what gets displayed in the sidebar), is essentially a static image that can't be edited with CSS.

(As an example, this is what gets supplied by the iframe on the Third Law Hub page: Link)

Now, aside from the inability to change the styling on the translation box, loading parts of the sidebar from an external site also represents a pretty major security risk. Iframes can be used to load quite literally almost anything, including malicious code. While I don't want to call the trustworthiness of the -RU site into question, if, for some reason, they lose control of the scpnet.org domain (which could happen due to hacking or a lapse in DNS registration, just to name a few possibilities), then a malicious third party could hijack the site to attack the wiki. Such an attack might take the form of inserting malicious scripts into the iframe code, or making it load incredibly large images to slow down page loading and consume user bandwidth. Some of these attacks could be done in such a way that we wouldn't immediately notice that the translation box had been tampered with.

Security issues aside, there's also stability issues with loading site navigation tools from off-site. If the connection to the scpnet.org servers gets disrupted (which could easily happen as a result of one of a vast number of reasons), then the translation box wouldn't be loaded at all, which would look like this:

What happens when the connection to scpnet.org gets disrupted

My own recommendation, based on my experience with web development, is that the translation box be removed entirely for now until a method can be devised to implement it without using iframes.

Last edited on 23 Oct 2017 19:34 by GreenWolf Show more

Re: Sidebar Translation Module!

ProcyonLotor 23 Oct 2017 20:53

My own recommendation, based on my experience with web development, is that the translation box be removed entirely for now until a method can be devised to implement it without using iframes.

As (co-)captain of Community Outreach, I can assure you that this will not be happening under any circumstances barring a major change in situation.

As for the rest, I will consult with my betters on Technical Team.

Last edited on 23 Oct 2017 20:54 by ProcyonLotor Show more

Re: Sidebar Translation Module!

Resure 08 Nov 2017 22:02

Hi, GreenWolf. I'm one of the SCP-RU administrators and also developer of this module.
You've raised a lot of valid concerns, I'd like to respond here so this information will be available to everybody.

Firstly, special themes. Indeed, technical limitations of wikidot are not allowing us to use any method apart from iframes to implement such complex things. And it is true that the lack of ability to apply wiki css to iframe content makes life little harder, especially when dealing with special pages like canon hubs with custom styling. But I'm planning to add support of the special themes to our backend so every page will have properly styled interwiki block. No estimates yet, planning to complete this by the end of this year. There is a public task that you can subscribe to for tracking progress (https://github.com/resure/scpnet/issues/23). And by the way, incorrect width of the block in mobile version is fixed already.

Secondly, stability. Nobody is perfect, it's indeed possible that our web services will have downtimes in the future. I'm planning to add some additional styling both to the backend side and to wikis to completely hide the block when our server is unavailable.

Last but not least, security. Domain itself (scpnet.org) is registered via Amazon Web Services for a few years in advance with autorenewing enabled. Access to the domain control panel is limited to one only person with two factor authentication enabled.

Domain leads to a server hosted by a big company with good reputation that works in this industry for many years. But we still planning to move to EU-based datacenters (Linode or Digital Ocean) in the next ~6 months to be faster (in terms of networking latency) for the majority of the scp community members around the world.

Access to the server is limited to one person's private key (password auth is disabled), it is running latest stable system (Ubuntu Server 16.04) with automatic security updates and some additional measures for intrusion prevention.

The only non-system software running on that server is our backend itself (coupled with battle-tested nginx web server). It is opensource (https://github.com/resure/scpnet) and uses latest stable runtime (nodejs 8.9.1 if someone interested) to power things up.

Web server & app logs are not being sent to any sort of external analytics services, I'm using them only to extract very basic things like current and daily service load. Logs are being rotated (= deleted) after a month by standard system tools.

Honestly, I'm much more concerned about safety of the Wikidot as a platform itself than about our web api (and the fact that they are placing mimic ads on this wiki is just terrifying to me).

Last edited on 08 Nov 2017 22:09 by Resure Show more