 My name is Preetam. I'm the moderator for this session. And I mean, the session after lunch is always difficult because people are probably still lost. So anyway, I'll let you start. Yes, sure. Okay. Just introduce yourself. Sure. Hi, everyone. So I'm Sandeep and I work for IRAD. And I work for international internationalization part of the international part of the computer science where we actually transform a software to get localized into different cultures and get software translated from one language to another languages. So trans stats is very new in the terms like its development and its evolution. So I'll take you to trans stats introduction in this session. So the first is what is product proliferation? So suppose we have an awesome product and we are working on this project from last so many years and now it is so awesome that we wanted to get proliferated to other parts of where it has been origin. So for that we need to get it translated into different languages and to get it translated into different languages. There are so many steps we need to follow, which I'll go through. So how actually Fedora achieved this? So we have a development team for Internet. I-89 is the short form of internationalization which work on core components of internationalization where actually all this happen. Like we have fonts and its configuration, input method, dictionary, rendering stack modules, locale type, typing boosters and these all components. These are OS level components which actually help the software to get transformed or to get topped to different cultures where we can have other languages supported for our system. Like for Fedora 26 we have so much of languages and you can choose anyone to get into the system in that particular languages. So behind the scenes it is these components which actually take care of all the support, all the APIs and everything. Along with this core components we are into development of translation platform. For Internet and Fedora we have Xanata and there are so many open source and close source translation platforms out there and there are other developments as well. So along with these developments we have collaboration between whom? Between developers, Internet managers that is localization managers which actually take care of localization process. Localization includes translation plus other processes. So IATNN is basically engineering part which add all the components required in your software to get translated or get localized. And localization is a process whereby you can actually adopt the software into different cultures. And there are quality engineers who actually check on like everything has been in the correct order or not. Like those translations are getting populated everywhere. The screens which are coming up has proper translations or not are in better quality or not and plus they are working all through in well mannered or expected way or not. So in Fedora there are so many packages behind. Suppose you have Anaconda which when you install any software, any operating system like Fedora. The first screen which appears is from Anaconda and Anaconda has several packages linked to it underneath. So and they have their own dates for releases and how actually translations occur for those packages is this way. Like suppose you have one package, package in the sense you have one software which is actually a part of Anaconda from backend system. So the source code will lie at Pagur. Pagur is GitHub alternative in Fedora we have. And it will link to Zanata. Zanata is the translation platform where all the translations are happening. And then it is being built into Koji build system. Koji is a build system where you actually package your software and produce RPM. So that RPM can be shipped into the final product. And in Fedora we have these much of I mean when you will see the release schedule of Fedora. There are some points which are actually linked to this particular process. And these point are software string freeze, translation deadline, beta freeze and final freeze are common points for everything. So in software string freeze developers are asked to better get stop with all the changes they do in strings. Like you are writing your software and you have some string which are going to the screen for user. So you actually have to stop making changes to those strings when software string freeze has been reached. And in translation deadline translators has to convert or translate all those strings into targeted languages. So that they can be packaged and released in beta and final freezes. So these are the steps and these are the actual milestones of Fedora development. These are the release date of different packages and this is the process. Now let's look at how they are interlinked in transters. What is package localization cycle? So there are so many packages and just consider one package and their localization cycle. Then in planning phase we decide on different aspects like which languages the package has to localize in. Suppose there are so many languages out in the entire globe. So suppose you are targeting 10 languages for your product or for your system. That should be done in planning phase. In development phase translators are asked to create... See in Zanata if you will see there are so many projects and in projects there are different versions. So translators are asked to create version of a specific release. Suppose you have a new release coming up that is Fedora 28. So you have to create one branch in Zanata saying that it is for 28 Fedora release. So here you have software, you have to extract strings from your software and push it to Zanata. In Zanata you have to get it translated and then in build system you have to build everything to produce SRPM or RPM. So this is the cycle. So in development translators are asked to create branches and developers are pushing those strings to Zanata and pulling back after translation. So this is mostly development part. In testing part QE like quality engineers check on those translations. They are correct or not. They are working properly or not and all those stuff and then general availability happen. So in this entire cycle the testing team got very little time because of bit of freeze and those all stuff. Because once translation deadline has been reached this phase has been over. So it comes to testing part and then before beta phase itself testing has to happen. So in the whole process when you will see like from development of a software then translation and then build system building that particular software in the whole process there are some challenges and we actually need to tackle those challenges. So what are the challenges? The challenges is how to track strings of all participating packages have been pushed or pulled from Zanata in time or not. Zanata is a translation platform. Now suppose we have taken example of Anaconda. Anaconda has more than 10 packages running behind. So all the strings from all 10 packages has to push into Zanata and pull back. Similarly we have so much of packages. We have more than or almost 20,000 packages in Fedora. So how actually we need to like how we should track that every strings from every package has been pushed to translation platform and pullback. So this is one challenge. Second challenge is once they are in pullback or they have been pushed are they really participating in the build system? Are they have reached every translation has reached build system or not? This is second challenge. Now what is the volume of translation required for next Fedora release? Suppose we have done a lot of things. We have managed everything and we have produced a new Fedora release. Fedora 28 with everything translated but what is for Fedora 29? What is the translation volume coming up which you have to translate and produce the next Fedora release? So this is one challenge. One of the major challenges for quality engineers is can we fix major translation bugs reported after translation deadline and before final phase? So it is very important. Like suppose there are 10 bugs which has been reported in quality engineering phase and do we have some mechanism whereby we can say that out of 10, 4 are very critical and you have to solve them. So hash blocker kind of thing like which are the blocker bugs and which are the high priority bugs. So there is no system as of now to have that information. Now which set of languages need attention and who should handle of or fix that? Like suppose you have targeted 10 languages or you have targeted X number of languages and you have language experts only for 5 languages. So which bug you can actually solve and which bug you cannot solve? So that particular question is very much I mean it is very complicated. So is there any system to tell me that okay you have 5 Japanese bug, you have Japanese expert who can solve these bugs. So this could be done. This is one challenge and second last challenge was like is there any way to automate some of these steps? So can we automate some of these steps? Pulling back, pushing back, quality checks and there are so many other steps underneath. Can we automate some of these steps and see like how this is happening? Now let's go to TransStarts demonstration. So this is TransStarts screen where you can see that we are actually mapping everything. So we are mapping languages, translation platform, product releases, packages and there are so many jobs working on that. I'll take you very quickly on this screen. Here we have summary like what is in Fedora 28. For Fedora 28 currently we have just one package in the system. So it is saying that for Korean language we have to translate 108 strings. Now select Fedora 28 from here. After selecting you will see everything in details. So one package is about, there are so much of messages, this much has been translated and 108 has not. Percentage wise only Korean has 7.3 percentage so we have something left in Korean. If we select exact Korean language it will show us like how much has not been translated and what is remaining percentage. Now go back to packages, this is very important. Here you can see that we can show how many packages are out of sync. Like those are not synced in what we have in translation platform and what has been built. So here we have everything 0 and one package is being cracked. So if we'll select any of one package it will show in details like here what is there. So this is the statistics we are getting from build system. Like what is the translation statistics at build system level. These are which we are getting from translation platform. Like this is from translation platform, this is build system and upstream this particular statistics we are getting from source repository. So we are actually mapping all these three points we are generating statistics and we are comparing. Like what is the position of all these three places. And then after comparing we just find out like in which languages the work is with us. If we'll go and see two different things. So we have so much of languages in this system. Ten languages has been enabled and in translation platform we have two. The engine is Zanata but we have two instance translate Zanata. In products we have one product Fedora and if we'll go and see in details it has all the release dates. Like what are different milestones it has. If we'll go to packages this is about and this will show what are the last sync date stamps. Now go to jobs these are very interesting. Like these are sync jobs which actually sync to different places. Like with sync to translation platform, with sync to upstream and with sync to downstream Koji platform. These are the logs for all three. So now what we can do we can go and add one package for the system. Login into the system and you can use Fedora authentication for that. So after login you will get add package button over there. So once we click on packages, add package button will be there and through this you can add packages. You have to give the package name upstream URL that is the source of that package URL. We are choosing one package from Pague that is IOK. So we'll be going and adding IOK as package. Now we can see that IOK has been added. So here we don't have any graphs because for graphs we need to get it synced with different places. This is a synced platform. Then we'll sync with upstream repository and here you can see this is an important part. So after getting synced to a translation platform we have these statistics. There are branch mapping in the bottom and once you will go and sync with upstream repository what exactly it is doing. It is cloning the entire repository from GitHub and generating filtering out all the PO files basically which hold translation for this package and then generating statistics on them. So when you will see 47 PO files has been filtered. So this package contains 47 translation files and now go back to IOK and see. So here you can have upstream statistics. So this is the YML-based format to sync with Bell system. What it will do? It will go to Bell system which is latest build details, pull out the SRPM and then unpacks it, filters out every PO file, apply patch and then calculate the statistics. So we are doing it for Fedora 28 for IOK package. Unchecking write-ins means whatever statistics we are getting we are going to store that statistics in database. Now this is the latest build details which we fetch out from Koji build system. We are unpacking SRPM. We are unpacking TABOL. Now PO files has been filtered. No packages were there and in the bottom we can see the statistics for IOK. So now when we will select IOK and go down we can see that we are having everything like we are having statistics from upstream build system and translation platform. We are having generate statistics. These are the languages which need attention because they are out of sync. And when we are refreshing it it will show that one package is out of sync because we got some languages where we need attention those were out of sync. Now let's get back to slide. Here we can see that left hand side and these are the answers to them. Like by comparing translation statistics derived from different places we can answer these two and what volume of translation is required. So in release summary we can see that what volume is required. YML based jobs can pass SRPM to check criticality of translation bugs because we are actually unpacking SRPM. We are running some of the task there. So we can add quality checks there as well. And trans stats can answer which packages are out of sync has diff and in which languages. So that will answer that particular question. And last is there any way to automate few steps. Yes we can automate these steps because we are following YML based. So we can write those steps in YML and the system will perform those for us. This is the diagram how trans stats work. It works by syncing with upstream, syncing with translation platform and release schedule and build system. Currently trans stats can sync with trans effect, zanat and dandelion. These three are translation platform. GitHub and Pague are source code repositories, release schedule and build system. These two are required for notifications, for generating notifications, scheduling jobs. Snapshots are required to figure out like what was in for Fedora 28 and now what is for Fedora 29 and 29 and so on. What should be the work estimation, translation differences where we have plus if we do scratch builds with latest translations and post those results to developers that would be very much helpful to them. So these are all in progress task for trans stats. Now let's make trans stats better together like what is the technical stack of trans stats. In trans stats we have server CLI. One project is of trans stats automation and we have some unstable scripts for deploying trans stats to different instances. In server this is simple Django application which uses request to talk with different services. For forms we have Django crispy forms. Postgres is the backend database for trans stats. For CLI we are using click framework and we have few commands as per the APIs being exposed. Translation, trans stats automation. We have selenium projects to test translations and to test trans stats and all those features and we have playbooks to deploy trans stats at different places. You can go and see project at transstats.org docs are at docs.transstats.org and if you got some interest then you can go and see source code which is at github, github.com slash trans stats. It is very quick to get development instance of trans stats. Just clone it and apply or run vagrant up. It will do all the stuff for you and you will get it running on your laptop. So, if you would like to see some more details or practical demo you can just go to transstats.xyz. This is the demo instance of trans stats where actually you can see whatever I have demonstrated. So, here you have everything for Federa 28. We are currently tracking 40 packages and 29 jobs has been run. So, here you can go and have a look like what exactly trans stats is and how things are getting generated. What I have not covered is graph rule. For graph rule is like you are generating one rule which include X number of packages which include X number of languages and one release branch. So, if you will go and see that particular graph it will look like something like this. This is the position of RH installer component similar to Anaconda which and these are the participating packages. So, this is the transmission structure at the start component. So, getting back to my questions slide. So, I am open for questions. So, actually anyone from like developers can have look on YML files and how what is the position of translations and what is the health of translations in the final product. So, it is helpful for developers. It is helpful for quality engineers, IT and quality engineers to quick their processes using those jobs and everything. They can from the early like when we hit before hitting their deadline or before hitting their start line itself. They can know these much of languages in these much of packages need attention. So, they will go and solve those bugs first like which particular bugs are critical to them. So, quality engineers and for localization managers basically can go and see the volume of data. Like if you will go and go to dashboard and when you will select Federer 28 release. In Federer 28 release if you will see at transaction.xyz then it will show for all the 40 packages like what has not been translated, what is remaining. And if you will go for detailed view then it will show like in which languages the performance is not so good. So, which are the languages for which all packages need attention. So, Eltenian managers as well. So, it is beneficial for developers, IT and quality engineers and localization managers or maybe localization team. So, that they can look at the set of packages they are working on. Does that answer your question? I was thinking because sometimes the customers time to customers like for translation line basically are not translated. So, it is like Korean, Japanese, Chinese. Exactly. Even like some line is like that we have made here. Right. Like some is across the line. We don't see them. So. Exactly. So, actually what is the benefit of using Transstats is it can talk to different translation platforms where translation is happening. So, it can give you very overall picture of any of the releases. If you are targeting any of your release and you have several packages, several languages underneath several translation platforms. Then you can actually go and have everything at once. This is the very. Is the next speaker here? Yes. Okay. Thank you. Thank you. Thank you.