 So, hi almost end of day. So, most of you must be tired. So, let us have an interactive discussion. So, I am thinking for this topic from almost last 5-6 months and finally I got a chance to talk about this topic. Let us start first with the what is globalization. Now how many here knows globalization almost majority. So, we started a globalization group as a umbrella group over the 4 existing group around 1 and half year back. So, it includes the IITNN which deals with the technology stuff like the fonts encoding. Then there is a localization which is even bigger group than IITNN. It is dealing with lots of languages and many active members are there. Then there is a third group that is Zanata. Zanata is not an official group in Fedora still, but yeah it is very closely tied. And then we have a FLTG that is seek for language related testing. So, we do organize some events specifically during the Fedora development life cycle. So, that is the globalization. Then wherever I go there might be some people in the group that is thinking why isn't English sufficient why do we need other languages right. So, I have some slides ready for those questions. If you see this world map there English comes as a third. Now, this is the map for the people countries with first speaking languages. So, if you see the first here is Arabic English is third. So, there is lots of diversity in the world from the language perspective and as a developer we must respect each user and his diversity. So, we must provide his language support. It is not like that we should force other languages to him. Now again if you see this chart languages with at least 50 million first language speaker. Now here again you see the English is third here, but one might say why this is so less it is the first language speaker. So, I can speak couple of languages Marathi is my mother term and then English is my second language. So, if you say English from the second language speaker that number is huge, but there is importance to preserve the first language of person. I have a whole talk about why we should support the languages. I can give you free hints here rather than that is a full-fledged talk of one hour. The first thing is that whenever you hear any word in your first language and your second language you are more emotional with your first language. If I give you two newspapers one is your first language another is in the second language. You will definitely read the newspaper in first language very fastly and you will understand it more than the brand names. If brand names are in their local language you feel more attached to the brand name. Then there is one talk it was on Ted from Susan and it was saying if you lose your language you will lose your culture. So, it's very emotional talk. I will recommend if you want some more points you should definitely go through that talk. Giving an example for that the Halloween day it's not Indian culture it's never was a part of Indian culture but now many people in India also celebrate the Halloween day. So, with the language these cultures are coming and as we are losing our language we gradually lose our culture. So, it's very important to preserve our languages. Then why federal atomic? Why I selected this talk about the federal atomic? If you see Fedora is rapid change distribution I will say whatever we are right now six month it might become obsolete. Now Fedora 21 was the historical release in the Fedora lifecycle. Before Fedora 20 we were only releasing the one Fedora product. It was serving to the desktop users, server users, cloud users. After Fedora 21 we have now workstation, we have now server, we have now cloud. But from globalization perspective we are still I think concentrating only on the workstation part. So, we are not doing that much efforts on the server or the cloud and the atomic is if you hear any talk from the last six to 12 months from the Fedora atomic is important atomic is important. Even the FPL last time said there is a huge competition on winning the atomic users and we atomic is high priority for us but we are not concentrating that much on the atomic. So, I thought I will better do the analysis of the Fedora atomic and we will see what is available and what we supposed to do for the Fedora atomic and then unfortunately I did not got much time. So, my analysis starts here. I can show the live demo as well of this it is installed in my machine but we will go the some screenshot. So, if you see this first slide while installation I downloaded the Fedora 24 atomic image and my language is available. So, I feel happy ok I have my languages. So, feeling bit comfortable then I said next I got message again in my local language and if you see the those two buttons those are still not translated. So, it is that issue and everything went well smooth I did reboot and if you see in terminal I found this error the your local is not there. Now, why is this? So, if you know in Fedora 24 we have done subpackaging of G-Lipsy local. So, ideally if I select Hindi language G-Lipsy-Langpack-HI package should get installed, but it was not installed. So, I did more quick analysis to see which packages are installed and there is G-Lipsy-Langpack-ALL is installed. G-Lipsy-Langpack-ALL package yeah. So, this package we supposed to install if you want all the system locals. This package was installed, but there was only EN local was available. So, I think that is the first issue I found and I will definitely report issue for that. So, in atomic image by default only this package should be installed G-Lipsy-Langpack-EN. I think they have still not implemented the changes which we did for G-Lipsy-Langpack. That was the first thing yeah. Then I thought let's see the fonts. So, fonts are important for our languages. There are no fonts in atomic. Then okay I say okay not fonts. So, let's see if there are rendering libraries are there. So, half bus is a open type layout shaper. There is no half bus package. There is no pango. Then I thought let's maybe we can install our language packages. There is no language. There is no pure and we can't install anything there. There is no DNF or yeah. Then I thought did I selected the wrong topic or what? Then I started my analysis from start. Though I know what is atomic host. So, if you see the atomic host it is optimized to run Docker containers and Kubernetes all the stuff. It is optimized host. So, it has strict requirement to be a small footprint. That is the main goal and that is why the cloud seek people have removed almost all unwanted things. And last time when I talked with the people they said rather we would like the globalization people to do the audit and let us know what things are required from your side. Because right now blindly we are removing everything. We are removing PO files. We are removing every package that is not required. Then whatever is there it's actually right because there is a strict requirement to be a optimized OS. Then how to proceed then. So, it is specific image then what to do. Is it like that atomic we don't need globalization. We definitely need because in words there are some part where the globalization is most like if you say Japan. Even with we are translating man pages if you know. So, it is important. Then I started thinking what should be the alternatives to do the globalization of atomic. And any question till this it. Then there is already some method of hacking atomic. So, with rule you cannot install any application or any package on the atomic. But there is some methods like the OS tree system unlocking. And there is a package layering in RPM OS tree. With this methods you can add certain packages to the atomic host images. And I don't want to go into depth into this topic. There is already link for that. That is the one approach because we need to go to all the approaches. Those are available. So, either you can hack the atomic. Then if you remember we are planning for customized language series for work session. When we meet in November fads. So, we were started thinking about the customized language series. So, this series is like I during some conferences I met with few people. And they requested me can I get a series which is specific customized for my languages. So, from boot it will show everything in my languages. Like I will get UI in my languages. I will get spell checker. My IMEs will be default installed. So, I don't need to install anything on the top of that. And with this we started a project. So, Parag Nemade is actually working on this. It's almost 3-4 months or 5-6 months now. He is updating the kickstart file. And also there is a landfax. So, he is saying that if we add landfax in the kickstart automatically we can pull the required components. So, with this approach I think this approach is more suitable for atomic host. Since atomic host is optimized it does not make sense to have an image which supports all the languages with the all the image all the PO files. Then again it will become huge. So, rather than supporting all the languages atomic image should be for individual language. Like it can have German for Japanese for Chinese. So, single atomic image for each language. And even we can add some more constraint on that. That only few packages might get the translations. Even the fonts right now for each language we have many fonts. So, rather than installing all the 10-15 fonts we can only select one font which will do our need. So, in this way I think the language CD project is a good candidate for atomic project. That is the second approach. I think we should definitely do some more depth in analysis for this. Then there is a landfax. Again landfax when I will select the language in the Anaconda it will automatically install the required packages. But even with the landfax it might be risky because it can pull more packages. So, we need to add some constraint to the landfax because landfax what it does all the packages with hyphen language code hyphen say mr hyphen jp. It brings those packages. And for atomic host due to constraint we cannot blindly pull all the packages. It will again make it bulky. It must be the packages which require. Then so any question on these three or any suggestions? So, I found three approaches might be good. And I think so since Parag is already working on this thing. So, I will request him that he can explore on this side. The language CD approach. This looks more suitable for me at least for me. If you have any other comments then there is a new aspect. So, from each team perspective where should we contribute in the atomic project development? Now since atomic is a custom streamline for running the dockers images there are different packages which we should concentrate. So, if you see the cockpit it has some transitions already. So, it is UI for administration. It already has some translations. Then there is a flannel. I think this there is not even actually I mean just doubtful whether it is internationalized. So, there is a git for it. We need to check it the flannel. So, flannel is a network for network management. Then there is a kubernetes. So, there is already upstream link for Google. Again there is a docker packages. Again each one has its own upstream. So, we need to explore these things. And of course we should more discuss this with the atomic work group because they can provide more inputs about this. There are many packages actually in atomic. So, and unfortunately I am not able to go through all this. But these are the most important packages. There are cockpit, flannel, kubernetes, and dockers. So, those packages are included when you download the atomic? Yes. Yeah. Those are by default included. So, basically if you are an user of project atomic and when you download it, it is not only to make a docker installation or cloud installation. It is with all those tools. Yeah. So, yeah. Because atomic host main objective is to run the docker images. And these are the tools which are most there. Okay. Those are the tools that are used to manage all the devices installed. No, it will by default those will be installed. Then I think yeah. Then there is one more thing which I planned for talk. So, we have to discuss these things. For atomic, there is atomic project is presently handled by Fedora cloud working group. And I found bit in frequent meetings of that group. Kushal is right now running those meetings. And it sometimes happens monthly. So, I wanted to ask with him actually what is the exact schedule for those meetings. So, if we are planning to do some more work on this. From my last few discussions with them, I found that they are also interested to have globalization of the atomic host. Because they need input from us. So, I talk with the Matthew. I talk with the Kushal as well. So, we rather than putting all our efforts into only the workstation, we should look for other things as well. How much time do we have? Lots of. So, I went fast. So, any questions? Yeah. In the perspective of localization, I would like to suggest to have some kind of filtering because of every branch. So, the main branch, cloud branch, every other groups have auto-run setups. And the people who have begun to translate, they don't know which is where included in the next release. So, when you setup in the translation UI that you are translating for the cloud and you will have the setup of the packages, it's a much easier view to select them and just go through it. So, and next time when the next release comes, I will get another release and you guys in the cloud group or the other group are managing these going to be included and it's providing the perfect result. So, that would be awesome. Again, do we have any prioritization in Zanata? So, if I give any weight for particular package, will it appear in top list or is it, I think it's presently sorted by alphabets, right? At the moment, it's alphabetically sorted, but you can sort it by creation date as well, but I don't think that's... Creation of? Creation date. Rather than date, if can I give the weightage for particular... Zanata. Not... How about... Yeah, you can create a group. Atomic group. Atomic group, yeah. Atomic group or just for the main group because basically when we are beginning to localize set of tools, I cannot say which is for the main branch, which is important, which has priority and which is belonging to where... If I do such package or such tool that it's implemented where we work, of course, it will appear in every group, but it will be on a huge scale to select it as... This has been requested by the cloud group that is localizing. Okay. Something like that. After seeing this schedule and how many days I have back to before it's released, that's helped a lot really. Yeah, that's a good suggestion because if you see federalized segmented now, but unfortunately, the localization packages are not segmented across the group. I think that is why we are still workstation. Yeah, that's always been delaying because people are just jumping here and back. There's no which one is where. Okay, I have one hour or I don't know how many time to finish one translation, but another is okay, you need another project, but we don't have any communication that's actually needed for now or just need a postpone or something or another. This is a combination. Yeah, but when we have the groups, at least we need the scratch. And for atomic, it's like we need to start from scratch because if you see the present state, it has nothing. Maybe I will open up the ticket with the working group that what the things about it because there are different approaches. I think the image approach is perfect. As far as I think with my experience, the image approach is because atomic for if I was talking with the Patrick, he is running the atomic workstation. Even the workstation is now moving to atomic way. So in long term, we need to. That's a good thing because when you are minimalizing the footprint, that is common with all the separate branches. That means you can figure separate pattern, I would say, bricks that you build upon. And as it's expanding, you can do it for different parts. So that's a good way. And if you have the right localization tools from the first one when you are selecting the language, then it can trigger the whole set. Actually, it would be also a good scanning that goes through all the packages that's already there. Or if you are selecting another branch, then it creates another list and adding the localizations. Even I did not understood since in the present image they are installing only English language. Then by Anaconda, we are getting whole list of languages. We might know that in the Anaconda, the atomic Anaconda installation, they are installing only one language, that in English. But still Anaconda shows me all the languages. Ideally, if it's only installing English, why they are showing me other languages? It's not live images, it's not live images. It's atomic images. So in Anaconda, it's not customized for its own use? Yeah, exactly, yeah. Yeah, so if that thing can happen, then in the installation itself, I will understand that I am doing something wrong thing. It's not for my language. Any more questions? In case being international, when we are ready to localization, I want to come back to the mentor of the conflict, but he is kind of irresponsible so that we need to talk to him. But the other package is since not really internationalization yet. So probably before localizing those packages, we sort of need internationalization. Yeah, of course, exactly. Any more questions? Yeah. What is the release cycle of project data? They do couple of weeks image. Each couple of weeks, they build new image. Yeah, they do two weeks. Yeah. And every time they produce a new image, they upgrade all the packages. Do they? They make the rebuilds. I mean, does the translation of the server are pulled every two weeks? Or is it pulled like a popular workstation, which tends to maintain a decision to take the server? I think, I'm not clear on that, but I think it's like they pull the latest RPM builds from Fedora. Like the same way we build the nightly images. From those RPM, they build the image. It happens that way. So if that RPM has the translations, it will get into the atomic image. Yeah. But one thing is, this is the server. The server is copied. It's translated in no language. I translate it. I write 70% of the translation. And I pass the container to make a new version. Then it ends. And it's an upstream new version. So I ask upstream. They make a new main version if they want. And then to release the maintainer, we go upstream and download it, package it, test it, and then deploy it. Then now it will write. And she does Japanese. And as she knows the subject better than me, she translated 100%. Then she said to the maintainer, hey, can you please update my computer? I'm sorry. It is an upstream release. So this is making the things very different. And it's not taking advantage of the short release like Fedora did. How can we make that process faster? And so we know that when we are translating something, whatever for which product it is, we know that it will reach the end user fast without needing to make five budget tickets and go again on the September ticket to say, hello, why did you forget me? I don't know how to say that. Yeah, so it's like the first things. It's a problem I actually have with app data that I can translate and try to translate app data. So it takes weeks and if you have one translation, from the moment you see the translation and when you are following it, from very close, it takes weeks to reach the end users. So how can we do something for project technique that is a very short release cycle to make it faster for the end users? Because here I understand that project technique don't have every packages of Fedora. It's something very limited because it's targeted for creating and processing stuff. Yeah, right. I think we need to understand the criteria they are following. Like is it actually upstream release that is happening after each week, a couple of weeks, or is it... We need to understand that thing first. And in Fedora, we follow upstream first. That is our first tick mark. So that is why we do not apply the local pages. So we make sure that first thing goes to the upstream. If we do not do that... Don't we really need a new release each time back at a long-range is 100%? I think... Just a few tests just to see if there is anything crash. After that, there is nothing having a test. So if you remember in November we were talking about the new architecture for globalization. Just if you remember. And we said that why to keep translation always with the package? Like if we keep the translation into a different package, which we can build frequently. So I know no need for me to build a package each time if I have new translations. Because translation is not that much affecting the functionality of the package. So to avoid these kind of things, we definitely need the whole... What we are calling that? The project? Like I said, there is kind of... I have continuous integration of translations, but there are some mechanisms that are very much... Because this is a used case that you can use for a short release and trying to have a very short release of translation, like in RL, it can be a perfect use case. Because generally we should have it for any package because asking maintenance to work for every translation is... How can we just... There are, I think, two-three approaches we discussed for the... What was the name of that? Next generation globalization architecture or what was that? I am just not getting that word. Was it globalization as a service? No. I think... We need to go to the fad nodes. But yeah, we should go into that line to resolve the dependencies on the package. If every package maintenance gets aggregate, then rather than asking them to rebuild the package each time, maybe we can have a separate package, a translation package, which will simply sync with all upstream PO files whenever there is a new update, the pool... Once the upstream developer committed those PO files, we can simply pool those and build our own package here. It can resolve all the problems which we are facing. Lots of communication and... We can try one package. See if it works. Yeah. The use case interesting is... It's definitely interesting. We can tell the translator, hey, we want to try something new, a very short release. Translation can try together. Maybe you can take advantage of the other side. The other sync, yeah. Yeah. Yeah. It's not... We'll discuss this idea in the workshop we have the afternoon. If we can develop some prototype and if we can get more bind from people. Yeah. Yeah, cockpit as we can do it. So why not? Yeah, why not? So what we'll do, we'll draft a proposal and which work group should it be? Pesco maybe, we should ask Pesco. It's a bit different the way it's happening right now, but in long term it will be definitely helpful. Yeah. Good idea. Any more question? No comment. Yeah. I'm just wondering if I get atomic workstation but also interesting when you're inside atomic host. That is a whole different kind of things which we should explore. So... Right. So I think we can discuss this thing in tomorrow's definitely tomorrow's workshop. Yeah. Tomorrow's definitely tomorrow's workshop. How to solve or maybe we'll make some plan. Thursday. Yeah, Thursday. Yeah, Thursday. Okay then, thanks to all for patiently attending the talk. Thank you for that. Yeah, thank you.