What's New in Wagtail CMS | Episode 1 | Content Import, Headless Preview & Customizable Workflow

Speaker 1: I'm gonna hand over to our first section and this is from Ollie, my co-founder of Torchbox, uh who's also our creative director, and Olli was responsible for some of the the really initial designs of Wagtail. He's gonna talk about content import. Over to you, Oli.

Speaker 2: Thanks, Tom. Hi everybody. So yeah, this first feature is Wagtail Content Import. It's all about importing articles that you've created in other applications into Wagtail. Which is pretty common because as a use case, because when we create content, most of us stub out an article and write it from there. And normally we do that in a tool like Google Docs or Microsoft Word or Dropbox Paper is my favorite one. And so what Wagtail Content Import does is it makes it easy for you to pull the articles that you've created in these tools straight into a Wagtail page. And I love this feature because it's an example of Wagtail fitting in with the way that we all work rather than trying to impose a different way of working on us. So uh I'm going to demonstrate uh Wagtail content import

Speaker 2: uh by by uh creating a blog post for you on uh Wagtail. io uh which many of you would have seen. This is the blog section here. And I've already written this blog post actually. It's a blog post about recruiting users for for new for testing new features on Wagtail, which isn't an accident because I want you all to sign up to this blog post today as well. So I've created this blog post in um in Google Docs. Here it is. You can see the post here. You can see at the top of this post, it's called Wagtail User Testers Wanted. And uh it's uh it's got an intro here and a uh uh a photo.

Speaker 2: Um if I kind of click on the photo actually you can see that I've set an alt text in there man holding glasses um and and the reason actually another reason that a lot of us use these kind of tools is because they're so easy to collaborate on and you can see that my colleague Tom, even at this late hour, is correcting my blog post. Thank you for that, Tom Thank you very much. And after that there's a little bit more content, it's a fairly straightforward page post, a bit of formatting and a call to action at the end of it. Okay, so what I'm going to do now is I'm going to show you how I'm going to pull that post into Wagtail. So if I go into the back end of Wagtail now. What I do is I create that blog post in the normal sort of way. So this is the admin

Speaker 2: site for the Wagtail. io sites. And I'm going to go in here, I'm going to browse to the blog section. Here we are and I'm going to make a child page within the blog section. It's going to make a blog page straight away because blogs are the only type of page I can make in the blog section. And here's my my page. It's got a title, author. A main image, it's got a date, an introduction, and then a stream field where most of the content will be. So ordinarily what I'd start doing now is I'd start filling that in or I'd copy and paste it from my blog post, but this time I can use this button down here at the bottom right-hand corner and I can click on it where it says import. And it's giving me a couple of options. I could import from a local file if I had a kind of local Microsoft Word file or something, or I could import

Speaker 2: from Google Docs. And you can also configure it to import from Microsoft OneDrive at the moment. And in future we hope to add more sources to that as well. But OneDrive and docs and local of what we've got at the moment. But I'm going to use Google Drive. So I'll click on that. And it's going to take me straight into the kind of Google Drive Finder. So I've done this before, so I've already authenticated. If you hadn't, then it was the first time you'd be asked to authenticate. by by Google there, but I've done it so I can start searching straight away. And this is this is Torchbox's Google Google Drive. So you can see there's loads of docs in here that have got WagTead in. But the first one is the doc I'm looking for Wagtail user test is wanted. So I'm going to click on that and hopefully it's going to pull some content in. So it takes a second longer, but there you go.

Speaker 2: You can see that Wagtail User Test is wanted has been has been pulled into the system The rest of the content on this occasion has been pulled into the stream field. You could configure it to go into different uh into different kind of fields, but at the moment we've configured it to go straight into the stream field. And you can see it's been a little bit clever actually. It's separated the first paragraph into one block and the image out into its own block and the rest of the content below. And if I click on the image, I can see that it's actually imported the image into the image library. There's my alt text that it alt text from the Google Doc. that it's pulled in there. And uh because we're using Wagtail Alt Generator, you might want to look that up as well. It's a it uses Microsoft Content Vision to guess what the relevant tags

Speaker 2: for this uh for this image would be as well. So that's quite clever. But I'm not gonna I could I probably would fix those ordinarily now, but I'm not gonna do that for now. I'm going to go back to my image, my document. Here we go. Actually it's worth noting that another thing that we're working on is an integration with Google Photos and Wagtails Image Library so that you'll be able to draw images directly from there and then from then we'll be able to go on and hopefully develop that to other image libraries as well. But focusing on this for now here's the rest of my article that's been pulled in. You can see that it's retained the formatting and the link at the bottom and looks pretty good. So I'm just going to fix the required fields in here. It looks like I need a date and I need that introduction. I'm actually going to use this This first paragraph for the introduction, and I'll just delete that.

Speaker 2: And now I'll preview it. And there you go, you can see that my article has been created nicely, having pulled that content in from uh from Google Docs, which is pretty cool. And I'm actually going to ceremoniously publish this article now because I want you to all look it up on Wagtail. i. io and sign up to be volunteer user testers. Last thing that I want to mention is the documentation. This this feature is is available right now, Magtail Content Import, and there's nice documentation for it. for it that tells you how to kind of configure sources and all the different things that you can do in it, but it's ready to go.

Speaker 1: I'm going to hand over to uh to Phil and Abigail. So um Phil and Abigail have both been working with uh with with our client, the Motley Fool, and we've got a couple of people from the Motley Fool here today who who have um uh I hope they won't mind me saying that they've been um moving a few of their sites to Wagtail and rather than kind of spending a lot of money on a big commercial system, they have um chosen to invest in in open source, which uh I think is fantastic. And and you know, because what that means is that firstly it means that they're getting the the tools that work for them, but also that these tools become available to everyone, to the whole community. So we've been working closely with Motley Fool on the next feature we're going to talk about, which is customizable workflow. Over to you Phil

Speaker 3: Thanks Tom. So the existing Wagtail workflow is fairly easy to understand. As standard in Wagtail today, an editor can edit a page, but they can't publish They can submit to a task which is called moderation, and then moderators then review this content and can publish the page or they can return it to the editor for changes. This is sort of Wagtail well as many small organizations don't need the complexity of custom workflows or anything more complex, simple is enough. However, for sort of larger and more complicated organizations Managing quality assurance and sign-off can become quite difficult. We're happy to say that on the 1st of August, Ragtail 210 will bring with it the ability for more complex workflows to exist. So

Speaker 3: here's an example of what one of these workflows might look like. So perhaps this could be for like a healthcare organization. So you can see this workflow has got three tasks, allowing reviews from peers, medical professionals and lawyers. And these groups can all sign off on page content separately and an audit trail is recorded. You can set which Wagtail users are able to approve them by using the Wagtail groups functionality. So here you can see editors of the peer review, consultants of the consultant review, and a group called law firmer for the legal review task. You can create as many of these tasks as you want and group them in a workflow and I could have 10 different tasks, could order them exactly how I want

Speaker 3: and yeah, kind of change them around. And I can also have multiple different workflows being used on different pages in one single site. So I can have most of my site using a simple workflow and any specific pages using a more complex workflow where it's appropriate. But even more than that, we've designed workflow to accept custom task types too. So the task type I've explained here, we've called a group approval task which uses the Wagtail groups to define who can approve or reject. And this comes out of the box of Wagtail 210. For those that don't know what Wagtail groups are, I haven't used Wagtail as much. The groups are site, kind of users are assigned to groups and it defines the permissions that those users have. So these

Speaker 3: more custom things Could be things like spell check. They could be things like payments. So you can see here this workflow would have spell check first, which would be an automatic task and would be handled without anyone needing any intervention. And maybe if that's passed, it would go through for a group of approval task for the editors. And then perhaps there'd be an automated payment back to whoever kind of edited that the author, authored the content. The other thing it could do is make use of existing Wagtail plugins, for example, Wagtail Review. So Wagtail Review gives the ability for non-Wagtail users to review pages and comment on them. Where users receive an email with a link to the page preview and can immediately give feedback. So this exists already, it's being used already, and this will work perfectly well with

Speaker 3: workflows as we design them. As I've said, the only task type that comes out of the box with 210 is going to be the group approval task. Custom ones are going to require customization by developers, but documentation is going to be readily available and we're excited to see sort of which tasks are created by the community. So now I'm going to show you what this looks like in Wagtail So you can see here under settings, if you're an admin, you get to see the settings panel and under here there's a couple of new areas. So you've got workflows So here this is listing out the workflows I've got. And on this site, I've got two different workflows. I've got one called Blogs Workflow with one step and it's applied to 10 different pages, which if I click here I can see. And I've got the clinical content workflow.

Speaker 3: I've got peer review, consultant review and legal approval, much like my example. And you again you can see it's applied to 26 different pages Workflows have got three different parts. So from here I could add a new workflow or I could edit a workflow. So I'm going to show you the three parts that can constitute a workflow. It's got a name It's got some tasks and it's got the pages which those workflows will apply to. This workflow will apply to, sorry So tasks can be added or taken away from workflows. For instance, I'll now create a task to show you kind of what that would look like. So I'm going to create a task. Which I 'm going to call SEO. I could choose from an existing task, of which there are a lot, because we've got a lot of testing done on this particular site. But here I'm going to create an SEO

Speaker 3: task. And I'm going to set the SEO team as the only people from the groups who are able to approve as part of this task. And I can then save that and it immediately applies. So you can see SEO tasks appeared here. And actually I might choose, actually I want SEO to be a bit higher up. I want it to be the second of those tasks. So again I can apply that. And you can see it will go peer review, SEO task, consultant review, legal approval. The final part is which pages this workflow is assigned to. So you can see I've got a page chooser and here I can select which pages it applies to. Now when I select a page, this workflow is going to apply to that page and all child pages as well

Speaker 3: of that particular page so that you don't have to go and select every single page on your site. You can select different areas of your site and you can choose which areas have which workflows. So the next thing I'm going to show you is the workflow tasks interface As the tasks themselves are also managed through this this kind of new interface for admins. And here I can see which workflows each task used on and what type of tasks they are. As you can see, these are all just group approval tasks, which as I said is the only one which comes as standard out of the box in 210. But tasks can be edited and created in a similar way on this interface Now, custom workflows build more complexity into Wagtail.

Speaker 3: We need to make sure users don't get confused by this. We've done a lot of discovery and user testing to ensure what we've built is flexible enough to solve most problems. but easy to use and understand. We also followed a principle to make workflows non-intrusive. So if you're someone who doesn't use or need workflows, your experience won't be negatively impacted. For those that are using workflows, we've introduced some new reports which are available to all Wagtail users and again are going to be part of 210. So I'm going to show you what some of these reports are like. So the first one is the workflows report. So you can see here This is showing user the details of every page that's been through or is going through a workflow, what happened to it and why.

Speaker 3: So I've got the workflow name I've got the page, I've got the status. So it needs changes a particular status of a page going through a workflow. And I can see which tasks and who and when and why. I've also got some filtering on the right hand side which we hope will be quite powerful for people. And if it's not enough, you can download everything. At the moment I've got this filtered on news changes. I could shift that and I could just show the in-progress pages The next report is that I'm going to show you is workflow tasks. And again, I've kind of pre-filtered this so it's not got too many things showing and it's not too overwhelming as we've got a lot of test content on this site. You can see that this is kind of focused on tasks themselves rather than the workflows.

Speaker 3: So where this is where performance might be something you might be interested in, for instance, how long are my consultants taking to review pages I could see when it started, how many of them are complete, or how long they've taken to do those things. So the final report I'm going to show you is site history. Which again is kind of a new report which is coming with Wagtail 210 for everybody. And this is something that's quite exciting. So this is an audit trail of all actions taken on all pages across your Wagtail site So again, this report's filtrable and downloadable, but you're going to get every you can filter by every action that exists to be able to do it to a page pretty much. And you can kind of see what's happening and what has happened on your site.

Speaker 3: kind of going back for as long as is as long as it's existed. Now I'm sure we haven't foreseen all the ways in which these reports will be used, but we hope they'll be flexible enough to fulfill most scenarios Now the reports I've shown you so far are all fairly generic. They're not kind of aimed at an individual user. But to help individuals find information around workflow that's relevant for them, we've also edited the home page. So I'm just going to show you that briefly too. So you'll see there's a couple of new tables in here. Users can see more information about the status of the page they've submitted and any pages which are awaiting their review. So here you've got your pages in a workflow. These are ones that I might have submitted. and the status of those things and when those things last

Speaker 3: changed and those which are awaiting review by me as well. Because I'm an admin, I'm getting pages in both sorts. You can still see the most recent edits and look pages too. So I'm now going to hand over to Abigail who's going to take you through some of the edits we've done to the page edit interface to help with workflow.

Speaker 4: Thanks Bill. So as we have been adding these workflow changes into YTL, some added complexity has been introduced. So we wanted to make sure that that really didn't impact the editors. So when we're looking at how that was all going to fit into this page edit, we wanted to make sure that we reconsidered those elements and we didn't just slot them into the existing designs that we had. So this is the current page edit screen, and those of you who use Whiteale may recognise this one. We've got the page title, the page type at the top here, along with a few buttons on the right hand side And we've got this almost full width bar along the bottom which holds your menu, your preview, when it was modified, and also this revisions link as well. So an early principle that we all agreed on was that this top section was going to focus on the status of the page.

Speaker 4: So for example, a page being in draft and this bar at the bottom here was going to focus on the actions. So if I jump over to our new page, so this is the once had some design tweaks happening to it. One of the changes is around the page title. So as you can see, we had the title and we had the page type up here. on the old version. On the new version, we've made this new page title a lot more prominent. It's bolder, it's larger. We felt this was previously a little bit undersold, so we just wanted to make sure that that was really clear for the editors. We've then added in this metabol which holds a bit more information and that is now where this page type lives. So this one is bread page and that there now. So

Speaker 4: we just wanted to reduce the prominence on this a bit because sometimes it can be really handy to have it there. On the old page, up here in the right hand corner, we had this status button. So this would show if a page was live If it was in moderation or draft or maybe a combination of those things as well. And we felt that this button was really trying to do a couple of things. So it was going to be better for us to split that out. So on our newer version, we still have this live button and if I click on that, it still acts as this link to the front-end version of that page. The difference here really comes if you have a draft version. So if you do, that information is now stored in this metabar So here it tells me my draft was saved 21 hours ago and if I hover over that

Speaker 4: it shows me the exact date and the time and it also shows me who it was saved by. So if they have a picture that will show up here And also if I hover over that it shows me their name as well. So if this page is in a workflow and it's in a workflow step, then this draft information is updated I have another example of a page here where it is in a workflow, so it's in this awaiting consultant review step. So it shows me how long it's been there, and again if I hover over that it shows me the date and time This also acts as a button, so if I click on this, it opens up this window that just gives me a little bit of information about the workflow. So you can see it was submitted, then it went through the peer review and it had a comment there as well, and it's now in this.

Speaker 4: next step. So it just makes it a little bit easier to see what's happened to it so far. If this page is in a workflow and depending on your permissions you will get a few extra options in this menu at the bottom So I've got request changes, approve, and also approve with comment. So if I don't think this page is actually ready to move on to the next task in the workflow, then I can request changes. So if I click on that, I get this window and I can add my comments, I can request those changes, and it kind of pauses the workflow. So this page can go back to the author, they can make their tweaks, and then they can resubmit this into the task. The other options that I have is approved. So if I'm happy with this and actually it can just move on to the next task, then I can click on that

Speaker 4: And if I want to approve it with comments, so it'll still move along, but I want to be that little bit more helpful, maybe add some comments for the author or the person who's going to be reviewing it next, then I can add them in here as well. So if I just quickly flick back to the old page, you'll see that we also had some buttons around the privacy and the lock-in. So we've moved the privacy and that now sits in this settings tab. So if I go onto here and set the page privacy I then get this window and I can choose one of my settings. So this is the same four options that you had before, but they're now just in this window here. So if I just choose one of those and save it

Speaker 4: You can see that this live button at the top has been updated, so it now says it's restricted, just to make it really clear to the editor that there are actually some restrictions on this page. The other button that we had up here was the lock. So we've moved this lock down now into this primary action menu as you can see here So if I lock this page, it just means that I'm the only person who can actually do edits on this page now and the page will need to be unlocked in order for other people to go in and make some edits So on this older version we also had this almost full width bar. This had your primary menu, your preview, when it was modified, and also that little revision slide. link as well. So if I go to the newer

Speaker 4: version and if I go to this primary action menu, you can see that we've actually added some changes into this as well. So There's now some hierarchy to this. So the actions that you use the most are down here at the bottom such as approve and approve with comment. And the ones that are still important such as delete but you obviously don't use them very often are there higher up at the top. There is a slight colour contrast here as well, which you might not be able to see over my screen share, but we have introduced that as well as some icons to hopefully make this a lot more scannable for the editors So on this older version, we had this revisions link over on the right hand side, which from some user testing it did show that some people didn't actually know that was there.

Speaker 4: So When we were looking into this, we wanted to improve that and enhance it for editors. So we've removed that and we've now got this page history link up here in the metabar. So this is very similar to one of the pages which was the site history that Phil showed you earlier. But if I click on that It will load up this new page which has all the actions that have happened to this page on it, as well as who it was by and the date and time as well. In the future we are looking at making this into a tab that will sit on this page, but for now we think that being in that separate page works pretty well. So we did make another tweak down here in this bar, so this was obviously quite long before, nearly took up the whole width.

Speaker 4: We've now shrunk this down quite a lot, and we think this just opens the page up a lot more. and hopefully makes it a lot easier for the editors to really focus on the content of that page. A couple of other small design tweaks. We've looked at margins, we've reduced these tab sizes and we've also looked at the font weights as well. We're pretty happy with the changes that we've made overall and we really hope it makes things a lot easier for the editors to use. And if you do want these changes, then they will be coming in Whitetail 2. 10, which is out on the 1st of August.

Speaker 1: Next, I'm going to hand over to Thibaut, our colleague, who's on the core Wagtail team and is responsible for lots of the really cool bits in Wagtail. He's also one of our accessibility specialists, and that's what he's going to talk about now.

Speaker 5: Thank you, Tom. There are lots of good questions in the chat, so I've been a bit distracted by these. I hope we're still on track. All right, accessibility, quite a big topic today. I want to focus on two specific areas in particular. accessibility of the WhiteTail admin for editors and accessibility of whiteel websites for end users. Quick word of learning. This isn't any single feature. This is very much an ongoing effort which we've been working on for the last couple of years now. So there definitely is things happening in each every release, but not a single single change. A quick word about why this matters and

Speaker 5: why we are discussing this now. I I think to me the first thing to say sounds quite obvious but still is that we we do build websites for people and we do want the experiences we build. to be accessible and usable by as many people as possible, no matter how they actually access our content. Since it's called inclusive design, which is quite an established principle and definitely worth looking at if you haven't heard of it before. And the other thing is that when we think of accessibility, uh It's not just improvements for three-minute users or people who are blind. Generally, improvements you make for accessibility do make your experiences more usable for all users. This is called the curb cut effect, which definitely look up if you haven't heard of it before.

Speaker 5: And also something to address early on, which is that accessibility isn't something you can just decide to do or not to do anymore. There are no really clear legal um implications with this in the US. There are well-established laws since quite a few years ago and in the UK since 2018 for public sector. also the Equality Act since much longer ago. So this isn't really something that's optional anymore. And if your website isn't compliant, you'll uh end up like dominoes pizza and beyonce and be sewed because people can't access your content and other pizza or other concert tickets But I don't want this to sound too negative either. To me there really is a cultural shift in the works, in how we perceive this.

Speaker 5: And I really believe that a few years from now, hopefully this should all be past us and it should just be something that's a built-in part of producing content on the web. And hopefully WhiteTale can can help with that as well. So a brief look at the What admin for editors. This is some work we started about a year ago with sponsorship from the UK government, the CMS team at the Department for International Trade. They dedicated some time for us to have clear accessibility targets. I mean for the standard called WICAG 2. 1 at the AA level. which is the most established standard and also the ones the one that uh underpins the laws I was mentioning earlier. And yeah

Speaker 5: not just having this standard but also establishing some clear guidelines for how to test Wagtail auditing WXL and actually making many changes to improve it. So my my my favorite way to demonstrate those changes is just to do a quick before after of the page editing screen. This is the before. and this is the after. I'm not sure how or maybe you can see this over screen share, but at the same time it's changed a lot and not so much, but it definitely feels much easier to scan and easier to follow. even even for me who's not yeah still wearing glasses but otherwise fine. So this is the type of improvement we're considering that does help everyone. And then we've also spent quite a lot of time looking at keyboard support

Speaker 5: three-leader support, making sure that people can also access the white admin this way. And the most recent effort on this front was at a sprint back in Bristol. So just want to showcase a few of the changes we've delivered since then. Lots of people on this very good webinar have helped making those changes happen. Thank you to them. So yeah, just a just a list of headline changes. And this is definitely something that keeps on happening from release to release. So kind of shows the value in keeping up to date with racket releases and yeah, there is much more to come. Now onto white-clicked websites. Personally I think the admin is great to have this accessible, but really what matters the most is to have as much impact as possible for end users of the organization's websites.

Speaker 5: So to me, when we talk about making a site accessible, I think of three different areas. I think of the UX and design of the site, making sure that it's designed according to inclusive principles the build, the code of the site, making sure that we follow quite well established best practices and standards and use as much automation as possible. And then the content, there isn't uh as clear of a guidance uh uh as of yet. Uh it's just emerging at the moment. So I think that's really where Wikid can help you take you to that level where you know that the tools you're using even for content do help you uh achieve those those targets. So we look at this now. I have a brief demo Oops, I have a video version of it, but I'll try to keep it

Speaker 5: keep it uh energetic on the live version, just make it a bit easier. So this is the white page editing UI. Hopefully you've all seen this at least once. And this is the rich text editor. So I want us to focus on this reading age indicator here. This is just one of many ways to help content authors assess the readability of the content. And this is really just based on the sentence length in the editor. So nothing really too fancy, but just uh just one way you can you can use to make sure that the content you do write uh does comply with those targets And this all happens live as you edit the contents, not really something you'd use as a past fail check, but definitely a good tool for editors.

Speaker 5: And I want to show another example of this. Which is this little plugin that is in the YTL preview view? You can see it on the bottom left here. This is a quite well-established YTL plugin that allows you to access those Accessibility checking tools. There is one for headings that allows you to check that your heading order is logical. One for link text that allows you to check that the content actually complies with best practices And so on. So really something that's easy for you to just install on your site and make use of right away. And I want to show one more little demo. That's something that's a bit more experimental. That's not published anywhere just yet, but kind of showcases the possibilities that we have these days with

Speaker 5: things like workflow and also with these editors APIs. So this little demo here adds a spell check feature to the editor where it uh flags words that are considered to be too wordy, flags jargon. or any kind of language you wouldn't want to have on their website. So this isn't meant to replace things like Word. This is just a way for you to have your organization's content guidelines. embedded directly in Wagtail and have this kind of automation of having this just appear as you type. And again this is this is all live so if I edit this it goes away if I edit back this place again So back to my presentation. Just wanted to highlight

Speaker 5: two resources that I think are really helpful on the topic of having content guidelines for your editors. One is from the US government and the other is from a community of practice group based in London. Now onto what's next for accessibility. Again, this is still very much an ongoing effort. So there are two things I wanted to showcase. One is uh a one-pager documentation uh update we we would want to make happen, which will make it very easy for tele implementers to know all all of the things they have to consider as part of rolling out a site in order for it to be as accessible as possible. And the other is just this collection of experimental Flexibility compliance ideas we've we've been working on. And I wanted to showcase one in particular, which is again

Speaker 5: about readability, which is just a way for the editor and Wagtail to display the length of sentences. You might have seen that before. Just so again authors can see this and right away know which content might need further attention and how to make it flow better, which is a benefit for everyone really. And on the CMS admin, just to keep it very brief, there is much more to come. Lots of changes still to do and the end goal is obviously to make it all compliant with the standards we mentioned. And if you want to help with any of this, we do have a dedicated accessibility team that has just started. And yeah, we're hoping to get it going quite quickly. hopefully have a good backlog of things we do want to prioritize before

Speaker 5: Whitehall space. So do join us on Slack if you're interested in this, even if it's just to say which of the things you think are our priority.

Speaker 1: Okay, I'm gonna move on to my sections. I'm taking on the last two, um, which are gonna be a little quite quick. And the first one is around multilingual sites. Wagtail supported multilingual sites from the beginning. In fact, I think the second ever Wagtail site was a multilingual site. But we uh we we tried not to be opinionated about how people would do multilinguage site langu multilanguage sites. Because we understood pretty early on that there are lots of different ways you can do it from the kind of news sites where most of your content is in the primary language, but a few, a handful of pages might be available in other languages. to the sort of sites, maybe more like government public public sector sites where it's a requirement to have all your content available in different languages. And you know, and the and the workflows are are quite different between those.

Speaker 1: However, I think not being opinionated has led to quite a different range of approaches and there have been a few plugins and apps that have sprung up trying trying to solve this problem. And what we've what we've come to realize is that we want to provide some just clearer fundamentals in Wagtail that are going to make translations and localization possible. So this is something we're working on right now. And this is in fact, this is being a lot of this work's been funded by Mozilla, who uh who using Wagtail increasingly for some of the really high profile sites, things like the Mozilla Developer Network and uh foundation Mozilla. org. Hopefully we've got some people from Mozilla here today. And Mozilla is obviously a very international organization. It's really important for them to have their content available

Speaker 1: internationally. So they want to have a good solution for this. So it's been great to work with them on this. What I'm going to show you now is very much work in progress, but I think it will give an indication about the direction we're taking. So let me share my screen. And again, we're on the bakery demo. It'll be familiar to some of you. This is a site that we use quite a lot for demonstrating and testing content. and changes. And this is already a multilingual site. So if I go to the tree, top of the tree, I can see the English version. And I would normally try and show off my schoolboy French, but as Thibaut's here, I will Spare you all that. So in the blog section, I'm going to add a new blog page. So this is in the in the English tree. So I'm going to write an English blog page. My

Speaker 1: new blog page. Very imaginative and um some content from Tom uh in sparkling Pros. I'm going to pick an image. Images are interesting because images are not translated and that's going to be the true true most of the case. And here we've you can configure which parts of your content you want to be translatable and which are just going to be mirrored or copied I think I need to have at least a paragraph blog block here, my first paragraph. And I need to choose an author, which is also a piece of content that won't be transferred. And normally I would review this, but I'm so confident this is going to be a great article. I'm going to make it go live straight away. And so that's live already.

Speaker 1: Before I look at it though, I'm going to translate it And we've decided to split this into two parts. So the the the part of creating a requesting a translation and then carrying out the translation. And that enables some flexibilities around the different workflows. Here we've set up uh in Wagtail the number of locales we want, and this this demonstrates that it's not just about languages. You might have different versions of the same language for different territories. But right now I'm going to choose French only. And that doesn't do the translation, it just creates a translation request. And splitting it into two parts enables us to have this flexibility. So uh eagle-eyed viewers may have noticed the translations item, which is new here. So in the menu, I can now see translation requests. And this is part of the area now where we haven't

Speaker 1: uh we this the the the user interface um is going to be tested and reviewed and improved. But um there's a translation request of that page and in fact if uh if my If I was confident enough in my French, I could type it here, which would be the simplest way of doing it. But more a more serious kind of approach would be using PO files. And those of you who are already working with translations or have multilingual sites will be familiar with these this PO format, which is the standard format for moving translated strings around. And there are lots of amazing tools, both open source and commercial, for uh that translators work with every day to to handle translation. So downloading the file and opening it in your editor or pushing it off to your translation service would probably be the way that you know a Sirius

Speaker 1: uh translation attempt would happen. But um the the best the best approach for demoing is to ask uh robots to do it. So that's what I've done and they've done it already because robots are super quick and now if I go in back into the page tree into the bienvenue section and then the blog I should find my nouvelle page de blog so apologies tivot and I can edit that this has been translated right now uh by google And probably the the you know Google's translation is getting better and better, but it's not perfect, and this is more likely to be a starting point for you to make changes to. But you can see that it's uh it's it's handled my translations for me. It's um just mirrored the content that isn't going to be translated, and I can uh publish that straight away. And have a look at it live.

Speaker 1: It takes me to the English version by default, which is in this case the default language. You can have other default languages, and I can toggle between the two languages. So French version, English version. Uh so this is this is the you know that the foundations and this is work on this is happening very actively. If I did this demo in three days time, it would probably look a bit different. But I think hopefully this shows already that this is going to be a powerful underpinning and it's really our goal that Wagtel is the best open source content management system for multilingual sites. I'm going to move on now to handle the last bit of my talk, and this is about headless mode. Share my screen again. And this is something that we're seeing is an important trend in content management systems generally, the division between the content management part and the bit that displays your content.

Speaker 1: Actually, Wagtail's handled this well for a long time and a lot of people have been building headless sites on Wagtail. I think we haven't done a great job of marketing that and there have also been a few rough edges, which are not really specific to Wagtail, but for all content management systems. The workflows aren't always as straightforward when the front end of your site is separate. And a particular example of that is around previewing. So here's an example of a headless site, torchbox. com. We use Gatsby, pretty trendy front-end tooling that uses React components and generates a very fast static version of your site. We're using Wagtil at the back end, so WagTil generates the content and then Gatsby sucks it all up and spits it out And it means if you have a Gatsby site, you get this really nice sort of liquid interactions between pages. You can see the pages changing.

Speaker 1: But it's it's it happens instantly. Uh if I go to this blog post about Caltech, it just loads immediately. And this that kind of interaction is quite difficult to achieve with a traditional site but it's one of the things that you could do with a headless approach. But the problem is that this is now being hosted off a a different service, something called Netlify. And and when we want to manage our content in Wagtail, we want to see what it looks like immediately because that that can preview cycle of edit preview change is a really important one. So that's that's that's an example of the problem that we've solved. We came up with this not very imaginatively titled Wagtail Headless Preview plugin, which is pretty easy to install and and bridges the gap between your front end and your back end. So now On torchbox. com if I make

Speaker 1: just a spurious change, add an exclamation mark and preview it, it will It takes a couple of seconds loaded because it longer because it has to load it up in the front end and then request it. But you can see that uh it's giving me the preview even though the front end is hosted somewhere else. This in this in a way is probably the the least impressive of all the uh the demos we've shown today because it basically works exactly as you would expect it to. But um I think it's just an example of one of the ways that we are trying to make headless sites feel like first-class citizens on Wagtail. And again, we wiki we want Wagtail to be, you know, really a kind of industry leading solution for for headless content managed sites. With that, I'm gonna wrap up on the on the demo side and

Speaker 1: there's no questions on headless, which is good because we're nearly at the end. To conclude, obviously we've covered a lot of ground. There's a lot of links, and I think the easiest way for us to do that is to share them by email. So I think Lisa should have the details of everyone who registered. So we'll follow up with all the links and references. to the things we talked about today, including things like dates of when you should expect to see these changes in Wagtail. I want to say again how grateful we are for the people who are sponsoring development on Wagtail and making it available for everyone to use. like Motley Fool and Mozilla and and the UK government. And if you think that um improving Wagtail for your users uh is something that that makes sense for you, then get in touch and uh I think it's you know this can be a really good value way of of uh improving this as a tool which is at the heart of your web presence.

Speaker 1: Other ways that you could stay involved in the in the open source project? The simplest one is probably just joining the Slack. If you're already on Slack, then um join the Wagtail Slack and you can get to at Wagtail. io forge slash forward slash slack. We have a new weekly newsletter this week in Wagtail which is um gives an update on all the because the pace is pretty fast so uh the there's lots of updates every week We're on Twitter at Wagtail CMS. And I'll just give another shout out for Oli 's user testing group that went is now available on the Torchbox blog that he published in real time earlier. We're also keen to make this a regular thing. So I think in six months' time there'll be another batch of cool stuff to show and we hope we'll see you all then And I think that's it from us.

Speaker 1: Thank you all very much, colleagues at Torchbox. Thanks everyone for joining. And hope to see you in six months.