 Yeah, so, the idea was to, it's a business case, so well, welcome to developers too, but we'll talk a little bit with technical things. The idea is to talk about publishing industry, and it's specifically one example from France. Well, so just the world, well, we are kind of doing a lot of websites, and, oh, yeah. So, we wanna talk about the one old French press group, which is called Le Monde, El Mundo, probably in Spain. It was created just before the war, you know, all this stuff with France and war. In 1944, and now it is a quite big organization, media group, publishing group. They publish daily news with Le Monde, which is not running Drupal yet, but also a lot of magazines, weekly, monthly magazines, there's a small part of them. And they decided at some point to change their technology stack. It was a very old custom development based on PHP and several layers of PHP with several databases all around. Actually, publishing itself, so we have actually two magazines. The first one is Korea International, which is, you can go and see. It is already up and running. It's all French. The thing with this magazine is quite, the overview articles all around the world and different magazines, and then translate them into French. So there are specifics due to this workflow. We'll go back to that later. The second magazine also is Tillerama, which is I think one of the number one websites if you want to check your TV program, but they also have a massive amount of content about everything related to culture. TV series, theater, spectacles. You have everything. You have a lot of content about authors, actors, articles, news, movie reviews. It's in quite old system. Again, a lot of PHP stack, different databases, et cetera. So as any publishing industry, they are facing the problem of revenues. So they sell less and less paper and they don't get enough money from the digital. So they have to obviously increase their sales at any, in any ways, but also decrease the cost of their system. So the idea is you have one journalist writing an article, spending days or hours, depending on the quality. And then you have to reuse it as much as possible over mobile, Facebook, Apple News, your website, your partner website, but also print. So they launched a larger, it was two years ago to create a B-media CMS, what they call it. So the idea was to create one standard system for all their titles. A CMS, a content management framework that covers all the needs of all different magazines, which are quite different, as you can imagine, Korean international, they have their workflow translating articles from other magazines. You have Tellerama, which is basically talking about TVs and they have a lot of content arriving from external data sources, but still they need the same. And the thing, and there was the first movers in France, I don't know from the rest of the world, but in France it was the first movers to say the digital will pilot the print, and not the reverse, because usually groups in publishing, but they do, they have their legacy systems used to print, and then they send an XML feed to feed the websites. This is usually how it works, I don't know if how it works in your countries, I don't know if you work with publishing company, but well, it works like that in France. And the idea was they want to reverse that, and it's a very huge change, because from a technical point of view, it's nothing more than just reverse sending one XML to another system, but from a culture point of view from the company, it's enormous shift because they have to force journalists to work on the print, for print journalists to work on the web. And well, so they launched the RFP, but during the RFP there was a very long six months RFP process with a real competition, real audit of different solutions. So the first one they was looking for was Symphony, because this was suggested by their legacy vendor who created all the multi-layer cake of PHP staff and say, okay, we remove everything and we redo everything in Symphony. The second thing was ADOS media-based internal team and with Symphony and Node.js guys working on the CMS currently used by LeMonde.fr, which is a daily newspaper, which quite different. And this last one was us with Drupal. So actually it was a very long decision they tried and when they analyzed all the things that have to be done to support their magazine, they finally selected Drupal because it cost them less because ADOS media and internal system was more designed to create small news every day, not magazines, not long term things, not media management and their legacy vendor, I don't know, maybe they don't like them. Anyway, what we want to create is something like we have different data sources that are really important. We import images, video, feeds of content from different sources and then we have journalists who create articles too and publish them then on print system using InDesign or QuarkXPress because obviously different magazines use different printing systems. The website is quite normal. We didn't go for a headless Drupal. It's classical website with template generation, nothing new and a set of mobile application. The websites themselves are responsive but there are also a couple of mobile applications that will connect using services and get the content. So Drupal acts like a CMS but also like a ETL platform taking content from different parts. So what is so different when you are talking about publishing in print? Because when you look at the website, you think it's quite easy. You have articles, you have content types, you have media and that's all. So you take open publish distribution and you install it and done. Well, it's not quite that actually. You have several things. Obviously when you're doing magazines, the media is extremely important and they buy a lot of pictures from different sources. So you have to be able to manage in central way all the licenses for the photo. So if they are using licenses, they can use it from one date to another date and once it's finished, you have to unpublish it from everywhere. And the same media may be used in several articles in the same time or several different content types. So you have to be able to, you cannot use IMCE, you cannot use media, you have to create some specific media management system. Obviously HD print image conversion system, it's quite complicated because the photos are about several megabytes, but 20, 50 megabytes, 40 megabytes, 100 megabytes and you have to be able to upload them in an efficient way, convert them and also extract exif metadata. Metadata is extremely important for them. So when you take a photo, they don't want to feel it. They have hundreds of photo for an article, for example, that they can select from. So when you import them, you have to take all the metadata. Who is the copyright? Because you have to note them, you have to quote the copyright, et cetera. Another system we discovered that actually we didn't think before the RFP process, but it's so obvious is the offline mode. Actually, when you journalists create for the web, if they don't have any internet access, it's not quite a big problem. They have some delays, they can go outside or whatever, they can create your articles or whatever. Well, there will be no article for three hours on the website, no problem. But if they don't have internet and they have to print magazine, the press and the printing system cannot wait, you have 200,000 of magazine to be distributed all around the country, so you cannot wait even one hour and there is no delay possible. So whatever happens, even if they have free internet connection in their offices from three different providers, one is ADSL, one is Fiber, whatever, Satellite. But even then, there was one time or two times per year, there was no internet in the office for any reasons. So they have to be able to print anyway. So they have their printing system inside the offices. So we have to be able to manage this offline mode. It's quite complicated in Drupal, too. I've said about external data sources, just to get you an idea, we are talking about hundreds of thousands of nodes synchronized every day because we have all the cinemas, all the movies, all the agenda of all cinemas and all movies. We have all theaters events, you have all cultural events and many other content coming from an IFP, for example, rotors, we all synchronize them and there are a lot of content. And well, the easiest thing to develop was the InDesign integration because actually that was the most scary for us because we don't know how to create plugins or whatever, but it's quite easy. From a technical point of view, you just export an XML to InDesign and then you have a small InDesign plugin that takes your XML and put it inside the templates. Another thing you have to think about the issue thing, like on the website, on the media thing, you don't, you just have a fluid of content with nodes and tags and things, but when you start to think about print, you have to assemble them in issues. So this issue thing is quite important because you have to arrange your article inside issues. And you have small things like char counters because in print, you cannot like unfinished scroll. You don't have scroll, you don't have panels, so you don't have views. So when you generate the content for a page, you have to be careful that there are enough space for that. And it's not easy chart counting and not working because obviously based on the font size, the place of the images, it's all combined. You know that you have some place for that, but we spend like a couple of months just to work on this chart counting system because it's really complicated because you have to not only say the limit is 100, is the limit is 100, if the font used is this size, and you don't have an insert of if the insert, but the position is there, then it's 150, et cetera, et cetera, et cetera, they have hundreds of rules like that. And finally, you also have to think about workflow because the workflow involves real printing. At some point on Drupal, you have the workflow, it's very easy, validated, I read, okay, it's okay, next, you have whatever. When you have print issues, at some point it arrives in design, it generates a PDF and it goes back to Drupal for the final validation. So this again, you have to think about that because it's important. But anyway, now they are running since I think February, so it's a couple of months. I think they are extremely happy and they really see optimization in their resources usage. So also, back office is quite important. We created about 150 pages requirements, documents, specifications in the wireframe just for the back office. This is how the back office looks in terms of pages. Why it's important because we have about, I think 50 or 40 content types there. There is a lot of small things like reviews, film reviews, authors, et cetera. So you have to work on the back office, it's really important because the guys are using it daily and they cannot wait or cannot be retrained or whatever. So this is, it's not that easy. You have to think a lot and spend a lot of time. I think we spend about three months just on the back office. Then in terms of architecture, it has to be like bullet proof because again, it's like an e-commerce. If the e-commerce website doesn't work, they lose money. Here, if you don't print one issue, again, 200,000, they all paid in advance. Distributors are paying in advance. There are millions of euros each week, which maybe. So we created a kind of robust platform using all high available, everything is on different data centers. And one thing we tried on this for the first time, it was quite good experience. It really, I think you should use it. It's Galera Cluster, which is a MySQL cluster and it really works perfectly well. It's master, master cluster. We have free servers working on that so it solves all the problem with classical master sleigh thing. And it's quite efficient. Then the offline mode, we still are using the experimenting with the two because we implemented the two systems just to test which one is good. So the main problem of offline, you have the nodes, they have one Drupal installation online, like in the data center and one another Drupal inside their offices. So the question is what happens if they usually everybody works with the online and the internal is like recovery plan. But the question is what happens if there is no more internet? So they start to contribute on their local server. And then internet goes back, but the problem that we have a lot of content which arrives from data sources, comments, user reviews, user accounts. So how we re-synchronize. So let's see, it's a very old problem it solved on Drupal 8. It's common to every Drupal 7 installation. So today we are testing the two solutions, one small one with services UAD and the queue. So we accumulate all the changes or all the things that have to be synchronized in the queue. And when internet goes back, we send it to services to the other node. Another one is using deploy content model which kind of the same with a little bit more packaging. I can at this stage, I cannot say which one is more efficient because we didn't have any internet issues. So we have to plan in a recovery test plan, but we are very scared to do that. So we try to do it later, later, later. So you will see one day there is no magazine in France named Korea International One Week, so you'll know why. It was a test. Another thing is like they needed to be able to deploy the solution over different magazines. So we have the big one, Telerama, but also a lot of other titles. So the idea was to create a distribution so they can reuse it with their internal teams or without teams, reuse it across different titles. So this kind of classical thing, we have this distribution with different items inside and you clone your installation profiles, whatever. But there is another thing that they ask it for is how to, because the problem with distribution is good when you set up a new project, you build a new project, you copy the distribution, you configure it and you have your new project. Good. What happens if the distribution gets updated? How you can mix updates from the distribution, the central core or whatever, call it as you want and your local sites and your instances. And the more complicated thing, so we created them this architecture using Jenkins and Dockroot, I think Dockroot is on GitHub, it's open source. So the idea that they should be agnostic from the hosting thing, so all the websites can be on the one single Dockroot, on several Dockroots, whatever. We are quite agnostic for that. We have there's our Git core. On the left, you have your Drupal core, you have our distribution models, everything. And then inside each site, we have only model themes and libraries and tools for deployment. And the idea is that each site might be developed by us but also by other agencies, for example, small magazine, we are a little bit too big for them, so we'll probably work with a freelancer or a small company, but yet the company will still work on the common core and get updates. They cannot commit on the core, they get updates from the core, but each site is independent, so they can override views if they want, they shouldn't, but they can. They still are isolated. They still can get logs and the FTP and backups from the central thing, even if they are on a multi-site platform hosting with one Dockroot, they don't see it like that. And we offer them all the set of tools to get their, set out their environments locally and it's kind of good. And we actually, we don't inventing that for this project, we reusing this platform, the system for different clients and it works quite well. We have over, I think over 150 websites on one of them, Sangobao. So we also have GitLab to manage all the things. So now I saw that GitLab released an eight version continuous integration. I didn't test that, so maybe it's good, but today it's Jenkins and GitLab. And we also offer some automatic testing then. So this is how the site factory is working inside. So it's quite good and I don't see there are many, many different solutions, but I think all of them are using most of the same things. Maybe you can change Jenkins, but something else, but anyway. So just to give you some examples too about print web, so actually you can create starting with a web version or a print version. And then you go through the process. So actually there is print and web but just two nodes that are linked. And there are some differences obviously. So we created actually, this is a web dashboard, classical dashboard, but the filters and the background, not the background are not the same. So we have one dashboard for the web, one dashboard for the paper and one for everything. So the filters, the way you search for the content is different. And when you go, well actually it's not really, you don't see the differences between background. Yeah, what's that, different colors, I'm sorry. They also, yeah, the way of searching for the paper, it's quite different. You search by issues, by printing categories, but it's quite different. But at the end, you have your workflow. So when you create your new article, you can, there is a complete workflow and you can split at any moment. So if you created an article in web, at any moment you can clone it and start a print branch. This is the idea. So you can clone at the latest stages. So the idea is to not, you have to rework. Still you have different version of your same content. But you wanted to do it as late as possible in the workflow. Why different version? Because, well, it's obvious. Links, videos, assets are not the same and even the content you can put more charts in the web page rather than on print. You don't select the same pictures because for example, when you send your content for print, you will send it with, I would say, like 50 different HD images. And then the print, the guy who is responsible for the layout, he will select one or several images on the web you can put on the gallery, whatever. So for the media, we are still using assets model which is we kind of maintain that, well, more or less. But at least we maintain it for the client internally. We don't never have time to release new version, but yet it's kind of a new rewamped version of assets where we have license management and the assets, it's like Scaldi, they are two models you should use. I think Scaldi or assets, whatever, not use media for Drupal 7. But you have all these entities, you can drag and drop your content inside Wizzy Week and it's still, it's not HTML, so it's still an asset code which could be converted, rendered as HTML. You can also drag and drop them in reference node in structured content like anything. And you have videos, photos, whatever. You have also quotes, you have Twitter status, whatever. So it's media assets management and not just photos. Quite important for magazines. So the workflow, well, I don't ask you to read carefully on the workflow, but just to give you the idea that the workflow is a little bit more complicated for a big publishing platform with using print. We have several states like draft to be translated. This is something specific to the Korean international because they translate articles from outside. But you also have translated, edited, validated, corrected. The page version, this is with the PDF from the print and then published. So, and it's extremely important because we discovered that how important the workflow it's like political thing, like you either validate or have to validate. Even there is nothing to validate. You have to push the button. So the thing is that actually we also discovered that the change management was the really, very big thing you have to think about also. The importance because, and this is something we didn't think, we created the nice solution with workflows, with publishing, with importing content, exporting. We also migrated about half a million of nodes from legacy systems. This was nightmare like cleaning up HTML, crappy HTML and putting in structured content. It's just, never works. You have to replay and it takes four days to migrate and when the release date arriving, you have to no more four days. So you try to write code directly in SQL. You shouldn't do that. But the most challenging thing was the change management for the journalists, the actually guys who were using because before you there was a bunch of geek guys who was using the web, publishing on the web and then you have this enormous newsroom with old guys wearing beers and they use only one tool, really. And they will never, ever go out of this. And it was really extremely complicated for us while using web CMS every day. It's easy. You look the interface, there are not so much fields and the wheezy is like Drupal. No, it's not like Drupal, but it's not like Word. So that was, we spend a lot of time to try to convince, to learn and you should never underestimate this part because the actual users, they will report to the boss who actually will say the project is a success or not. Technically it will publish and you can print but if the users will complain saying I don't like it, it's enough, then the boss will hear I don't like it, they don't like it, it's bullshit. So all you did is just crap. So really be careful with that because, so in terms of numbers, and this is a thing, last thing I have to say, so we have two sites so far. On the first time we have 15,000 nodes and on the second 500,000, we have about 20 content provider different, yes? So, can I ask you a question? Yes, yes. So you ask a question, Word? Yeah. Obviously I cannot help you, but yes, let me. Yeah. There is no journalist in the room? No, okay, you can go speak freely. Oh, God. And French are not good in French, you know? It's a complicated language. Yes, well, just to answer your first question, actually yes, it's absolutely true. The spell checker is extremely important. Again, that's what's discovery for us, the spell checker. Okay. With all these reviews, but yes, it's still important and we integrated Prolexys, which is a Prolexys v7 version and it's quite working quite well, I would say. Yes, they have French in it. And the thing is that again, but you have to think about small details again, they're all fucking all your project. It's like Prolexys working perfectly well, you have the model said, okay, no problem, today's we integrate the model. So, but the model works field by field and there is a lot of, and it integrated with CK editor, which good, but we have half of the field are not CK editor at all. So, we still have to control the legs and there is, ah, it doesn't work, we have to integrate. And then we added a button on each field, check the syntax. As I said, it's crap, we don't want to patch the button each and every one. One button checks all the fields and now you start to see the problem with Drupal when you have one interface, not edit and you have all your fields and you have one button there who actually goes and checking all the fields which are different, you have CK editor, so it starts to be and we spend two weeks as usual. So, yes. And the second question was? The other editor, right? Word. Yeah, comments. Yeah. You actually have also a library, I don't remember JavaScript, we also integrated that, hey, it's good, we actually, you should have done my slides. Because I got the previous version of this also, so you remember me. Maybe? Yeah. Yeah, yeah. And the thing is, yes, the common system, yeah, there is a JavaScript library which is, I don't know, it's jQuery tool which actually adds your tool tips and comments inside your, you just underlining text. And then you can store it. I think there was no Drupal models for this slide, so we had to develop it probably. But, yeah, they still can do it. But again, yeah, you have to add in comments, it looks like easy, I add the lib, I store them somewhere in the model, that's okay. But then you have a comment answered, oh, I want to have workflow over comments, comments not answered, I can answer to a comment, it starts to be complicated. So, yeah, that's why at the end, at the end we ended with, so we have 20 content providers, we have free mobile application, we have 150 people to be trained. We trained 150 people, it's a long process. You don't train them, you train them by group of five to six person maximum because they ask questions. And they are reluctant, they are right there and they sit like, I don't like your tool. And at the end, after two hours, three hours, four hours of training, you show this amazing drag and drop, everything is much easier. So, do we like it? No. So, yeah, and they note you, because when you have this industrial way of training people, they have notes and then you receive after four hours, three, three, two, two out of five, one out of comments, I didn't like the tool. So, yeah. And you have to repeat, they forget and you know everything. And they support also. Also, well, at the end what was really good idea was to involve the guys from the beginning. So you take the big mouth of journalists and you take them in the room and you work with them on the product. They don't understand nothing, but they still work and they are involved. This is important. The second thing is to have on-site support guy during the after lunch, because the Bing bang, it's everything works. Like the website is okay, no 500 errors, no 44, everything is okay. The content is migrated, wow. But still there is millions of questions arising. Go, I don't remember how I have to push it and it's really stressful because there's like 10 minutes they have to answer. It's being in a newsroom. It's really stressful experience because everything goes so fast. And in the e-commerce side, you don't have this energy and you don't have this level of stress because everything goes like, I have to publish it now, then I leave there. And so you have to answer questions. So put somebody inside and good luck to him. So 15,000 men hours so far, the project is not yet finished. So we have still many evolutions, new lots and so on, 18 months. And I counted this morning 1,193 tickets in red mine, which is not so big. Probably some bugs are missing there. They don't see them yet. So I think that's all. So if you had some questions, well, welcome. Try to answer them. No, those guys are not authorized asking any questions. Yeah, yeah. Well, Jen can stuff. So the idea is, maybe somebody will help me. So the idea is Jenkins is used to run jobs. So we have three things. We have our Git organization. We have a tool named Docman, which actually builds from different repository, one single doc root. So this is a tool you can find it. It's just Docman on GitHub, you will find it. I just got whatever. So the Jenkins actually works on several things, deployment. So he is responsible of automatic deployment of each commit from dev to the hosting, from stage to the hosting. You, inside Jenkins, you can also manually deploy one production tag. So you press, I want to push in production tag, whatever it pushes there. It also executes all the things like backup the database, run the update PHP for updated models, act, revert features, running PHP, CPD, running automatic test with mink, and reverting the deployment if everything goes wrong, anything goes wrong. So a lot of small things that during for the deployment actually. So this is the main way. So the main thing is like I take all the websites, their current release state because they are all in different states and I all put it together and deploy in one doc root. Mm-hmm. No, it was the Quark, it was InDesign. Or InDesign. Yes. Yeah. No. Well. It's just content going out too. Content out, yeah. Obviously one thing, you cannot recreate InDesign with the panels. Well, not yet, there is working on that. But yeah, obviously the layout of the newspaper is still created, but it's fixed. I mean, they don't change it every day. So all the layout is created. They reworked also the layout because it was created as previously all the content was manually copy pasted inside from Word. Now it's automatic process. So they have to rework on the layout because the layout in InDesign, it's like in Photoshop, if you don't create it in the right manner, you cannot automatic because title, it was title one, title two, title three. So we have to rework the entire layout without changing the actual look until but the layers, the name of the boxes and stuff. So we can automatically connect with the XML. Yeah, yeah, just another pain in there. So yeah, actually, I think there are translations in Korea because there are always two versions, the original version of the newspaper from El Mundo and then the translated French version. But it's not a Drupal level multilingual system. If you add it because you have workflow, you have a web print and you have versioning, which is kind of enough for complexity. If you, on top of that, you add translation, which can multiply the number of nodes, it will be just much more complicated. But, well, it's nodes, so you can do it. I think you can do it. We didn't try yet, but you can try. Yes? Yes, absolutely. Yes, exactly. So yes, there is two stages. Everybody knows 150 people working actually on Drupal now only and they select what we call I know how the breadcrumbs, I know that the word in French, yeah, chemande fer, I don't know which, which select the pages, which pages this content goes to which page? Yes, I don't know. Well, something like that when you have to say which page? Yeah, thank you. And they also select suggest images, like when they create articles, they go for the HD library and say, I want this, this, this, this, this, they select the images. And then there's another guy who actually, the pickups the right image. And then it's transferred to the server with InDesign and there the guy take it and have just to select the picture and maybe modify something. Generate the PDF, it goes back to Drupal. And then the final validator, Editor-in-Chief validates the final printed version in PDF inside Drupal. And once it's validated, it goes to printing. Everything is Drupal. Yes, everything is Drupal. Yes, yes. Everything is Drupal. So yeah, that's why I say that change management, it's an old house and there is a lot of guys and it's an old organization. So you have to really spend time on change management. This is something very new for us because usually guys are happy to have Drupal. Here they had a tool which is quite cool compared to what they had previously because it was really, really crappy, but they are get used to it since 15 years. So you know, you're still using QWERTY keyboards which is not the more master ergonomic, but you just use it because previously there was printing, typing machine, you know. So it was QWERTY, so that's the same. No more questions? Yes. Yes? Ah, no, yeah, because we don't have, our nodes, well, sorry, yes, it's a misunderstanding. We have actually, there are much more entities. But in terms of nodes, what I call nodes is articles and the dossier and things inside QWERTY are on the, if we count all the images and all the entities, they are much more. I don't know how much the entity, I think we have like 50,000 images only because they have a large library, because they have all of photographs who created their own library from since, I don't know, since 40 years. So yeah, they have much more entities. Articles, they are 15,000 articles. And in Tellerama, they are half a million. But again, I don't have stats. It's quite complicated because we had versions. So the database is big. So the QWERTY is launched since February. The second site is a private internal beta because it's a much bigger website. So we have also performance issues, not issues, but we have to be sure that, because it's a very well-known website in France to check the TV program. So at 6 p.m. from 6 p.m. to 9 p.m., we have these three hours, the traffic skyrocks. And it's all, it's not static, so we cannot just put it behind Warnish. And we, because it's personalized, you can connect and based on your preferences, you load your favorite usual thing. But yeah, so the second site is not yet launched. We plan to launch it very soon. Hope. And the first one since February. Yes, all the archives are printed. So the entire websites, you can go up to, I don't think I have 20 years of archive, I think, I don't know. But all the archives are here. Yeah, yeah, yeah. No, no, no, no, no, no, no, no. Yeah, I understand. No, the archive is for XML content. Obviously, everything before the digital world are only present in, they don't digitalize the old archives. So we got this problem on another project, which is a B2B project. They, we hired a company that actually digitalized all the OCR system, just digitalized all the content. But here, no, we don't have archive with images. But it would be not so complicated just having PDF, but they don't have that. Yes. Hey, I will repeat. Yeah, yeah, I will repeat the questions. No problem, sir. Sorry. Yeah. Yeah, to understand the editorial workflow for print. Yes. Is the editor, and the editor can select the articles. But can they select the, for each page, the article or just the order of the content to? They have the both. So the first two, they have the validation. Once it's validated, they can select the theme, based on the theme of the article, let's say politics, or Spain. They talk about Spain. So it goes in Spain. And inside the Spain, they can select the page. And they cannot select where the articles goes, because this is an offline decision between the editor-in-chief and the guys who is putting the layout. So they can change it at any time. They can, I think it's an offline process. I don't think they can select the emplacement, because it changed a lot based on the decision between editor-in-chief, the guys who do the layout, and the guys who select the photos. So I think the position on the page, they cannot select in Drupal. But it would be quite interesting, try to replicate the layout of the paper inside Drupal with panels, and it would be the next stage, I think. No, but it's not possible yet. The page, where it goes. But then there's a guy who can rearrange it. Yes. Assets, assets. It's an old model existing since Drupal 5, but we revamped it, so we maintain it now for Drupal 7. It's like Scaldi, but it's using medias as entities. So, sorry. Yes, so the question was, what was the model we used for the media? And the answer is assets. And yeah, welcome. And the idea is like using entities and not going from, because the problem with media is using files and the creative file. And then you admit that, but it's wrong, because medias are not usually files. You have videos, you have quotes, you have whatever thing. So we created this model, which is named assets, and you can add whatever you wish. And you drag and drop with whatever, which might be file or not at all. You can add a questionnaire inside your WYSIWYG whatever. So this is, and you have an alternative model, because we are very honest, you have another one, which is kind of the same features, but a little bit less good, I would say Scaldi. We prefer assets, but it's normal, we created that, we think it's better. But yeah, yeah. Yeah, two questions. One is about the format, like do you use a subset of HTML to format like bold and things like that? Or that's... Yes, yes. And do you consider something else like markdown or another kind of... No, it's still using HTML, but we restricted obviously the CK to the minimum, so they can use. And then at the import level, we have to convert to a different way in design, but we still use HTML, standard HTML tags. But with classes, which are restricted and work it out to be sure that the layout is good, but HTML is okay. Yeah, and also about the InDesign export, like is that something that can get into country or something like that, or because I think it's quite an interesting feature? Yeah, well, the feature is... Actually, the feature itself, it's extremely easy. It's very custom to each newspaper because you actually, what you do, it's a mapping between an XML you receive and your layout. So it's extremely dependent of layout. The code itself, that just do them, take the XML and insert, there is, I think, examples on InDesign app so you can just grab any of the plugin example, tell the world example of importing something. So the real work is to map it. And add business rules like, if I already have an article more with 50 signs, please put it there. And if the article is noted as sticky or important, then put it there. But actually it's just mapping. You're done? No more questions? No, good. Thank you.