 So, welcome to our presentation about the Drupal 9 localizations of Upgrade Initiative. Well, we'll know why it's important to take care and to cherish our translation tools. I am Philippe, I'm a freelance in Perpignan. I'm the maintainer of the French translation of the user guide. I'm in the French team on localize the Drupal org and I'm the coordinator of the initiative we're currently talking about. By the way, I'm a language enthusiast and the maintainer of biodiversity-related modules and libraries like GBIF. And I'm a firm believer in external entities. Hello everybody. I'm Nicholas. You can find me with the Nikola username on Drupal.org. I'm a CTO at Actancy. And I'm a Drupal enthusiast, a Drupal translator with the French translation team, maintainer of various modules and, well, voilà. Hi, my name is Stefan Auditor, send us on Drupal.org. I'm working at Covain in Berlin. I'm the chairman of the German Drupal Association, German translation lead, actually, maintainer of various modules since, well, I think 20 years. I'm a father of five and we have two dogs. I guess everyone in this room knows that Drupal is multilingual, but what does it really mean? It can be multilingual in various meanings. It can translate content, which was greatly improved by the Drupal 8 multilingual initiative, which was led by Gabor Hoetsche. And I think we should thank the people who worked so hard on this. You can also translate config, but this will also be an autoscope. And today we will be talking about interface strings provided by Cov as well as other country projects. These strings can be manually translated on a Drupal instance. You can see that on this screenshot. And then translations can be imported or exported as PO5s. And for quite some time, translations were distributed in a folder in modules and projects. This is all very well and good enough for custom projects, but is there a way we can share translations across projects and instances? Well, of course, there is. I guess you all know it. Whenever you install Drupal for the first time in another language other than English, for example, check when you select check in the list, Drupal will download translation for you. Or whenever you install a new module, or whenever you decide to manually synchronize translations. And what happens behind the scenes is that Drupal is in contacting a translation server, most likely, of course, localize.drupal.org. What about it? As I said, it's a translation server. It serves translation at HTTP, but more precisely, it's actually Drupal 7 instance. So you guess we have a problem here. It is used to share translation files across Drupal installation. We host about two million strings, which apparently is quite a lot in the world of free and open source software. But more than that, it's actually a collaborative tool that translation teams can use to translate projects according to their own guidelines, and this is possible thanks to permission systems, which is based on organic groups currently. It is, I'd say, an important part of our infrastructure and even the central part of it. And I think it does lack some visibility. It does need a dedicated team for evolution and for maintenance and evolution. And as you can guess, there's an evolution which will be imposed to us. I just wanted to point out how Humberto Eco once put it. The language of Europe is translation, which only means that there is not a single main reference language in Europe. The general way of communicating is by translations, which is why we might be interested in multilingual websites here in Europe, and also maybe the reasons why currently in the team there are only European contributors. Of course, contributors from elsewhere would be more than welcome. Okay, so as we all know, the current instance of localize that Drupal.org is in Drupal 7, and we are here to change things. So here are the two meta-issues for the upgrade of all the Drupal.org websites, and the meta-issues for the localize instance specifically. The initiative first started at Drupal Dev Days in Ghent, where we based our work on the previous issue from Tobias B. We started a little bit of work on it, and then a team of contributors gathered around Gabor and Drum and asked many questions about the architecture. So there was Mepsy, Philippe, Radelson, Caulofield, and Stefan Leder. And we all agreed to create this core initiative, well, community initiative, D9 localization server upgrade, to, well, port the current instance of localize. First, we asked ourselves how we could maybe getting out of the island. Maybe there are other solutions that could help us translate what Drupal is for the community in general. So like the community took a specific path for our version system, where we started from CVS to go on a self-hosted Git instance and then GitLab, we kind of, well, think about it and try to see what other popular tools may be used. And our specificity here was to address, well, to handle two million strings, which is, as Philippe said, quite unusual for an opponent's project. And we had very many existing features for the people to collaborate on it. So we would need to port some specific feature for Drupal.org anyway. So we looked at, for example, Weblate, which is quite a popular tool for this, and thought it was not unfeasible, but for a certain reason, for example, the fact that it stores the translation in a Git repository, that we don't do that, and that we don't share strings across projects, we choose to not go on this path and stay with the Drupal 9 port. So the roadmap was to focus on the D9 port. And the first step, which is the one we are still on today, is to make it work. So port the current community modules and, well, make it work. Migrate data, get a workable front end that Stefan will show you after that. And then make it neat. So maybe refactor a bit, add more modern approach to the way it works today. Like, for example, we had a session in the previous room with Balu who said that statistics analytics are hard to reach. So maybe add some REST API or JSON API things to gather statistics. Make it pretty. For example, optimize or improve the filters on the UI, make it reliable. We must create a test set for it, and then make it live. So our goal today is this session. Then we have both later in the week, and we will be in the country room in C3 on the other side of the building. So come see us. There are various improvements. We can work on, like I said, statistics. We have also things that we can improve on the credit for the validators and translators. And also we need to work on the organic groups versus groups where we want to go with group. So there is still work to do on that. So the current state that Stefan will show you today is that we already have all the Drupal.org project that can be imported in the platform. So we get all the modules, all the themes, everything. We have the releases through the connectors that are already ported. And we already have the translation teams by languages. So this is what Stefan will show you now. Never do a live demo, I heard. OK, this is the current state. We have a working Drupal 9 setup with Blue Cheese, which has been part of the porting efforts already. We have the core translation status on the front page. We have projects overview, a downloads page, which isn't working yet, but doesn't matter. We have the translation groups, which will be imported, migrated from the D7 setup. But the board page, that isn't working yet. With the translation page with filters that do work, what doesn't work yet is the translation UI, actually. We have an import page, which does work. Importing profiles into the setup. We have got an export page for exporting translations, which also works already. Yes, so I just show how to parse a Drupal release with Drush. Done. This is Drupal 4.3. So just 45 files and 1,200 around Jinx. This is much more on a D9 or D10 setup. But nonetheless, this proves it works. So this is the current state. We have numbers, really. We have some statistics here on the right side. Group members? Yeah, it's groups already. We got, right, we got translation groups. This is group module, which are already migrated or can be migrated. And I add the back end. We got overview pages for the entities. We have the projects, the releases. We have the files, the lines that have been parsed, the strings that have been parsed, the translations. We have a change log. We have status flags for the translations. If it's suggestions or actual translations. And the list of errors and warnings that the parser gave us. So this is just lines. Which way? Yeah, essentially. This is legacy from D7. So it doesn't have much functionality. It's basically statistics. So now that we've talked about the current state, how could we later improve and localize? Here I gave some examples of a tool which has been used by the French community for some years. It's a separate website, D7.2, accessible at traduction.druple.fr. We do have a glossary that is a list of terms for which we agree on a generally accepted translation. The screenshot is in the middle. It's just to show that every team can act according to its own guidelines. And here it has its own good practices. And then we have a statistics screenshot. And this is done by parsing with XPath. So we wish we had, I don't know, web services or JSON or these new things we've just heard about. And I was glad to learn that by law had just the same issue. And so it confirms that we definitely needs tools like this. And then thanks to this glossary. And again, it has already worked on a memory tool solution. We could generalize it because currently it's only a browser extension for the French language only. And when you install this extension, whenever you hover, sorry, whenever you hover a term, you've got this tool tip which appears and which shows the generally accepted translation for this term, node, item, et cetera. And this could be generalized, implemented in localized and generalized for every language to make it more easy to contribute and to translate Drupal. As a conclusion, you saw that what we can do in the current state. We also have a ddev local instance, which is handy to begin to contribute. We did your feedback. We definitely would like to hear from you what you need, what features are important to you, just missing. You can ask us now, but I guess we won't have a lot of time left. So you can also scan the QR code below to fill in the form, the virtual suggestion box. Or just come tomorrow at 3 PM, room D2. There will be a buff. Come and see us in the contribution room at any time. If you'd like to contribute, please do come to the buff tomorrow, 3 PM. Or you can also come to the contribution room. We hold a meeting on JITC every third Tuesday at 1 PM Central European Time. And you can also reach us on Slack, or localize dash, port dash, D9 on drupalchat.me. Everybody wants your contribution, of course. So there are many occasions to contribute. I guess you've already seen the slides before. And of course, everybody wants your feedback. Please evaluate the conference and also this individual session. Please give us at least one star. They will ditch us from Drupalcon forever. And that will be such a great loss. So I guess there are some minutes left for questions. Thank you. My first question was regarding migration. Do you plan to separate off the Drupal 5 and Drupal 6 related strings? Or is it would be hard to separate? Because I'm not sure if the release is stored on the strings level, which release it is using? Yes. No, it isn't. We could separate this. We are starting at Drupal 4.0, by the way. So the data goes back to the earliest release we have, I think. We could pass them out, but not on a string level, because the strings do not have the relation to the release. So if you want to play around with this site, is this a distribution where it's hosted? Yes. It's an installation profile, basically. We got the full configuration in our Git repository. It's localized Drupal. No. Come to see us. You can't remember the URL. Yeah, you can't remember the URL. But we have a working setup to clone and install right away. OK, yeah. OK, yeah. I think one more we can do. I was just looking around if anyone has questions, so I don't want to steal the show. My question is that, do you plan to migrate all the contexts from the current localized? Or do we have any plans to somehow clear up this very hard situation with the context? Context with the strings. Well, this is data passed from the code base, so we won't clear that up, I think. It's like it is, and we have to handle that. OK, OK. That's one last question. Is there a vision why we need to change data model? It looks working all these years. Why the current state needs to discuss it? Yeah, that's clear. First thing is Drupal 7 is end of life at some day. And we need to upgrade to Drupal 9. We are currently implementing the current state as it is, but surely we want to improve someday. Good, then thank you for joining us today. If you have any more questions, go to the meetings or speak to them privately.