 Here is David Privott and Rhonda from the website team and www.debian.org. It's alive. Thank you. So, thanks for coming, and I want to talk to you about the website, www.debian.org. There are many website stuff on Debian, the Wiki, many others. This one is the first contact point, especially for our users, and it contains so many documentation for us and many links, of course, to the other services. And what it is? Kind of a big stuff, actually, because it used to be everything on www.debian.org, for example. Now, let's start with some numbers. There are a huge number of pages. These pages, 5,500, are only the first language pages, mostly in English, for most of them. Only a few pages have the first language in French, where it is about the French internet, French localization group. Easier to say localization than the other word. There is not only French, because there are 36 languages available. Japanese, German, and Spanish, and 35 others, again. With all these translations, we have almost 30,000 pages on the website. Not every pages are translated in every languages, but some languages are translated from 95% of the website, and a few languages have only one page translated. So it's really different. I think the Spanish is about 45%, so it's very good, and it can be improved again. It's kind of a big stuff. There have been around 100,000 commits. And we just recently arrived. Yes, we just recently passed the mark of 100,000 commits. I think it goes back to 1994, if I'm not completely wrong. So every commit since then is stored in CVS. Yes, and we are going to talk about CVS soon. There have been around 200, actually 300 contributors. 200 is the number of the current contributors on the website, but there have been around 100 more contributors that are not playing with us anymore. And it makes it kind of a big project and quite scary, actually, when you first come in. So like Rhonda said, it begins in 1994, something like that. And it has been used in its still in WML sources. WML is kind of HTML with Perl stuff around. There are WML typical commands, but many of us don't even know how to do code in WML. So we use some hooks to do what we want to do in Perl, but other languages can be used. We have some Python script on the website for a few pages. And everything is stored in a CVS repository. After a few talks, the two president talks, well, kind of the old guys in Debian are still using CVS. But it's not that bad. I'll be back to that in two slides. It's built every four hours. So if you add a page, if you fix a page, if you add a new translation, it will be available in more or less two, three hours. If you're lucky, less. If you're lucky, it can be five hours. And some of these pages are actually automatically rebuilt, like, for example, the WNPP pages that are picked from the Debian bug tracker, the BTS, to have up-to-date data offered on the static pages. So it's quite easy to see. There are no JavaScript or PHP stuff around everything static. In order to have the website up-to-date, we have a translation check on every page to be sure that the translation is either up-to-date. If it is not up-to-date, it is shown to our users. And we can mail our translators to say, hey, you have a translation to update. So we can follow every single page of the website. And we also do daily validations run to make sure that every pages are correct. And if they are not, the people that are responsible of the language, actually, are aware that there is something to do. And behind this, it looks like an old stuff, but it really is up-to-date because some of the documentation, for example, built from the DDP packages that are built from the DDP, the new mental guide, the release notes. So those kind of documentation are already built at the last versions. And some other, like the Debian policy, the Debian reference, developer reference, for sure, is extracted from the package. So when a new package arrives, the policy, last up-to-date policy, is displayed on the website. It doesn't need any end, so it works. The website with these 5,000 and counting pages, actually, they are in many different directories. For example, bugs contains the BTS documentation. CD distrib and releases contains in many different places lots of information about our CD. And one other to-do, one of the things we want to make is take together all of those pages to make it more useful for our users. And recently, we gave with the Tiv sledge commit access, so it can help us. Maybe we'll see that later. And I didn't list everything, but the things that are quite moving are the events and news parts, because when there is new Debian project news, that happens every two weeks, we add this page on the website. There are some other press releases, like we have done already some during DeepConf and Depcamp. And the security part is also moving, because almost every day we have a new DSA and a new page on the website that can be translated and that is usually translated currently in Danish, Japanese and French. Maybe updated quite often. And lots of other pages that we are taking care of, thanks to the help of many contributors. For example, in the ports part, Samuel Thibault is taking care a lot of the Earth port and is often updating the related pages. So why CVS? Why didn't we move away from CVS? Well, first, it works. And it works fine for what we do with it. It works fine because actually we don't have huge requirements. We don't want to do crazy reverts, remerge, branches. All we do is online. And using CVS, maybe you don't remember, but it's not that hard. You do an update, you edit your file, you make a diff, just to see what are you really changing just to make sure you didn't make any mistake. And you commit the file. It's quite straight. There's no rebars, remerges. And actually, it is for non-technical contributors. It can be quite an easier workflow than one with Git, but we're working on it too. And actually, another thing we are using from CVS is the translation check is directly linked to the CVS version. When we add a new version in English, for example, one file that is 1.10, you update this file, it becomes 1.11. And every translation that is up to date with the 1.10 English version, that's crazy, I can't even explain that. It's easy stuff. Can you try it, please? Yeah, we note down in the translation check header of the files, which was the last translated CVS version. And given that CVS versions, when you commit a new file, just increase by a number of one. You can easily calculate how many commits you are behind with your translation and see easily you're behind three commits. There's so many things to translate and keep up to date to make the file current again. Thanks. So, what we did recently, you may remember our whole website looked like before. So, two years ago, we had a website and ten years before, it was quite the same website, actually. So, we thought, oh, it looks rusty, it looks like some dust about it, some dust on top of it. So, when the squeeze was released, we make it, yeah, let's do it. And we finally managed to do some new stuff about it. We changed kind of a lot of stuff. You may remember it because we had lots of messages about it. Oh, you did something, oh, it's not dead. And, yeah, the website is alive. And the funny thing when we switched to this new time, we had quite some work because there were some hard-coded acts, stuff around, and we had to fix lots of files. So, we had to prepare the new design with a test host. Thanks to Ronda, who made a lot of this work. Yes, several years ago, I stumbled upon the proposal from Carl Södermann, and he had it already in patches. So, being a hacker, it's quite useful to work with patches. So, we are used to work with that, and it worked for the website pretty well. I did put it up on a test site, applied the patches, and there were some tiny bits that we had to tweak along, and to make it really happen, we thought we need something better to be able to work on it. So, actually, what I did was import all the CVS history into a Git repository, which is quite large, given with the 100,000 commits from well over, I think it's now 14 years or even more, and that's quite some history that you have to import. And I updated this CVS import every now and then. We created an extra branch for it in Git, and worked explicitly on that branch, merged from the main branch every now and then, to have current data. And that way, with the two branches in Git, we managed to prepare the patch for the main website to get it back into CVS. It took us several months to get there, but the surprise went well. People really enjoyed it. When Squeeze was released, we were able to also release the new look of the website, and not even just on W3, DBNorg, but also on the wiki, on the... Lots of services, actually. Some other sites, too, so... It was quite a lot of work, but it was important to show people that it's possible to get changes into the W3 website, and the web team is alive, and that we are able to make changes and willing to do so. Yeah, thanks. And when we switched it, just before we switched it, some of the new contributors arrived, like I did, I'm turning, and also Francesca Serri, and Kor Torlosan. I hope I pronounced it right. Kor was a quite long-standing translator at that time already. He's working on a Danish translation, quite tireless. Also Tafit was working really hard on the French translation side, and I'm very happy that I managed to get them into the webmaster team for making this happen. And... Oops. And one of the other recent achievements, we mentioned it because it's a long-standing issue, and I think Simon Payard began to do it or was one of the persons who began to do it, I don't know, five years ago? Around? A few years ago? Ages. Yes, ages. Simon started... Simon is one of the webmasters of the team. Started to make every French page in UTF-8, because we used to have a charge set for every language, and it began to be quite a headache for every page that are available in various languages, with part of English, part of translated data, for example, the internal pages about the localizations, and we finally managed to finish these last steps, thanks to lots of help from Francesca and Carl, who were in contact with many of the translation coordinators. We recently, a few months ago, managed to push the last remaining languages to UTF-8, it's quite nice because it makes it a lot easier to add some new pages, new scripts on the website. You don't have to bother about the various languages, the various charge sets that can be used, and what we are trying to do now, among other stuff, but the big stuff, is to change the license of the website. So this one, there is a bug report from nine years ago, who asked about the OPL license that we used, we used actually on the website, is not compatible with our guidelines, with our own guidelines. So it prevents us to pick part of the data on the website, put them on our own packages, it was bad, and we are currently on the way to ask every contributor of the website to agree with the new license, we agreed on EXPACT or GPL2 plus license, and Simon did a lot of work about it, we have already 150 contributors, among the current 200 that already agreed, and 5 about 50 we are still looking for, who don't still answer our mails, but we'll manage it. Yes, some people haven't really responded yet, most of them that are outstanding haven't responded yet, there were no clear objections to it as far as I know, but I'm not really involved in that process, so I think it will happen eventually, hopefully soon. And thanks to all of us who already replied to us with the agreement anyway. And one of the usual thing we have to do is to maintain documentation, and thanks to everyone involved, for example Don, who is involved in the bug tracking system, he's also updating the bugs part of the website with BTS documentation, I already mentioned Samuel, who takes care of the airport, and many, many, many more, I can't see everyone. And what's next ma'am? Lots of people are telling us that I don't want to play with the website, it's an old crappy CVS, we want some brand new Git repository, it's possible, that's what we did for the switch to the new design, so there are some things that are possible, there are some bottlenecks, we need to resolve the issue with the translation check, but we already have some ideas, all we need, all we miss? All we need is someone with a fair amount of Git knowledge, who is able to convince us that sub-modules would be not a pain for the translators, and that it's possible, we need to find a way that it's still possible to just check out the preferred language they want to translate in English next to each other, and things like that, so they don't have to carry the whole archive, some possibilities are there, I'm not sure how it would work with Shelloclones, but the Git knowledge within the website team is on a base level rather, but I think to make it really happen, you have to have quite a lot of deeper Git knowledge to be able to improve things speed-wise with that big history, and that lot of commits, so it really works out in the end. We are really looking forward to people that approach us and would help us make this happen, and not just people, yes, please move to Git, but yeah, we would want to, but we need some people that are helping us along that way. One thing that is important is we have to keep a workflow simple, make sure the steps to help us in the website doesn't need to have lots of technical knowledge. We are applying the website, two of our five webmasters are actually non-appledding Debian developers, and it's quite a huge number because there are only five non-appledding developers currently in Debian, and two of them are working hard on the website, so that's very nice, and we would welcome many other non-appledding developers, so just non-appledding developers, some of them, you wanted maybe someone with kind words? Okay, I hope you hear me. I've been told I don't talk too loud, so I hope you hear me. Wouldn't that be a good topic for Google Summer of Code? I know that GSOC is mostly about coding, but I think in this project, moving to Git, there is some coding involved, such as the translation check and all that kind of things. Yes, you're absolutely right. It might be a good idea to get this into Google Summer of Code if we don't manage to find someone by next year, early spring. We probably will submit it to Google Summer of Code. Hopefully someone will sign up for that and be interested. It's a great idea, we should pursue it. It's just not the right time of the year currently because it's midterm right now, I think. We would also need to find a tutor. You could do it. I do that all year, actually. So, nothing new for you? It's all the days, Summer, come on. Yes, and welcome new contributors, the scenery we could have. And if you want to help, we have actually a pretty long to-do list, more than 100 and 150 times and counting, so they work for everyone. There are some teeny ones, some that need some script knowledge. There are also probably quite a lot of duplicates still out there, which simply could get merged. I think the amount is huge enough to find a lot of bugs that are already fixed since a long time, but no one really noticed. So, everyone is encouraged to look at our bugs and also work on them. I think almost 50 of them are about the packages that debian.org contained, which is a little bit different, but some of us know more about it. And for those of you who care, there is actually on the bug tracking system, we made it like some packages. And we... How do I say that? Yeah, we started to use user tags and user categories to categorize the bugs for ourselves to make the overview easier. So, we have content-related, design-related, script-related, and packages-website-related. And some still untact, but it helps with the overview and if you just want to work on specific issues, like on the CSS files, stylesheets, you can just take a look at the design-related bugs. I think we're done with the presentation, but we would welcome some questions, comments. Tomatoes, muds, no. Well, whatever. I might feel ashamed because you may have mentioned that. How about the switch to the use of PO files for translation instead of WML? That would be also a very nice improvement. A second Google sum of content. Yeah, maybe we could have two students working on that. And actually, if we manage to move to PO file to under translation, we don't care anymore about the translation check sort of hack we have on the website, and it will be a double improvement, actually. So, only one Google sum of content. Yeah, maybe. I think it might be depending on how we try to approach the things and how we envision how much work it would be. It might need two students, but we have to look at it. There are some concerns, at least from my side, with respect to switching to PO files, which I think you are aware of when you have read the threads on the W3 mailing lists that popped up every now and then, which I really would like to have addressed. Some of them are not strong objections, but I care a lot about the websites. I'm maintaining it since several years now, but if I find a convincing argument, I'm all for it. Okay, here's another question, but I will try to translate. He wants to suggest that you put some buttons there so the user can decide if he likes it or dislike the website. Like Facebook button. Oh, some like it button. Well, I think that this is a clear objection from most parts of the web team because it would be playing into an organization that is seen controversial across the developer body in Devian as a whole. But tracking, yeah. We had a better fissure last year about tracking our users. Yeah, especially, yes, there was just recently, one or two years ago, a discussion about having flatter buttons on Planet Devian, and there was brought a policy up that there were quite big concerns about user tracking, who is looking at Planet Devian because it's including an image from a third-party site and code from a third-party site, JavaScript code that is running your browser, which is not coming from Planet Devian. And if I like it buttons on the Devian website, it would be even more that it would be JavaScript coming from Facebook on the Devian website and a lot of people will object to that for privacy reasons. Yeah, I think you have two objectives in front of you. Any more questions? Related with Christian's question about to use profiles, there are currently profiles in the website for certain things. What's the limitation to use it for all the websites and not just to replace in translations? Yeah, the places the pao files now are used is for things like index pages or the navigation which appears on multiple parts of the website, which appears for the data, the date in front of the security advisories and things like that, which is just a part of the website which gets used multiple times. For the website as whole, I'm a bit... Well, I don't know all the pao file translation things, but I'm a bit worried that it might be quite long strings, tend to be hard to translate and if there are only a few words changed within, most pao file translation tools aren't able to cope with that and highlight it properly. The current approach is that we sort of limit the lines to 18 characters and you'll see and we try to convince people to not re-schedule and to not move around parts of if they just change a word within, that they don't re-wrap all the lines so that translators see just in this line something has changed and if there is a lengthy string for a paragraph of about six or seven lines, it might be hard to spot the difference, but of course that's a job for the correct tool. The next thing would be to have all the strings next to each other because in some languages you might squeeze some paragraphs together and translate it as a whole thing and not put a break in between. You might shuffle around paragraphs with lists, put something behind it, things like that. I'm uncertain how they would work with pao files they are used usually. One thing to say also is that pao file is currently used on the website. It's kind of an homemade solution for very specific tasks. It would be a bad idea to use the same homemade system for all the websites. We will need to start fresh with a proper tool like for example PO4A that already has a proper module to do that and even if it isn't yet, we can improve this module to make it right. There are solutions that have to be pushed to the end. I would invite Nikolai, who is PO4A maintainer, to approach us and help us with moving forward that part. Yeah, right now he's sleeping in Europe, but... Any question? Okay. Thanks everyone for listening, for sharing your thoughts, for staying with us until the end. Hey mama. Thanks for being here. My first time on TV, mama, c'est moi. Thank you.