Beyond Po: How to Make Django Work... by Cho Garcia & Payam

Speaker 1: Come on, no.

Speaker 2: So this is my first time speaking in a conference and this is really impressive although not much people here now and that is great for me as well as you can imagine. So with this talk um I basically aim to provide tips and tricks from my experience working with right-to-left languages. And I think everyone knows how to make Django work with a multilingual, like multilingual site, but not um maybe not everyone with a right to left where everything needs to switch and everything needs to adapt for them to to to read and work with it properly. So I will address scalability uh settings very briefly

Speaker 2: because Django docs are great. Direction in text editors, characters, encoding issues, especially with Python, Python 2. 7. And uh different system uh for calendars. For example, for my own experience I work with um So my foundation work focused on Middle East countries and North Africa countries. That means sometimes we need to work work with Persian and that is right to left and they do have a different calendar. So all of that we're gonna address in this talk. URL-based language and finally some front-end

Speaker 2: tricks. I really hope this is helpful for you guys and any feedback, questions, comments will be much appreciated. Okay, so a bit about me. As um you said I'm a UX designer and uh self-made for stack developer so everything I learned I learned for myself uh during 10 years coding because I love coding and the last four years working with Django and that is a pleasure since I met Django. Yeah, my my company is a small media foundation, it's a non-profit, uh based in London, providing research training. technology and in at risk communities.

Speaker 2: Um Okay, so there we start. How many of you guys have worked with uh Django and right-to-left languages? Yeah, not that many. That's good. Um as very well stated in Django Dogs Translation depends on the target language and formatting usually depends on the target country and that is Totally correct, right? Uh different calendar system, so we really need to know what the target is, what the audience audience is. in order to address um uh interface and problems

Speaker 2: uh for them. Um So there you go. Plan, plan, plan. We need to um know what the client uh uh want. They usually don't know what they want, so we need to actually determine what they want, how many languages they are gonna have now and in the future That means your system needs to scale obviously and it needs to be ready to add more languages in the future in especially if they are right to left. Regarding the content, are the translations gonna be linked? That means they are gonna translate side by side or they are gonna be totally separated, that means we are gonna have

Speaker 2: same model but they can create uh for example a Persian article or an English article um So the answer to these questions determine the good approach that we need to choose on the on the side Actually having a multi-site with Django sites that is gonna solve some problems that is gonna cause another many problems. That means you're gonna need to have different settings and that is probably in most of the cases from my experience

Speaker 2: a pain in the ass. That is because, for example, uh a recent um um project we had, it was a really huge, massive database that we needed to migrate and we had two sites for uh Farsi and English, Persian and English. And in that case, uh running like 10 Django management commands was really a pain in the ass uh problem. So actually You need to think, I'm not saying that the genocides are they are good for different purposes, but uh you really need to know what uh you need what your approach is and what is the right uh solution for you according to your specifications of the project you are working on. Um

Speaker 2: we could consider having one language, one app that also works. That means removing Django size but having one language and one app and select them uh with the URLs that is uh a good approach or shall we consider a pseudo domain based which is essentially the same but uh you know uh just different settings for nginx for deployment or using um uh packages like Django subdomains or whatever you want to use to set the the the subdomains properly. And the last point in here, should we translate URLs?

Speaker 2: From my experience is not a good idea. Generally talking is never a good idea. And that is because imagine Persian is not a Latin character language. That means you're have a huge uh Unicode strings in your URLs and it's gonna be really long and really ugly and no one is gonna understand what that link is So it's not a good idea also for Google and for the SIT system itself. You want to keep, you know, because it's a multilingual site, you wanna keep your your absolute URLs. preferably in the main language, a Latin character language, for example English, and then have your

Speaker 2: um different URLs for for the different languages. Again, uh you will also want to use for non-Latin uh languages um in uh absolute URLs something like IDs uh for the same problem and avoiding Unicode and loan uh um URLs and also for sharing proposes. social media and stuff. So we usually use IDs at the small media. So all of these considerations obviously depend on the specifications of the project.

Speaker 2: I would like just uh point a few things that you should do and you shouldn't do. I will I always think about the simplest implementation. Don't overcomplicate things. Keep your uh system and dependencies as simple as possible. Try to reduce complexity as much as you can whenever you can. So in that sense Add a translation approach that does not impact the core of your system and this means add translations without changing the existing models or views this will cause less pain in the inf if if you modify your your component that manages the translations

Speaker 2: in the future. and you also need to support uh inheritance of your models. You also will consider to store translations in the same table just to avoid expensive joins when working with big databases. That's another problem we had um and it was a really big one you know especially in the in when migrations are in the admin where you have uh less or many inline models so in that case you probably can build your you know own views or own anmin and that is that means you need more time

Speaker 2: And again, don't translate URLs. Apart from other things I will mention after, this does not work for non-Latin characters. as I said, yeah. So yeah, essentially having your specifications in mind, choose your right component. to handle painless model translations or write your own approach having all of this in mind that you don't you want to have your component for translations a part of your main core uh system. There are some solutions out there

Speaker 2: that you can choose or maybe you can not because you don't like them. I will say that the first one is model translation that is the less obstructive. That means you don't need to uh edit your models or change anything. It works with a registration approach. where you register your files and that's all about that. HBAT uh you need to modify your your model And uh keep in mind that this uh does not support many uh Django admin features. So you won't be able unless you you actually develop that to support it, you won't be able to search fields, translate that fields.

Speaker 2: And then the last one is Parler, it's very similar to HVAT. It stores all translations in a separate table. That means probably expensive joints again. So again, depending on your specifications. From my personal experience I will refer to have them in the same table. So then query sets are much easier and faster. faster. Obviously you can perfection all of that but um again think about scalability in mind Settings very briefly. Um

Speaker 2: Your local mind will uh have to be there and that is after the uh session and before the common all in Django Docs, I won't say anything that obviously is I think is active by default, that's cool. And then add your languages And you notice here the EU get text lazy. What's the difference of you you get text and you get text lazy. So the the first one is um mainly from forms um or models the code the code uh of these definitions is only execute once

Speaker 2: mostly on Django startup and um every time you access the name of the of the attributes on a model the string will be new translated. So you might be looking at this model in different languages since Django was started And the other you get text uh is mostly for B use and function function calls. So every time the view is called will be newly executed so you will always get the right translation fitting the request. Right, so here a simple thing, welcome to my site, and

Speaker 2: that will be collected with uh Django messages. uh command. So here's where the font part starts, the direction. The third question is do you really need Django admin to meet right to left? That is supported actually, but since it's a multilingual website and they need to translate I mean it's most in most of the cases it always depends on the your specifications, but you probably don't and uh you probably wanna have just this relationship by side. They can't translate if in the case that the context is linked or you want to have you just create uh

Speaker 2: the right to left items in a separated uh Django admin view where you actually can switch the direction of the form, just the form. And that means it's really annoying for them. It's not that annoying when they have a text field to write in the wrong direction for them, but it's And text editors like that, they need to have the right uh direction. So that is quite easy to do with the settings of the text editor. You obviously need to choose one one that supports right to left. Uh CK editor. Um all cool.

Speaker 2: And that is the bit actually you need to just change the language. This approach will work perfectly if um the the content is not linked so the same model can be you know Persian or English they can just uh select the the language and then change the direction and then save the the item and that's all. So some issues. Um yes, I've been working with Python two point seven, but uh I'm migrating now and that is uh uh that means a lot of issues with um encoding

Speaker 2: um So you probably will get this nice one, this Unicode, the code error. I I got that many many times and uh drove me crazy actually So there is a really really good article. I think the the best article I found, which is that one if you want to check out. is Derek Dahler is a really good article that explains easily how you can replicate this. Obviously I've been replicating this every day, but So you set you set up your uh variables, right? Um You plug in a Unicode

Speaker 2: into another Unicode that works fine as you can see. You plug in UTF into another UTF. That's worse, no problem. You can plug Unicode into a UTF uh byte sequence But plugging a UTF string into a Unikid doesn't work so well. And that is one of the cases where you you get that nice one So again, that's the article if you wanna write that down. If you don't want this trouble, just migrate to Python 3 Solution.

Speaker 2: If some variables are byte sequences instead of Unicode objects, convert them to Unicode objects with decode. before handle them. So as you can see there Python 3 solves this problem by becoming more explicit. String literals are now Unicode by default, while byte sequences are stored. in a new type called byte. Dates, this is a really fun one too. So this is today date, right? Yeah.

Speaker 2: Exactly. That is the Jalili calendar, the Persian calendar. That means they they need they need to select dates like that, right? And the Jaguar Django admin. So as easy as possible, you want to provide them with the tools to select that. I will recommend their widgets. uh date pickers that supports um um halili calendar and many other different calendars. But I won't recommend that because you want to minimize your pain, right? And you will end up probably with problems. So this this library

Speaker 2: specifically for uh uh Jalili calendar And uh it's most of the cases that will just provide a drop down, you know, day, month, and um and year dropdowns and then when saving convert that with this into the our calendar we go Grigorian calendar Let's talk about international internationalization and euro patterns. Append a language code or fix that's most of the cases you want to do. You can also can do subdomains. So that's cool, easy.

Speaker 2: And uh about translating URLs again. There's a big warning in Django Docs. In most cases is better to use translated URLs only within a language code prefixed block of patterns using IETN patterns. This is to avoid the possibility that the translated URLs cause a collision with a non-translated URL pattern. So generally talking avoid translating URLs. You want to keep the same for all languages in a main language, in a Latin character language, and then serve the rest with. So cool front-end tips that um

Speaker 2: um we find out pretty helpful and I hope is also for you guys. So this is simple. Yeah you can get the current language. You can also get the direction of the current language The actually the get current language uh direction is it returns true or false. So that's why you can see there if blah blah blah RTL or LTR, right? So you can also make a template tag just for illustration purposes. Here you can see that I'm selecting the dynamically when the templates are rendered that append

Speaker 2: the RTL or LTR that means you can actually use any um task runner like Gulp or Webpack or whatever and compile your SAS and your JavaScript files like that and then just uh selecting dynamically depending on the uh language Um and here's some SAS um good things and really easy actually, but uh is good to mention. So imagine that your app dot rtl uh sasfile is your entry point for your gulp to collect all of them or webpack and it's that is where you set it's right

Speaker 2: to left true a different font size because usually they need uh a bigger size and then you can import your you know a specific uh right to left uh styles for that language in the other way for the English you can for the other direction I mean you can set that to false and then import your specific SAS easy. And here the sax seismic sins um can probably decrease your um Development time by 50%. That means you don't have to write different styles for the different for the two directions, right?

Speaker 2: So you can use that nicely and say include margin left value. And that will actually do that just that check and apply left or right depending on the direction. So that is pretty cool and really easy to use. Um so yeah, that is my statement. Anyone can make the simple complicated, but creativity is making the complicated simple. Think really simple and achieve your goals and

Speaker 2: don't be in trouble. Thank you Thank you.

Speaker 3: Yeah, we do have time for about two questions.

Speaker 4: So my question has to do with model translations. Um have you either had the opportunity or run into any issues with translating um maybe models from third party apps that bring in migrations that you don't control. Have you guys added model-based translations to any apps that are reusable apps that you've installed? um from outside the project.

Speaker 2: If it it depends on your approach, right? And that what I mean about um

Speaker 4: so I'm using model Jenj Django model translations.

Speaker 2: fields, right?

Speaker 4: I guess the yeah so the the conflict is that if it's a if we add a translation that adds migrations to add fields. But then but then you have migrations. But if this was a reusable app

Speaker 2: In that case you probably want to extend that model, create your own inside your app, and then do the installation, right? So you import the, yeah

Speaker 3: Perfect. Uh

Speaker 5: thanks a lot for the uh presentation. Um so question and this is sort of like I this is is just more about like translations in general. Like I've noticed like a lot in the last couple years that uh browsers are getting better at identifying that it's a different language displaying on the page and they'll prompt you to say like okay hey you know it uh looks like this page is in French but we're you're English do you want us to do the translation? And I'm wondering like uh how much if you know how mature that is and 'cause obviously, you know, like for for cl clients it might uh it cost money to you know do all these translations and that they like the idea of just having an automatic thing and and where that's where the state of that is at.

Speaker 2: That is probably not a good idea. You mean translation on the fly, right?

Speaker 5: Yes, yeah, like

Speaker 2: is that is usually not a good idea because everyone knows that for example Google Translator uh does not translate properly, right? Especially w uh for, you know, Arabic speakers or

Speaker 5: like idioms that are in the language.

Speaker 2: So even to English to Spanish sometimes is really fun. So it's it's not a good idea for UX from a UX per perspective, you know?

Speaker 5: Okay.