 Welcome everyone. It's May the 12th, 2022, and this is a Jenkins online meetup, localizing Jenkins with crowd in enterprise. We're grateful to Alexander Brandes and to Bruno Verrachten for joining us. Alexander is a native German speaker. Bruno is a native French speaker. In case you can't tell, I'm a native English speaker. That's about all. Next slide, Alex. Would remind you that Jenkins online meetups are community organized events. We try to do things that are interesting to the community, that highlight things that the community could find beneficial and that would be of interest to you. If you'd like to speak, check in with us at the Advocacy and Outreach SIG meeting. We regularly talk there on Gitter and we've got a once a week or once every two week meeting. Next slide. So in this session, if you've got questions and answers, feel free to use the question and answer facility that Zoom provides. We'll also tend to answer things if you ask in chat, but question and answer is a little easier for us to manage. So as a kindness to us, if you do it in question and answer, that's better. It's not that we'll ignore you in chat. It's rather that it's just easier for us if you do it in question and answer. And after the meetup, this hyperlink here is to our discourse site, community.jenkins.io, where you'll find a copy of the recording of the meeting and we can have conversations about the topic right inside that discourse site. We're very grateful to discourse for hosting the site for us. Love what's happening there. Next slide. So Alex, this is yours now. Thanks, Mark. Yeah, let me introduce myself first. I'm Alexander Brandes and I'm a native speaker from Germany and one of the main presenters today during this online meetup. A few words to myself. On GitHub, I go with the name, not my fault. You may have already seen me contributing to a variety of repositories in the Jenkins organization. And outside of Jenkins, I'm currently a business science student from Germany. Yeah. Here we have the agenda we are talking about today. We will start with what the current enterprise is and what we are planning it on using in the Jenkins.io organization, how we translate something with Groudon that something Bruno will show us, how we translate something, how he translates one of Mark's plugins into French. Then I will take over again and show us how we review something on Groudon. Followed by that, we will see the approved strings, how they land on GitHub. And after that, I will give us a quick rundown how a plugin maintainer would configure the repository on GitHub in order to be able to use Groudon.Jenkins.io. First of all, I would like to thank Groudon for sponsoring us and hosting our instance available on Groudon.Jenkins.io because without Groudon, we wouldn't be here at all. So thank you. Yeah. Actually, translations and localization is an important aspect in terms of user experience. Like you may know or have already seen in core, if you change your browser language or something else, for example, in my case, that would be French or Italian, you can see that Jenkins Core itself provides various views localized in different languages. And the same process applies to plugins too. You can localize plugins in the same way like you can localize Jenkins Core. However, localizing plugins isn't easy, especially for people who are not necessarily familiar with Jenkins or Jenkins views at all. And that is basically the reason why we have spent the past bunch of weeks investigating into a different alternative. And Groudon Enterprise is the solution we picked for us. A quick recap on how localizing works in the current ecosystem of Jenkins plugins. To localize a plugin, you actually need to have quite a bunch of different prerequisites. For example, you need to know how to work with Git at least at a level to work with different branches and make it recognize the changes and push them back to the GitHub repository of the plugin. Then you need to know how to work with GitHub in order to submit these changes as pull request. But on the other hand, it's not just all about software. You also need to know how views in Jenkins work. They're often written in jelly that is by far not a language that is common to know these days. And last but not least, we have Jenkins views written in Java or Groovy. So we have many languages you basically need to be aware of and aware of the oddities. For example, using non-Latin1 characters in Java's properties file and having proper UTF-8 encoding just in order to submit a few translations or exchange a few words in a plugin. That is basically quite a lot just in order to submit such a simple change. And that's basically the step where Groudon comes in. Groudon provides us a much more streamlined solution that is able to be used by everyone with no prerequisites at all. Groudon just gets rid of all prerequisites I just mentioned. If you are using Groudon, you have a nice and handy web interface you can use to provide these translations. You don't need to use Git at all or work with branches or submit something on GitHub or need to know anything about Java, use groovy views or Jelly or anything else that is used in Jenkins to make views in the way how they are used at the moment. You just go to the web interface, type something in, save it. And that's basically it. That is the whole process broken down and outsourced to Groudon because they provide such an intuitive web UI that is basically be able to be used by everyone. And I would like to go ahead and just go stop screen sharing here and Bruno take over that he shows us how we translate a few strings into French. Bruno, you're muted. Okay, bad keyboard shortcut. Anyway, thank you, Alex. So here we are. I just typed crowding.genkins.io on my browser and there I am. Of course I had to create beforehand an account in order to be able to participate in this project. Now I've got two plugins that I... I'm not assigned to this plugin but they were there in the crowding.genkins.io. So I worked on the first one. And as you can see, it's named Design Library Plugin. And I've got Chinese, French, German, Italian, Portuguese, Brazilian or Spanish. Unfortunately, I know only French. I'm a native French speaker. So I went ahead and clicked on French and then I had the list of all the files I could translate if I wanted to. Okay, I did them all. So that's not maybe the best way to show you but there are some property files. There are some jelly files. Maybe not in this project anyway but there are also HTML files. You will find lots of different... No, not lot. Three different types mostly of files to translate and it's pretty easy. I haven't finished the Elastic Axis plugin yet. So I show you. Unfortunately, I just let the most easiest one just helpname.html and msg.properties. So let's try them. So I chose the Elastic Axis plugin. Then I will choose the helpname HTML because as you can see, it's only translated to zero percent. It should not be that much. Cool. This one seems to be an HTML file. So I've got a renderer on the left of the screen that shows me how this should appear in the HTML file at the end. So at the top here in the middle, I've got the name of the ethic so that's the phrase I'm supposed to translate. And as you can see, there are already lots of proposals. The non-deluxe, non-deluxe, non-deluxe, non-duvendeur and so on. So most of the time, I just choose the one that looks the best for me. And I click on it. If I think something is not looking good, I modify it and I made a mistake, unfortunately. French is pretty nitpicky about comas, spaces, point, punctuation in general. So I made a mistake, I did a space and I shouldn't have done so. And Crodin tells me I made an error. So there is a one so-called in red which will tell me, hey, you should place a space before the point and it's written in French. It will be written in Spanish if you're Spanish, for example. That's super cool. I learned some things by the way because I'm not sure about the place of the comas, the number of spaces I'm supposed to put before or after and so on. And then Crodin did everything for me. So once I'm happy with what I see, le nom de lax in French, I can click on save. And that's okay. I have finished with that file. I could have lots of different messages to translate into a file, but for this one, there was just one message to translate. So it's, oh, I haven't clicked fast enough but he has proposed me to open another file which hasn't been translated yet. So as I haven't clicked, I will just go to the next one. Yeah, open next. And then it will ask me for translation for elastic access. I don't really have the context. So maybe it's just the name of the plugin. So I should not touch it. That's what I think. We could maybe look afterwards if that's okay or not. But I think I will stay prudent and just keep it this way. Of course, elastic is not a French word. So Troudin is telling me, maybe that's not such a good idea to leave it like that. But yeah, I'm gonna leave it like that. I won't add it to the dictionary. It's perfectly just a name. So I will keep it that way. Yeah, spell check failed, but that's fine with me. Now I think I'm done with it. Yeah. Okay, so let's go back. How should I go back? I thought clothes would take me back to Ed in Dozen. Yeah, just hit the quit editor button. Yeah, thanks a lot, Alexander. Cool, so I have, yes, go ahead. Sorry, Bruno, I had a question maybe to Alex. You mentioned that you lacked context. And I think the only way to get context to decide what that string should be is you would have actually had to have run Jenkins in order to see what the context was where that was being displayed. So this isn't the perfect flawless solution. It doesn't show you in Jenkins. You'd have to look at Jenkins on a separate screen to see what that message looks like in context. Either that or Troudin provides the ability to include screenshots, what these things are used for. So you could have included a screenshot where this elastic access message is shown and Translator just wants to say, hey, this is actually the name of the plugin. Let's burn or not translate it. Got it, okay. And as it turns out, that actually is a headline for a section of the configuration page. So I think we do want to translate it, but that's a separate exercise later. You showed brilliantly and you showed a good way of asking ourselves a question. How do I answer a question? So I could have embedded a screenshot of that to give context to the translator. Yeah, or for example, in this case the screenshot would be sufficient, but in the best case, just don't have names, not translatable at all if you don't want to translate them. Hmm, right, good, the other, right. Intentionally choose things that I don't want to translate. Thank you, thanks very much. You're welcome. Yeah, I would take over again and head forward with taking a look over what Bruno just translated. I think everyone can see the messages here. Thanks, Mark, for the confirmation. Yeah, Bruno just translated the help.name.html and the messages or properties file. And the entire process Bruno has shown us is basically the entire process any translator has to do in order to submit a translation proposal. They basically had to, concurrently Jenkins.io and select a project from the project grid. At the moment, we have only elastic access and the design library plugin integrated. They would select the plugin which they want to have to translate, select a language, in this case, in Bruno's case that was French, select the file they want to translate or simply go via translate all and open up all open strings. Yeah, and basically just to recap it again on the left side, you can see all strings that are up for translation indicated by a red square. In this case, it is green because Bruno was smart and went ahead and translated everything. So everything is already green in the middle part. Here is actually where you put in the translation. In this case, elastic access stays as the source string elastic access because it's the name of the plugin. But if you pick a different label, we can see the French proposal by Bruno which he translated a day ago. Yeah, and this is basically the entire way a translator would go to select a string you want to translate, put in the translation or work with crowd and smashing translations if they're accurate. And actually they're very, very accurate in very, very match cases. Click the save button and you're done. You don't need to use Git or GitHub or anything else here at all. The plugin maintainer can provide additional information like we just named through a screen just for example to show where something is used in Jenkins because not everything is always visible or sometimes you have to click for different menus on the Jenkins web interface itself to find where something is used. For example, if it's used in help strings or something which may be a bit difficult. So yeah, that is one way to streamline it a bit. This is basically what translators do. Then a plugin maintainer or a proof reader would go ahead and approve these strings before they land on their GitHub repository. The step to go here is actually the same step as a translator but a plugin maintainer can click on crowd sourcing and switch to the proof reading view. Here I can see all source strings on the left column of the table. And on the right column, I can see all proposed translations. In this case, this is for French. So I can see every source string, how it is used in the plugin and every proposal in this case of Bruno. As a plugin maintainer, I would now go ahead and review them and I can either approve them by clicking the tick and this is an approved string or I could say, hey, this isn't just, this isn't accurate or something or this doesn't actually fit or this context is actually wrong and go ahead and say, no, but I keep this up and leave a comment on it. So possible future translators are able to pick it up again. So Alex, could you go back to the approve one that you did? That one, the very first one you approved, can you still change it to be a French language one? Because I think in this case, it could be French language. Is it possible for you to even propose that as a proof reader? I think it should be this. Yeah, you mean like in this view? Yes, in this view. Yeah, kind of go ahead and type something here. Oh, okay. All right. So as a proof reader, you could alter it to be Ache, Ache, Ache, Elastique. Yes, you can still go ahead and make changes and save them right away. Yeah, and this is basically the set of proof reading. I would like to go back and pick a specific file. Yeah, now we have approved and translated everything of the messages to properties file. This was basically the step where the GitHub integration takes over and proposes messages underscore fr.properties as new file to the plugin repository on the Jenkins AI organization. So basically if something has been translated and has been approved by a proof reader or maintainer and a file is fully translated and approved as we can see here, it lands within the next 12 or 24 hours as pull request on the GitHub repository. If Mark goes ahead and triggers the workflow of the elastic access by hand. And I just did that. Yeah, let me grab the appropriate tab. We could go ahead. It's not done yet. So this is the one from earlier. There will be a new one that will arrive. Yeah, this is basically the integration. I have committed a few hours ago where I proposed the translation of German and approve this translation. As we can see here, we have the typical HTML syntax because it's an HTML file. Yet the syntax actually doesn't appear on crowd on itself. You just have to translate this file. Oh, I think it's just here. Let's take a look. Yeah, there we have our elastic access display name. The one we just approved, proposed by Bruno and approved by me does now land as proposal for a new PR on the GitHub repository of the plugin maintainer. In this case, Mark would go ahead and review this PR and merge it right away because we have already proofreader on crowd. And once merged and once merged, it would basically be available in the plugin repository and released within the next regular release of the plugin. Oh, I see, I've already approved it. So I approved it and I confirmed auto merge. So when it passes its CI checks, it will be merged. And now it may even be merged and automatically released. I don't remember the automatic release settings for elastic access. This particular plugin may not auto release on changes to localization. I don't remember. Yeah, we are not using continuously delivery here. However, plugins which do have the set up, for example, design library and many, many others. And if they use the enhancement label or localization label are basically released within the next few minutes once the PR has been merged. Yeah, this is basically the workflows shown once from a translator aspect and once shown from a proofreader or plugin maintainer aspect. Now I would like to go ahead and show how to actually get crowded to recognize these changes, these files. However, this is more something for plugin maintainers and it's not something a translator has to do or has to know. So yeah, let me go ahead and pick this one. A few hours ago, I've integrated my console column plugin with crawlin.jenkans.io. Yeah, basically, if you want to integrate your plugin with crawlin.jenkans.io, you have to add a couple of new files to the project. This, for the time, we have the actual action file and we have a crawlin.yml configuration file. The action file, we have the actual action file The action file is obtainable if you head to the actions type of the repository, click the new workflow button and it will be available here very soon. Once the PR are on the correct template suppository has been merged, you can basically go ahead here, click configure and basically commit a change right away. You don't need to copy paste anything else. You can work with our proposed sample here. This workflow is set up to run Chrome-based every 12 hours, which means every 12 hours, crowd will go ahead and pull new approved strings from crowd in or push new translation messages from your GitHub repository as we have set it up here. If you have set up this file, you need to make one minor modification. At the end of this file, we have the crowd in project ID. This project ID equals the project ID your project has on crowdin.jnken.io In order to obtain a new project on crowdin.jnken.io, we have made up a new workflow. If you are heading to the infrastructure repository, you can select a new help desk ticket category called, I think we named it crowd in projects, which you can use to request and the creation of a new project. It's basically has just a couple of files where you enter the repository on GitHub you want to integrate and list the users you want to have management permission and the infrastructure team or basically the car administrators will take care of it, create this project and report the project number back to you. You can also obtain the project number from the URL of the project. So yeah, once you have changed this, you're basically done with this file. Of course you can change it, change the commit message or change the pull request message if you want to let it say something else. This is just our default we are using here. But below, you also need to add a crowdin.yml file to the root project of your repository. That is where you tell crowdin whether translations of your file should go to where the source strings are and which files it may be, it may should ignore. Right below we have, we are using this setup. The source string tells crowdin where the source files of the repository are. In this case, we are localizing everything by default in English. So our source files are available in this directory under the proper ending with properties. In Jenkins, the localized files are going in the same directory as the root file. So if you have a messages of properties file one translated as messages underscore DE the properties you would want to ensure that the underscore DE properties file is not recognized as source file because it's already translated. Hence, we have an ignore clause here. The file name placeholder equals the original file name and the two letters code equals the proposed language. In this case, underscore DE would be this one. And the translation is the format how we want to form these messages. Here we are using the same placeholders again file name underscore two letters code. This variance that we keep our name of the file in this case messages again and underscore the letter code would be DE. That way we export a messages underscore DE properties file which is not recognized as source language. And the source file is the original thing. The bottom bar, here we have the project IDF and API token and we leave them untouched. They're just variables for the crowd in workflow integration. Once that is done and we have committed these changes we are already all set here. You don't need to add further files. Within the next step is to head to crowdin.jankins.io and go to your profile and authenticate the workflow. For authentication, we are using a personal access token scope to the project you want to integrate. You would go ahead to your profile, to your account settings, access tokens, create a token, give it a new name, scope it to projects and bind it to the project you want to use. If you click the create button the next window shows you the personal access token once. This output you put back to the GitHub repository because it is used for the GitHub action to authenticate with the project. If we head to secrets and actions we click on your repository secret and add the token shown on crowd in here and as the secret name we are using the string obtained from the workflow. In this case, the name of the secret is crowd and personal token. If we name it like that and put our actual token here and click the secret button we have secretly added our personal access token to the GitHub repository and re-referencing it in the workflow with this token, with this one with crowd and personal access token to not obviously reveal it. Yeah, and then we are basically outside that is the whole integration. Within, in this case, the next 12 hours the project swings with crowd in and pushes source strings to crowd in post translations from crowd in but you can also go ahead to the actions tab and trigger it by hand. If you don't want to wait or just basically want to go ahead and do that. If you have done that your project appears on crowd in the Jenkins that I owe with all languages enabled. In this case, that would be the console column plugin. These are the languages I enabled. And for example, here we have all column properties file and all properties file from the crowd on volume L where they should pick it up. This is basically the entire setup. The setup is a one-time setup. It means you just need to do it once. Once you have everything set have your path set and have your source and target languages set and have your strings and messages set. You don't ever need to update it again. Yeah, that would be the process of setting up a project. Just to mention it again this is only for plugin maintenance. This is not something a typical translator has to know or has to take care of. And so now that you've registered console column plugin Bruno could translate into French you could translate into German other native speakers could offer their translations into their languages as well. Yes, these are just a couple of default languages. I left enabled, but obviously and of course these are not all languages crowd and offers crowd and offer several hundred of different languages but I don't think we have that many translators and the current ecosystem to take care of it. So I just left these languages enabled by default. Obviously if someone says, hey, my language isn't listed here and or I want to provide this language the plugin maintainer can always go ahead and enable a bunch of different languages or remove once that nobody wants to translate. Yeah. Now Bruno could go ahead and provide a French translation for the console column plugin. Yeah, German isn't listed here because I have already translated it into the German a bunch of months ago. So yeah, but this worker would be available to oh, I see, just went ahead. Yeah, I had to. Okay. And Bruno's highlighting concurrent work now can happen, right? All of a sudden translations I received a translation just this morning from Chris Stern in Hong Kong providing a traditional Chinese translation for the elastic access plugin. And I did nothing, he contributed it or Chris contributed it. And with Chris's contribution that was a great thing to have. Hey, I didn't do anything and here comes the Chinese language translation of the elastic access plugin. Yeah. The more projects we have on our cloud instance the smarter cloud instance machine translation actually gets especially with Jenkins relative terms and makes localization much easier because so don't need to reinvent the wheel over and over again but can work with something that has already been here. Now, Alex, I don't see Jenkins core. I assume any guidance you wanna give us on we're starting with plugins for a particular reason or what prompts that? Oh, I think everyone can submit their plugin through the infrastructure help desk now because why not? We have the templates here. Everyone is welcome to join us and opt their plugin in. I think Jenkins core needs some special treatment especially because I think I countered it through IntelliJ a couple of days ago we have several hundreds of actual source files there in many, many different locations and partly translated stuff half translated stuff, super outdated stuff that is actually unused that should be cleaned up before we put it on here because there's basically no point in having something up for localization that is nowhere used as sourcing anymore. But that makes sense. So we've got more work to do before Jenkins core is ready just because we don't wanna waste translator's time translating something that ultimately will not be used. Good. Thanks for that clarity. But definitely makes sense to clean up core first and sort out everything that is basically unneeded in case I'm a ghost head and want to translate something and their translation basically lands in the trash can then because it's unused and provides nothing useful for us. So yeah, but we definitely could and should have core itself available here and probably guide new translators and contributors to use this over GitHub. Thanks very much, Alex. Thank you, thank you. This looks like a much better experience for people who are willing to contribute translations to Jenkins. No more property file editing, no more UTF-8, unicode escaping of things, no more complications hiding things into properties and figuring out which file to translate, where to create it. This simplifies things dramatically. Yeah, indeed. You basically don't need to know anything about localizing Jenkins views anymore because Crawlin basically takes care of it. And like you just mentioned, exporting stuff in UTF-8 isn't a pain anymore because you can't mess up anything any longer because Crawlin takes care of it. Well, and now maybe that'd be a worthwhile thing to discuss. Would you be willing to share a little bit on the history of UTF-8 in Jenkins property files? That for me is a surprising thing to realize, oh, oops, there's a complication here and how Crawlin has been so kind to help us work around the complication and make things much easier for users. Yeah, just a bit on the backstory, we had a case of Chris Dern providing a Chinese translation of the design library plugin, but it was exported as plain Chinese and not as kept as UTF-8, which Java 8 is not that lenient to load. Let me grab the appropriate PR to show it off better. Yeah, got it right here. This is basically the current translation provided by it. As we can see here, that's the title in the description in simplified Chinese. And this doesn't work out well in Jenkins, at least not yet, because we do not require Java 11 yet, not allowing us to use the newly added API in Java 9. So we had to work around this problem in order to still be up for Chinese translations, but still be able to support Java 8 until September this year. So yeah, because this Chinese renders as this in the Jenkins interface, which obviously is just gibberish and not Chinese at all. So we basically had to work around this issue. For the time being, Gordon implemented a custom solution for us to export stuff properly escaped in UTF-8, looking like this one. This is the UTF-8 exported string of a warning. As we can see, or not yet. As we can see, everything is prefixed with an inverted slash U and the appropriate code that is used to represent the Chinese character. And it renders basically like this one shown in the Jenkins UI. As we can see, this is properly proper Chinese simplified, having a few links here and everything looks great again. For the time being, Gordon implemented a custom solution for us to export these things in UTF-8. Thanks a lot for that one. And we provided the necessary updates to Stapler to make sure to no longer need that's when we moved to Java 11 and onwards. So we can properly use these normal letters again. Special thanks to CrowdIn for doing that. That for me was absolutely heroic. The Java way of handling in Java 8, these Unicode-based multi-byte characters is a little dismaying, right? The fact that we had to put them in with backslash U and the actual Unicode character sequence makes it very hard to read, but they did that translation so that the translator does not have... The person doing the translation does not have to do that work. It's done by the CrowdIn software at the back end. Did I understand right, Alexander? Yeah. The translator doesn't need to do anything at all here. If they are using the CrowdIn UI, Bruno has shown a bit before here, they will just type in their language, in this case, Chinese. And once the action exports these approved strings, they turn into UTF-8 and are properly encoded. So they are shown as simplified Chinese again on the Jenkins interface. Excellent. Thank you. Thanks to CrowdIn and thanks, Alex, for showing it. That's amazing. So were there any other... I haven't seen any open questions come in from our participants. Are there any other topics that you'd like to highlight, Alex, for us things where, where, hey, we should be considering this or that improvement? Yeah. For the time being, I've just opened it here. We are using the Jenkins infrastructure helpdesk to manage the creation of a new project. So plug and maintainer would add to the Jenkins infrastructure organization and select the helpdesk repository, creating a new issue and select current localization project. This issue template is pretty simple and pretty basic and helps us taking care of our repository. Someone wants to integrate and promoting people with appropriate permissions to be able to manage these projects. So could you, would you be willing to complete this one? For me, I have another plugin I need to add. Yeah, if you... Or should I do it? I mean, so add schedule build plugin because it's been in this and I inadvertently deleted it. So if you could, if you'd be willing to put, submit the request here, that way people can watch what it's like to submit a request here to please create a localization project for plugins. Yes, I promise eventually I'll get the git client and the git plugin included. But for right now, let's do the easy ones. Yeah, this was the proposed workflow. How is it in schedule build? Schedule, yeah, schedule build plugin. That's perfect. Okay, I think this is this one. And that would be in this case, that would be you. Right. And that's basically it. I think, oh no, no, there's one more actually. I don't know if he's a crowd-in user and at Darren, D-A-R-I-N. This is my co-maintenor. P-O-E. Yeah, we are using the GitHub username for that. Yeah, and this is his GitHub username. Just keep going, P-O-P-E. Oh, okay, yeah. Oh, the famous Darren, okay. Yes, that Darren, right, exactly. Darren is P-O-P-E. And it won't prompt you. If I remember correctly, he's not, yeah. So just submit that. Yes, that's the one. Perfect. And that's nice if I have other plugins because it's part of my morning routine, you know, doing a few translations to Walmart. So thank you for adding plugins. Yeah, this is basically the workflow. In order to be able to request the creation of a project, you just go ahead and fail out by dropping a link to the GitHub repository and the people who should have management permission on crowd-in. In the best case, these people have already initially logged into crowd-in.jankins.io. So they'll be able to enter the team right away. This is our code. If not, do I need to then submit a help request later? So Darren probably hasn't logged in. So we may create this. He doesn't initially have permission. I then need to ask separately later, hey, please add Darren. Yeah, for example, but we can also invite Darren through crowd-in by the way. Oh, okay. The process is similar, how you would invite someone to a GitHub organization. You can just invite them to a team on crowd-in as well. We have a question from Dira. How much is the demand for the translated contents? Can you throw some light on this as well? Thanks. Thank you for the question, Dira. So I can tell you how much more comfortable it is for me to read things in my native language. Of course. Yeah, actually translations are a major part of the user experience. For example, if you're not a native English speaker or don't use Jenkins Core at all in English and have it available in French or Italian or something, you often stumble apart plugin pages or fusing Jenkins itself, which aren't translated at all. So if you're using Jenkins Core, let's say in Italian, you basically have many plugins which either do not support Italian translations at all yet or basically are not up for localization at all, which looks out of place and is definitely much harder to use if you have different locates in one ecosystem. And crowd-in provides the streamlined solution here to be able to add your project with ease by being able to receive translation suggestions by everyone who wants to help out. So to give a past commercial experience, I worked for an organization that was selling very heavily in Japan. We were selling a mechanical computerated design system and the users there flatly refused to use something if it was not fully translated into Japanese. They expected everything to be translated. Now an open source project doesn't have the benefit of commercial, commercial cash-driven development. We rely on our community to do those kind of translations. So having a facility like crowd-in makes it much more likely that we'll be able to get those translations from our users compared to my commercial world experience. We spent enormous amounts of money being sure that we were translated into Japanese because our customers in Japan, if they saw an English word would send it back to us as a bug report, right? So it's intensely valuable and especially so in languages that don't use what you might call Western European alphabets, right? Because then it's disconcerting. You're seeing your Cyrillic alphabet or your Karakana or your Kanji or your Korean character, your Hangul character set. And then all of a sudden it switches character set and now you're seeing English. It's just not nearly as comfortable as having a localized product. Yeah, that is basically- That is basically- We answered your question. You're right. Sorry, go ahead, Alex. Yeah, that is basically the reason why we have picked crowd-in because it lifts all entry barriers or at least possible entry barriers for translators or plug-in maintenance or basically everyone who isn't familiar with views in Jenkins at all and allowing a handy and actual easy-to-use web interface to submit a translation proposal. Yes. To tell you the truth, I have tried other ways of translating messages within Jenkins in the previous weeks before crowd-in and it was not a really pleasant experience to say the least. So yes, crowd-in is much easier. I'm not that good at Jenkins yet. So I don't have to know Jenkins to be able to translate anything and that's super cool. And as a translator, I'm not alone. I don't know if you see that easily in your interface, Alexander, but there was one of the translation for your recently added plug-in that I was not able to translate because I don't know what this acronym is. And I'll ask you a question. And as a translator, I think I'm not alone. You will see it. You will be able to answer my question. So it's not just a process of me and myself and I just stuck in a room translating. I can also interact with a plug-in maintainer who could help me finding what the issues are and trying to solve them. That's pretty cool. And there is another thing I wanted to address which is not that cool, is that there is no glory in fact because the pool of crest that will happen will not be in your name. So so long for the glory of having contributed directly within a GitHub repository belonging to Jenkins. But anyway, I'm super happy to be able to translate things for Jenkins plug-in so easily. I mean, that's a no-brainer and I really love it. And that's all. No, go ahead, Alex. Yeah, thanks for your insight Bruno. That is definitely nice to hear and possibly we have more translators for different kinds of plugins or core itself available soon. Now, there's another piece of work yet remaining. The work that has to be done by plug-in maintainers who need to actually internationalize their plugins, right? A number of the things that I do embarrassingly, I've only done it in English and I didn't even make them translatable. So I didn't internationalize at all. And so I've got some work to do on plugins that I maintain just to make them internationalize so that their messages and their help can be done in translation. And that part, now there are instructions online on how to do it, but it's work that I have to do. Yeah, as of the time being we have provided a few guides on Jenkins.io how to integrate your project with crowd-intern Jenkins.io, how to prepare it that you're able to use internationalized strings, how to export these strings back to GitHub and how proofreading basically works to cover up everything we just talked about in a text form again. But yeah, like Mark just mentioned, your plugin should be internationalized meaning working with the key value relationship in files. For example, you have a key in the jelly file and have the appropriate value of this key in the properties file. As it is seen in many plugins and the console column plugin or the design library plugin already. Yeah, like we can see here, well, let me move this here. The key value relation in this case is title equals in the Chinese translation and description equals in this one. And this is basically the part you are using in the jelly file itself. Now, Alex, would you be willing to go to Jenkins.io and let's look at that page that documents it so that people are aware where they go. Yeah, let me take a look. Let's hope I'm not subject to caching again. Yeah, should be available on documentation and I think. Yes, so documentation developer guide and then under how to guides. And at the very bottom of that page is the Jenkins crowd in integration. Yeah, these are a bunch of guides we have just published to be able to read everything at text time again. How to translate something, how you proofread something or how you set up a crowd in project, how you create a personal access token, how you authenticate the action, how you work with the crowd in file. And yeah, or for example, how you translate a plugin through crowd in, have a breakdown on the web interface again, what actually everything means here, what the colors mean, what the symbols mean and how you actually propose a translation, how you work with machine translation, suggestions and translation memories and how you proofread existing translations from a proofreading a plugin maintainer aspect. How you can switch the view, how to approve something, how you propose a difference translation. Yeah. And at this part of something has been approved, it lands as pull requests on your GitHub repository. Thanks Alex, an excellent job on the documentation. Very, very good. Thank you for doing that. Yeah, for the time being, we are still using the helpdesk repository for that. But I don't know how I pronounce your name, but had the idea that we integrate this with the repository permission updater and utilize the crowd in API to create these new projects automatically. Bruno, would you help us with the correct pronunciation? Yes, my pleasure. Hervé Luneur. Thanks. Yeah, he basically proposed an alternative approach of project creation, which I have drafted on the repository permission updater, short RPU, which we are using in Jenkins to update permissions on the artifactory or GitHub, for example, and integrate a new sequence here, plugin maintainers could add themselves to and let the repository permission updater create a new project on crowd.jk and .io to propose a more automatic solution instead of doing that by hand through the infrastructure helpdesk. Yeah, which I think is brilliant. This would be a really great addition sometime in the future that instead of, or when a new plugin is created or when a plugin maintainer wishes to add crowd in support, all they would do is submit a pull request to repository permissions updater, adding crowd in managers and their username or the username of the other administrators. Yeah, this is the proposed workflow of what Mark and I are doing at the moment. We are basically creating a project and creating a team on crowd in .jk and .io adding these people, they are creating the project, adding the team to the project, that's already it. The process isn't super difficult and doesn't actually take a lot of time, however, having it available automatically is definitely easier for users. I mean, even easier than the helpdesk ticket because if the PR is merged right away there's no more work need to be done here. And I am pleased to announce a new release of the Elastic Access plugin has been delivered that includes the change. That plugin happens to use a continuous delivery mechanism that's a little different than other mechanisms but if you go to Elastic Access plugin you'll see that a new release has been delivered. Thanks so far, Mark. And its key new feature is new crowd in translations. Fringe, yeah. Yeah, as we can see here plugins which are using continuous delivery to be released can release these mutualization strings actually within just a bunch of minutes and don't need to be released by hand again. Just need to make sure your pull request is labeled as enhancement or labeled as localization. This was a recent addition from me to the Maven CD action to ensure that this label is actually be recognized by the CD workflow. Yeah, thanks very much, Alex. If there are no other questions I think we may be about at the end. Were there other topics you wanted to discuss, Alex, before we close? I think we went over everything. We have the documentation of this and the text form available on jenkins.io how to create a project and how to manage it. And I would say if there are still more questions or someone actually needs help or is lost at some step you can always hit up on community.jenkins.io or use the mailing list or use the Gitterchats. We will be able to assist you there if other help is needed. Thanks very much, Alex. Yeah, so a recording of this will be available on the Jenkins YouTube channel and will be posted to community.jenkins.io. Thanks very much to Alex and to Bruno for their contributions. Thanks in advance to all the rest of you for your contributions that are coming in the future. Thanks very much. We'll call an end to our session. Thanks again and see you soon. Thanks, bye-bye. Bye.