 Hello, bonjour, guten tag, dzień dobry. I'm Łukasz Jena, I work as a software engineer for Allergy Group. Since the Havana E-Leaks I'm a volunteer translator for OpenStack. I've been involved in translations since 2004, started with the Dome Project. I hope I give you some hints how to translate properly, where to start, how to update our infrastructure and what roadblocks you make in a new way. So first maybe I'll tell you why start being a translator anyway, what are the reasons, I became one, what it gave me. Then we'll talk about the tools and processes we're currently using on OpenStack, and a few stories from the trenches which I encountered over the years. So how does one end up a translator anyway? First, it's an easy point to open source, when you want to start doing open source, providing new software for people, translation is an easy way to get involved. Because if you can read English, you probably can translate it into your own language. Also, these days it's not difficult, when I started ten years ago, I had to know specialized tools, be accustomed with version control, know some magic variables. And yeah, do a lot of unnecessary stuff. These days you just go to a web page, click translate and you're done. Ok, you actually don't have to know any programming language to develop in some way software. Of course there are some variables you have to take care of, but it's nothing special, nothing that requires any specific knowledge of programming. And translating software is a good way to help others in your county. It's also a good way to have a higher user base, because not everyone has to know English to use your software. Of course IT professionals usually do know some English, but we have to work with our users and we shouldn't expect them to know it. Ok, also it's a good way to improve your own language skills. When translating software you have to accustomed yourself with many dictionaries, teasers and glossaries. For me, my key translation provided me with a better vocabulary. Now I tend to build better sentences in my own language. Of course this has a minor downside, in that I pay the WAs for my text messages. And you should be proud of your own native language. Diversity in open source is a good thing. Diversity makes open source software different from the commercial one, which is usually developed in a specific culture i sometimes hard to translate into another part of the world. Ok, maybe let's go to the tools and processes we employing in OpenStack. First and foremost, the community. The most important piece is one thing that made me do translations in the first place, because in some communities we tend to have annual parties and pretty much we are becoming fans of the time. One place to contact us is the OpenStack i89 mailing list. It's low traffic for now, so if you have any questions, if you want to know more about translating, please go and ask. Other means is the OpenStack translation IAC channel on the Finnault network. We are there, of course sometimes we can respond in five minutes, but someone eventually will respond to you. Ok, our primary workhorse now is the Transifx platform, where most of us do the actual translation. Ok, after logging in you should find the OpenStack organization and you will get to a similar screen where you can select your project. For example, we focus mostly on the horizon project, which is the OpenStack dashboard. Then you select your language, join a language team, you haven't done some already and just click translate. Ok, that's your main UI for working with Transifx and translations. It's separated into three groups. On the left you find Stinguist, which contains the entire list of Stings in a given project, together with the translations. In the middle you have the actual workplace, where on the upper side you find the English Sting, in the middle you find the edit box to translate it and below some contextual information about the location of this Sting, in what file is it and any information that developers could add to it. On the right you find some useful tabs, which I'll describe later, exactly now. An important tab is the suggestions box, which contains suggestions based on previously translated Stings, and the amount given Stings matches to the current one. That's the history, which the name implies, it's the history of the item, and one useful thing is the grocery, where you find description definitions and simple translations for a given Sting and of course the comments. Another set of tools used by our team is the tier of Jenkins, Zule and Gate. Any of you know what these are? Okay, so Jenkins is a built system, it does the actual work. Gate is a system where developers review the code, they comment on it and which then triggers Zule to do some jobs. The process is as follows when a developer measures a patch to a project, a post-commit job is run by Zule, which accelerates the translatable Stings and then they push the trans effects, and then the developer translates it and every day another job is done, which pulls down the Stings from trans effects and proposes as a patch for a gate for the developers to approve. They don't check the actual content of the file or the translation only that it doesn't break the build and at the end the process repeats itself over and over again. Okay, maybe go to the promised dragons. The face hippie dragons comes from old maps where places that were either unknown or dangerous were marked by a face hippie dragons to warn other sailors to not venture into this area. Some people tend to think that translation work is easy, but there are a few situations where it can be really hard and really tough to do properly. For example, there was a story about the column back, so when I was translating the ice house illies, I've noticed that there are many Stings that seem to be duplicated, which are different only in the ending. For example, you have image details, image details column space and image details column. So I propose that we just get rid of the tearing spaces, tearing columns so that a translator would end up with only one Stings to translate. In that case, when we had three Stings, every Stings could be translated differently because they appear in different places in the tens-effects UI. Some of them are at the beginning of the list, some are in the middle, some are at the end. In that case, these Stings were meaning the same, but one of these Stings was the page tutor, the second one was a header, and the third one was in a message. Ok, but then can I e-mail to the mailing list by Douglas Fitch, a Fitch which said, while I understand the need for consistency, I just got the request for a French translator to do the opposite implementation. The translator of French shared with me that the punctuation as part of the translator in material makes it much easier to create a correct translation. In French, a column is expected between the final word and the final punctuation, including a column. So I said, oops, the whole part which is already prepared had to be averted. In the end, there was some discussion on the mailing list, and in the end we decided to keep the column but get rid of any spaces at the end of the sentences because we couldn't find any possible language where this was needed. And another case which you have to look at is stinking concatenation. It's a common thing for developers to do something like that. My name is Placel Wajorbel and Kowalski. Unfortunately, for a tense letter, this will be two stings without any context because the variable will be lost and wouldn't appear anyway in the translation system. So a better form would be my name is Percent S. Kowalski which would end up in the translation system as a single sting and also give us information inside that is another sting. But the best version is my name is first name Kowalski which tells the translator that there's a variable called first name which gives us context. So it usually won't appear another Kowalski but probably it will be John, or Alice or something. And it's way better to translate and won't end up in any errors. At least it shouldn't. Okay, another issue we have translating software from English to another language is plural forms. English is easy. It's either singular or plural. But for example in Polish we have at least three plural forms. Some languages are even more complicated. So let's see for example, there's one file, 2399 files. One file is one plik. 24 pliki, 21 plików. Then 22-24 pliki again. And then plików again. So... Sorry? 32 pliki again. Yeah. And zero is plików. Okay. So the usual convention where the developer does that if a variable count is for example more than one then do another thing. That doesn't work. Fortunately there's something like ngettext which when we pass a variable to it forces to appear in transifx in the proper way. So we can select the one form, the few forms and the other forms. And it allows us for a good translation. Unfortunately for Polish we can do a proper translation because we are missing the number of instances here. So we, but at least without the number we can do a more proper translation that just copies that one over here. Usually there should be a number. And the most complicated thing is declension. For example the nouns which have in different forms. Let's look at the sample string where we have viewing something. The variable substituted by map, by instance, by whatever. So the translator would end up with two strings. One would be viewing types and the other would be map which means a singular form is mapa. Unfortunately there is nothing similar which is wrong in Polish and in many other languages also. Because mapa declenses like that. There is who word mapa, who's word map, mapie, mapu, mapie i mapo. But in that in that very sentence we would have to use the genitive form. So the sentence would end up with wyszutlanie mapy, viewing map. So the previous sensation that which didn't have the context would be wrong. Totally, actually. It's even hard to read in Polish. So it's better to not substitute the variable as a variable content as a variable but match it somewhere else in the whole sentence. Ok. And the last thing I said yesterday is a warning for designers. Don't use fonts that contain only ASCII characters because you'll end up with that. Something's missing. Ok. Of course, translators are always welcome. The few of us would like it to be more, especially for Polish single single co-ordinator translator and whatever you can find. The best way is to go to our wiki. There's a modulated procedure about how everything works. Of course there's the mailing list. You can chat with us and find a link to the project that is the most so open start dashboard. No, thanks for those who stayed and also thanks for for allowing me to be here and if you have any questions. Can you please go up to the mic? Yeah. I've tried to create translations before but not for open stack and I'm just curious how you came to do it and specifically when you very first started doing it what were some of maybe simple but big issues you ran into at the very beginning? The issues I ran were that my desktop environment wasn't fully translated and that's why I started doing the translations actually and I had to learn in GNOME we use SVN to translate the projects. We had a separate team which we pulled the translations from the GNOME repository and then merged them back and really the hardest thing was getting the developer to merge that patch with the updated translation. The hardest thing was to get the developer to merge the updated translation into the baby intergnome. Yeah. Okay, thank you. Okay. Thanks.