 Hello, hello, yeah, it's okay. It's typical Sunday morning. I saw lots of people going to roaming out Sunday in the morning I came here. How it was in the last year during the Sunday? Audience? I think it's always on this. In the client session? It's why people can watch it on YouTube. But I only saw it for one day or five months. Okay, ladies and gentlemen, please welcome our next speakers, Previn Satputte and Mike Fabian. Yeah, thank you. Thanks, thank you for introduction. So good morning all. We have an exciting presentation today. First of all, we'll cover basics terminology of globalization in first 15 minutes, and then we'll spend 20 minutes on the development activities. So it's a plan. So if here you see the internationalization, it is represented by I18N. If it's localization, it's L10N. The language testing group is represented by FLTG. First, we'll see why globalization for Fedora. We started globalization group in Fedora around one year back now. And I got a couple of questions that why globalization? It's so widely used terms. It's like there is a global economic globalization, market globalization, business globalization. So why Fedora globalization as well? There are a number of definitions for globalization, and those all are different. But when we say globalization in the Fedora context, it's a strategic collaboration between four different groups, that is localization, internationalization, Sanatan, Fedora. It helped us to achieve a number of things with globalization. First of all, there were earlier few active members in each group. Now with the collaboration, it's huge group now. It's almost 20 plus people are active meeting regularly. Other benefits of the Fedora globalization is that all of these groups require collaboration with each other. It's like we cannot start a localization if there is no internationalization. If strings of the localization are not available on Zanata, they can't be translated. Testing groups require language expertise that comes from the localization team members. In this way, all groups are related, and with this collaboration, we now are more comfortable, and we are thinking more strategically how we can help Fedora to become a truly globalized distribution. In that way, the globalization is going very well. There are still few people feel that why term globalization? It's not terms that we found it, but I have not found an alternative yet. I'm still open. If there is anything we can call, I'm fine with that. Then again, these questions I get every time that, why do we require languages in the computers? Isn't English sufficient? If you see this chart, it's very small, unfortunately. But if you see, the green part is English and the other different language colors. There are the statistics. These statistics are only for the first language in each country. English is only a first language in some part of the world. And if by number of people, the first language, people of English language, if you see, it's English stands out the third language. I'm saying here from the first language speaker. If we count English as a second language for the people, its number is huge because the English is, we say, the world language, business language. It has more speakers. Now, for this purpose, I have one complete whole presentation that why globalization is required. I have added this link in the reference section. If you feel there is doubts, please go through that. It's a very interesting presentation. Then I am coming back to the concepts of different parts of globalization. First comes of internationalization. Internationalization comes at two ways. Its core, base, or is internationalization. That starts with the encoding standard. So it starts from the Unicode. The SJS here is SIFJS. It's used in Japan. There are a number of ISO encodings as well. Then I would like to add one point here. Unicode has become a de facto standard in the world, but I recently visited Myanmar, and unfortunately they are still using the local encoding, that is Zoggy. It was really surprising, but still we require some push for the encoding standards as well. Then it comes the IMS. We have a number of IMS. Then we supposed to have fonts and rendering. It becomes very tricky when these are the complex fonts and rendering. We have a whole rendering stack, and we need to add support for complex script into that. We have Hubbus now. Hubbus has become a default open type layout shaper, and it has resolved lots of issues over the time now. Then commits the local and sorting. This becomes the core part of the IITN, and each OS should support these things. Without this, we can't go further. Then in internationalization, the next parts come there, and that is the application internationalization. Here, actually since most of the developers here in the conference, we use the best practices of development of applications, like we supposed to use the get text for get... We should keep strings and programming code differently, so we can easily translate the strings, so there get text and pure files come into picture. We have found that sometimes strings are not available for translation, and that time we need to fix the application itself. Here it comes application IITN. If you see all these trending topics like the atomic, open-shift, open-stack, each require the IITN, and we actually working on that to make it happen. We have recently submitted patch for the open-shift UI to get internationalized. Here it comes the localization. Localization, though you feel it's just translation from English to remote language, it can be any language, but it is a huge domain. With so many standards there, there are like... One can... If I ask to translate some word or line to different people of the same languages, they might translate it in different way. It must be same, actually, if you want to be, and it requires the need of lots of standardization. Now, after this talk, Noriko is going to talk on the localization. I will keep it to her. She is going to do a depth dive into localization. In Fedora, we have around 80 plus teams, but only few of them are active, so we need some statistics for that. Then, again, the Zanata. It's an online web platform for translating the strings. Once your application is internationalized, you can just push your strings to online platform, and then one can translate it from, say, English to any language. We migrated to Zanata around one and a half year back. It was Transifx. Transifx became closed source, and we started finding some new alternative, and Zanata emerged as a platform of choice. Recently, around six months back, I think, the open stack also now using the Zanata, and a few more things are coming. For Fedora, it is advantageous to have most of the things in Zanata, because already lots of translators are there, and they are using Zanata. They are used to it. One more thing is that Zanata upstream developers are closely working with the Fedora now. They are participating in the meetings, and we have good collaboration with them. Then, there is a Fedora language testing group. Now, if you want to test language, we want people who know those languages. It's very important. Without those language people, we can't do the testing. We can simply do CES. This looks okay or not, but unless and until we don't know that language, we can't say is it accurate or not. Here comes the Fedora language testing group. It specializes in language testing. They collaborate closely with the localization. We organize language testing stuff regularly with the Fedora language testing group. For each Fedora release, we have two test-day events. One is the localization, one is internationalization. With this, I completed the basic terminologies of globalization. I have a small video which is just three minutes. It shows how it can be problematic to end user if your software is not globalized. Hopefully, it will work fine. You have a mic, right? Can you keep the mic? Just as I show, it becomes very problematic if our software is not globalized. As an English-language person, we know English-language. We find it very easy most of the time, but it's very irritating. If you have visited countries like Japan, you will find it that they are 100% localized country. We need localization for that. From here, I will move into the development activities. We have a mic with us. He is leading right now the G-Lipsis of packaging. Can you get a mic? G-Lipsi has big packages of locale for many languages, and that is 106 megabytes big. Until now, it is only in one package, G-Lipsi Commons, so you have to install them all. It was very inconvenient, especially if you want to install some minimal system for some Docker image or some virtual machine, where you don't need all these languages. For Fedora 23, we made a workaround that you can give a command line option while installing G-Lipsi Commons to install only English or something like that, but that is not a very good solution because you have to give the command line option again when updating, and if you don't do that, you get all the languages back. For Fedora 24, we are going to make one sub-package per language so that we have something like G-Lipsi, Langpacks, EN for English, and for all the other languages, and this took a long time because there was a long discussion how to do it right. Currently, we are using a database file, locale minus archive, which has all these languages, and so you can't easily split that because that is one file, so all the sub-packages would have file conflicts, and we would need to merge more data into that file in the post-install and delete it from that file in the pre-un and that becomes very ugly and error-prone, so finally we decided to do the sensible thing and stop using the locale archive file and use the second approach to use a separate directory for the locale data for each language, so then we don't have file conflicts anymore for the sub-packages and the post-install is not needed anymore. There's a slight disadvantage with that approach, is that a few more file excesses are needed. With the big database file, the advantage was that G-Lipsi opens only that one database and that's it with the sub-tier approach. It has to search for the correct sub-tier, has to use some fallbacks, you could spell the encoding of the language in the lower case or lower case, so it has to check for these possibilities and then look into that folder and each folder contains 13 files for LC-type, LC-time, LC-messages and so on, and so you have something around 20 stats when a program starts and uses set locale, but we did a lot of benchmarking and in normal use cases this doesn't matter. For example, if you boot a system and check how long it takes until the system boots with the both approaches with the database and the sub-directory approach, we couldn't find any significant difference, so we decided to use this. We have already test packages here at Kopa to try this out. Another feature of these test packages is that they use the new supplements system, Paracinamada and the DNF developers are developing before when you wanted to install support for some language with yum, you could do something like yum, lang install German and then install German stuff and yum itself had the data somewhere which languages need to be installed and with the new system for Fedora24, there is a meta package langpacks.de which contains no files by itself, but every other packages which have something interesting for German have an RPM supplements text to supplement that langpacks.de, so if you install langpacks.de, then the dependency resolver pulls in all the other packages supplementing it and if you delete it again, then they all get deleted again. So that's basically it. Anybody who wants to try whether it works can try to use this Kopa folder. Thank you, Mike. It's a very basic thing, like we are using G-Lipsy from the start when we started using Linux and if you know on your machine there are 327-plus locals are there, but how many locals of those you are using actually? It's almost two or three something. With implementation of sub-packaging in your machine, there would be only locals which you require and it's very crucial change because it can affect so many things right now. We are taking very cautious approach for this. We were planning for this F-23, Fedora-23, but we just hold it on. Now we have a bit more better, good picture as Mike said. So as soon as we get some green signal from the upstream, we can actually do this. Then next comes for its Fognome. These are the international tax set. This is a standard from W3C and it allows you to translate XML using the pure format. When we say pure format, the whole documents of XML, it gets split into the words or some lines and it's easy to track changes if it is split into words. If new words get added, it changed. That's where the ITS is very useful. There is already tool, it's tool that is developed by the Sean. He is from GNOME and that tool is useful for translating the documentation of GNOME. Then it's useful for the documentation side, but if you want to translate something like the GLAD XML, G-setting, app data, for those kind of thing, he's working on adding its support in the get text. Then DNF langpacks. If you know any old systems, you might be remembering, you select the system config language, you select the language, then it starts setting default language for your system. If you don't have those packages in your machine, system config language also install those packages. It was using the yum group install command. Then we migrated from the yum to DNF and we started working on the DNF langpacks. For the DNF langpacks are already used, but if I have installed my system in the Japanese language and I have the LibreOffice installed, then since my local is a Japanese and if I'm installing the LibreOffice, it should automatically pull the translation for the Japanese, but that is not happening right now. There is some issue and that change proposal we have submitted for the Fedora 24. So what will be advantage of this? It's like even if you are installing the Fedora or any system which uses the DNF langpacks, if you select the language, it will automatically pull the translations and require file for that languages on the fly. Now, this change is also useful for the G-Lipsy sub-packaging, as Mike said earlier, that since we are planning to split G-Lipsy into different language packages, sub-packages, so if you select the language, then only your local will get installed. It's like that. So it's all related thing. This is actually presently lead by the Parag Nemade and he is working with the DNF developers as well. Then comes the auto-testing, iotn and ltn. This is very time-consuming, the testing each time in each release and unfortunately, as I said earlier, since it's in all the languages, maybe if you say the rendering, how can we test the rendering automatically? We need some manual intervention, but we had a fad in November last year and we thought at least we will try for automation for the things which we can and we came up with some list that list is like the IMS, the input methods. We can test the input methods, whether those are available or having all the Unicode code points required for that languages. Then we can also test if the translation is missing in the UI. I actually don't know in this how they are planning to do it. Then font coverage. Font coverage is a bit easy to search. We have lots of tools to pass our font. The font config is already doing great job in this. This is a plan to lead by the Akira Tiger. We are actually working on this for Fedora24. We are having continuous discussion on these things. Then it comes the string breakage monitoring. This again issue came up when we started collaborating with the localization. The problem was if you see the Fedora schedule, there are strings like string phrase, translation freeze. When I say string freeze, at that time all the developers should freeze their strings. They should not update string after that. Localizers based on those strings start translating. But after the localization is done, if some developer changes software, the UI elements, then what happens? It result into missing translation in the UI. One of the major package where we were facing this problem was Anaconda. Anaconda is always its most critical package during the release cycle, and it frequently keeps on changing. As soon as they change the string, it affects the translation quality. We thought how we were thinking that maybe we should change the deadlines of the translation freeze string freeze. Maybe we should move it to the more after beta, but then it creates more risk. If anything wrong happens, it can happen the release schedule. Then we came up for these ideas. This idea says that we can track changes to certain packages. Now, how can we do that? There are two approaches we were thinking. One is that we can simply track the package built in the Koji. If anyone is building new package, new version, maybe we can say is it breaking any strings or not. There is a second approach where we can check. Each package has a PO branch, and there they push those PO branch in the Xanata. We can watch or compare the Xanata PO branch with the package upstream branch. That can also help. This is again, we had a number of discussion, and it's actually led by the Gens and Akira Tagore. We have a ticket for this, and if anyone of you have any comment, I feel free to crowd your comments. Then comes the badges for contributors. I think this is the hot topic we are discussing here from last couple of days. To motivate, badges are doing very well in the Fedora. The contribution has been increased. Even if you see my personal experiences that earlier, I was only doing the packaging in the Fedora, but with the invention of badges, gradually I started contributing to Wikimore. The testing is also the point where people were not contributing, but with the testing badges, now we are getting more contribution in the testing. Same way, we want badges to the translators. But how can we do that? It's like when I do any translation, it gets committed into the Xanata, and that message is still not getting to the Fedbus. Fedora messages maybe, FedMessage. I just had a discussion with Ralf yesterday, and he says the code is already ready. We just need to do the integration. Even if you see the, Matthew in the morning presentation, he's shown the graphs of how many people are active in the Koji side, Vicky side, but there was, Elton was missing there. And I think if we implement this thing, I'm definitely sure that it will increase around 40 to 50 people, because there are lots of huge community of translations doing good work. I'm sure we can do this for Fedora 24. So Alex, it's from the Xanata team. He's actually working with us. And here is my last slide. Most of the references are here. If you have any questions, please feel free to ask. I have just given the overview of most of the things, because it's not possible to actually do the demonstration or do some in the show short time. And most of the scripts are in Python, and so just we need to push those in Xanata. So the question is that when we break, normally developers need to change the code in the emergency. Maybe they have some little time. So how we can manage that? Though that mostly will base on the PO, the files, how many strings are coming there. We can track that actually. And what happens? It's fine. Developer needs, in real life environment, our release is tomorrow, and I need to do some changes immediately right now. That is perfectly fine. But if we are doing that change, it must get notified to the localization community. That is very important. And I think that is what we are planning here. It must get communicated, right? So if any changes are required, they can start doing that. Yeah. Any more questions? So we are almost, we have eight minutes, right? Exactly, exactly, yeah. Exactly, right. So question is that on Xanata, what are the major translations we are doing? So on Xanata, mostly the Anaconda is one. Anaconda is one. And mostly the Fedora packages, like say the system config language, those are Fedora-specific packages. Those we are doing there, from the GNOME perspective, though GNOME has its upstream, those packages are also in the Fedora as a downstream. And that is what even I was talking with the Matthias yesterday, that can we, is there any chance or scope to have GNOME into the Fedora? Because it's sometime become the double work for translators to translate it in Xanata and maybe in the upstream as well. I think Noriko is doing and facing this problem from a long time. But each community has different dynamics. They have different priorities, different references as well. So maybe we need to leave with this. And it's good actually, it's good that LibreOffice has their own, they use the Putol I guess, right? So one way, but there should be some collaboration between all these things. That is my plan to do something because we have a good contact with the Mozilla and they are doing good work in the language technologies. So we are planning to collaborate with them and have some sprints, use the resources effectively here and there. Any questions more? Then I think we'll close. Thank you all for attending. Yeah, thank you. So I have three staff. So I got two questions, one comment. So I will give one to Mike for just helping me. Yeah, he has not listed and the two for you guys. You already have one, okay. He also have one. So thank you. Thank you. Yeah, so I will take this one back. Yeah, thanks a lot. Yeah, sure, I will take this one. Yeah, all right. You want my slides? Do you have a pen drive? Please repeat the questions to the mic. Yeah. Yeah, even I forgot it. Our next session will start in 12 minutes. So if you need to go grab some water or something, you still have some time.