 Hello everyone, good evening. Welcome to the talk about the LibreOffice template system, the extension formerly known as Walmux. My name is Thorsten Behrens and I will guide you through a few slides of this quite interesting if a little bit fringe extension, Java extension to LibreOffice. So very quickly, what is it? It is actually written from and for the city of Munich for their use of open office and then LibreOffice. In a sense, it is a template programming system which means it is there to have a large set of templates who interact with each other, who can include templates where you can actually write code that dynamically does something with the template and with the text and use that produce a lot of, in this case, document or government forms. And it integrates affiliated functionality like data inputs and mail merge, for example. What you see here is the sidebar, the custom sidebar of Walmux when you install it on the left-hand side and on the right-hand side the result of such a template run. So this is a letter with data filled, multi-page. So that's the product. Essentially it is for producing this very complex, mostly government but not exclusive to government but very complex forms. Project history started, as I said, inside the city of Munich with a goal to replace an older system that, first of all, was not maintained anymore and second, it wouldn't work with open office. And it was developed alongside the migration and then, I think, in late 2000, 2008 or 2009, was put into production. 2012, it was a major upgrade in the reword, mostly due to the fact that, at that time, the city of Munich migrated from open office to Libre office. There were some changes, slight API changes but mostly semantic changes in the API. So that took the opportunity to clean up and to modernize. There was another major rework, 2020 and 21, with a move away from custom Java dialogues and UI towards native Libre office UI, mostly located in the sidebar. So sidebar was available a little bit before but you have to bear in mind that there's like, especially in enterprise setups like that, there's several years usually for new functionality even to become available in the deployed versions. So that's always a bit of a lack. 2023, finally, with the sad migration away from Libre office in Munich, the move away from the Linux project to GDF. I'm quite happy that there was funding to do that. There's always a bit of work when you change the way the project is maintained. And there was an opportunity for further improvements and further cleanup. And I consider it a highly valuable piece of the Libre office extension ecosystem. It's the size to the tune of I think 60 or 70,000 lines of Java. So it's quite a large project with a lot of value, I believe. With the move came the suggestion to rename it because the actual original name is a bit of an oddball. And it's even an oddball name in German, but internationally people are just scratching their head what it is about. And to credit I think Uwe for the idea. Libre office template system, shorthand lots. I think it's quite a suitable name that sufficiently describes what it is. Major features. As I said, it's a template engine for really complex document generation. It also includes a form generator where you can have for PDF forms, you can have your check boxes and radio buttons and whatnot in a nicely GUI supported way. And also fulfilling those forms then later on. It has some extra features around mail merge, in particular if you need to generate multiple versions, multiple copies with different recipients with different blocks of text there or disabled for your forms. And it has so-called content-based directives, which is shorthand for text programming so you can have very dynamic templates like depending on the clerk name, depending on the department depending on the role, your template behaves differently. So you have different things included or excluded with different expansion of words, et cetera. This is the general idea. So you have a hierarchy of templates with this wonderful software engineering dry principle. Don't repeat yourself. So you have all your information exactly once. So you have your letterhead and your footer and your logo. All of that is in exactly one place. And everything, everyone is including that. And then you have those little building blocks where you generate the full document out of. And whenever your logo changes or your address changes of exactly one place, you need to change another million documents and templates and copies over all your stuff that you need to go through. What you see at the bottom, this WM opening brace CMD, that is a glimpse into this text programming thing. So this is an include statement. Like you know that from many other systems that just pulls in another fragment and you can do that recursively. So the included fragment can include another thing and another thing, et cetera. You can also add access control, for example, so you can have that on various places on your file system or even in a database. So for example, that the some legal disclaimer on the bottom of the page can only be changed by the legal department, for example. And as I said, it's programmable quite extensively. So you can have statements, you can have loops, et cetera. You can personalize that. So if you like that, that's just another aspect of the programmability. But what you can do as someone using it, you can have different roles. So you can, let's say, be part of some 3, 4, 5, 10 virtual departments. And then depending on your role, you would have a different sender or different phone extension or different email address like that. Or completely different looking templates like if you work for the county and if you also work for the, I don't know, for the federal state, for example, and the government that is doable then. Data can be pulled from very many places, also from an LDAP. So with the, let's say, with the role-based information that you need. And of course you can impersonate, so you can overwrite things, you can write letters if that is permitted from your administration for other people. And below that in this box you see another text programming segment, how to do this kind of data supply thing, pulling something out of a database with a query and then working on the text, mangling the text a little bit and putting it into the file. Yeah, that's a screenshot from the mail merge extension. There's support for the form, so you can also like virtually print a PDF with a form support and you can support those content-based directives which means you can print five or six or seven different versions of your document with sections there or removed. For example, you have one version of your contract that is for your employee, the other one is for the HR department and the other one is for the workplace union, for example, and there might be different texts that you need to include or exclude for that. There's a preview and you can also switch to data sources, so you can have a production version and you can have a test version of your database. Okay, and several output formats, of course, your PDF or print or just fill an ODT document and then continue editing that. So then some, let's say, ongoing report. I keep having this or a similar version of this talk since last year and has been the process of moving things over to CDF that has been ongoing since about a year. That process has now concluded. So current state of affairs is that the Git repositories got moved and really moved. It's not a copy. It's not a fork. We've physically moved the GitHub repository from the city of Munich over to liberal office project, which means the old links still work, but you get a redirect and then you end up on the liberal office, GitHub.com liberal office site, which is nice because we don't want to fork things. We just want to move things for anybody who's contributing and still has the old links will then automatically get redirected and the pull request will end up with the liberal office project. We did quite some work around the UI translation. Before that, lots was available only in German, which is nice for the city of Munich, but it's kind of unsuitable for a project like liberal office. So we changed that and moved it to web late and we added the necessary code and infrastructure to have the same translation workflow as we have that for liberal office and the website in other places. So people just go to web late to the translation there. When there's changes in the code, they get eventually imported there. And when there's new translation output, then it gets extracted. And occasionally, I don't know what's the time frame there, but I don't know, once a week, once a month gets committed back, somehow, magically. So whenever there's new translations that gets committed back to the code, which is great. Also, we moved the documentation. There was a bit of an interesting thing in markdown. So it was kind of auto generated from markdown and then a static website was generated from there, which was also not something that would work really well with our TDF translation workflow. So we moved to media wiki syntax and added the necessary markup so that also the volmox slash lots documentation and handbook is now in the wiki and it's integrated and included in the translation workflow. So we also end up on that slide. We fixed a number of problems and fixed a number of bugs and extension works with all active versions. Should probably change that from master to 7.6 and we continue to support that. So if there's any problems coming up with master, we're going to fix that. And quite some robustness changes. So while we were looking at that, we discovered that some code was a bit, assuming a little bit too much. So we removed a bit of brittleness there and hardened things and made it a bit more fault tolerant. And also the fact that the config, so we're simply not in a position where we control what the users do and their environments. We simply don't make as many assumptions as you can make in a corporate environment. So even if there's no config, we still start and then we fill in defaults. And if there's an old config that was back in the day, the configuration was also done in German and his German keywords, if you find that, we read that still. But the new config format is English, so that is what we recommend. And also that's what's written out by default. Some build fixes, some changes in the way that it's built in Java. So there's a Jenkins job now that regularly builds that. We also changed the internal names in the code. So the namespaces are now org.lib.office.org.lib.office.lots for the namespaces for the packages and org.lib.office.ext.lots for the name of the extension. And while we were there, we did lots of translation. Hopefully that's better. Lots of translations, not just the documentation, but also inside the code for comments and for the how-to's. Finish the handbook, as I said, so that's now fully translated. I think it's near 100% English and German and some other languages catching up quickly. Yeah, and lots of people, so that's the great thing. Lots of people actually help with translation. And that's going really well. I'm very happy with that. Because obviously, as a user-facing software, it's of no use like for the typical end user, if it's not in the local language, it's of no use. And the software is complex enough that yet you would need it translated, otherwise you wouldn't be able to do much of it. And of course, also having the handbook and the documentation translated is quite important. Next steps. So we don't have a landing page yet. I'm not sure if we actually need one. The old project had one and that was then linking to the download and to the handbook. So, yeah, hard to say. I would assume it's probably good enough if people know that it's there and a search engine query would find the extension page and the wiki page with the handbook. But I'm happy to be told otherwise. There's a bit more renaming work necessary. So for example, the handbook still talks about volmox. And the code also contains lots of old volmox references. Whether that is valuable to change that in the code, not sure about that. Clearly, the namespace and the package name change that was important. Because with that, we can actually upload help libraries and stuff to Maven, which is really quite useful then for Java. What I think would be quite useful is to get the logo changed or have a new logo for lots. Anybody who feels like designing or sketching something would be most happy to see some suggestions there. There's a bit of bug fixing. There's still some handful or two of bugs open in GitHub. So we use, actually, since it's a GitHub project and hosted there with the original version under the LibreOffice umbrella, we're using GitHub also for the issue tracking. It makes things a little bit easier and more streamlined and doesn't need, like, interference with Vuxilla, which most people actually go for LibreOffice core bugs. So, yeah, with that. So that's a bit of bug fixing. And plausibly, with the 24.2 version that we want to make work, that's a bit of QA work to make sure that that really is functional. So for releases, please do watch that space there. And the slots releases page. The current one, which is beta level is 1901 and just a 1902 already in preparation. So, yeah, go check it out if there's any problems. In particular, I'm interested in problems with non-English UI and latest versions. And, of course, if you have a platform that I'm not using like Mac, I would be interested as well if everything works down. Yes, and then it's almost at the end of the talk. So this is a call for contributions. I mentioned a few things already. Comment translations is very appreciated. It's a very nice, easy hack, not just for LibreOffice. Almost all comments are translated now. So now there's a new project for easy hackers for some quick fix. You got half an hour in the evening and you'd like to contribute because you haven't this week, then go check out this commit there. That's very easy. UI translation. So that's the current state in Weblight. So you see English is pretty finished. German is also pretty much done. But there's some other languages. The stats. Can't read that. Too small on the screen. Oh yeah, Dutch, interestingly. That's also 100%. So feel encouraged if you're not 100% yet and you're a native speaker of that language. It's not that many strings. So that is also doable in finite time. So yeah, translation obviously. And documentation clearly would benefit from some cleanup, from some search and replays. Just get the rename done there. And maybe the language is not as polished as it could be. It's not as well explained as it could be. Or there's some old screenshot there that could be easy to replace with something new. So also any contribution will come there. As I said, a new logo would be cool. And of course, if you like bug fixing and new features, it's open source. We're happy to mentor anyone who would like to get their feedback there and the code. Just poke one of us. And we also, like usually we hang out on the LibreOffice IRC channel. So that's probably the easiest way. If you want interactive feedback, otherwise just use the developer mailing list for some general information. Yeah, I was showing that. And as you see, this logo is... Yeah, it's a bit obscure. So I think it's not... We should have a new one. Great, that was that. Thank you lots. Thanks a lot for your attention. Are there any questions I can answer either here or later in the hallway? Any questions? Okay, thanks a lot again. And hope to see you later. Maybe I had to hack first. So that could be your first contribution. Some comment translation there. See you then. Bye-bye.