 My name is Jean-Baptiste Elcroft. I'm translator. I'm trying to help in the coordination of the federal localization community. We currently are in a situation where our translation platform, our current translation platform named Xanata is in end of life. There is no maintainers anymore. There is no developers since no nearly one year. If you go under Fedora Vicky, you have the L10N for localization team. You can go down a little bit. You see current task. One major challenge is the migration of our translation platform. I will do this. Can I zoom a little bit? Can I zoom a little bit? Yes. So you have the history. First, it's not our first translation platform migration. We already had two in the past. There is some content I wanted to highlight it because the people don't know what's represented to migrate from one translation platform to another. And they don't know the reasons. So we're migrating in 2011 to TransEffects.com. Before, at that time, we had the TransEffects installed in the federal infrastructure. And we wanted to share the maintenance with the TransEffects.com infrastructures. But after a few years, TransEffects stopped being an open source product. And then they decided, the community, as a whole, to migrate to the tool Zanata. Zanata, by that time, was already managed and developed by Red Hat. For a reason I don't know, the whole Zanata team is not part of Red Hat anymore. So there is no more activity. And as there were no external contributors, the tool is dying. So there is here a group of pages that are dedicated to the migration. I really encourage you to have a look at these pages, what are the objectives, what are the current situation, and what are the things that are mandatory. If we do that, the purpose of doing that is to make sure that every single person in our community understand what are the strengths and the weaknesses of our current translation platform and what are our need for the next one. As far as I know, the only existing serious candidate that we have is the translation platform, them WebLate. This translation platform has some very good qualities, but it's not perfect as any other tool. And we have a group of requirements that I try to list here on these pages. So we can make sure that the federal project can ask for some new features, eventually pay for it. So our translation platform migration is a success not only because we are leaving a tool that is dying with a high risk on our ability to work, but also because it better match our needs as translators. So you have here, you have my name. You know how to reach us on Freenade. We use the I11, the internalization channel on Freenade to discuss. We also have some tracking numbers to talk about the activity. And we've wrote already two articles, one giving the current status about our community, which is an article that you saw a few weeks ago on the federal community blog. It aims to show that our community is not healthy. It's too much based on very old-time contributors, and we don't know how to welcome new contributors. And the second article is a work Adam Chamelec from the documentation team and modularity team and I, we did together. We did the translation of every single documentation of Fedora. We have the whole process to transform it into PoT file, and then the translator can produce some Po file, and then we can generate localized content, and we can jump from one language to another. It's ready. It's works, but we are waiting for the new translation platform to make this live. So this migration is not only about risk. It's really a discussion about what do we need, and it's really an improvement about what we can translate, because any kind of documentation published on docs.fedraproject.org can be translated by any team. So the teams and the different people contributing to Fedora just have to publish a very basic documentation, and it will be translated about instantly. I already received some requests from diversity team and from other teams to be able to communicate in multiple languages, and this is one of the answers. So I will first read the objectives. Then I will read the current situation on each of these three items. And I would like us together to react and to discuss, does it match the reality? I did my best to list in a very agnostic. I tried to be neutral as possible to reflect our current situation, but I may be mistaken sometimes. So please react if you don't share the point that I listed. And then I think it will take 20 minutes to go over these three points. Then I will talk to you about what is beneath the migration planet in itself with the schedules and the steps. So sorry, it's not my computer. Can you read? Is it big enough? Yes? Good. So first part is being able to host projects. Second part is being able to support team processes. Third part is being able to translate to support translation process. So this first part is about hosting projects. Today, what we have in federal.zanata.org is we host upstream projects. And we host some federal specific project. Federal specific project, for example, is a website or documentation. Upstream projects are DNF. Some upstream projects will follow the release cycle of federal. It's those who are in the group main. And upstream means they have their own release cycle. It's not related to the release cycle of federal. This is how it's organized today. In addition of these two groups, we have a priority package list that was built with Previn and other Elton and contributors to make sure that in that huge amount of projects, we know where to start, what are the priorities, the things that are the most impactful regarding the end users. And we also have a Red Hat Enterprise Linux group, which aims to make it easier to identify what goes into the different releases of Red Hat. To be honest, I don't really know what is the detailed interaction with the Red Hat Enterprise Linux lifecycle and those translation. It's something I'm not expert in. So today, any project owner, meaning a federal contributor can come and Xanata create a new project, add some documents, and it's on the translation platform. Inside Xanata, you have the documents for a project that are grouped into a version. And normally, most of the time, it's just a single version, which is master. And I would say that's it. In theory, Xanata is handling multiple file formats. But what we currently use for 99% of our project is PO file. So the standard get text. The project owner today in Xanata, they push and they pull manually. Exactly like what you have on TrezFX, it's a manual process. If the project maintainer forgets to push new content, the translator will never know there is no translation to do new work. And if the project owner forgets to pull translation, he will make a release without the up-to-date translation. There is also a command line interface. And here are the strengths and the weaknesses of that. The strengths is upstream projects are very autonomous. I don't require anyone from the localization team to add a new project, to add new documents. They are autonomous. And in the Git repository, there is only one commit for all translation. The weaknesses of this situation is nobody knows when there is a new project added to the translation platform. There is no easy way to know if upstream downloaded the latest translation from Xanata. That's also the reason why we have trans stats making sure that the synchronization is good. There is no easy way to know if new content is, if the content is in Xanata, is in sync with the source repository. And projects can decide not to store translation in the Git repository. For me, it's something that is a very, very bad practice. But project maintainers can like to have this because they consider translation to be something like documentation. It can be out of the scope of the core product they are maintaining on their Git repository. So the question of the genesis, is that OK with Anaconda? Yes, it's exactly this. If you want to reproduce a build of Anaconda for a previous release, you will not find the translation inside the Git repository. So the content is basically lost. It's only joined in the RPM file. It's not in the Git repository. So if you have any side usage of this content, you can't because it's not in the source repository. So question here. Does the context match your knowledge of the current situation? Yes, very good. Question two, does the current process match your knowledge of the current situation? No remark. You can take your time to read it again. It's fine. Question three, do the strengths and the weaknesses of our current situation are OK for you? Do you validate it? Do you see anything else in the current situation that should be added as a new strengths, a new weakness, and a new risk, and new opportunity? Yes. So far, that's good. Sorry? So yes, there is a current risk with Zanata is as the project is not maintained anymore, the tools that the upstream team uses to push and pull content may not be available in the future of federal releases. And if there is any bug or issue, there is no one to fix it. This is a risk on the current situation. Very good. So as a requirement, it means as a project matter, I want to be able to pull and push contents in at least PO files. I want to have a direct connection between the translation platform and my project repository. I want to have a manual connection between the translation platform and my project repository. And eventually, I may want to be able to interact with the translation platform with an API. And at the end, as a project maintainer, I can set or unset some technical checks. So for me, these are the requirements for the web late to fulfill to handle our current situation. Do you have questions on the listed user stories that are here? If you're certain to read. So the question is, why would you like to make it manual? I pass I as a translator. I don't like the idea of making it manual, because it creates the possibility to be out of sync in one side and the other side. And I don't like it. But project maintenance, I use to that behavior. And we cannot force them to directly interact with their gate repository. So we will invite them to accept this new behavior. But if they don't want to do it, we cannot force them. So we want to let them an opportunity to do it. OK, so let's say that these are fine. Do you see other requirements? So I'm a project maintainer or I'm a coordinator. I want to add a new project in the translation platform. Do you have other use cases that you want to see here? OK, I just need a paper. Can I get a paper from over there, please? I have a pen already, because I don't want to edit the wiki directly. So the question was, as a project maintainer, I want to be notified when there are new translations. Do you want to be notified for any language and any new amount of translation? Or do you want a threshold? OK, more on the regular basis instead of event-based. I don't think so. OK, this notification will arrive by email, by a new issue, or by a commit on any repository, or pre-request. You think it will be email? OK. And so you want to be able to subscribe? OK. Mm-hmm. Yeah. So it's fine, because this feature exists in WebLate, so no worries. That's good. OK, I don't go into the system requirements. This is not very interesting, and it's not very up-to-date. Maybe I should remove it to make it show. So that was the first part. The quite technical part about the hosting project. Now we will speak about team collaboration, and it's way more user-focused. So context. The federal localization project handle an informal global team handling schedule, planning, project communication, and follow-up improvement regarding the localization in the federal project itself. And the federal product, there is a FAS group, administrative translation platform and resolving conflicts. There is only one person who have this role at the moment. I think it's Piotr, which is a Polish contributor. And we also have 86 formal translation team, as described in the Elton and Teams page. You have a huge list with all the teams. You have the list of project coordinators. So normally, these teams have at least one coordinator. We suggest to have many to be able to welcome new contributors. These teams may use review process inside Xanata. Nowadays, there is the Portugal spoken in Brazil, Hungarian, Russian, French. I ask you, I don't know what it is, Hungarian and Indonesian who use this review process. And every translator follow an onboarding process, which is described using this link, which basically is quite complicated. I will describe it beneath. So you want it bigger. And let's try. It's better. I try a little bit more. OK. So, current process. The user who is not member of the Fedora community, you go on Fedora.Xanata.org. They have a welcoming page with all the required information with some links to different pages and the Fedoriki and the documentation from the tool itself. And a newcomer trying to login will be redirecting to the Fedora account system fast. After fulfilling multiple steps, accept FPCA, then connect again to Xanata to create an account inside the application, validate the current creation. Then we'll ask a team, we'll ask to join a team. Then someone will manually accept the request. This request often requires to send an email to a mailing list. And then they will have to ask a fast group named CVSL10N to get CLA plus one, which means you are at least in one user group in addition of the FPCA. And so this brings you the normal rate of any Fedora contributor, like voting for the election, editing the Viki, and that's it. And once you are in the team, there is no process anymore. You can do whatever you like. Nobody will know. So this is, as it is being recorded, a not very optimized process, but it's our current process. So, strength. If you have a Fedora account, it goes very fast because you already suffered quite a lot in many other places, so it goes fast. Weakness, there is no communication between project managers and translator. We don't know when there is new project document or content to translate. There is no team management features. We don't know who is working and what was changed in Xanata. And there is no community management features. There is no activity information on the platform, new users, bigger contributors, best teams, et cetera. So I was a little bit bad. As an opportunity, I see any other tool will provide more visibility than the one we are using. So I was a little bit bad when writing this. So, as before, is the context matching our current situation, the organization of teams? I see people nodding and people reading. Don't want to, someone want to react. Good. Very good. So it means yes. Do the current process that I describe it match the reality that you see in the team behavior and in the way the team are today working? Do you see the same steps and the same difficulties? Very good. So the question is, do each team has a dedicated mailing list? I think most of them have it and the email that the new contributor have to send is to this new, this specific language focused mailing list. I think in the official process, we have also to send an email to the international mailing list, but it's pretty rare and nobody makes sure that it's the case. So, strength, weaknesses, do someone want to add something? Yes. Okay, so what you just said is in these 86 language groups, there are probably are many coordinators who are not active anymore and we have to make sure that we will identify them in the migration. But what is the weakness with the current situation? With the current rule? Okay. Okay, so the weakness is when there are new contributors, they can send a request but have no answer because we don't know that the coordinator is inactive, so he will be faced with a wall without knowing what to do. Okay, very good. Anything else about strengths and weaknesses? No, it's fine. Good. So, here are some user stories I've wrote. I'd say, as a translator, I want to easily access the translation activity of my language team so I know, so that knowing active contributors is easy. As a translator, I want to know the translation activity of my language team on a document so I can review changes. It sounds quite basic, but it's something we don't have. Okay, as a translator, I want to get notification if someone does a first contribution to my language team so I can easily welcome and review changes. As a translator, I want to get notification for events of the document so I can easily keep up the translation of a document that matters to me. This match your requirement as I'm a project metaner, I want to know what's going on in my translation so I want to get notification. And I added a few things about purity management. I said, as a global localization coordinator, I'm able to edit the welcome screen with text and images so newcomers have the basic information to join the community. You know, like you connect to the application, you have the basic where you are, you are in the federal community location project. Here are the key information to know. As a localization coordinator, I'm able to highlight specific project groups on the welcome page so that contributors know what are the priorities. As a global localization coordinator, I'm able to create a list of components so contributors can easily find a group of related components. And as a global localization coordinator, I'm able to create a list of projects so that projects with different communities can be easily identified. So these are the key user stories that I identified regarding team management. Do you see other user stories? What do you want the tool to do regarding our team management? It's... Okay. Okay. Okay. Can be. So, thank you, I will repeat that. The question is, don't we have some kind of roles in the team because there are multiple activities that you can do in the translation team. The first one is you submit translation, then you can also review translation. And there is some use case when some teams or maybe globally in our community, we would like to prevent a newcomer to push directly new translation if he's not in a specific group. So we assure a quality process. Okay. I think it's very true and I will add it. But I don't think we can say this review and validation process will apply for every languages because if it works for languages with more than one contributor, it doesn't for very little languages. So I will say it's a per team configuration to do a validation before pushing content. Does it make sense? I already speak about review content. Content reviewing. So I'll just write this. Add roles and possibility for teams set. So the two requirements. The first one is to have different roles in a team. The second one is for a team to be able to set a review process that is mandatory before pushing content. And you also talked about quality checks. Can you be, because you talked about two kinds of checks. One which was language check and the other one which was technical checks. What do you? Okay. This is the translation platform who will handle this. Okay. Okay. Very good. Do someone else see something to add here? So let's go to third part, translation process. Translation process. So this one is fairly short on purpose. So today, so the federal localization project contributors translate using a web user interface and can periodically use command line interface or file export imports. But most of the time the contributors use the user interface from the translation platform. User will connect to Zen at times such for a project or group, select his or her grade, select the document to translate and then actually translate. User can search and replace even single characters. User can use a translation memory and a glossary. User can translate a group of messages without changing the page. Meaning they enter and they have a list of 10 messages to translate and they go from one to another. So the strengths of the current translation platform is the user interface is very efficient for the translator. Second, the search and replace is very efficient for quality reasons. It's very useful. In French language, it's especially for typography but there are many other use cases. Translation memory is very efficient on Zenata which is a huge help for little teams even for big teams just to know how a term is translated. Weaknesses, there are multiple steps required to reach an actual translation and there is no overview of activities. So I see people nodding which is quite positive. I see no risk and opportunity on that subject. The risk maybe I could add is Zenata is very strong for the translator. Very, very efficient for the translator. The future translation platform, Weblate, will probably be less efficient. So we will have to find a way to make sure that the translator still feel comfortable with the new Weblate and really well explaining how to use it the best with the new, so they don't come to us saying we had a good translation platform for us and now we have a bad one, we have some indicators but we are way less efficient. So if we want Weblate to be an efficient tool as efficient as we have for Zenata, we have to make sure that the user interface is efficient, the search and replace is efficient and that the translation memory is efficient which means if we have some issues with these features, we will have to invest money or contributor time to improve this feature on the Weblate and if we don't do it, we will have some translator who will argue against the translation platform. Gents, compared to Weblate, so the question is what kind of problem do we have with Weblate? I will make a demonstration of Weblate with the documentation system in a few minutes and you will see that there is more waiting time from one translation to another. The translation memory is less accessible, it works but it's less integrated than what we have in Zenata and so it can be pain points for translators. And I don't know if the amount of new features and new integration of the new translation platform will balance this or they will not see the value where I personally see. I personally prefer to have a good translation platform from team management, even if I am a little bit less efficient using it. So, user stories. As a translator, I want to be able to create a translation memory containing a wide range of content so that knowledge beyond federal community is accessible. This means, include in our translation memory, translation, sorry. This means, include in our translation memory, translation from projects out of the scope of the translation, the federal translation community. For example, you take the translation memory of GNOME project and you put it in our translation memory so our users, the federal community can make advantage of this. As a localization coordinator, I can automate, complete, I can automatically complete existing translation using a translation memory, using a manual threshold that, so that user's operation for translators are limited. Maybe the sentence is a little bit weird, but it means automatically complete an existing translation. And as a localization coordinator, I have a tool to handle non-federal translation content so that translation memory is continuously up to date. This part is maybe a little bit advanced, but the idea was, do we want to try to have some kind of automated translation? So I see yes and no in the room. So the idea is, if we can access a large amount of translated content, we should be able to feed some kind of engine to do automated translations. And it will not work for every languages. It will require some tuning for each language. And of course, a big amount of translation for each language who want to use that feature. But do we want to try to do that kind of things? Or do we say it's not mandatory for now and we will see later? What do you think? So that was a yes phase. Okay. So the comment is, I am a translator for the Mozilla community and in Ponton, I already have some suggestions of translation in Hungarian. It doesn't work very well. It's an automated translation. It doesn't work very well, but it saves me a lot of time in my work to translate. So that user will say it's an interesting features, maybe not mandatory for a first step, but it's something that brings value to a translator. Any other comments? I saw no at the end of the room. Exactly. So the comment is, the feature is very useful, but it has to make sure that it's a suggestion for the translator and not an automatic translation. So the string should be identified as fuzzy and not be able to reach. Okay, very good. Thank you very much. Any other comments on automated translation? No? So last point, asynchronous translation. As a translator, I'm able to upload my translation file. So contributing with limited internet access is possible. As a translator, so first line is, you don't have a day-to-day access to internet for any kind of reasons, or you just don't like the translation platform and you have your own tool, whatever it is, on your desktop or laptop or whatever, and you want to use it and then you extract your work and you push it to the translation platform. This is the use case. Second line is, as a translator, I'm able to interact with comments made inside the translation platform with an email client so that contributing with limited internet access is possible. That means like a GitHub or page or comments, you get an email notification, you can respond to it, and it will be displayed in GitHub or page or. So the idea behind this is to lower the distance between the contributors who are used to the mailing list compared to the one who prefer the user interface. So someone who is not a registered on a mailing list or don't like emails will still be able to communicate with the rest of his group and the rest of the community without having to register to any kind of mailing list. And last point is, as a translator, I'm able to interact with the mailing list from the translation platform so that interaction issues with limited access access, contributors are limited with limited access. Okay, so this was the requirements for the translator. Do you see other prints or other requirements that were not discussed here? Yes? Yes, yes. It's the same idea. So the question is, does this ability to upload documents works also for project maintenance so they can do the first initialization of the translation platform? So it's the same idea, but it's absolutely not the same for sure. In Weblate, you will tell to Weblate where is your git repository. He will detect the translation, every translation file, and it will automatically take the existing translations. So you don't have to do anything, but the AD is the same. Any other comments? Yes. So the question is, here we are talking about interaction between users using the translation platform and its name comments. But there is also in the PO files, in the text format, there are some comments that the developer writes for the translators so they can know a little bit more about the context and maybe the words not translate because there are keywords in the software. So this is a totally valid requirements that I will add and I confirm this in Weblate is quite well handled. And more than a comment, you can also join a print screen of where the string is displayed, which is very costly to upload and to make the print screen, but it's doable. I was talking about the context. I didn't know there were two different type of comments that a developer can add, both a developer comment and a specific context comment, message ctxt. Okay, very good. Good point, thank you. So the question was a remark and more context about the different kind of comments that you can have in the get text file. So that was it. Thank you very much for this long time of validating everything in the migration plan because it's very important to do it open so the people knows what are the current situation and the things that are very important for us. Yes, what is the use case for this? So the question is, have we already thought about integrating the translation platform directly with Pedro? So you can easily inside Pedro having a button to go to the translation platform or integrate with the integration platform to make the translation of content easier. I never thought of this. I have no idea how difficult it is technically. And yeah, I don't think we can add this as a requirement if we don't know how it could work. Any other comments? Yeah, it's Pingu. Pingu is the maintainer of Pedro and he's here. But okay, but I don't see the requirement here would be to what would be the goal to make sure that the developers think about translating documentation, the document or source code. The issue is, so the comment was, I imagine that the source code platform could automatically handle some quality checks and the transformation of files. But the issue is the internalization of a software is very related to the technologies that are used and there is no magical way to do it. The most difficult is not to handle POT file for translator, it's to extract it from the source code and to introduce it back to the source code once we've translated content. And this part is very specific to each project. So I cannot see an easy way to bring automation. So do we have someone from infrastructure team or CPE? Okay, easy, okay, sorry. So this migration plan is based on the future of federal 32 release. 31, sorry, release. No, 32, sorry, I'm confused by my own presentation. So I will list the key activities that I see required. The first one, communicate why we migrate. I think it's obvious for the little ecosystem of the people in this room but not for the whole world. Develop the mandatory feature required for the federal community. Explain to project manager what are the impact on source management. Zanata uses command line interface to push pool while we wait, interact with the Git repository. Roll out the federal website and make sure that the continuous deployment that is here still also work with the new behavior. For example, federal website don't store translation so that we have to store it somewhere. Roll out the federal documentation, deploying, pre-production, the current staging, continuous deployment scripts which are running in staging. Voila. And roll out the federal packages. Basically what we need is, we need a confirmation for each package where is the Git repository and then we will do the configuration inside web late to directly take the translation and push it. Normally this doesn't require much upstream contribution. I need the most important things to know the which branches to push and pull contribution from because depending on each project you don't contribute on every bunches. The amount of projects to migrate are 114. The amount of projects in Zanat are 114. I think there is 106 to migrate. Some are not concerned by the translation migration because they are not active or they are like old documentation projects as we have a new documentation project. It's useless to migrate the content from the old migration project or maybe just add it in the translation platform. And here you have the full list of projects and we will need to make sure for each of them that indeed it requires migration or no. Like AppStream, Glib, Anaconda, ABRT, ASNUT, et cetera. There is quite a lot. Are you clear on what are the key activities to do for the migration or do you think there are a few that are missing? I see people reading, very good. So here you have the schedule, the schedule hypothesis that Ben gave me. It can change, but if I understand correctly, no more than one or two weeks. Okay, Ben is nodding. The key milestones I see is one, to be ready for software translation deadline, which means we need to make sure that before January 28th, we have all conserved packages on the new translation platform. So the translator can translate and before March 3rd, they can push that translation. And the second thing, milestone I see is to be ready for system-wide change proposal deadline because as changing the translation platform is quite a big change, it will be probably a good thing to have a change proposal so everyone knows what are the actions, what are the contacts, what is the schedule and we don't do it without telling the rest of the community. So this deadline is January 7th. So before January 7th, we have to have this change submitted and approved. Do someone see a reason to do or not to do a system-wide change? Does it, I see Ben. So what is the impact on people out of the localization community? It will impact the project maintenance. It will impact the federal documentation group and the federal website groups. It will mostly change nothing from RPM maintainers, it's changed nothing and it's changed almost, no, it changed nothing for the end user. So it's mostly internal change. That requires coordination, just we are sure that the existing pipeline indeed works and that everyone thought about the organization of repositories and that they checked it worked fine. We can do it way earlier than that. It's just to match the future process, the future release. Yes, yes, these are impacted. The upstream project maintenance are impacted, like the DNF team, the Anaconda team, the ABRT, is it a team, people. That's it. But not the end user. And for the packaging, it doesn't change anything, the RPM packages. So how do we agree on system-wide change proposal? My idea was to do a test phase with pilot projects and translators. So we can experiment it together and make sure that it's worth the migration, that the translation platform works okay. And I assume that a go-no-go should be probably handled in December. But to be honest, if we say no go, I have no plan B. I don't know any other plan B for there's not much of the translation platform. So I think it's just to formally say that we go. But you can express another point of view. We can wait for any amount of time until the challenges will still be the same. Yeah. So this was about the schedule. So we discussed about the objectives and the different subpart of the requirements. We validated the current situation and the requirements for the future translation platform. Now the thing that we did not speak about is where will we host this translation platform and related translation memory server that we will require with Weblight. So as we have someone from the infrastructure team, do you have answers about this? Because as far as I know, the infrastructure team would like to focus on very core tools for the federal community. And I don't know if the translation platform is considered as core tool for the federal community. Important maybe, but core tool. So can someone ping pingoo and ask him to come here? Ben, can you please do it? Thank you very much. Oh, let's wait to see what's, what if Ben can have a feedback if there's no quick answer, maybe. My hypothesis is as follow that the federal infrastructure team will not host it and that we will have to make it host by the Weblight Enterprise Company. This is my most likely answer because Weblight communicating with upstream source repositories, you have some Git manipulation to do to solve conflicts because it's Git. There's some conflicts sometimes sometimes and it requires to some configuration steps that can consume quite a lot of time if you do it badly. So I would not recommend our community to try to be experts in hosting Weblight. So while pingoo is answering the ping, we can go on this. So this is Weblight, which is very, very little. You can go on translate.holcraft, H-O-L-C-R-O-F-T dot F-R. It's live. It's hosted in my bedroom, not my bedroom, but my, yeah, the main room of the apartment. On my own server and I know how to administrate and how to host a Weblight server. So what you can see here, maybe I will zoom a little bit, what do you think? Good idea. Okay. So I will log in, I will log in using federal account. I automatically, I said open to open source people can connect to with open ID. Can you connect with your fast account? Because I will never be successful using my, because of the keyboard, right? So I did something very bad. I could be pasted my password very well. So I am connected. This is me over there. I have access to settings and stuff. And in the translation platform, there are a list of languages for the documentation system we did with Adam. We focused on a very limited set of languages, French and Czech because of our natural language and Japanese just because Japanese, we don't have specific reason for that. So you have a huge list of components because the documentation system is very, very huge. And you inside a project, you have a list of components. This is entora.yml which contains the description of the website, the list of pages. And then here you have the index. So it's fitra.elten and slash docs. It means this is the homepage. You see the number of strings. So there is two, three strings to translate containing 313 words, next pronunciation test to requiring an action. So we can go directly there. You see this is ugly because the documentation team is embedding directly at the translation, the HTML directly inside the content. And you can see here the changes. Before it was 29, it changed to 30. So you see what changed. Previously this was F28, now it's F29. So you can see some information. So let's go through another project. What do I do? Like this. So as we have been with us, we will have a look at the console. So we have service people. So you can see all pages of the federal documentation system, the console parts. These are exactly the same as the URL docs. So you go to console. You have a page that is named contact, console contact. And you will see here, it's console contact. And it's the content from the master branch. And you will see the six strings to translate contacting the federal console, which are exactly what you see here contacting the federal console. So you will have the different, here the translation to put. Here you will have close strings, mean close inside the file. The commands from other users, the machine translation. I'm not sure there's any activated in my own server. You can see the translation in other languages. There is none on this. And here you can see the history of a string. If I go there, I have so my profile. I used unpurposed English for the presentation, but the user interface is translated in many languages. I did 333 translations. There is my last login registration date. Oops, sorry. Here are the list of project I contributed to. The activity in the last 30 days, zero, sorry. And the activity in the last year, showing when I did translate some content. Looks like slightly buggy. And you can see that my last translation was the translation of the letter D, which is very difficult in the federal release notes, federal 26 in the sub-part developers. And it was in French language. So you can see here the history of everything I did and I can go way further seeing every change that a user did in the past. If I go, I don't remember where it was. I think for a specific project, I think there's also an activity tool. Mm-hmm, raise it, tool. So this is for the federal budget projects. You can see when there were some activities. And you can also have the full histories. When there were an upstream change and your string to translate, you have different kind of events. And you can even go and see all translated strings for that particular project. So of course, I took one with no translation, bravo. So this tool is online. Anyone can connect and translate. It's just not very, very fast because here we can see there were a translation for Czech language. And so here we can see documentation, the federal, which is written in Czech, which I will not read. So this is kind of a field that the maintainers will use to see if there were some new translation in the project. Do someone have any question about weblet in SAFE? No, okay. Do we have some news from Bingo? No reply. So I think we're done. Do someone have questions or requirements? You can connect with your fast account to this. You can do whatever you like. Worst case scenario, you destroy my personal server and I will be angry, but I doubt you will successfully kill my server. I think so. Let's try this. So I go on languages, I go on Czech. I go on tools, no, I go on activity. I have the statistics about the translation in Czech language and I go on history. I see there were some updated content, which are the same for all languages. This is just one, the Czech community, there are some new content to translate and there is a look which say that two French guys or two Czech guys or two translators of the same language cannot edit the same component. A component in that context is one file for the further documentation system, but there can be multiple teams contributing the same component. It will not be an issue. So there will be a lock. So I'm still searching for, yes, yes there is, but I don't know why there is a huge list of non-related, normally you can see it, but I don't know why there is a huge list of events. I think that probably is a way to filter to have only translated strings. Hello, let's hope I will be, oh no, it doesn't work. So let's try with the French language, I don't know why with the Czech I have no results. Page one. So, okay. So I think it's just that in the Czech language I did many, many technical updates, so we only see the technical updates and not the new translation. And here when you go to French language I did some translation last month, so you can see also the translation coming from me. And maybe I can filter, I'm not sure. No, this is bringing me. This probably is a way to filter this. This is an export in CSV and this is an RSS feed, so you can register using a tool or one application. So there is something, it's not perfect because we have a lot of technical updates, but it's answered that. Any other questions? So, yes, but no. Yes, but no. Yes, we can add new languages, but I'm connected as a French speaker, so I will be able to add French language. And if I want to add Japanese language, I can try, but. You know the Muffelow? It tells me it will not work. I did a new language in a project, requires a few steps in the background. And my server not being very, so I want to be able to translate in Japanese too. I save, we will try. Let's try to be optimistic. But normally it doesn't work when you show that kind of things. Okay, I will take projects. So the question was, is it possible to add a new language? So you see here we are in a project only, only translated in French language. I think I have a tool, where is the button to that? Where is the tool translate? I don't remember where exactly I have to add the language. Okay. When you are on a component, this is the entire component, which is a default component for localization system. You say, start a new translation. You select the language you want to translate in, or we search for Romanian. At least I can write it. But I will not be able to write it with this camera. So you select the language you want to make the translation in. You validate, you wait for 30 seconds and you have your new language. That 30 seconds wait is related to my own server. Because it's a slow machine. There's some kind of suspense now. Will it work or will it crash? So the documentation system is a little bit complex because we decided that for every single page, HTML page that the user can see, there is one translation component. So it's very easy from the HTML structure to go in the right place in the translation platform to translate. Which means also that there's thousands of components on the translation platform because there are thousands of pages which is a use case, a web late, don't handle so often. It's a rare use case. Normally you have one project, one huge file with everything inside it. Here you have one project and thousands of components. So it added the Romanian component and then you can translate. Anyone can add a new translation, a new language in that particular settings of web late. So I will not translate in Romanian right now, but I could do it. Thank you everyone for coming, for contributing this validation of the translation platform, migration plan. So next steps are to effectively have have web late hosted somewhere, either on our own infrastructure or paying the web late company to do it. And once we have this, we will put the documentation system. We will put the documentation system live, like, I think it's like this. Sdhj. You see here, there's an ENES. You can switch to Czech, to French, and to other languages. So we just have to find a page that is actually translated. So I think, okay. Here you see it's written in French. And you can switch to English again. And your experience is still good. When you go from one page to another, you will still keep the same language and you can switch from one language to another. And if it's not fully translated, it will display what is translated. You see, here I only translated the two... Here I only translated the titles. And the part on the right. But the rest is untranslated. So the English content is displayed. So even if there is an upstream edit of the documentation, the user will still access the content. Unfortunately, not in his language, but that's life. That's it. Thank you very much.