 To have here Bubul and JFS, who will tell us a bit about the results of that talk sessions, about the current state of internationalization and language things. Sorry, the other beam is not working, that one there. Hola a todos. Nos alegra veros aquí. Bienvenidos a la charla de internacionalización. My chance for you, the remaining of this talk would be in English. Thank you. Part could be in Spanish, yes. So the main point of the talk is doing a kind of state of the heart of internationalization, quite arrogant statement, state of the art. Well, the main point is to say here what you are with internationalization in the biennium. And here is what we want to go. We will talk about this at the end. We are very productive both sessions currently during that conference. And I think the summary I'll give you at the end of this talk will be interesting to give good ideas for the future. Basically, we will have a new kind of interactive part about internationalization again, again a talk about internationalization. We will talk about the project in the biennium. We will talk about the infrastructure of internationalization, which will be the point also of the summary. We will talk about the tools we use for internationalization in the biennium. The relationship with other projects upstream or other free software projects. A conclusion as usual. And after a conclusion, which will not be exactly a conclusion, we will have a kind of summary of what has been done as work for internationalization infrastructure work. I'll explain you at the end. So internationalization again. So first my favorite statement, which I did last year in Helsinki, and I'm afraid it's still true. English still sucks. Okay, how many English native speakers are in the audience? Okay, and how many non-native English speakers are in the audience? Okay, we won guys, so English sucks. Yeah, but this is our de facto communication language, you know. It covers only 5 to 15% of the world population, so we have to cover all the remaining population if we want more users. Operating system not only in English, of course, is not a universal operating system, or you know that Debian is the universal operating system, of course. And even not all geeks speak English. This is a very common idée reçue, I would say, in French. You know, all geeks speak English, I don't care about English. My own system, I'm not a geek, but anyway, my own system speaks French. Okay, Javier speaks Spanish. He does. Okay, so let's go. I had to put this one somewhere. Let's go toward world domination, the path toward domination. You know about this one, you know, but I like it. So in Potato we add one language, covers this. This is about the installer, and now we have this. Yes, that's good. And as I like it, and hopefully you like it. Thank you. So we'll do it again. The last part of South America is Guyana, which official language and most spoken language is neither Dutch nor English. I don't know which one it is. So let's do it again for the sake of it. I'd like to, if you have questions, I'd like to keep them for the end, please. Yeah, just for the sake of it and slowly, in search. This is what we were last year, mostly. In the recent release of DI, we have 53 languages, and now we are, that's good. 63 languages are currently supported in DI, so we can say that from the beginning, Debian supports 63 languages, and as you see, we begin supporting more parts of Asia. Yes, that's good still. So why did this happen? This mostly happened because the wars between maintainers and translators are mostly over. Those of you who were in Debian several years ago remember of these fights and flame wars and all these nasty things. This is completely over, and internationalization with what kind of last wheel of the car is now becoming one of the most important parts of Debian, for me of course, but for many people in the project. And more importantly, I think it's closer to the art of nearly all development issues. Okay, so the translation wars are over, but there are still grimaces. Actually in the paper, there's a lot of information there, so you've got all that in the procedure, so we're not going to go in detail in every step, but we wanted to focus the translations on some things that are good for maintainers more than translators because we already have all our buffs and all our talks, Cabal talks. So one of the main points we want to make here in the talk is that translations are actually very good for code you write or packages you provide to users, because that actually makes that code more available to users because people are going to use that because it is available in their languages. So you have to treat translators, and that's actually one of the things that the project has changed and shifted to because you can now go into the new maintainer process as a translator, so you don't know anything about code. You just do translation and you can get into the project with those testing skills. So translators should be treated as valuable contributors. That's one of the reasons why projects that actually give CVS or SVN or whatever access to the translators actually get a much better translation than those that don't. So some helpful advice here is that actually translations helps improve the quality of the things you write because they actually review stuff. So for example, on the Spanish mailing list, the guy that was translating a manual I wrote with a screen data manual actually pointed in the mailing list in which I'm subscribed about about something that didn't match, didn't make sense on the document. And I actually said, yeah, it doesn't make any sense here because he was actually translating it and he was trying to see how to make the translation. And actually that made that part of the document improved because I noticed that the translation had issues with that. And that actually happens a lot. So translations are a way to do quality assurance of the documentation and the messages you rewrite. They actually find typos on those messages and they actually tell you this is not consistent with what other parts of the project is. So that's actually one of the reasons you might want to do translations. But in order to do them, you have to help translations get translations done. That means let them have time to do translations. So that's why you have to make swing freezes and say, okay, I'm not going to change anything from now on. I'm not going to do any release every day. Messages are not going to change. You can now translate all the things we have here. Because otherwise translations, if you don't do this, we'll get pissed and we'll abandon your project because you're making change every and every day. And actually, translators are aware of some sources you can use for translation. I mean some things that can be translated in Deviant, which is probably not out of it. And that's why maintainers that know what pieces of code that can be translated in their packages should go to Deviant, I, 18N, mainly these and say, okay, I want this translated. Could you please translate that for me? Or I want this updated. Could you please update it for me? So that actually is something that maintainers could do in order to improve translation process. So we're going to go now into some, okay, this one, yeah. Some projects, I'm going to talk about a few. Krishna is going to talk about another one. We're not going to go into details. You have the details in the paper. We're just going to give you an overview of those. Okay, so the website is probably one of the things that is best translated in Deviant. We have a number of teams working that. We're actually working both with content negotiation on the client on the server side. So all mirrors are used content negotiation. User doesn't have to go to the website and select the language they want the website to see in. That's supposed to be done on the client side. So if the user is working with a Spanish-speaking system installed, he's going to see the website in Spanish, which actually seems like a no-brainer, but you can go over and check out some other free software projects and see how many of them you have to go and say, I want that in Spanish. I want that in Russian. I want that in Japanese. And we manage that stuff with both translation headers. We'll probably talk about that later, and we get X. It's actually translated while there's teams working on 33 different languages, but only six of them have most of the content related, depending on if you take an account number of pages and number of bytes. We also have a lot of documentation translated. That means actually translators have access to this documentation project if they ask for it and they can work on that translation there, or they can use the maintainer of the document as a proxy. And there's actually some documentation there, and there's some documentation out of it. So like the Devian Installer Manual is outside that project, but the translation has access to that. And even though we're not all the way around, you'll see that we're starting to use tools that try to help translators to get their work done both on the first to see what is translated and what is not, and when the documentation people make changes to see what has changed and what's not. The man pages is kind of an issue because we write man pages for programs we write on Devian, and we also provide man pages for packages we provide outside Devian. That's kind of a mess because there's both man pages inside some packages, and there's also these man pages slash ES slash FR is slash DE, whatever, that provide man pages for some comments that are not on those packages. So it gets translated, but it's not that easy to handle. We don't currently do any work. I actually don't believe any project is doing that. The translation on the info documentation. Okay, so that's a gap we have. No, it's serious thoughts. So we can do these dance more time. Just to give an overall stats, you got to get an impression. The release notice now from the last release has been translated to 11 different languages. That has been increasing with each release. There's more than 20 teams working on the Devian documentation project, although not all of them are as active. On the manual, Devian installation manual is actually translated to 15 different languages. I think that's probably a few free software operating system projects can boast about that. Most have maybe three, four, at most five translations of their main documentation. They might have more coverage of the documentation, you know, like WRECAT, the documentation might cover, they both have translated the installation manual, the system guide, the what, what, what, because they pay professional translation to do that. But they don't have as many languages. And you take a look at what Mandrake or SUSE or OpenBSD or FreeBSD has translated. They don't have that much coverage. So it's actually something we can be very proud of, just like with Installer. So that is yours, yes. We want the most, more tango. Yeah, we will. Yeah. Package descriptions are part of packages, of course. You all know about this project, which was named DDTP. Debian Description Translation Project. This is a big demand by our users, because our users are actually installing packages. They are looking for software for doing this or that. So what should I install for doing this or that? And what is this software I've seen on my system and what is it doing on my system? So this is currently work in progress, we'll talk about at the end. Current status of translation are available at the address you see on the slide. I want to repeat, I suck at giving URLs in English, so I won't try it. The issues with, currently issues with the package description, sorry. The project has been abandoned for a while after the compromise of the Debian machines. And it has really recently been renewed slightly. It needed APT changes, which have been done recently and which are in all.sex version of APT. Other issues are the work done in Ubuntu currently. Ubuntu is working on Debian package description translation, sorry, mostly most often Debian package. We don't know much about it. So we don't know how it's happening and what's happening about it. Anyway, the next step will probably be some action collaboration with the FTP masters to have these package description translation put on the FTP servers along with the packages files and available to download by the new app. Another big important part of localization of packages are the DevCon screens translation, DevCon templates translation. So in that part, we have the Kilo application named PioDevConf written by Denis Barbier. So we have the magic tool for doing everything. We have the correct infrastructure. I will talk about it later. So this is one of the best translated parts in Debian currently. What we need now is probably more writing style consistency all over these Debian DevCon templates. You know about these things which are prompting you for passwords. Sometimes you have please enter a password or password column or password integration mark and so on and so on. This is not consistent. This is not really professional style, I would say. And we have to have some overall consistency. This is explained in the section 6.5 in the developers reference. And now your maintainers should a bit listen about with the tool in Tian actually because recently a lot of warnings have been added to the Tian. So you maintainers will recompile your package with DevCon templates. Look at the output of the in Tian, please. And you will be surprised. And you'll have the people to blame if you don't like it. But look at it. What's important here again is communication with translators. We will ask you all the time to your maintainer, package maintainer, to communicate with translation. Here we have we when I say we translators we even have the right tool. This PEO DevCon free port PEO tool is the right tool to communicate with translators. You want translation updates, you just launch this utility. Look at the man page, it's very well written. And no, it's not me who wrote it. So this is why it's well written actually. We need you maintainers to provide up-to-date port fights. This is very important for the localization infrastructure. This is very important. And we have recently discovered that many, many packages are provided without up-to-date port files, which means the DevCon templates do not correspond to what's provided to translators. So we believe we are okay. We are 100%. We are proud. And no, we are not complete. So one of the ways to provide this has been to suggest maintainers to use the DevCon for PEO in the clean target of package. This is a quite debatable issue because this modifies the content of the build tree of the packages. But this is the best suggestion we have currently. Now we covered mostly all of the various internationalization and localization projects in Debian. We'll see which infrastructure we currently have to deal with all this stuff, various stuff that you've seen, website, all these things. So we'll cover the PEO translation statistics, which means we will talk about PEO DevCon and programs translation. We'll cover the installer translation statistics with the most specific part. The use of the BTS because this is an interaction between the maintainers and the translator. This is the best method of communication. And we'll talk about what we call the translation robots. Well, the PEO DevCon and PEO statistics webpages, I should call it the earlier framework for localization. Why framework? Because it gives statistics so it can make you proud, you translator, because your language is the first ranked at the top. Not you actually, me, because this is French, which is ranked at the top. But the most important, it gives access to the translation material. So it's pretty crude, but it actually works quite well. One thing important, which was recently added a few months ago, is it uses popcorn statistics. So it ranks the most used packages first. So actually translators have their tasks prioritized. This will be an important point in the future infrastructure because there is so much work that we need to prioritize tasks. We want to translate the XORG templates before that MySQL stuff, which is prompting me for so much things I don't know about. There are a few weaknesses in that process. Mostly, this framework depends on a few developers' accounts. It runs on a Glock server, and it depends on Pierre Machard and Denis Barbier for the story. But this is some weakness because this is not completely integrated in our fresh structure. Well, anyway, it works in about three or four years, so it can continue working. It only reflects the status of uploaded packages. This is the biggest weakness. More and more developers work with source control management systems and make their changes and change the wording of their templates or the wording of their programs, and they upload the changes. They're changing after they upload, so we always desynchronize with the developers. Also, in the recent release, we were allowed as translators or maintainers to make translation updates during the freeze, so it would have been good to have status for testing just to know which packages would benefit from translation updates. We have nothing for doing that, and we are in need of such a tool. The installer translation statistics, it's kind of an attempt to override such of these limitations. It's possible because the installer is a project by itself. It's been coordinated quite strongly, I would say. So we have basically all what's needed to do some good framework. We have an all-in-one page. Most of the translators of the installer know about it. This all-in-one page, it's pretty huge. It's a very long page, not the best page ever, but it gives you information. We have more over the direct access to the material. It means we can grab the files from the installer SVM. As soon as France has the idea to change one minor string, first it gets me mad because I don't want him to do so, but then we discuss, we change it, and then the status pages are updated immediately, and the translators have access to it immediately, and this gives a quick reactivity, and translators are happy, actually, it gives them the opportunity to update strings one by one and not a big bunch of changes. So we have this... Well, I was on the strength path anyway. We have a lot of weaknesses also in that process, also. It depends on Zeppi. Who is Zeppi? What is Zeppi? Zeppi is Danish tamper who is running these status pages. So it depends on him to do some magic stuff, on his account, on Gluck, on the Debian server, for the statistics to properly work. And this is kind of a weakness. It's also very sensitive to upstream changes. Because in the installer, we don't only have the core installer, we also included a few key packages which are seen by the installer, such as apps, such as the package, such as ISO codes, and so on, and so on. So if the upstream, most often, the Debian maintainer changes, SCM, oh, okay, oh, SVN is completely out, so let's switch to Bizarre and OK. We have to change everything. Not very scalable. And it needs, actually, someone who coordinates all the stuff and still survey the old stuff and also survey the old translators and comes with a bat. And we have to release, please, update your translations. Anyway, I think we will always need such coordinators. There are also some strikes. I mentioned the reactivity. And another side effect, interesting side effect, in the recent years, it promoted what I call localization helper. Localization helper are people who are working with maintainers, but are mostly translators or translation specialists, and they help the maintainers to maintain their localization stuff. Oh, okay, Mr. Maintainer, oh, I want to make change to this string, but this doesn't affect translation. I don't want to make the translators mad. How should I do? And Mr. Localization helper, okay, I'll save you, my friend, and no one will hate you. Okay, this concept of localization helper is important. It makes a very small team of two people, and it works pretty well. Well, most of the time, I am the localization helper of many packages, but I hope that many others will show up soon. Another part of the framework is the BTS. The BTS in Davian is the way to communicate between people, between maintainers and translators. I said maintainers and translators have to talk together. So the first way to talk together is to use the BTS, of course. We promote the sending bad reports for translation updates. This is the easiest way after all. We have a kind of standardized way to do so, so every wish list, this is kind of historical way, which should be serious, in my opinion. The tags are L10M and patch, because you send a patch, you send a translation, you send a patch, the maintainers know how to apply it. The subject is somewhat codified. This is not really important. It helps most of the maintainers to know which language this is about, because if I send you a file named dz.po, what the hell is that language? Who knows? dz, dz, yeah. France knows, but no. This is donka, donka, language of Bhutan. Okay. I'm in my Bhutan mode currently. The material for translation should be, of course, attached to the bug reports. This is a message to translators. Don't forget the attachments. Okay. So use report bug. It will help. You'll not forget it. Optionally compressed. Many translation teams like to send updates compressed. This has been initiated by the Japanese people, because they don't like us to mess up with their encodings, and we should not. So it's a good idea to send the files compressed with dz. Currently, not really often useful, but anyway, it's quite safe. So do it. Do it. Can I ask you a question there? Yeah, I repeat it. You tend to like to... Sorry. In original, you tend to like to send in clear text, because you don't need to have all these extra tools, and you never know what kind of tools people use. So it's a point, not packing text. But I can see the Japanese argument, because it's not very supported on a web browser, for instance, but a lot of translators really likes things in clear text. Yeah. The point is, is that really needed after all to compress the stuff? Yeah. The most important is not breaking anything. So, yeah, most often Latin languages translator do not send a translation compressed. I never do it. But it doesn't hurt after all, and it's safer. Now the mail user agents are safe. So that's not so much risk, but it's kind of tradition. In that regard, the maintainer duties, Javier also talked about, already talked about this. Please, please, please be responsive to these bug reports. This is very easy to fix, even though if you don't have a localization helper, it's just to just put a pure file in the right place. Check if it works, because sometimes it's broken. So you'd better look in our paper, there are ways to check for files. Apply as soon as possible, yeah. Do translation updates during freezes. It's allowed. You can do it, so please do it. We will soon have a freeze, you know? So I want to be 100% for edge, please. No, not 70%, Javier. That's yours, yeah. Okay, so also important part of the infrastructure, and so you, the people that are not involved in the translation process, actually, this might help until you guys to see how work is actually done. Because some people just think that it's, okay, I'll send a file to somebody, get translated, I'll receive it. You know, it's like professional services for free or whatever. Actually, many translation teams use, and that's not all of them currently, those that have a main list, use through the main list what we call a translation robot. And that's part of the infrastructure, because that's used for coordination with translation. Basically, I'll probably show you better with this slide, to change that one. Yeah, I'm going to do what you're not supposed to do in a talk. That is your work. Okay, actually, it actually works. It works there. Good, you guys come over here. That's funny. And I put that in sleep mode. So we'll go back. Yeah, yeah. I'm going back. I'm not going to show it. Oh, that one fell. Okay, basically, what you have there is that you have teams making a process in order to ensure that the translation has a good enough quality. Okay, now put it back there. Don't worry about it. So, thank you. 100% guide. What you can do, what we actually translation teams do, is try to ensure the quality of the process by doing reviews of translation. So what we do is, first, when translation wants to work on things, it says, okay, I'm going to work on that to avoid duplication of stuff. So we'll tell the other members of the team, I'm working on this. I'm going to work on that and I'm working on this. So those are the first two. That's translation afail, right, Christian? I did that correctly. And the other one is intended to translate. So when a translator wants to work on something, he says, okay, we have to do this translation. That's probably coordinating. You have to do that. And then the translation says, okay, I'm going to do that one. Please give me that one. Thank you. If I'm going to do the intros to translate, then as soon as I finish, I'll go and ask for reviewers. Okay, and I send that to the team. And that's just like when you do CVS comments to source code. If you send that and nobody answers, then you get, okay, did actually somebody review this? I'm not sure if my translation is good. Please review that. And this is actually sent to the mailing list so everybody can jump in and say, that should be done some other way. This is the proper translation for that term and so on and so on and so on. And when that is finished, then the translator will send a last call for comments and say, okay, this is the final file. Are you all guys okay with that? And when that is done, it will be sent to the BTS. Eventually, at some point in time, it will be fixed by the maintainer and then it will be done. Actually, no, because this is a loop again. So when the translation is updated by the maintainer, you get a loop here. So from here done, again, you intend to translate and whatever, whatever, whatever. That process that is made by most of the teams is actually automated by Robert that listens to the mailing list on all these UCDO URLs so he knows what currently translation status is. So that main country in America can say, okay, a guy sent a file. He was going to translate. He hasn't been sent the translation for maybe three months. I'm going to ask other people to go back here and do it because he's obviously not responsive. Okay, so that actually is a process that has been used by many teams. Okay, so we're going to talk about some tools in Debian. Actually, I'm going to talk about two and Christian about two, so we are fair enough here. That are used by both translators and maintainers. Yeah, go back. That's okay. So one of the issues we have here is how to handle the communication translation because it's not that recently that we've been using pull files for documentation, okay? And that's really crappy because I know that because my translators of the security data manual get very angry with me because when I make a change of a manual that I think is maybe 300 pages long if you compile it into PDF format if I make the change, it's really complicated to see where the change is, okay? So the translation teams and some other guys have introduced a few files, a few tools to work that which is based on the same idea that the website works with, okay? We're not going to introduce the tools that the website uses, but we're going to introduce these ones because we want you guys to use that. And it's called DocCheck. DocCheck is actually a script that is different from some documentation that will work with translation headers on files and it will tell the translators, okay, this file has been updated upstream. And check the translation. And when that's inserted into a source code management system, he can actually know that he worked with revision 1.5 and the latest revision is 1.7 so he actually has to guess as for that div and he has to translate that div and not review the whole file with maybe 1,000 lines long. Actually some of mine are. Actually, that's possible in some cases when translation documentation is in XML format. We tend to just use in poxml which will take the XML code and convert that to a po file. You know that po files, and if you don't, you have to pay for it for that. Can't do that management automatically. Okay, so instead of breaking it on strings that breaks on paragraphs and that puts it on a po file so that the translator can just check the paragraph that changed. What's the issue of this? I can use it right now by four documents but maybe four of the documents that are most translated because the translator asks for that and the different scripts and different health formats so that needs to be unified. But one of the documents that uses that and has been really successful has been the devil installer. Which is one of the reasons that it translated too many languages because it's broken into many files so there are not very big files that you can see a change that has been made. They have to parse a very long deep. They can go to a very small deep. Next. Another tool, more user-oriented that has been developed by translation teams and actually not only translation teams. It's both the use of localization config that has been used on the devil installer in charge but it's no longer working for edge. So if anybody wants to help there please you're welcome to do that. Is that a tool that will actually handle the fuss of having all the different bits of the system that need to be localized. Because in some cases it's not just sufficient to just say locale equals whatever in my case es underscore es. Maybe that's not sufficient. Maybe I have to touch imx in order to work with Latin 1 characters or UTA characters or whatever I have to touch some files over there. Maybe I want to touch ispels so it will use by default when it installs this Spanish dictionary. It doesn't ask me because I don't want him to ask me because I already told the system that I'm going to work in the Spanish system. So that's the work of the localization config thing. It will actually do some pre-seeding on DEF CON stuff. It will actually touch some files here and there, not many, and it will get the system localized as much as possible for users that say on the installation process, okay, I want this language and I want this language all the way through. Which is quite an improvement from Woody to Charge. I didn't do it. There was a member of the Greek team. I couldn't pronounce his name. Right now he's in military service so that's why he cannot work on this stuff right now. Okay, so that's what it does. Actually there's another piece of that which is Taxel and that's thanks to Yohyes doing that, which is that there are some tasks that are language oriented tasks that will install a set of packages that are thought to be more useful for some guys. So that actually works both in Woody and Edge. So this part is not broken, at least not yet. So that means that if a guy says, okay, I want in Spanish, it will normally install the Spanish task or the French task. We'll try to get his desktop kind of translating to Spanish. Okay, that's yours. So this is my advertisement moment. Again, you had it last year, those of you who were at Helsinki, you were at it again for PO4A. PO4A, PO4Anything. This is a kind of attempt to bring text translation, PO based translation to new files. Most of the time text based files. Text based files like man pages or documentation of whatever, actually the most important part of the last dots. Barely this PO4 anything. In Debian, this is a project that started like two or three years ago. It's currently quite widely used for man pages for native packages. We are lucky enough to have in Debian, the PO4A maintainer, upstream maintainer, please stand up. Nicola, thank you. And the French, yeah, he stood up. Yeah. And this initiated a lot of work inside the French team to bring more localization possibilities to the Debian native packages man pages. These long and boring deep package apps or whatever package man pages. We have set up some experimental status pages for these man pages. We have the link in the slides. I'll show you at the end if you want. And the main problem is documentation, big documentation currently prefers PO-XML for big files. There are a lot of things for that. And this is often a debate between translators and maintainers which is easily solved most of the time. So what we want to ask currently to maintainers is use it in your package, please. Try to have a look at PO4A, ask for help. The Debian internationalization mailing list is a good way to do so. It can make your life way easier. So in short, of course, I said it a lot of time. PO4A rocks. Thanks. PO-DebConf tools are very well known tools because I said PO-DebConf is the oldest stuff, which is a good localization framework in Debian. We have a few tools. I'll cover it quite quickly. PO-DebConf update PO I mentioned it. It's the way to have all the profiles, all the pod files ready to Debian.DebConf templates up to date. So they have to be up to date. It should be run in the clean target possibly. PO2-DebConf is part of the package. Actually, it's mostly run automatically by DH. Install DebConf. So please use DebHelper. Don't use this funky Yada stuff that some people use. PO-DebConf report PO I mentioned it. This is the way of communication from the maintainer to the translator. The BTS is the way of communication from the translator to the maintainer. But we want the communication to go this way also. PO-DebConf report PO has been originally aimed for PO-DebConf translation. Actually, you can use it also for upstream translation. Just look at one page. And it's same to one translator for neither update. It just send mails. The relationship with other project I'll give the mic to Javier, but it's all about how to interact with other project upstream or to package specific translation stuff for Debian. Okay, thanks. I'm not going to go into detail about some projects. Let's go here first, Christian. You all go too fast. Yeah, plenty of time, right? Even though we started late. Okay, I'm not going to go into detail about projects that already do translations like the pre-soverefitation or the genome or KDA project because those are actually very easily explained because we actually just reuse the translations. There's actually between teams on one side of the C on the other one. So actually the KDA teams and the non-teams share closures and they share it with us. So there's a lot of work between all the teams in order to do stuff. But what I'm going to talk about is one of the XX packages, which is not porn. Okay, so that X is time for whatever language code is being used. And the other thing is that maintainers will provide two and that actually will get installed by all the textiles stuff I talked about. Mostly as independent package in the system, breaking down program and translations. So there's the good, the bad and the ugly about these guys. If we all were porn, it probably would not be... We'll also have both of them. But in any case, the good thing is that separate translations uses that one to install the translation of French but don't want Spanish. Can do that because they're separated. So they don't use up this space. We don't have to use those hacks like the, what's called the one that breaks the, removes the translation. Locale? Locale purge, yeah. That's kind of a hack in order to say, okay, I installed all this translation, remove it under your feet because you don't really want it. And I say, okay, all these profiles of languages you're not going to use, I'm going to remove them after installation of package, but they actually don't load them. So that's actually a very big waste of bandwidth for large profiles. So in order to avoid that, if that translation is separated, users can just download the translation they want independently. That means that it might not be on the same level as the original source. And that actually happens a lot with mind pages, okay? Because mind pages translations are developed not by us, not by the translation within Deviant, but by other guys. And they might not follow the mind pages stuff that is done on coroutils or file tools, which are actually the mind pages package provided by the documentation, the Linux documentation project that provides that package. They actually follow a given version, but might not be the later version, and it's not integrated, so it's not easy to check if the version distributed by them is the same version as the one that is being provided by the Linux documentation project, which ends being a problem, which is the out-of-the-side. That is the users that use a locale might get information of a mind page, and they actually might be doing completely wrong information about a program, okay? There's also a problem because they don't notice, because actually it hasn't had any feature, like just like Info I mentioned, doesn't have any feature to, it does have a feature to localize content, but it doesn't have any feature to show you if the content is up to date with the version, okay? So it doesn't do any version in between them. And it doesn't come around and hit us in the head when, for example, it happened to me with Mozilla packages when the translation is so tight with a given version that it only works with, you know, 0.9 version of Mozilla, and when we upload that to CIP, that all goes well, they all proceed to testing fine, and testing has Mozilla 0.9, both French and Spanish, whatever, whatever, whatever. But when 1.0 comes out, and one of the translations are not updated in the package translations, that means that Mozilla cannot 1.0, that cannot go into testing, because it will break packages already in testing, because it will remove the Mozilla 0.9 package, but there's already a package that is the Spanish guy, for example, me, that depends on that. So it will try to remove that, enter testing, it will break another package, so it will not go into testing, even uglier than that, because man pages at some point in time are even moved on to upstream and including the source, and that means that when a new shadow version comes in, that has a French translation, it has to be removed from man page IFR, and at the same time a conflict version has to be introduced on shadow and on man page, so because it cannot be installed at the same time, because they provide the same file. So crap, crap, crap, ugly, ugly, ugly. So deep doesn't tie that much with the other one, but it's another issue when working with upstream, that is it happens a lot of times, well it doesn't happen a lot of times, it happens to me at these a few times. When providing translations, you can actually decide to work either with the dev inversion of the package or upstream version. If you work with the dev inversion, you can work with that and send that to the BTS. What should the maintainer do when he receives a backup report of a version when he knows that a new one is available and he's going to package that. He could either just let it die in the backtracking system, he could apply it on his version, make a release and try to forward the port to the new version or what we actually suggest is to keep it touching later, you shouldn't be working with the versions we distribute because we don't want to divert that much from the stream and if you handle this translation as a team, please go directly upstream and that's actually the best case. If you're a maintainer and receive a given a new actually a new translation, not a backup of an existing translation, we actually should go upstream also, but in any case you can decide if you want to integrate that or forward that upstream and it's actually best if you forward not the file but the translator upstream so it's not as easy, you don't have a key for that on your MUA to forward the guy but you have to forward the guy, not the file. You can mark them as pending, you can close them with a new upstream release that includes that translations and handle them that way. There's a special corner case here however and those are the freezes because if you get translations updates during the freeze you know you're not going to update a new version and you know you cannot send the guy upstream. We're talking here about Debian freezes but that might be freezes of a stable version of a package even. Maybe the upstream is working with 2.1 and that's beta and it's not going to be releasing in six months and Debian has 2.0 and that actually happened to me with game. 1.5 versus 2.0 the beta is not going to be released for a long time but this translation could be updated to there. That translation could be used to make a new update for the Debian package that will mean that the guys using the package at that point in time the Spanish users will actually profit from that translation later. So at that point in time that's a maintenance issue but we recommend that during freezes either upstream freezes that will take a long time and most importantly Debian freezes that might last three months and we cannot make a new release but use the VDS for translation and get those translation supplied and do a new version of that. So yeah. Conclusion is mine. Actually it's not exactly the confusion. I propose you will have a small question break because I asked you to keep the question for the end and after the questions I will keep some time. We have a big time slot. We are lucky. Actually because we have a big time slot and we will summarize this both during the depth conf we need internationalization in more areas. Why? We want more users. We want to dominate the world. We want the CDDs to be distributed everywhere not only Ubuntu by the way but also Debian Edu for instance or Skoli Linux. So we want these users happy. We want them to use our software. No single English word should appear in a Skoli Linux install. We need to target more languages. You've seen this nice nice red planet but it still has some blank parts. You have seen it Africa. I asked Marc Chateau what this morning about it because this is one of the most important part in the developing countries. We are mostly covering Asia also but we are missing some parts and this is important if we want to target more audience. Jim Geddes had this talk about the one laptop per child project on these laptops we don't want English as language. We want the child's languages and for all this to happen, for this all this to scale well we need a better internationalization infrastructure. We have such good things it works currently but it doesn't scale that well. So this is what bring us when I mean us I mean most of the people in this audience to work quite closely during this depth conf mostly to discuss together what do we need for good internationalization infrastructure which I will talk just after. But before if you have a few questions about this part of the talk, this state of the art, please go for it. Is there a mic? So actually you show a picture of Africa which is quite blank full blank but if I recall correctly quite a lot of currently in Africa can speak French or French is the official languages and at least I think that when there's a computer and when there's someone can use a computer it can speak French too because at this point I mean not the child in small villages where French is not spoken at all. So the question is mostly as we support the colonial language English and French for instance in Africa this is a good example after all if we cover Africa there are two ways to see this I can actually paint Africa in red but it would be right actually if we want one laptop per child the child this is not true, not all child in former colonies speak English or French yes currently the people who use information technology in these countries they speak English, French, Portuguese most of the time Spanish in some of them but the ordinary people they don't so this is these people who want to target the people who don't use computers at this moment we don't want some big companies to give the software in these countries to localize the software they are doing it in these languages and implement that software in these places you know so this is why I think and I still think we don't cover Africa at this moment so as a package maintainer I often receive bug reports which ask for localization and I'm really happy to be responsive on this bug report but I have two problems the first one is that I sometimes I don't know if the required translation is authoritative or not since I'm not native language in the language which can be in or in the bug I don't know if it's a correct translation or not so the first question is if there are ways to know if the bug report has been submitted by some random user or from some people of the translation group and the second question is sometimes it happens that I'm missing the knowledge to answer a bug report like it happened to me I request to change the encoding of some Chinese translation and the reporter added that it can be not fair with respect to traditional or whatever kind of Chinese so do we have a place in Debian where we maintainer can pose such question is Debian internationalization the right place or do we have something else? How to know what is authoritative for translation, what is the reference etc most of the big teams have a mailing list so that's the good point so one of the first place to go is the list that Debian.org to check whether this particular language has a dedicated mailing list not all of them have because this is a request by our beloved Listmaster not to have as many lists as we have languages because several teams are made up by only one person so if you want to know whether someone is authoritative for his language first or her language most of the time first ask to the corresponding mailing list if there is one, if there is none you can use Debian I, 18 and mailing list this should be the place not only for translators this is not the translators corner the maintainers should use it and most of the maintainers use it quite often to communicate with translators question by Alfie yes the map you showed before was covered with the red parts that was the installer only I want to point this out again because there are very much other parts that need very much support from translators so don't lean back and say oh it's covered already it's red there are very much other parts to translate and get into good stuff and even there are still programs that are not internationalised now which needs to get code patches to be able to be translated this was mostly a message to maintainers by Alfie first of all I want to apologise for always using the installer translation stats for this kind of demonstration I know of course the installer is not everything in Debian this is just the first thing you see when you try to install Debian so it's kind of the entry point we define some new processes inside the installer new language process so it's kind of a model but of course it's not everything most of the time the end users application which is the main target OpenOffice Firefox all these things are well translated and most of the time the new translator we have in DI come from these translation teams so this is something that goes both ways so of course I know the map is not right it's a neat way to show what's happening hopefully I won't make it next year again you'll get both people Can you tell me again from the infamous school of Linux project Jim Getty has a point and we have also done the same in school of Linux that the program isn't really finished translated because we haven't catched up in the Norwegian branch the translating and we have even then translated the package even if the DBM is freezed and we have installed an updated language version of the programs even if everything is freezed and Jim Getty has also pointed that out that they should because of the child project there are a lot of problems in a lot of parts in Africa it's child we're talking about here they don't speak French they talk the native tongue so they should use the native language but it's not really translated and it has to be updated on already released software and could that be a thing I break every DBM rule here asking of this but could that be a way to get newer translating things into DBM stable or DBM H plus 1.5 for something I just ask so you merely suggest that we do translation updates to stable release yeah I think so maybe Javier has an answer we probably have a thing there but Ubuntu does write and we don't do write which is translations are not updated without updating the packages themselves what Ubuntu does right now if anybody here can correct me if I'm wrong is that they provide packages that include new translations that they can be targeted as stable so that's probably one of the things we have to think about maybe doing somehow maybe in a hacky kind of way for but we don't have a target for that and nobody's working on that so we haven't even started thinking about that first thing one of the things the translation team want to first have covered is to have a good idea of all the things that need to be translated and be able to work on that before targeting major changes in the process of how translation are distributed as you say maybe one of the things that we have to make is like KDA packages that are done and the translations are all outside the packages of the software themselves so they can be we could probably get away with talking about the stable release manager to be able to make updates for edge plus one for those packages which do not include code and just include data but that's something that has to happen in a more global way and without any hacks we don't see that coming for edge at least so maybe that would be a target but that's definitely something we have to start thinking about as soon as we got covered as you'll see on the above a proper infrastructure to handle all the different things we have translated but that's also something that has to be done with the release managers and none of them are here because our release manager do not care about internationalization even one of them left yesterday that's too bad they do care about it Bruno please last question I want to go with both conclusions it's not a secret that no developers are very active in this area and somehow it's the way that they get integrated in the project so my question is you are happy with the current permissions that they have for example in the SBA you ask me for a personal opinion so am I happy with the status of translators I currently am yes I would say that two years ago, three years ago I wouldn't have been because more than three of let's say four or five years but now I think that first of all internationalization localization has been widely recognized widely accepted by all developers and I'm still waiting for someone to just come at me and say I don't care shit about your internationalization stuff it didn't happen maybe some think about it but they don't want to be killed anyway so the status of translators has improved certainly there have been some debates about some official status for translators but I think that maybe some discussion can happen I hope some of you have seen Christoph Berg and Mark for new maintainer process and new status inside this has to be discussed my personal opinion maybe we can find some intermediate status yes it will be complicated and maybe we don't need that and one last comment please just to make a point here and that's from experience just to make a little point I haven't seen anybody that has shown that can do translation and has asked for access to CVS on the DDP on the website which is at Lyov and doesn't require a deviant account or your special guest accounts to work I haven't seen anybody that has been turned down if they have shown that they can probably France has gone away but people are getting access to the SVN without being translation without any problem at Lyov and the Web site so that's not a problem and actually the only one person that has been removed coming to access is not a translator kind of joke this leads us to yeah Felipe I would like to go on here just one point the updates of the stable maybe I'm not sure but maybe we can use Volatile for that they are aimed for data data packets so it's as language we can talk I can talk with the Volatile team but maybe that would need language packs or such things well let's see keep the suggestion so I'd like to summary if someone wants to escape now please do yeah thank you yeah we have like 15 minutes thank you to summarize all this buff we had with many of you during this step so I try to make it short so that maybe one or two questions pop up my experience first of all it has been so enthusiastic so good work with it during this step so I have a lot of things to summarize I have so few time I try to be exhaustive but please forgive me if I forget something we need the internationalization infrastructure we conclude it with this and we really desperately need it if we want to scale we want it as modular design as possible I mean this is a conclusion of most the technical people in the audience who have talked with we want it to be as modular as possible to give as much possibilities as possible because our targets are very very various so we have to be completely modular we currently have two opportunities to advance on this project to very soon opportunities first of all the google sumo of code proposals there has been one proposal in the google sumo of code to work on the internationalization infrastructure discussions have already started on as usual the db and i18 and mailing list with the the guy who proposed this who is oh I tried it Gintautus Miloas Carl you can actually pronounce between between here so a guy from Lithuania maybe he is watching us I hope so sorry for breaking your name so we are talking about this this is a good opportunity he will not write down the whole db and internationalization infrastructure alone that is absolutely not possible but some parts can be done and we still need to discuss it actually iGas this project we don't know if the project will be accepted or not we have good hope for it to be accepted we also have what's called the extremadura session the sessions funded by the junta de extremadura in Spain to work on some specific db and project I proposed one in September we will meet over there in September for actually the September 8th to September 10th like 20 people probably we'll see and either work on technical stuff either continue to discuss because maybe we will need to discuss again to be sure we design something well so we what we've done during the db conf we have mostly achieved overall specification analysis we have identified our targets who are the translators of course our targets are the translators who want them the tool or you because most of you around our translators are working translation teams we want you as to work in good infrastructure have better tools and fulfill what's missing in what we said before the reviewer who are most of the time the translators we want to fulfill also the needs of the team coordinators of the tasks and so on I won't go into the details of what will be these needs but we need to find many of them then some of our targets are the maintainers we want to improve the discussion with maintainers and translators and the maintainers and the systems for instance allow the maintainers to grab the translation or to call for updates in a way to communicate what we call the visitors the visitors are the people who just pop up on the future DBM internationalization servers just like some people pop up on the Rosetta server and just say oh it's cool nice colors red green and my language oh my language is red not completely translators I want to come in jump in oh I want to do some review process oh I've seen the specific strings completely wrongly translated I want to report it these are visitors these are people who pop up and the administrators of the system of course the people who will run this stuff authorize the translation coordinators so we identify all these targets and maybe there are a few more but I think we cover most of the needs we know mostly all of the needs of these of these targets we need probably to improve the analysis of the translator needs because most of the discussion in the DBM I18N have focused on these needs of translators but there have been also discussion on the side needs not side I should not say side other needs we need to improve analysis of the maintainer needs maybe this is one part we lack some input from people who are outside translations that the maintainers are the people who maintain the DBM packages but also the upstream maintainers what do they need how do they want to work all this should happen from now in the DBM I18N mailing list so I expect it to become one of the most active mailing lists in DBM I think we need to get outflame more please in the next week please also we are 33 we will be on time awake to go and I think this I really hope this will be the way to go we finally conclude that it would be a good way to collaborate with the WordForge project we were lucky to have Javier Sola representing the WordForge project thank you Javier made a long trip to come over here but to be with us and to learn with us and our changes have been very very interesting and maybe we will continue just after he has to leave as soon but maybe we will have some more talk again yeah what we why do we want to collaborate with WordForge because we found that WordForge is a committed to promote open standards this was most of Javier improvised presentation committed to ex-leaf to as standards for translation committed to standards and promote standards for glossaries, translation memories all these things that make translation work and scale they want also to promote to open protocol to communicate between internationalization infrastructure so this could be a good way to not going against Rosetta and Launchpad stuff we have mostly decided not to go with Rosetta tools mostly because it's not based on free software most of you know about this but we don't want to go against Ubuntu people we have good talk and we will have still good talk with Ubuntu people about this and they are very open to collaborate with WordForge so I think that the three of us can do very neat things and because communication would be possible in all these systems modularity is the key this was coming over and over and over a plugin to be able to communicate by mail with translation we want a plugin to be able to work on the web etc etc we want some client tools client service stuff our target is very wide there are some countries where bandwidth is so cost full they can't translate on the web even downloading stuff is not that easy maybe they want web server in their countries etc so we want all this openness and we found that WordForge is able to provide all this yeah I prefer I keep this because this is the typical conclusion of a good talk as Mike explained hopefully it was a good talk but it's open for questions about this part I guess there will be a lot of if there are too much we will just move and meet especially with Javier and use last time he has in Mexico for that please for us for WordForge has been also a really rich conference we have been working on preparing this localization infrastructure as a general thing for open source but coming here has opened me to a lot of new things and especially to work together with Debian on the specifications of the system that we are building and maybe on the development also our interest also to make sure that our specifications in our project fit what Debian needs because whatever Debian needs also will be what other projects in open source we need at the end the infrastructure doesn't have that many specific things for different projects but I have seen so many good ideas here in the two days that I have been here and I have seen a lot of people that we would like to work with for specifying what WordForge should be and yes and we are lucky to have Javier now subscribe to Debian I18 and my review so we can talk with him now so you had no questions okay you were moving so you are happy okay so let's make so yeah for those who don't know about it despite his name Javier he is not from Spain he is from Spain of course but he lives in Cambodia so it's quite a long trip just to come two days at Debian so thank you again Javier just out of curiosity do you have a view of the Summary of Code Proposals which regard internationalization and how we interact with WordPress staffs yeah the answer will not be very precise because we are still thinking about it problem of the problem of this Google Summary of Code Application it comes very early for us to finish discussing and setting up our ideas my main idea is well Debian has waited like 13 years for having a good internationalization infrastructure so we are not that in a hurry but okay we are also in a hurry but better well designed and badly designed so what we are converging to maybe I guess would like to comment maybe we would like to converge towards having the Google Summary of Code Project work on some specific parts of what's needed and especially we will probably work with the WordPress specifications I sent recently the URL this morning actually to the mailing list they have very good specifications for the needs they have very good roadmap to be achieved so this project could be one of these bounties we don't know which one probably some core parts probably some design parts because most of the Google Summary of Code Applicants are people who like to code and Githun Tass or whoever is his first name is also very open to discuss but he appeared to me as someone wanting to code and this is fair of course so we will find something and we have not completely decided frankly so thank you people for staying awake all the time