 Alright guys, welcome to my talk on Xanada Translation Platforms, first bear with me my cough, I got a bad throat this week so I'm coughing, just bear with me. So I'll do a brief introduction of myself, I'm working with Red Hat at the moment from the Globalization Tooling team, I'm a Source Senior Software Engineer, I've been joining Red Hat for five years this year and been working on this project ever since and our team consists of four full-time software engineers, so let us begin. So these are the topics I'll be going through today, what is Xanada, the workflow obviously, translate in Xanada and what's coming up in 4.0 release. So if you've got any questions during the presentation just let me know or interrupt me anytime. So what is Xanada? So Xanada is a translation platform that used by various community projects. It was started as a tooling to help internal Red Hat translators to help with their workflows and translation processes but then it evolved and get into the community of open source. We are currently used by internal Red Hat translators, open stack community and also Fedora and as far as I know there's couple of our private company that's actually using or deployed their own Xanada instance using them by themselves. So Xanada starts off in 2008 and the main focus is how we can help the maintenance and the translators with their workflows in order to get their projects translated. Two of the main components that is I think important which is the server side and the client side. It is written in Java and JavaScript for the front-end and running on my scale databases. And for Fedora we're actually migrating my great all the Fedora packages in 2014. It is fully migrated now in Fedora.Xanada.org. So the server side, so basically that's the back-end of the whole Xanada. It's the brain of the Xanada. It hosted in JVOS EAP in internal Red Hat, handles user interactions with the REST APIs and through the interface interactions, persists data into database and the line there, process of migrating ReactJS from front-end. That's basically if you have noticed our front-end is actually using JSF at the moment. It's been obsolete the technology so we are currently migrating to ReactJS to handle the front-end itself. So there's a couple of instances that Xanada has for the open source community. Fedora.Xanada.org is the one dedicated for all the Fedora packages. We've got Translate.Xanada.org which is for the open source project so anyone can host there if they register themselves. We also got JVOS.Translate. JVOS.Xanada.org which is for JVOS project itself and we've got one more instances in Xanada internal and also OpenStack has their own instances which is OpenStack.Translate.OpenStack.org. So all the four instances for Dora, Translate.Xanada.org, JVOS and internal Red Hat is managed by the Xanada team whereas the OpenStack ones they are ops teams actually handle it. For the client side it's a command line tools that I think mainly used by the maintainers. It handles the command line interactions with Xanada server so we do a push-pull getting some interactions or getting some data from the server itself. And push-and-pull source and translation files obviously so previously I think in two years ago we have a Python client for Xanada itself. The problem with that was we having problems maintaining it in terms of keeping up with the technologies and there's no expertise in terms of Python programmers in the team. So currently it's maintained by community so it's not that up to date compared to the other client that we have. We have Java client which is currently maintained by the Xanada team. It has gone through a couple of migration before. Currently we are using a framework called zero install so what it does it helps the client to be packaged to multiple platforms. So it supports in Mac OS Linux and Windows. That's the main problem that we had previously with the Python client where the users need to install different packages in different platforms itself. With zero install basically it supports multiple platforms so all you need to do is just install zero install for either of the platforms or operating systems then zero install would handle the Xanada client through downloading some feed from the Xanada server itself. So we're talking about workflow. So workflow in Xanada as in general pushing operations mainly on pushing source files. So to me the operation is mainly done by the maintainer itself. It's about pushing the resources that's been ready to Xanada and make it available to all the translators in Xanada to be able to start translating. There's two way of pushing source files using browser and using client. For using browser obviously it's not recommended. The reason I put it there because it's kind of like a one-off operations where if you got an urgent to push a single file without going to configure the configurations for that project itself then using browser is the best way to go. So all you need to do is to log in and you know go through the links and you can push it up straight away or upload it if you call it. And the benefits of that is there's no extra installation which is does another client need it so you can basically a browser login and done. For the client itself it's more recommended because basically with the project hosted in Xanada there's a configuration files attached to it which is called Xanada. And in that file there's a lot of configurations of the directory's name, the downloader's files, the naming convention and everything is been set up by the maintainer. So it's more recommended to use the client to actually push the source file because it's actually reading the Xanada Xanada configurations and push it to the correct directories or the file name itself. So using client is more appropriate and it can be automated because you can set up a con job basically to run the command line itself. For pulling translations so it can be done by maintainers or the translators. For the maintainer obviously they do it when the translation is finished or completed and ready to be packaged and sing it to the repository. For the translators I would imagine it's mainly for previewing their work after the translation has been done and it mainly be done by the QA as well to build up the test instances or the documents and have a preview or QA on that. Again it can be done by browser and client. Browser is easier just click on and download the file straight away. It's the same benefits and same pros and cons as the pushing of source files. So using browser obviously it's a quick preview of translated documents, a quick way to QE or get the resources that's been done in Xanada but it's not recommended for the repeatable operations. Using client again it's the same, it can be automated, it's more controlled because the configuration is there and everything and it's more recommended, it's more stable in a way. So this is diagram for overall diagram for the workflow in Xanada. So you got the G itself is actually quickly possibly I can't find a better icon for that so sorry. So you got a maintainer or the writer that actually push and pull translations from Xanada and you got a translator that actually only handles translations in Xanada so you can only translate the strings and the maintainer actually syncing the after pulling the translation syncing it to the repository and built the documentation or the package itself. So overall this is the well this is the simplified versions of the operations. Obviously there's a lot of backend stuff happening when building a document there's a different process and also when building package as well there's a lot of happening in the backend. So translate in Xanada so in general obviously when I put up the slides I didn't obviously I forgot about the processes in Fedora where you need to forget the processes in Fedora where you need to register in the mailing list and introduce yourself and the processes of a translator to be able to contribute into Fedora translations. So what I put it that is actually the process for for Xanada itself. So from Xanada point of view user just need to have an account in Xanada and you are a member of a language team. So the process would be you register yourself you get an activation email for your account then after that you request to join a language team. So obviously for Fedora's process is a bit different as far as I know you need to join a mailing list and you need to request for joining a membership in the language team and it's up to the team coordinator to approve it and then you can start to contribute into the Fedora translations. So that's the general part for mostly all the projects in Xanada. We also recently introduced a project security so it's more like a more tighter control projects for translations. So for the in the project setting itself you can actually set invite only in the security tabs. So what that means is if it's set it's only a set of users or translators can actually translate in Xanada rather than all the people that are actually registered in Xanada. So it's more control environment. It's actually focused more for like a corporate projects where you don't want anyone to be able to translate in the project itself. You just want to tightly secure it and you only trusted a set of people. That's the whole idea for that feature. Now for translate obviously if you guys have been using it there's an editor that you guys go into. It's an interface that is actually written in Java but it's we have a framework called GWT that actually converts it into JavaScript and it's an interface for translator translate. It supports concurrent editing for multiple users. So if multiple users actually in the same entry when editing you can actually see their name in there and try to avoid the conflict translations in an entry. Now the last point new improved editor is in progress. If you guys have been seeing it there's a small icon on the top of the editor saying alpha editor. So that's the new migration that we moved to React.js which I mentioned earlier. So in that new editor we are still working on it at the moment. It's in alpha state. So we are slowly migrating all the features that's in the current editor into the new editor itself. So keep an eye on that. It also supports with the new editor it supports responsive design. So that means if you try to view it in a smaller screen or in a mobile it will support that. So in the editor itself I call it helper but some people call it different names. There's a couple of features in the editor that helps with the translations. So it's a translation memory and glossary at the bottom if you if you in the existing view in the editor itself. It acts as a reference for translators during translations. You get to see what has been translated in Zanada in the past and has been approved or saved as translated. For glossary at the moment it's uploaded by admin. So it acts as kind of a dictionary for the translated itself. So glossary is not as updated as translation memory because it's by per upload. So it depends on the admin that actually uploading it. For translation memory it can be from any projects in Zanada. So any translation that has been approved or saved it will instantly show up in your next translation when you actually translating a string. It will search for the matching ones and it will display at the bottom there to help you guys to translate. I'm going pretty fast here. Any questions? No? All good? So at the moment in Fedora.Zanada.org the version is 3.9.3. It was 3.92 as of last week but this week is 3.93. The reason was there's a bug fix, urgent bug fix on the login in Fedora. The main problem was the Unicode itself where if you got a Unicode in Fedora on your full name or in your name it would create problems. So it's a problem in Zanada itself. But so the next one we expect to come out is 4.0. That would be in three months time. So we just release 3.9.3. So three months time we try to release it every three months and every six months there's a major release. So in next three months hopefully we can see 4.0 up. So the features that we have in 4.0, there's couple of changes in the UI itself and some extra features in the front end. Docker image for developers and quick start. So from what the feedback that we got from some of the contributors to Zanada, it's very hard to set up Zanada in their machines. So we have provided a Docker image where you can start up a speed up a container and start up straight away easily and you can pretty much start coding itself if you want to. The first release of Zanada Sync. So Zanada Sync is a site projects that we do around Zanada. The focus was the idea was to help out with the workflow that we have. If you look at the workflow just now, so if you look at the push and pull translations and sync to repository, at the moment it's done by the maintainer manually or he can set up a cron jump. So that Zanada Sync projects is to automate that three processes. So basically it's a scheduling system where a maintainer goes in there, put in some settings, point it to the project's URL or project settings. Then in the time or in the schedule that he set up, it would actually push sources from the repository to Zanada and pull translations, sync it back to the repository. So it depends on the configurations. So he can set up every hourly or daily stuff like that. That would done so it will automate the whole process. So it would eliminate the need for installing Zanada client on your local machines, worrying about the source is not updated in Zanada. Translator is not getting the latest source string in Zanada. The effort for translate all the old string is wasted. So that Zanada Sync project would automate all that process and it supports only the same login as Zanada. So you don't need to register a new account. So you use the existing account, although it's a separate service, but it uses the same login as what you had in Zanada. So it's a tool that look what is going on in Zanada platform and look what is going on in the source repository and asking to, and making some new automatic syncopation in one side and both sides. And we have a very long tool to move one side thing, you know. At the moment, yeah so at the moment we don't have that yet, but that's because it's a new project. So we try to take it step by step. So we're trying to do the first release. Then we will provide, I don't know if you guys use Jenkins before, but there's a lot of good features in there where you can see the logs, the history and all the job status. So we try to have that then as well. Obviously it's going to take time, but the main focus right now is to have it working with the basic syncing. So to automate that three processes first, then we can add in more features in the future. The idea was allow maintainer to have an easy life. They don't need to worry about, oh I need to push, I forgot to push the source string when it's updated to Zanada, or pulling the latest translation from Zanada. That's the worry that you don't need to worry about anymore. It's a setup, then he would have done it automatically in the back end. Now the next one is project-based glossary. At the moment the glossary itself is global, meaning that it applies to all the projects in Zanada. One of the feedback that we got was some of the projects prefer to have their own context, and that's a lot of problem for the translators because different projects, same word has different context, and translating it would be a lot difficult. What the request was, we need a project glossary. Again, this was base, the idea was coming from the external parties where they want to have a more control environment, and therefore they want to have their own glossary to be used or referenced by the translators, meaning that that word should be translated in that way, or it shouldn't be translated. That's why the project glossary is introduced. It will be in 4.0, and also the existing glossary, the feature will be improved. I'll show it to you guys later on some of the previews for 4.0. But we have improved the existing glossary where if you assign to a role, you can actually edit glossary itself in Zanada now. Unlike previously, you need to do it outside Zanada, push it to Zanada by admin, but now you can actually edit it in Zanada, but it doesn't keep the history as it doesn't before, so just be careful when you edit in glossary. Is there a plan to bring back the history? There are talks on that. We're still evaluating whether it's worth the effort of doing that or not, because at the end of the day, it's a glossary, it's a dictionary. It's not like a translation memory where we need to keep track of the contributions for individuals or the history of the translation where it goes bad and stuff like that. It's just a glossary, it's just a dictionary, so we're still evaluating on whether we want to put in the effort of having that or not, because that would increase hugely on the database sizes, obviously. Having it completely run on itself, but are you considering storing that to make it triple? Yes, so there are a couple of, actually we are having a side project of how we improve the storage. We have been looking on document-based database. I'm thinking more of something like the current version of the database, unless you are doing now, and GBA3 and B3G, if someone wants to consume GBA3, they can just access it. Then translation memory is the first one that we're going to migrate first, because it would improve hugely on the performance. Then we were looking at the glossary move there as well, so it's going to be step by step. The last point is integration with Fedora. So for the recent few months, we've been concentrating on integrating with the systems, so a couple of systems. So from Fedora point of view, we are trying to integrate with the Fedora batch and Fedora Hubs. As mentioned earlier this morning, Fedora Hubs is the upcoming project for Fedora, where it tracks all the activities in the Fedora community. So one of the early experiments they want to do, or prototypes, is to have another feed information about the translation activities into their systems. So previously we already done some of the implementation on that. This one is just an improve on the previous versions. So there will be extra information feed on the Fed messages, and obviously the batches itself is the same webbook that we call a webbook, because it actually fires up a message to a system. So it's the same message that's going to be used by the batch and the Fedora Hubs to actually have them consume the message. In progress, again, it's the editor itself. It's a big thing because we have been trying to push it for over a year, but almost a year now, since it comes up. The reason being was there's a lot of changes in the backend where we have used the old technologies where it's already obsolete, so we try to migrate to new technologies. So it's taken us a lot of time to actually migrate that, but we have got to the point where we will start migrating some of the features from the old editor into the new ones. So hopefully it will be ready to be used soon. And new plugins in Zanara Sync. So as I mentioned just now, Zanara Sync is a project to automate the process. It's actually designed in the plugin-based systems, so you can write as many plugins as you want. So the idea was not only you can sync to a Git repository, but you can write plugins to SVN repository or CVS repository if someone is using it still, or even to other systems. So its main purpose is to sync or pull source files into Zanara and get transition files into somewhere else. So that somewhere else can be a Git repository or any repository or any system. So as long as the plugin is there, it will be able to automate that whole process itself. So the idea is to, obviously we first start off as Git because that's the most commonly used repository. But in the future we're probably looking at some of the systems, probably some of the subversion is one of them because some of them are still using that. And one of the systems, Drupals, which is having their own translation management, but we were hoping Zanara can do some sort of syncing with them to actually have the resources available in Drupals. But that's the whole idea. That's the whole idea for the plugin-based system. You can write as many as you want. And as long as it can be, it has a REST API that supports it, we will be able to sync it with Zanara. Actually that's the last slide. It's pretty fast. So again, any contribution is welcome in Zanara. I know there's a lot of Python programmers in Fedora, but if you know a bit of Java or you've got any feature requests that you want to try out with Java, please do. It's easy. With the dockers right now, you can spin it up straight away. But yeah, that's about it. Questions? What's the requirement for Zanara? So that's a question. It involves a couple of processes. So if you understand the whole process, the project needs to start off with internationalizations where you externalize the string. So the most common one is pull and pop files. But the recent one you can see in JSON files, or XML files, or Xleave projects, or property files for Java. So there's a couple of formats. So Zanara supports all of them. Well, not all of them, but the majority of them. So if you look at the Zanara XML, or when you create a project in Zanara, it would ask you what project type you are. Then when you push it, it would actually scan for a certain extension of the files. So if you set it like you are a Java project, it will scan for dot property files. If you set it for Xleave, it would look for XML files. So there are a couple of them. So if I set it up for POP, then it scans for... POP files as the source files. Then pull files is the transition file. So can it also work if it looks like IEP2 or no IPS2, which is used by no, for example, regenerators? At the moment Zanara doesn't support it. But if you set up your projects, I believe if it's a Python project, you can set up easily to externalize the string or internationalize it, as you said. So I believe, well, I'm not entirely sure, but most of the programmers, if you actually develop a package, you would have a fair bit of idea what you should do to have your package prepared to be translated. So to have that files ready. So that's why there's a lot of confusion where a programmer write a program, it's not internationalized, and please translate my package. It doesn't work that way. But having said that, in 4.0, we are trying to centralize everything. So the idea was you no longer have to select the project type. You just create a project, then Zanara itself would be smart enough to figure out what type of project is that. So that's the whole idea. We are still working on that, so hopefully you'll see that very soon. Now with the new endpoint, it actually supports ODT files as well. So the open office or LibreOffice file format. So the slides, the LibreOfficeWriters format. So ODT, ODP, HTML, even .srt, which is subtitled files, if I'm not mistaken, for videos. So it's all supported by Zanara. The upcoming one is JSON files. So it's largely used now by a lot of the JavaScript projects. So we're trying to support that as well. So that's the whole idea for the file projects type. So at the moment, if you are doing it through browser, yes you can. But if you try to upload it using client, then it doesn't support it. Because in client, we have some rules where it only scans for one specific file type. But if you're using browser, you can actually upload multiple file types. ODT, ODP, multiple file types in a single project. So if I want to do it with the common line, I should create a different type of document. It should be a different type of project. Because obviously, yeah, yeah. So the idea was to give you a bit of background. The client was created on port and pro get text format as the first format. So the intelligence or the rules that we put in there is to have only one single type. But as the project grows and more and more different types of projects, there's a lot of requirements to coming up saying that, oh, we want to support multiple file types in a single project. For instance, there's a markdown with dot properties actually request from internal Red Hat. So at the moment, yes, we are using browser to actually upload all those files into Sonata. But hopefully we can improve the client to support that in the future. With the file project type that I mentioned earlier, the new improve project type, the client does support it. We're still working on it. But if you use file project type, so you don't need to specify any projects that you want. You just need to put what extension you want to include during the scanning process. It would actually support it. So I believe it's in 4.0. So hopefully we can see that. But yeah, it's there to support multiple file types. It's our contribution. If someone wants to contribute to translating, it needs to be invited. But how it works is happening. It's invited as in the project security checks? Yeah. Again, the extra security check, it's a decision from the maintainer. It's from the package maintainer. So if there is a package maintainer that says, okay, I only trusted this set of people. I only want this set of people to translate my projects so big. So obviously the project would be limited to that set of people for all the translation effort. But if you set it that way, that means all the translator that has been approved by Fedora that goes in and translates will not be able to translate your projects. So what the project maintainer does is actually limiting the possible translation that he can have from all the contributors in the project itself. But it's up to him because it's his decision to actually say that I only trusted this set of people. Yeah, we value that opinion. No, but my question was, let's say I want to contribute in docs. Where are the steps I have to follow? Where I have to move to? To be honest, I don't have the exact answer. I believe Noriko has, which is that. So I believe that that's a wiki page that has all the steps. Yes, but in the case of docs, he doesn't send my name to the main list. I actually live and I'm not there. I'm not a pro in the team. Okay, so it's actually the coordinators that's not approving that then. So you should contact the coordinators. Or I can look it up for you, I can approve it if you want. So as I mentioned earlier, the four instances that I mentioned, the Fedora, Translate, Jboss and the internal ones are handled, it's all managed by the Zanada team. So the Zanada team is an admin in all the four instances. But having said that, for the Fedora instance, it's a bit different. We don't interfere with the request for the Fedora instance. It's all done by Noriko and one of the guys... So Noriko and Peter is actually handling the administration for Fedora.Zanada.org. Well, does the Zanada team only interfere if there's a bug that we need to go in or we need to debug the systems? So for the Fedora instance, it's a bit different. So if you've got any problems with approving your language team, approved by a language team or you have problems with logging in or stuff like that, you should contact Noriko. She should be able to help you to actually push the coordinator to approve it for you. Can you show me the feature I required with looking at how much each person has? Yeah, I'll demo some of the stuff in here. Let me... Just need to see it that way. So this is just a quick preview of what 4.0 will look like. So this is running on my local instance. So I need to find my link. Actually, I should show you... Let me show the personal statistics first in the current versions. So as soon as you log in... Sorry? If you're not logged in, you'll be able to see the profile but not the statistics. So if you do a search here, let's say Noriko. So you can see the statistic here and you can select the time frame. And we actually got an API to have that. Sorry? That was in 3.8, if I'm not mistaken. Sorry? Oh, it's a bit sensitive now, so... So for Noriko, it's a bit different, right? She's not a full-time translator anymore. She's managing the team, so she's not doing any translation. So not to make her look so bad, so let's not continue on that. But yeah, that's basically the page to see the statistics. It's a statistic page. It works well, but it's well hidden in the past. In 4.0, it will be more easily accessible. Like for example, when you're in the project page, you can have document view. And you know who was the last editor, and there's a name, but there's no link to that. Yes. Will it be some improvement? Yes. If I click on Japanese because she's not... Whatever she's Japanese or not, Japanese may hear that she's part of the Japanese team. And if I click on the Japanese team, will it be possible to have this? To have an idea of the activity of the Japanese team? Yes. Because it's possible. To be honest, Zenata has a lot of information of this. We keep every data on every translation that all the individuals have made. So there's a lot of valuable data in there. It's just how we actually present them in Zenata. What sort of information that we need to show in Zenata. So we are currently working to improve our project page. Project slash version page. At the moment, it's separated two pages. So you've got a project page with a list of versions. Then in the version page, you've got the document list, or the language list, and the documents. So we try to combine all this into one single page, where you can actually only see... Well, it's only highlight the language that you actually join in. So you don't need to go through all the languages, click on that, and select the documents to translate. So it's going to straight up with your languages that you have joined. Then it will have some useful information. By useful information, I would mean the recent activities for these projects, or for these versions. And that's something that would interest most of the translators. To make them easy access to the recent updated documents in the project itself. So we are currently working on the prototype for that page. So hopefully it would save a lot of problems where the... So one of the complaints that we got from the translator was they need to go through the list of the languages. And some of them, if it starts with Z, then obviously need to scroll down at the bottom and slide on that and stuff like that. So yeah, that would actually solve all those problems for the individuals. Is there any way to compare also? Not at the moment, but... But it would be nice to have a batches, it's kind of a batches thing. People are starting to compare it to each other. Yeah. As I did about command translation, it was like... I said to them, look at the Vietnamese, they have 8.9%. And they really did translate until they reached 9%. I think they had more as a Vietnamese. People like to compare with our computers. Well, generally I would say, well, it's my personal opinion. I would say we try not to create a competitive environment in the package itself. But it's a different opinion, right? Some people love it because it can improve the performance in different teams. So it's a good idea, I would say. Perhaps not so much of comparing between two people, but you can select a set of people to show it in the screen. Yes, I agree. Was it actually about to do the gamification and the idea of batches here? Yes, I agree. Does it have units comparing people that you're rewarding for work done? Yes, yes. And you get a better understanding before comparing the batches, but it doesn't actually reflect an issue. There's not necessarily a good place. Yes, so it comes down to the whole idea of integrating with the Fedora batches system. So that feed itself would actually send a message to Fedora Messages, the FAT message, and they will consume it and there will be implementation on that site to actually award. I think that's something to trust. Because currently we have this situation here in the front row, who has a sonata can, so they have a FASACA, a CLA, but no other group membership. Right now it means for them, we don't even know who can make it. We think it's a factory that doesn't allow it because it doesn't have expenses. For them it can create a problem and they cannot work because of that. That's a very good question. Which open ID, do you use open ID? Do you use the FASACA or this local ID? FAS, FAS open ID. There is the risk at one point that in the same way that Spammer got into the Terraristic Trash, that you may get to a point where you need to require people to use the FASACA on sonata to prevent Spammer from trying to... So you get the amount of translated which is reviewed and if you have enough reviews, you get a problem actually. It should be not like the people should go for sonata and then come to Fedora. They first come to Fedora and then they go to Sonata. So it goes back to the initial process where how to join in the Fedora translator's process. So if you look at the Wiki page, you should actually start with Fedora first before you join Sonata. So you have everything set up in Fedora except the CLA and everything. Then only you sign up in Sonata. That's the whole idea. Because from Sonata point of view, we try not to interfere with the login system. This last step giving me another group member to CLA. So I mean I have some rights only in Fedora if I have more than CLA as a group. So I cannot work for the council, I cannot work for Basker. Well, I can work for Basker but that's it. Not everybody feels nice with that. But I would say it's not something that Sonata can handle because it's an entirely Fedora system. It's an organizational thing of the Indonesian and the same as Sonata. Patrick from Infrastructure. It is infrastructure, yes. He invited us to go to this group about spam. And he invited us to discuss what can we do for Consulate? How about fast groups? My personal opinion is we have to repeat it. And we have to find a good process at the moment. It's a real problem. Can you say it again? This is the last time now. Yeah, but fast group which is not there. We need to use and we need to delay this, create a new one, make clear who joins, who manage the list. And so, it's 100% organizational. But just one question. The first page on Zenata, will it be possible to write it? So we make sure the end users, the translator, if they arrive with Zenata, they say, okay, you are there. You are on the Fedora translation tool. This is when I find information and the user is less lost. And if the user arrives at the connection page, it doesn't have access. And so he has this link. Yes, we can... We take the page 4.0 release to improve the communication towards... The front page, it can be easily added by the admin. It's customizable in every instances. So if you look at the open stack one, they have different front-end because admin put in the information. So at the moment, I believe, again, it's the Noriko that handles that. So if you need some information that's in the front page, please do contact Noriko or myself. Yes. So I'm trying to... Yes? So can you use that to extract data of all the... Yes. You need to have an account in Zenata. That's it. Can you show the API? Well, I don't have it ready right here. But I'll show it to you or I'll point it to you later on on the link. So the API actually allows you to extract the list of contributors over a period of time. So you can get the username. Then you can fire up a second request to get their contributions over a period of one year. So whichever one year that you... 365 days. So from there, you can get all the information about how much that person actually contributed during that time. Yes, yes. So I have... I'm having a problem connecting to internet right now. But... It's time. Okay. Yeah, that's it then. Any last questions? So I think we have a workshop down to tomorrow. We're going to join us and we can have more discussions. Yeah. So give it... Give it... Yes. So please do join the workshop. If you have any more questions, then we can discuss that there. All right. Thank you guys.