@ThatAndromeda I'm not sure what priority this task should be so I'll leave it to you.

I think this should not be blocking beta. When we have someone working on a translation in an RTL language, this ticket will become an issue, but until then it's a lot of work for no benefit.

Feel free to re-prioritise, I think this is one I left because I didn't understand it!

Should we consider whether the entire interface should be reversed? This is done on Wikipedia for RTL languages as far as I can tell. Perhaps it doesn't need doing until the full UI/UX overview, but noting here for now anyway.

@Samwalton9
So I've done a fair amount of research on this. Wikipedia does its interface flipping on the fly by using a php port of the cssjanus project. That basically takes the source styling from an ltr stylesheet, runs it through a program, and then returns the results. If that sounds familiar, it's because that's the strategy we're using to convert between wikicode and html for editor descriptions (at least in staging).

The difference between those descriptions and the stylesheets, is that the content is already baked into the django mvc, so it's easy to manipulate dynamically. Currently, css and js work a little differently. There are a few options. We could:

• start using templates for (at least rtl, maybe all) stylesheets and cache them like the editor descriptions. We'd write some custom wrappers to call in the templates, which would run uncached assets through the conversion process on page load.
• integrate the generation of the rtl assets into the django build process using something like django npm or writing a cssjanus compiler for django-pipeline
• add a decoupled step to the deploy process to the build, using something like gulp-cssjanus and just expect the files to be in the right place.

This will involve a bit more tooling work than the original idea of using the user contrib version of the current bootstrap template. There will still inevitably be bugs to work around, but it will lower front-end maintenance, and the process would be in line with what the rest of wikimedia is doing.

Quick update: I've got a solid start on reading the ltr css into css janus, and flipping the css. I'm a nodejs novice, so I'll need to fiddle with it a bit to direct the output to programmatically named files that can then be referenced by the django bidi machinery.

I'll be happy to help with testing this, but I'll need some guidance because I'm not familiar with the platform at all.

@Amire80 We'll be adding a partial Arabic translation into the platform soon and would definitely value feedback on how it's looking. I'll update here when that's the case :)

@Samwalton9 In a dev branch, I've added the partial Arabic translation and fixed up numerous issues that were apparent to me both on the RTL rendering side and the translatewiki "add languages from the translation files" side. I can see that we have the additional issue if we're missing a translation for tags or descriptions, we're not displaying anything, rather than defaulting to the English version.

Okay, I've got the issue with the empty values resolved so that we're defaulting to English when there's no suitable translation. The biggest issue I now see is that our pipe delimited tag list is running into the blue tag bullet when there are a lot of tags. Working on it.

The tags were running over the bullets because the bullets weren't in the right place. The background-position css attribute must be explicitly set for CSS janus to modify the position of those images. Default is top left. That issue is now fixed in the dev branch.

@Samwalton9 I've got the (very) partial translation with the current RTL implementation up at
https://twlight-staging.wmflabs.org/

For anyone interested in testing, you can make any number of actions or applications on staging, the site is purely for testing.

I can't speak to the arabic portions of the site, but from poking around it looks to be working well! Only thing I noticed was the "Hi [username]" greeting in the top right isn't displaying properly for me on my staff account, because it ends with a close bracket. It reads !(Hi, Samwalton9 (WMF. Seeing the same thing on partner pages with :(Language(s. Suspect the latter isn't really an issue, because it should be translated, but usernames won't be.

Yeah, it's because the username is part of a larger block of text that's marked for translation.
https://github.com/WikipediaLibrary/TWLight/blob/b249eb48b0af54f8c0e53b3500495c452216aea5/TWLight/templates/base.html#L76

That's going to be an issue in any template that has untranslated variables that may contain punctuation within in a translated block. The correct thing to do would be to exclude the variable from the portion that's marked as translatable, but that would take some clever template rejiggering in many places to achieve.

I'd like to go ahead and merge in the current rtl code so that translatewiki can begin work on rtl languages as soon as its ready.

I'd like to go ahead and merge in the current rtl code so that translatewiki can begin work on rtl languages as soon as its ready.

Sure, that makes sense.