 Welcome. Thank you very much. This is the Doc's office hours for Jenkins, European, and it is Thursday of May 19. For today, we've got an agenda already planned out. We have localization and internalization with Alex, he ends up joining us. We have the June LTS change log, an upgrade guide and blog post, which I've added, and we will discuss further. The require Java 11 Epic and the tasks associated with that. Basil's done a great job of compiling all that, putting that together and creating the tickets for us. So we'll go over that and see what else we can do for them. And finally, our she code after Africa contributes on. It's getting close to wrapping up Mark way it'll tell us more about that. So first off, it doesn't look like Alex is here yet so. I'll give a quick status report Kevin, if that's okay and then. So this, this can be really a nice story to tell that we now have eight plugins on crowd in dot Jenkins that I owe that are managing their translation process with crowd in. And Bruno has been a great contributor there contributed translations into French language for many of them. It's looking really good. I've got an open question that I need to discuss with Bruno further, because this is a great way to contribute to an open source project and would be a really nice story for Hacktoberfest, however, the Hacktoberfest counting system requires that they be done by pull requests, and the pull requests here are being submitted by a bot that collects multiple changes for multiple contributors into a single pull request so as it sits now crowd in is not a great choice for a hacktoberfest hacktoberfest contribution. But I want to talk to Alex about it in case he's got some idea of ways that we might be able to make it fit better. And that's in part because of this how to encourage translation contributions. I'm wondering as a separate story, is there a way we could motivate and inspire people to contribute some form of leaderboard or some form of thanks thanks to our top five contributors showing in the crowd sourcing ideas so those are topics for then as the very last point, Darren Pope and I are going to do a live stream probably one hour on internationalizing Jenkins. I've learned some things about what it means internationalize a plug in, and we'll use those to talk to people about how we used to do internationalization and how there are slight refinements that we can do now to make it work better with crowd in. And he and I will probably do that within the next one to three weeks. That's it for me. Great. Thanks Mark. Any questions on that for move on to the next topic or. Okay, I have a question. Very basic one maybe that's regarding internationalization and localization. When I used to do some internationalization with Java only, we could go up to internationalizing images or HTML files, not just with, you know, the sentences translated but also the look and feel and some will Jenkins go up to that, you know, maybe changing the images if that ever makes sense, or, you know, changing the way it is read from left to right or right to left. Good question and as far as I can tell right now there isn't. So HTML files can and are included in the translation process so so that part yes, but in terms of images, or, or what what I might call deeper, deeper changes behavioral changes Jenkins doesn't really have support for right now. Okay, thank you. Any other questions before we move on regarding this topic of how do we encourage translation contributions. I really liked the way that the old translation support plugin worked in the sense that it provided a link at the bottom of every page to submit translations. And at the time, they were collected with a central server which is no longer active, but the brilliance of that was that if someone had this translation support plugin, I think it might have been called translation assistance plugin and I don't recall the exact name, but the brilliance of it was that it had a link that you could click on from the Jenkins UI that would immediately allow you to start filling in translations and submitting them to us. So, I think it would be, it would be cool to kind of take to think about that idea and think about how we might be able to apply that to crowd in, in a way that we could maybe put a link at the bottom of the Jenkins UI that might direct people to crowd into just immediately start filling in their translations because that kind of lowers the barrier to entry and I think that was one of the reasons that the old system is very successful, because it lowered the bar the barrier to entry in that way. And for the timing, we only have some plugins, some Jenkins plugins available that we can translate for the time being, the core is not yet entered into the crowd in system. And the thing is, we could have a link, as you say, for existing plugin which are already registered within crowd in and for plugins which are not yet we could add some kind of another link that could start something at desk or maybe that's not such a good idea because of the spam we could get that triggers something that we know that somebody wants to help with the plugin which is not translated yet all the parts of Jenkins, which is not translated yet. That will be really helpful I think. Thank you for this suggestion Basil. Yeah, so, so to work off that idea. Could you envision that this, this facility were somehow detecting hey I'm running in non English language. And I'm this message that I'm seeing on screen is in fact still the English language version show them a choice to go somewhere to help convert it I think I see your point, muscle. That sounds very attractive. Yeah, I mean if you, if you look at the plugins, you don't have to do this right now but if you look at the plugins website for the translation assistance plugin or whatever the name of it was they have a screenshot. And the screenshot shows the kind of the old UI so there's a link in the footer you would click on the link, and it would give you a bunch of strings, kind of like the crowd in UI does, you can just hit submit to submit them to a central server, which is now shut down. So I think, you know, the idea would be we just give people that link but instead of our own user interface, it would go to the crowd in one, and then they could do the same thing. But you know we'd have to be able to detect whether that plugin is using crowded and where to direct them and things like that. And though but those are in fact solvable solvable I mean in context I know that the little subsection of help that's being displayed is coming from a specific plugin because it tells me the plugin that contributes that. And so that kind of information's got to be available I think it sounds very interesting. Yeah. Good. Alright, thanks. Back to you Kevin. Okay, so if there are no more questions on that move on to the junior LTS change log upgrade guide and blog posts. So I submitted the public quest last week for the junior LTS. And I'm currently putting it together for the blog post about the SVG replacement based on Basil's feedback in the request itself. I'm going to be going over that with Mark a little after this to just get some more structure to it and take a look and see what else I can add. There's still a little bit of the format that I want to make sure I understand and have ready to go outside of that though. Thanks. The feedbacks being given. We're getting a lot of traction. There are a couple of other tickets that are linked to the SVG replacement item. So, just looking through those getting further information from there as well and making sure that I have a full comprehension of everything prior to writing. The change like PR needs review and refinement. Yeah, that that was sort of my my voice on the my concern that it's if you if you let's see and I don't think you can even view visualize this one but if you go to the. Oh, I'll have to put it into it. If we were to look at this in the visualization view were it available what we would see is 1520 or more UI improvement items as individual line items that are each one by itself doesn't look terribly interesting the bigger picture is that there's a major UI improvement and I'm not not yet settled on what the best way is to express that in this in this change log. Okay, great. Thanks for clarifying mark appreciate it. Would it be good to just group them into themes and write one paragraph about each theme for maybe a handful of things like three to five themes for example plugin manager improvements. Configure project improvements or things like that. Yeah, that that might be that may be the technique because what I detected three or four themes, and actually group them in the poll request by those themes with a comment above each so I may I may experiment with that just as an alternative Kevin because I'm wrestling with this one. The, this is a cool release it's got some brilliant functionality in it and the change log sometimes obscures it by being too detailed. Got it. Can we add screenshots to it because that would make it even more. Well, it might not be possible. We, I don't have a way to do screenshots but if we want that we could certainly do a blog post that highlights this and then, then we can do the full story right and that maybe we've certainly done. We did a full webinar on 277.1 when we did the tables to divs transition, and we could do the same thing here as a blog post and a webinar on. Hey look what's coming and then we can talk high level we can show pictures we can demonstrate. And that may be the thing to do here is just admit this one is large enough that it really needs a separate webinar. That makes sense. Any other questions for move on to the next item under the June LTS change law. Okay. So, again basil created the required Java 11 epic and documentation related tasks. So right now the first week releases scheduled for June 21 and the first LTS to require Java 11 looks to be September 2022. And, and in that regard, these are the four document tasks that basil created. He's assigned them to himself, but there are a couple here that I might be able to take over or help with just due to what I'm going to be doing my experience and everything else. So I was hoping that you'd be able to kind of just take us through those. And if there, once we get through those, just, if I have questions or anything like that I can ask them for and get some better insight. Yeah, absolutely. Sounds great. Great. So Kevin if you'll just click the links for each of those. I think that'll give us a vehicle for Basel to get and start from the very top. Oh, yeah, okay. Bottom one is fine too but for me that top one. Yeah. So, so this, this is referring to the changes in the packaging repository. And these pages are visible. If you go to Jenkins.io and click on the download Jenkins link it'll take you to a list of packages that we build and publish. And in the footer of, or sorry, the header of that page is header dot HTML. And the link has a list of releases and the minimum Java version that you could, you could also find it in the UI and on the actual website there. Yeah, exactly. So somewhere on this page. I think might be, it might be if you click on one of the, one of the packages like, like for example I think if we, if we can't remember where to find it. Kevin, going up to going up to Ubuntu slash Debian on either the left or the right hand side. Yeah, yeah so on this page at the very bottom it says, you know 2.164 requires Java 8 or Java 11. So, basically that list needs to get updated to show the new requirement for Java 11. So there's a complication with this page in that the code you're looking at to generate that text. It's currently the same HTML file for both the LTS and the weekly. So that's really the difficult part of this task is to figure out how to show something different for the weekly compared to the LTS so the URL we're looking at right now is slash Debian. But there's another, there's another URL mark probably remembers offhand that shows the LTS download link. For example, I think you could get to it if you go back up and then go to the page for the stable. Yeah, so left hand column. The left hand column. Yeah, there's a button to slash Debian. So on that link that shows you the setting that shows the same information down there. So the challenge with this to figure out how to keep that the same for this page but to change that text for the other page for the page for the weekly release. Do you see the point. Yeah, because the LTS is going to come out after the weeklies have already been coming out. And so we have to make sure that the weeklies get updated and show the relevant information but at the same time the LTS will be able to require that until it's released or until we get to that point. Yeah, so I think this would have been a trivial, just updating one string in one file, if it weren't for this complication. So, I think it could just be done by, you know, copying and pasting the text or finding some way to include a different string a different page. I haven't looked into it very closely. So something to that effect. And actually, there is a little bit of JavaScript available that would apparently allow a page to dynamically change its content based on its URL. So we may actually with a little bit of JavaScript embedded have a facility to do this. Wonderful. I have no idea if it works I'm not a JavaScript coding but Mark is it something that we'd be able to work on together or check out or I think so. We can certainly toy with it to see because you need to know how to how to modify this and and Basel's right on the weekly side we on both sides we want to accurately describe what the version requirements are it would be better for this page the stable one. If it gave stable version numbers instead of just giving weekly version numbers right the reader of this page doesn't know that 2.54 was some was followed by some LTS sometime later they're they're thinking LTS. So it's a good, good excuse for us to do it in general. Great. Thank you so much. I appreciate walking through that one. Is there anything else on this specific date or on this one that you want to mention or is that everything. That's all. Okay, great. Thank you. Okay, and then we'll take a look at the user documentation updates as well. Yeah, so this, in this ticket I went through basically did a grep through the entire Jenkins.io repository looking for any place where I found the string Java aid JDK aid jre aid, anything Java related and the number eight. At a high level that's not, maybe not the best way of going about this because what that shows is things that are incorrect that need to be corrected but that doesn't, that process or that methodology doesn't necessarily highlight things that need to be added to explain new things. So that's the same methodology I used for system D. And once I worked on that mark very correctly pointed out well it's not just matter of correcting the now incorrect pages but also adding new pages about the system, the new system D functionality. So we worked on that together to not only go through this process but also to add new content. I don't think it will really need any new content about Java 11. I don't think Mark has a different opinion but there aren't really any new installation requirements or management requirements so I don't believe that we would need to write any new content here apart from just how to upgrade and we already have a page for that. And it's even linking to a YouTube video about how to upgrade. So, I think that all that's needed is to just update everything that's going to be wrong to the correct values rather than ready new content. What about that Mark or did you think that we need new content here. No, I think you're right. In the main, if we discover something where we're missing content. We should be ashamed of ourselves because we've been shipping Java 11 support for over two years. Right, so if we find something missing it's not a new missing it's wow we should have had this for a long time. Yeah, so with that point aside, all these bullet points are just going through the existing content and finding any places that need to be updated. And the, the, the general theme here is, if it says Java eight or 11 to simply change that text to say Java 11 and there, there are some places where there's two sections, a section for Java eight and a section for Java 11 so the Java eight section can just be deleted in those cases. And, and what one thing I noted in this ticket is that a lot of the times the wording is set up to introduce a contrast between these two sections. So, a mechanical removal of one section might still result in an awkward flow of the text. If the text is setting you up for a contract and then you only get one half of the contrast rather than the two, the two sides of the contrast so one thing I noticed as I was reading the messages was that if I was going through and mechanically deleting the Java eight sections that I had, I would probably need to reword some of the text a little bit to now read smoothly under the, under the assumption that there's no contrast being made anymore or something now. So, so at a high level it's a very mechanical change but then at a more low level I think there might, there might be some areas that just need to be phrased more smoothly to deal with this lack of two, two items being contrasted and that, that's probably the most objective part of this, this change. And the other subjective part of this is this. Again, this perennial issue with LTS versus weekly, because there's only, we don't have branches in the Jenkins.io documentation and there's only one primary branch that shows the latest version of the docs. And I think for system D, we kind of took a compromise approach where in some cases we just changed the page to refer to the weekly version and decided okay, we're all right with this not being very accurate for a period of three months until the LTS is released. And if the, if it's some very minor section of a minor page, it might not be worth spending too much time to, you know, write the page for to describe both weekly and LTS and then go back in three months and revise that again it's a lot of work to do that. If it's a section of a minor page, that effort may not be the best use of time. But I think for system D for the, there's one major page that we, we did, I think edit that to describe both weekly and LTS, because in one case, and in the main page about managing Mark felt that it was important to have that page remain accurate for LTS, since it was the primary discussion of that topic. So that might be necessary here as well if there's, I think there is one primary if you scroll up. There's one primary page about Java. Yeah that the very first link, you know requirements slash Java dot a doc. I think that's really the main primary documentation page that describes Java support. If any, if there were any page where we do that extra work of describing LTS and weekly and then going back and revising it, it would probably be that page, rather than for example these other obscure pages like Jenkins command parameters dot a doc which has a section of the very one about these old Java versions that might not be the highest priority to go and rephrase that for LTS and weekly and go back and update it in three months will we probably be okay living with that page just being slightly inaccurate for LTS users for for two to three months or three to four months. But to to further support what Basel is saying, I think it is perfectly okay for us to just like we're doing with the screenshot project. We're taking screenshots from a weekly version to 346 or later, because that will be what LTS looks like in the future. And we've accepted for the screenshot project that for from now until the June LTS that screenshot is not quite accurate. In most cases it's actually still better than what we had before than what it's replacing, because what it's replacing was so old and in this case, most of these with with a notable exception that that Basel noted maybe the first first one. I think it's perfectly fine if they just act like Java eight is no longer supported, because we don't want people doing new new installations and new works with new work with Java eight. Even if it is still supported we don't want to inspire them to use it. Right and where the end goal is to have everyone on Java 11, pushing a narrative where we're kind of still supporting that is just going to send the wrong message. Exactly. Yeah, so I think it's, it's safe. Kevin, when you start looking at this one if you're willing to look at this one that that there are places there where you'll just delete entire chunks that are referring to Java eight. And we accept that in the short term. Hey, we're not admitting that we still support Java eight in this aspect. Yeah, no, and I feel absolutely capable and comfortable taking on those two documentation tickets helping out updating that stuff no problem at all. One question I did when I asked Basil, as far as the original value versus new value stuff. I mean, is this kind of just where you were marking down what changes you found needs to be made or are these the exact changes that should be made, I guess. No, this is the, this is the edit history of the, the JIRA ticket itself. I basically, I wrote, I wrote this issue description, and then after I had finished writing it. I wanted to add an additional note at the bottom about this, this perennial issue of LTS versus so I went back and added some extra text, and that's, so that's what you see there. So when I'm when I'm browsing JIRA, I usually hide that view and just look at the comments view in order for me not to say I'm normally not so interested in the edit history of the description. But it's useful for me when I want to go back and see someone made an edit what the original version is. I don't think in this. I might have done better in this case or just add a comment with my note whether it's edit the original description but either way I don't think it matters too much. Yeah, no, and that's fine. It was more my curiosity since I was just looking at the ticket really kind of in depth for the first time off Jenkins JIRA. So, yeah, so I was more my curiosity of what the all meant in this case and if those were actually part of the needed changes or not so thank you for clarifying that I appreciate it. And GitHub to there's a way to look at friendly comment and get up this way to look at the edit history for that comment as well. So, I think that that's mostly just a matter of the tool, allowing you to look at the edit the edit history and sometimes that's very valuable valuable for me because people will sometimes paste stuff into JIRA and when people go and edit it they sometimes lose the formatting. So it's sometimes valuable to be able to go back and see how it was originally formatted before someone made an edit and messed up the formatting so that's what I that's what I use that feature for the most. Got it. Thank you. Appreciate it. Okay, and then the other two tickets battle where the upgrade guide and the was the last one the blog post that I have. I didn't fill in any descriptions in these yet or it's not yet, because I was fighting on writing them myself, but few, if you want me to discuss what I had in mind that could do that. If that's, if you wanted to use this meeting for that purpose. Mark, if you want to feel that when I'm not sure on that case. So I have no objections Basel but I trust also what you're going to describe will be. I've loved your past blog posts, the guava post and the system be posts they were both brilliant. For this one I'm going to try to talk about the nature of this migration because it's not it's not a it's not the usual Java upgrade for like we've done for Java seven to eight and before that six to seven. You know Java 11 introduces a lot of incompatibilities. So I think I'm going to try to explain what those are and what that means to administrators. One of the big ones is this removal of Jack's be which affects Jenkins the most. But more generally kind of reflecting on the, the, the evolution of the Java community and how 11 was a release that broke compatibility and some ways that were unprecedented. And the same will be the case for 17 so kind of explaining to administrators who might not be familiar with Java programming on a day to day basis that you know this is not, you know that the community has gone in the direction that is different from some of the past releases and I think explaining that in a to a target audience of Jenkins administrators who might not necessarily be Java developers themselves. I think that's probably the goal of my blog post. So I'm hoping to kind of cover that, that topic, as well as the usual how to file issues and how to upgrade your plugins and things like that. So, great. So for the for the upgrade guide it's just going to be the, the how to file issues and upgrade your plugins portion of the blog post. Just repeated. So that's what I'm going to start writing that today, hopefully, but I plan on sharing a draft in these tickets, I'll probably write it in Google Docs and then share the draft here. And, you know, I'll be happy to get some people to read the draft and to leave comments on it. So instead of getting this information to the users, the blog post will can certainly be highlighted to the users as a link from the June 21 change log saying hey here's this. We don't really have an upgrade guide for weekly so I'm prone to say we'll point them to the change log from the change log to the blog post for the weekly and this upgrade guide will be mostly for LTS is that does that work for you. I think that's what we did for Guava, but if we didn't then we should have because it's great. Okay, great. Thank you. Thanks for the clarity. Thanks so much. I appreciate all of that. And I know we're running up against time. So, Mark, do you want to just quickly go over those you go to Africa. Yeah, this is a one minute update, it's that the screenshots update project project, the screenshot updates project has surveyed the Jenkins.io website, www Jenkins.io looking for what pages that need a screenshot update and identified them and they did a lot of them, and the ones that they didn't do are still in our list. So we know to do them. So nice, nice help there. The inclusive naming project had actually already touched the Jenkins documentation long ago, well before she called Africa, most of the all the pull requests from this change, this particular project were to specific plugins. So, good work. Thanks to them. That's it for me. Does anyone have anything else before we wrap up for today? Nope. All right. Thanks we can wrap up now Mark for end recording.