 I'm going to talk about one of the challenges that we have in the domain of the LibreOffice in terms of getting a help language that could help users and keep a lot of requirements in maintaining documentation and synchronize it with the developments. My name is Olivier. I am from the Document Foundation. I have been involved in LibreOffice since the beginning. I live in Brazil, which is quite hot at the moment, 42 degrees, and I'm also the translator for Brazilian Portuguese. So I handle not only the generation of documentation, but also the issue of translating the documentation. What we have is that why we need a help language, because historically the developers don't like to make documentations. So essentially, in our culture, in LibreOffice, everybody writes code but doesn't like to write documentation. So sometimes we have a lot of new features without documentation, and this is something that we need to fix. The gap between the features and the help is widening. We are working to make it as narrow as possible, but it's always very hard. And the speed of development is much faster than the possibility of generating documentation, especially because in our environment, documentation is done by volunteers. So coupling the help pages and the user interface elements is a challenge. The user interface of an application like LibreOffice is extremely extensive. We have more than 1,000 dialogues. We have a span of application that goes from spreadsheets, text documents, presentations, drawing, math equations, and databases. So it's a very broad scope of application. And we try to focus on user experience because user experience is very important for us, for the acceptance of software. So basically, what we want to achieve is sort of a help language or XML, maybe XML or whatever, markdown, as open as possible, so no way to use closed tools or paid tools or proprietary tools. Flexible that allows specific situations such as translations has to be precise because essentially the help that we have in LibreOffice is also some form of a reference for regressions and feature descriptions. We would like, and this is one of the main issues, is to be contributor friendly. Today it's not contributor friendly because we have a cycle of development that includes the help pages into Git. And this is not very easy for the newcomers. And keep the pace of development. That means don't let this gap widen. Very well. So basically, the specific of LibreOffice help, it's an application with a broad scope, as I said. All the modules are tightly co-plated. I mean, we don't have a spreadsheet application. We don't have a text document application. This is all integrated into a big application with several modules. We have a legacy XML which is inherited from OpenOffice. The help that we have at the moment is above 500,000 words, which makes a book as thick as this one. We have to maintain and keep alive. It's mostly textual and few images. There is not multimedia at the moment, but the idea is to extend that for including new forms of communication between the help and the user. And we have a translation process in place that works. That means LibreOffice is translated into about 100 languages. So we need to address the translation. We do that, which also means that it's very hard for us to change the process in place, because we are touching about 100 teams of translators. And when we do a mistake, times 100, that makes a lot of noise. So this is what the challenge that we have. And what we do propose with what we have is that we have a set of XML and namespace that we want to improve for describing the menu path, the widgets, screenshots of the dialogues, describe icons and toolbars, includes multimedia, address the guide for the user and not only references, and also do indexing and search and save the translation work. So at the moment, only half of these specifications are already working, and we have others to address. For example, in the menu, the menus in the application are described by an XML, and we would like to have these menu paths describing the textual help directly taken from the application. So we should use a transformation that picks the XML of the menus and the commands and put into the help directly. So if we change the position of these menus, automatically your help will change as well. This is one of the challenge that we have. The same for the widgets of the dialogues, for example, not only we have to take the widget itself, the representation of the widget, but also its contents, which has to be translated. So again, we can use the dialogues XML, which is something used by GTK. The dialogues are in a GTK language, and to bring that into the helper pages. Icons and toolbars, we have to describe the icons and toolbars for improvements on the icon designs. On the last couple of years, we had a lot of discussion in LibreOffice design team. There is quite new icons coming, icon sets. So the interface may appear different from you, from one user to the other, depending on the set of icons that you use. And this has to be also covered by the help application. The screenshots, we would like to, we have already screenshots done by simple copy of the screen, which is in an automated process. But it would be nice to have it also using the XML to generate the image. Images is already implemented, so no problem there. And also we have some issues or problems to address, which means our system, our application runs on Mac, Windows and Unix. And depending on the system, you have some features implemented on Mac, which is not implemented on Windows. Very few of them, not that much, but nevertheless, we have to address this difference between the systems. We have also inline context switches or block contents switches. For the visual part, we are implementing a specific text to describe Python code and basic codes and also code in general and icons specifically to icon tables. When it comes to tips, notes and warnings, this is already done. It's quite easy to just address the CSS. But it's the way that we have also to enhance the layout of our pages. For everything like that, we also have character set, character classes for specific contents of the description on the helper pages, such as literal information. It's something that allows us to click on a class input and then it copies to the clipboard so you can, if you have a code or a spreadsheet formula, you can just copy the formula and look at it working directly in the application. This is for better user experience. Widgets, I told, I already talked about, menus and key codes also for all the keyboard codes that we have in the application. We develop also an online editor. This is the very first pre-alpha display. We have the XML of our editor. Some of these blocks can be automated. Then we also can render the content of the page immediately after we edit here. You edit here, you click on render and it displays the page there. Our help system is a sub-module in Git. So every time we change the XML, we have to create a commit and push to get it. It's going to be reviewed by someone. You can imagine that reviewing XML is not something easy. It's quite complicated. So we are trying to connect this kind of editor, which this is just code mirror, okay, a very well-known JavaScript editor. And it's the same as Garret, so we expect to be able to edit directly the pages in Garret and get the results and submit the patch automatically. And we would like to avoid all the work that today volunteers have, which means download the code, compile the code, compile the help, check if the change is correct, and then generate a patch and push to the... So this cycle is extremely lengthy and it takes a lot of time for us. For me, who is killed, it takes at least one hour to generate all the stuff, okay? Then what's next? It is an interest to investigate then the XML transformations for dialogs, menus, and toolbars. We also would like to converge the help with these existing open document guides, which is a project we call Conventions. We have guides that has been written by volunteers, for example, on spreadsheet. The spreadsheet guide is a book with 400 pages. And we would like also that this kind of information be available in the help system of our library office, okay? And we are open to suggestion and collaboration. And if you want to join us, please go ahead. We are eager to get you. One thing that is important to say is that our help system is either offline and online, which means that today we have this XML. We do a transformation to HTML, and this HTML can be uploaded to a server, or it can be also deployed as a package for offline use, and it's exactly the same layout, okay? So this is a constraint that we have. So it's not so easy just to generate a server installation. You have to also pack the HTML into a package. The other thing is that we have about 2,500 files per language, and it generates about something like 500 megabytes of help contents per language. So it's pretty heavy application that we have. The traffic that we have on our online service is about 60,000 visits a day of people looking for help when they use the application. So that's the context that we have and the challenge that we are addressing ahead. We cannot use throw away all legacy contents, so using a brand new tool like I have seen here is very nice, but how can I address all this legacy, especially not only the legacy on English, but also the legacy on the translations, which it's about 100 translations, so it has to be something smooth for us if we have to get something different from that. So at the moment, this is not the main or vision. We expect to simplify and get it easier for the people to really help us in documenting the application, okay? That's my presentation. If you have questions, please. Yes? Are you familiar with the DITA project, the DITA standard? No. Darwin Information Type Architecture. It's an XML language for documentation. Okay. It's huge. There's a really big community. It stands for Darwin because it's adaptable, so you can take the standard that has all of this that you're defining and make your own specialization, and then you would be able to use their tooling. And they have an open source tool called the Open Toolkit that allows you to generate a bunch of things. Yeah. It's mostly proprietary community, but it's an open standard, and it would be super awesome to get open source community into that, if I can introduce you to it. Yeah. And we are using, of course, all the legacy from 15 years of, I mean, 20 years of open office and then liberal office. And moving away, it's not that we really have to make a decision, and if something is easier, then I'm interested, at least. But if it's not necessarily easier, there's more to it. Yeah. Okay. Yeah. It's also XML, so. Okay. Yeah. But there's a community, mostly proprietary vendors, they're using an open standard together, and there's a lot of interest for open source tooling, so there would be much made it happen. Oh, perfect. Yeah. I actually have a question as well. When you generate the screenshots, you generate them per platform, and I think it does mac and minnows. You can generate the screenshots on every platform. But you automate them. It's not yet automated. I mean, I do make screenshots in my builds, and it generated the screen starts to flicker because it opens all the thousands dialogues and takes the screenshots. So they run locally, not on CDI? Yes. So. And yes, then you have to connect the screenshot, the image, with the dialogue, and with the help page corresponding. So it's, this is not yet automated. Okay. Yes. Yes. Well. Is that the bottom line? No. The translation is done by volunteers in every language. We have used to have a leader and a team, and they handle themselves the, I mean, each release that we have, and we have two release per year, we publish the help. 99% of the help of the new release is exactly the same as the previous. So there is only the delta, the difference that is being addressed. And then the translators, the team of translators, the locally is in charge of keeping the translation synchronized with the help in English. This then, then the user of their language will suffer because they were not addressing. Yeah. Yeah. No. No. This is because this is a volunteer project. It's not, there is no specific investment by the foundation into generating professional documentation. Okay. It's, it's the board. This is a decision with the board of the foundation. LibreOffice is a project that is run by a foundation without, with no non-for-profits. If a company wants to take the code and improve it by, by themselves, they are free to do that. Okay. So at the moment, we generate the, the content of the help in a volunteer basis. The foundation doesn't invest in, oh, this is not me. Okay. Any questions? Thank you very much. Yeah. Thank you. Yeah. There is another track right there. Yes. With a lot of new things. We'll be back again in about eight minutes with a Smackdown. I'm a huge fan of Pandoc and this next week you want to tell me why I shouldn't be. Sure.