 It was the agenda somewhere actually. Yeah, that's what I'm doing right now. It's a dynamic agenda. Can we start with introductions? Yes, of course we can. Yeah. Thank you for volunteering. I work at Boku, which is a software consulting company based out of Boston that works on the eCMAA compliance to it as well as other things. And Leo and I are co-editors of the eCMAA 402 internationalization extension to eCMAA script. As of recently. I haven't read the whole thing yet. Adam, I work at LinkedIn. On the side with a lot of my time. I'm the com com driver for notes. I've been working with LinkedIn with one foot in the open source space and the other foot in the corporate front-end build system. It's been helping out a lot with website redesign and helping to illustrate other parts of the community design. Thanks. I'm Chris Mills. I am the content team manager and content lead for MVN over at Mozilla. Nobody turned up to my session. Hi, Emily. I find it interesting and fun to work on JavaScript localization projects. The message format is one of the projects I'm in today, which is now the JS project also make plural. The internal plural rules polyfill is mine and recently I've started messing around with the fluent project that Mozilla has set up. I have been hanging around occasionally in the 402 monthly sessions, but not for a couple of months now. That's how long you've been attending, so that's how long I've been attending. It was terrific actually working on one of the things for internal plural rules, the polyfill for that, to hit one of the things that is in the spec because I was messing around with it. The way that you can take the same object and pass it to multiple different constructions and it just works. It's semi-magic. The same options of it. Hi, I'm Dhruv. I've recently completed my graduation in about seven to eight days. I'm from India. I've been involved in the website redesign and internalization team. Also, I'll be joining as a software engineer. Also, I'll be joining as a software engineer in the front-end engineering team at Clear Tax, which is one of the biggest or say the biggest platform for online taxi fillings in India. Hey, I'm Ben, the most organized person in the world. I'm Ben. Hey, oh, hello. Hello. Hi again. I work for InVision, the design software prototyping company, and I am a part of the community committee for an OJS, work on various initiatives, including internationalization. And so that's what brings me here today. And yeah, really exciting things in the design world and really exciting things in internationalizing all the things for node. I'm excited to have Dan here and Steven and Felix looks like Felix is online too. Yeah. It's really excited to get to know y'all and put some places to names and Very good. What did you all say? Introduce yourself. Introduce yourself. Well, I'm honored. I actually don't know what's going to happen here. I just heard about I-18. Wanted to just say what can I do? Awesome. Cool. What's your name? Honor. Honor. Hi, I'm Daniel Aaronberg or little Dan on the Internet and I work on TC39 on different specifications, including I can forward to. And so, yeah, would be if folks are interested, one thing we could we could talk about is like what proposals are being discussed and what things we should discuss. But Emily mentioned message format. And well, I guess that was sort of a different context. But to make internationalization work for node. You want. Oh yeah. Oh yeah. Hey, can you introduce yourself, Steven? Certainly. So I'm Steven Lemus coming to you from sunny California. You can see the sun in the background there. The sun is scheduled. So, and I work for IBM's Global Foundations team. And I work on ICU and CLDR libraries for with the Unicode project. And with JavaScript, one thing I've been involved in is getting node ICU to be on by default in node version dot 12. That was a kind of my first foray into JavaScript land, and I've also been involved with ECMA 402 committee. Awesome. Felix, are you on the line there? Would you like to introduce yourself? Yeah, sure. I actually just found this on Twitter and thought it would be interesting to follow along. So you don't mind that. No problem. That sounds great. Welcome. What's your story? I'm a software engineer. I work remote from Germany for a company in San Francisco called Source Graph. And I'm just a node enthusiast. Brad, that sounds great. Well, welcome. Excited to have you. Okay. So there is a agenda published if you go to the summit issues. So if you go to the NodeJ Summit issues, can everybody find that if they'd like and then go to should be at the top of the list since I just updated it. It's 164. Scroll down to the bottom there at the last comment I've published the agenda. As someone said, I think it was Dan, this can be a dynamic agenda. So please feel free to add. If you know the ones you didn't remember all the things. You know, there's enough here to fill up the next, you know, 45 minutes or whatever I feel like. So let me start out with the first part of this session here. So first I'd like to reiterate what this working group is about. Internationalization houses about three different concerns and one is translation so translation infrastructure for translation of textual assets like, you know, our documentation and our websites and how do we translate those into every language. We utilize the service, the crowd and service to perform as a landing for translators to be able to translate those. And we've set up the automated, the automation of putting translations in as PRs and to our documentation repository right now. So there's that translating our stuff. And the next would be INTL implementation in Node.js, which is where Steven and other folks are involved. And we'll get into talking more about, oh, Steven, did you, were you able to get the agenda? Yes. Okay, cool. Awesome. So I'll give some room to Steven to update us on that in just a little bit that we are excited to figure out how to support that team more and create ways to contribute to that initiative. And then we also concern ourselves with support for TC39 and ECMA402. We're excited to hear from Dan today on current status on all the things and figure out ways that we can, what the needs are and how we can support them. So first, I'm going to kick things off with the website redesign initiative, which is a community committee initiative. And we've been talking a little bit about our needs, but what I'd like to do now is create some action items for supporting new translations. So this first item was mostly for me, just to be able to connect on this. Yeah, so really where we're at right now is we've got translation infrastructure set up, but we need to target our, your textual assets, right? So we need to figure out how to consume that and then be able to publish it as an NPM module so that you can consume it. So I think we're just kind of just like a quick update and then we can move on to other things. But we, yeah, I guess the next steps are to set up an NPM account, publish, you know, publish the module and then update and version from there. And all this to say, you know, like I think as we create a project board for that, and I would love it if, you know, what's that redesign could keep in touch with that. But right now, like, what are your main concerns, you know? Yeah, so we aren't blocked from new features quite yet, which is awesome. Like this is, it'll be a blocker for launch, when that happens. We have a lot of feature additions to add if we're talking about tomorrow morning, first event tomorrow morning, website redesign, cool, talk about cool new stuff. And what next steps are. But yeah, so we're, we're not immediately blocked by it. It will be a locker for switching it over to the main domain when that choice was made. So it from what it sounds like that we're mostly going to be working in markdown files. We're going to be pulling from a number of sources, I believe is the plan. We don't want to break up documentation from the core or API docs. We don't want to, we're, we're not at the moment, all the kind of like, learn documentation, getting started documentation does live in the NodeJS.dev repo right now. But we may also start pulling in files from other repos. Like it would be nice if community page stuff could live in the concom repo. You know, try and keep documentation where living alongside the team that is working with it on regular. So we're hoping to take this kind of federated model of pulling content. And so we'll probably blown from a few different sources. And I'm not sure how that will affect like the module publishing for that. We then have the flip side of this problem where after after stuff is scooped in translated through crowd and and the module is published, we need to make sure that we're updated. So like we need something like greenkeeper or something up there just to keep, keep this thing auto updating on the regular if we do go the module route for just a minute. Congratulations. You're, you're pulling from multiple markdown sources, right? Correct. You will be yeah. Right now the pages it is just comes from website redesign that repo because it's literally just like a little. I guess that dev is a microsite that just has getting started documentation like starting to learn node, but we're going to expand it to have API docs on page downloads page. Community pages. So we'll be pulling from a number of different sources. Okay. Quick question just for my understanding to get in what should that npm module accepted to. Oh, yeah, so you mean the internationalization. Yeah, yeah. Hi, I'm so sorry. Not a problem. So what the what the internationalization repo is going to export as a module containing all of the just like one, one giant JSON blob with all the text translated texts so that it can be key to imported into the website or whatever the end destination is. So we may want to consider when publishing that module to like publish a different one per repo. Yeah. So that we're not like, if something bumps in the API docs, we have to bump the text translations for, you know, to learn documentation. Just keep kind of separation of concerns there is one option. Yeah, I'm sorry. Just yeah something to consider as you kind of craft how that gets split up. So we probably don't want. It's just like a giant monolithic JSON blob, because you can't do, you know, you know, a huge page page with the route splitting or anything like that. So, yes, it's kind of like per, per like one JSON per markdown file probably be best because I'm going to bump it. Because you're, yeah, you're using. Yeah, I mean, there's a guest base. Yeah, but yeah, the API docs are already being translated. Yeah. Yeah, we just don't have a publish. Yes. So actual action items sounds like our hook in Node.js.dev so we can get translations for that. Come with a process for adding new repos, the translation pipeline, getting the module publishing down the third action item. And then for the action item is mostly on the website redesign side of how do we auto update and consume translation. So that's on us after the module gets out. Yeah, that makes perfect sense. Yeah, I think we're going to have to figure out how we, yes, definitely. Okay, I think you covered all that we're going to figure out how we want to split it up. Consuming various or consuming disparate sources, I think, even I should stay in touch about how we're going to utilize that. You know, that's, I'm just trying to decide, like, should internationalization consume one thing from you, or should we target all those things to since they might all be the source of truth. Because like getting down to one source of truth would be nice, but okay, cool. Yeah. Great. I think in the interest of time and other stuff we can push along. Do you have any questions for me? Let's just work through, you know, technical details, not find out how to split it up. Great. I guess online. Yeah, totally. I also have other thoughts. I've been doing some documentation automation at work for this sort of thing. So when we do sync, when you do get to the point to where you need to set up like greenkeeper or something like that, let me know. Because there's definitely ways that we should hook it into releases, I think is the most important thing. Yeah. Cool. Okay, let's go down the line. Yeah, nothing like that. I'm going to refresh and just see if anybody dynamically updated this part in the complete word also. Okay. Or no, it's AIS. Wow, I'm tired. Okay, so great. Let's move on to intl. In Node.js, and that's specifically Steven's area of expertise here. And my only question here for you, Steven, as far as facilitating a I18N repo is something I've noticed is there's a few people in the intl GitHub team or like in the Node.js team. And it just seems like, you know, there's not a great window for contributors to join or to help with getting into, you know, supporting intl like in Node.js core. It seems like there's a few, like a handful of active people working on those issues. We have a tag, you know, that like for whatever. But like, how can we support that group more? I'd like to like create a contributing guide, that kind of thing. And what are your thoughts on that? And then maybe you can give us an update on how intl and Node.js is telling anything that you'd like to talk about. Sure. Well, the one thing to keep in mind is that the intl object in Node.js, its implementation comes directly from v8. So on the Node.js side, a lot of the items are more in the realm of kind of packaging and options and configuration. Specifically, data loading is the, is often been the elephant in the room, so to speak. And as far as the, as what's in Node itself. And so a lot of the intl contribution work actually happens in v8, which is where the actual implementation is for intl. And then the implementation of what v8 is calling is in the ICU project, which is the international components for Unicode. It's an open source C and C++ and also Java library from Unicode itself. And so a lot of the work happens there or in the CLDR repository, which is the local data, which is also from Unicode. The good thing is that the Unicode repositories are now all on GitHub. That was a migration just sealed there, just moved a couple a month ago, I guess. Pardon? Around the table, people are just saying, whoa, yeah, that's awesome. So it should be a lot easier to access the, what's happening with those projects and even open a PR into upstream. So I know if that answers your question. But in the, so for example, from my, my history, getting NodeJS into, sorry, getting international turned on by default in NodeJS.12 was a major milestone. Because the internal support was there before, but it was optional and have this build process. And the big, the big issue with that was data loading and data loading remains a major issue. There's an open, open issue in the full ICU project. I'm just going to try to type while I'm speaking here. Can you put that maybe as a comment? Yeah, I'm typing directly into that. If I don't click the close button. Okay. So I put a link to an open question on full ICU NPM. And it's kind of a question of whether the data loading for full ICU should, should move out of NPM and to W get, because we get a lot of concerns. There was one just, one opened just a few two days ago about the way the full ICU project actually works. And full ICU is just a loader. It's not, it doesn't do anything fancy. So anyway, if I could get some eyes on that, that one. But the idea is to basically pull from ice from GitHub instead of trying to do this hacky post install sub NPM install that full ICU does. It would be great to have a contributing guide. I think what I, what I had started on previously was something that tries to explain the stack basically where all these different pieces come from. If you're at the level of, hey, the date format is wrong when I try to print this date. You're offering an end up having looking at that at the CLDR side, for example. Yeah, that's great. No, I really appreciate your work on that and being able to like, I think that's something that we can involve and figure out how to. So the thing that I perceive is there's going to like looking for looking from sort of like a high level. People who are getting involved in this repository or in the work, the internationalization working group. We're just going to need a verbose contributing guide that basically brings to light everything that you just said, you know, like from sort of the ground up and yeah. And like, that's something that I would, I would love to do to focus on sharing like, I mean, even what ICU, you know, Unicode and ICU and CLDR and all these things are and how they work and how they support. You know, the intl object and that sort of thing. So I think like creating a contribution guide there that is sort of like a knowledge dump and then how to support Unicode would be a great place to start as well as. Yeah, I guess I just want to figure out how we can lead more help into what you're doing. So the more that we have all that conversation through the it and repo, the veteran I think. Right. Yeah, does anybody else have thoughts or questions on what Steven just covered, or potentially like to take the conversation in another direction based on intl and them. What about shipping full ICU always by default. Yeah, that's that there's an there's an issue open for exactly that. And I can, I can try to link that one in here. I mean, that that would be my preference. I mean, the terms English only are kind of grading, shall we say, I mean, that's kind of what I spend my career trying to avoid is English only. But the the the issue with that is is is just download size. But I'll put a link to the issue. I originally support that. But the other thing that we could do is have downloads provide both. So basically just however pre built binary. There's a small one if you really want to download a small one. But basically, you know, encourage people to just download just download the full full content. Do we have numbers on the bloat that we get? Yes. Yeah. It's bloat if it's a new basically double it doubles the size of the download. So yeah, it's like 40%. And I guess it'll get worse over time. And you'll get worse over time. I mean, 35 megabytes to 49 megabytes. Yeah, I mean, it is a real it's a real issue. I mean, it's not a it's not a trivial and I don't I just don't I'm not finding it at the same time. I guess I shouldn't search and talk at the same time. Yeah, but it is it is a I mean, it is a real issue and I understand I mean I run I run node on a Raspberry Pi and small devices. And so there are cases where where people are more concerned about the the disk space than than than actualization. You know, not everything has text content flowing through it. And you also might have something that's constrained in terms of of you know runtime footprints like if you're if you're running on a server and you're running for the disk space. You know, but so it's a it's a valid concern but I think I think there's some value to having the default be be full just so that it reduces the pain point because it's always the issue right we get these issues. Once in a while and node basically my date format doesn't work. And the reason is because you're not using English. What's the phrase the optics the optics aren't don't look great on that. What do I guess like it's like how many people are in this situation where they need to run node on like a Raspberry Pi or very constraint versus how many people are there that are just running now and development environments run that pack or run in a container or on the server where they don't really care they probably dump like tens and thousands of megabytes and note modules in that container. So, like, could like the default distribution haven't included. And then there's another binary distribution like a separate package like no dash no ICU or something like that. That is that the Raspberry Pi users can download and they would probably be aware that they they want to go for the minimal one more so than the people. It's not no ICU. It's ICU with English. Right. Yeah, sorry. What do this now. I think that personally I don't believe that an argument that Oh, because of our thing. We'd like to increase the size of node by 50% or 100% or something. That's not enough lie. But would it be conceivable or considerable to think about despecializing English and rather make it explicit that this distribution that you're downloading has just English in it and possibly provide in parallel with it. Yeah, a number of different alternatives. Yeah. Yeah, I mean that's just that's that's really just a question as far as what you know what we want to provide. You know, basically does this rise to the level of where we want to where where when people go to download that this is that this is their a B choice. I mean, effectively, they've got an a B choice. Now we just don't tell them that you're picking just think. Yeah. Right now they have an a choice. Yeah, English is good for you. What was your question. Oh, I asked do we we don't even publish a binary right now. That has the whole language back right. Right. We don't need to get that in. That's why man, they only have an a choice. I'm going to ask something that's crazy and comes from not probably having a full grasp of the tech involved but it's something that we can turn into packages that we can say if you have a use case for it, install it. Is there any remote possibility of having that type of often as a package. Yeah, yeah so basically there's a package called full ICU. And if you do npm install full ICU, it turns around and and installs installs the data for you as a package. But the thing is that the the data needs to be configured at startup time of node of the eight. So you can't you can't just include it. It's not really it's not really a module. It's kind of just a post install loader hack. But it's a way that you can you can get the data on your disk by adding it to package Jason. And this is documented in the in the in the read me. Yeah, on the agenda we have a link to full IC npm number 36 is my question about pulling from ICU GitHub release instead of doing a post install sorry having post install script just do a download basically like a just a fetch from GitHub rather than turning around and reinstalling a sub package that's not really a package. Yeah, question over here. Why you called that a hack because it's really there's no problem with it right and it's very easy for the programmers perspective right just to include it. I mean, I guess it's not like a regular node model but still it's it's very easy. Right. It's easy. Yes, but you can look at the if you look at the linked there's a linked issue install processes broken unsafe. So it's it is it's easy when it works basically. I call it a hack because it's not first of all, including it as a module doesn't actually get you data. What do you have something else as well. Yes, you have to start up the node. You have to start the node run time with the right option to include the data. And probably point it. Yeah, point it to the path. So, so, you know, npm install and require this module doesn't do what npm install and require a module usually does which is full in functionality. So that's hack number one this hack number two is that it's, you know, any package manager is trying to manage the transfer of dependencies. And this in this breaks that by what when it in post install it goes and installs another package and which package installs depends on the indianess and the version of node that you're running. So you can't predict it at, you know, original install time. So it's that's why I call it a hack. You know, it's a it's a convenience. It's kind of a convenience when it works, but it's it's it's not the best. It's not the best approach. I've used full ICU by like setting an environment variable in my profile that points to the global node modules full ICU. But then like once you upgrade a node version with npm suddenly notes fails to start up because it says like well couldn't find the ICU data billing. Yeah. And then you have to like on every upgrade you have to reinstall full ICU. And it just it would make way more sense if that was not inside the node modules folder or I don't know some somehow managed out of and not know module. Yeah, that would that would be good. And it really it could be it could go somewhere else easily mean node could could have a directory that it it expects. And we looked at there's an old issue to do to basically detect full ICU right eventually got closed just because, you know, really I needed I needed to figure out how to how to test it on all platforms. But all I'll put a link to that one also. Cool. Awesome. If you do that, that'd be great. Steven, think in the interest of time, we're going to move along. Yeah, thank you so much for your updates. Yeah, I really appreciate it excited to connect with you again and spin up, you know, some regular working group sessions again. I think the action item I'm taking from here, as well as to update our contributing guide and kind of work with you on that. Yep. Cool. Okay, let's spin over to what's going on with TC 39 in ECMA 402. I think the, you know, the main question that I, or the main, I guess, rhetorical question I'd like to answer more over time is how this working group can specifically support the 402 specification in a way that is useful and what are the priorities and how do we create a more meaningful collaboration over time. Yeah, so I could talk about the different ECMA 402 proposals that are under discussion. Also Valerie, I don't know if you're interested in presenting part of this or I didn't ask you to prepare. Yeah, go ahead. Technically, I believe we have 15 minutes for this session left. On the other hand, there's nothing else scheduled for this room. So I'm going to go to another thing after this. Okay. So the Intel API provides things like date time format where you put in a date and you, you can put in formatting options like including the locale but also including different like which components of the date you care about. And it gives you a string which is locale dependent. So there's, there's a bunch of ongoing, ongoing feature work to add more functionality to this, like, there's one PR that would add sort of like Chinese calendar functionality, but certain kinds of like informal related lunar calendar, sorry, not lunar calendar like 60 year cycle things, but also about millisecond digits. There's also with like number format there's ongoing work to add features like unit formatting or approximation with sort of millions or thousands. We also have new formatters like relative time format, which I think is shipping in node. I don't know which version. And, and thrills which which Emily discussed. And we're considering additional things like that. So format format range to show the difference between two dates. So these can be useful in internationalized web apps. When they're trying to generate strings, you can use the same functionality on both the client and the server. And I hope that web compat issue is is for the older features they're, they're very broadly supported and I think you can you can count on the basics of daytime format number format and collater being there. And then the other ones are more mixed. And so I'm wondering, like, do you face these needs in node and what what functionality might be useful for you. And one one high level thing is something like project fluent, should we should we eventually standardized something like, like that, which provides not just like a message formatting format string, which could unify a lot of things when you have to get translators, then you have some point where you're choosing a format and there are various different tools that use different formats and then but also not just that but also the format for the bundle, which would be used, which which has meaning both on the client and the server, potentially. And so project fluent goes in this area and this is sort of a frequently requested thing for x one four or two. So it's something that I'm kind of wondering what whether you have thoughts on these things. Also, just to say one thing about the compatibility on browsers is that really Firefox and Chrome and Safari are like up to date and have been really implementing until as we've been developing it and acma for two. But Microsoft is far behind. But as we know there, they are also switching out their JavaScript engine to the eight. So going forward, like soon enough will have intel and all the and all the browsers. Well, if you're interested in working on JavaScript engines, there's still a lot of exciting work to do. Like on the Firefox and like some of them are implemented, but there's still some gaps and it's all on a volunteer basis on Safari. I'm not aware. I guess Safari's not really working on new, but but they've come to the meetings there. They're calling the steps. So the great thing is that we have like buy in from all three browsers about this. And the person from Safari actually said that he'd be up for mentoring somebody who wants to come in and implement this. So if you're interested in getting involved in C++ coding. And if you're interested in improving web compatibility of these things, this could be a great place. I like how you said all three browsers. It's a very sad phrase, all three browsers. You know, that's the world. Chromium and through the note itself, they're not quite complete. I mean, there are still a couple of bugs still left there. The reason why I have an Intel plural rules polyfill that still is because the minimum fraction digits is still not working practically anywhere. Do you have an issue open for that? Chromium. Yes, there is. So I'd recommend writing an email to Frank Tang who's working on implementing this. He's last commented on that in February something. 8866, it's under the year. Well, I'll take a look at that. But it's like nearly complete. Like the gaps, plural rules, minimum fraction digits. Okay, that's something I've worked on in implementation. I apologize. Three browsers right now. Yeah. Yeah, so there's a bug. Oh, really there's plural support in Safari. Yeah. But I know, but I'm very, we should do that. So I'll look at the bug maybe at all. What do you say the bug number was 8866. Yeah, that this is quite detailed. Regarding message formatting, which he mentioned earlier. I don't think there's reason to do anything quite right away because fluid is early. The JavaScript implementation of that is still in 0.x. And there's like active discussion about the API for that. And it's the current API will change and break. And it's just this discussion. Oh, we're going to break it this way or that way. So it's not stable by any means yet. Okay. Oh, it looks like they're, they're making good progress on tissue. So maybe soon. I think, I mean, that one in, but did the plural rules in a fraction digits. I think the only thing that the now fluent, for example, is instructing use the internal plural rules polyfill, you know, to get that one working. Everything else from Intel. At least they're not saying that anything else needs polyfill. Okay. So, I think in the interest of moving along. Are there other proposals that you would like to. Also just want to hear what people, what do you guys want. So there's like Intel segment there, which is undergoing a bunch of potential change. Yeah. Do you want to describe it? Well, you should actually. Okay. Until display names is like a way for you to get certain things like the names of all the countries in the world in all the different languages, which is useful. You build a region picker. Well, yeah. You might have heard like, oh, the Unicode people want you to say words like code point. It turns out there's all sorts of different words that in any nationalization world you're supposed to use like region rather than country. I wasn't going to say anything but Yeah, you guys, you could probably walk us through a lot of these. Yeah. That's one of those. Well, not I mean, Antarctica is not a country, you know, I mean it's, you can take a. It doesn't have to get political to to describe that. Right. And then like, what, what is a language? So wait, I guess people are okay using the word language but language is okay. Yeah. And locales supposed to be a place right. Technically. Anyway, go. Yeah, it also includes like names include names for a bunch of these different things. And so that should help well on the web it should help reduce the, the binary size that has to be shipped over on the server. I think it has the same function, but it doesn't reduce the size of things to get shipped over but it reduces the amount of stuff that you have to the data that you have to pull off of. You know, some MPM module, and you can instead have this sort of higher level looking API for it. And it allows you to externalize issues like the Czech Republic being Czech. Yeah. Did that, did that happen. It's happened. Yes, it's happened. The thing is, they're always, they're always things like this, you know, Swaziland is now East Wattini and such. And, but even besides changes, just the, the, the load in, in translation, you know, there's, there's a lot of translated content. You know, my, I work with our internal translation processes and tools. And a lot of times people will have submit for translation. You know, a list of, a list of regions, a list of languages. And if you don't have to translate the same stuff over and over, you know, you can spend your money and time on something else. And display names. Yeah, I mean, there's a million application reasons for having display names really available, you know, through the. But it does exacerbate the megabyte problem. Yeah. I mean, like, until four or two, I mean, my forties having this problem because we're increasing the size of the browser. So that's an issue. Yeah. Yeah, I expect though that that data is already there for, for on the browser. In many cases. But like, like where Talking about the size of the download of the browser binary. Yes, but some of the, but the, the, I mean, if the browser already shows an except language pop up that says enter the languages you want to translate, then the browser already has a translated list of languages, for example. Yes. Yeah. That's getting bigger now. But I think so I think this is something that we've been looking into in this group and that for most of the ECMO 402 things, their data that's already in the browser stuff like units is not in Chrome, but then it's there and iOS. So then it's kind of okay, or moderately okay. They ended up reducing the list of units that are supported. So then the increment in binary size was less. You know, working through these issues is a really kind of pragmatic issues. People update their browser less if they have to download a bigger browser. I mean, arguably, of course, all of this is shared, not just being JavaScript engines, but the whole ecosystem of everything running on your system. So it is arguable that the data is possible for getting that data and making it available ought to be on an even higher level, effectively with the distribution, distro that you're using. Yeah. Arguably, everybody should be updating their operating system frequently. And that shouldn't be dynamic thinking. That doesn't that happen sometimes it doesn't happen other times Chrome statically saying it's ICU and in use some resources. And I don't know all the all the details. Yeah. It is an issue it is worth noticing issue it doesn't it's not it doesn't come for free. Yeah, I'm curious because I'm new to the browser implementation side of things like what kind of footprint is adding these names, you know, incur and then like in comparison like how big of an increase is that I can look through the notes and discuss it. And there were a bunch of numbers that we were talking about for this particular one for this. Insult display names. And there was one version where like the Chrome binary would have been 700 kilobytes large or something. And then they had a bunch of different alternatives calculated out for like, what if we left that this stuff, what if we left that that stuff. I don't know if that in. I don't know if that's what the question was. Yeah, it is. Yeah, like what's the data size and then like in comparison to, I don't know, like in this in the standardization process, like what I mean, how much data is acceptable to increase with something like Intel, you know, like what is there like a typical acceptable, you know, level or anything or the first time this is being discussed really. So, no, I mean, nobody notices and gets upset. It's usually like a different team that focuses on reducing the their binary size from the team that's trying to add the features. Yeah, at least that's how it seems. At least that's how people talk about it for Chrome and Firefox. I have no idea how, how in Safari infrastructure. I haven't got exact numbers, but you constantly see discussions in the platform team go, nice to shave this bit off. The graph is sometimes like creeping upwards in Chrome and then like they put in this deliberate effort and get it down and then it creeps upwards again, because just like writing any code at all increases the size. Right, sure. And I wonder if anyone has an idea of like a max size that they would like their browser to be depends on the application. To the extent that one does have such a size, it doesn't seem to be making it through to our discussions. And also, you know, we're always trying to add more, you know, a colleague of mine is going to visit the Chickasaw people and some other groups, language groups to try to bootstrap their language support of Native American languages. That's awesome. But but then but now you have new locales that are coming in basically so. Speaking of, I was just trying a couple editors the other day to see which one supported the most languages. And it was Emax. Cherokee was the one I noticed. That's awesome. Oh, the size problems to kind of make a parallel. Here's questions with size is acceptable. It sounds like a lot like the, the web question of what's the maximum size to progress with that. Yeah, like, yeah. And there is what's your application who downloading it. You know, opening up the app. So, you know, a lot of the solutions that the web does found for loading or playing a bundle. So it's like that might some of that logic for reducing initial size might go by here. Could you actually make no lazy load bits of the ICU data. As it needs to. Yeah, I had, I had thought about this. There's the short answer is there's no mechanism for that now. I thought about something like a callback handler, or if you don't find data, then call back to the user function and say, let me go fetch it for you. I think that's a good place to go fetch it without being configurable. Yeah. In the interest of time. We need a wrap up because it's three past the hour. But I definitely have some action items here that I'd like to take for kind of, I think it's more about making the contribution process for proposals and how to get involved less abstract to people who may want to contribute for the first time that I think that's really important and we can do that through internationalization, but just having this conversation has been really, really good to get visibility into it and I'm definitely learning a lot too. So I'm really, I'm really, really thankful for y'all to be here. If it's cool. I'd like to take a picture. And I'll hold the laptop. All right, sweet. Yeah, we see Steven. I can get a picture of the computer. There we go. Yay. I'm going back under the table. Actually, asparagus. Potatoes is where you go. Thank you. Thank you. I'll put a link on that lazy load question. I'll put a couple of months in. I mean, it's kind of the same as we have to website. We don't want to load every language up front. Same issue. That's easy because we already have all that. You don't talk about lazy loading. Hey, thank you for coming, Steven. You're welcome. I really, really appreciate it. Felix is already off the line. I would have said thank you, but I really, really appreciate it for coming so early. And thank you for always being up for doing rad stuff. So thank you. Okay. Yeah. Right on. Hey, we'll see you next time. See you. Bye. That is so cool. That's in my like hometown backyard. Yeah. Yeah. Yeah. Yeah. Super see that like being a thing that they cover in the press. Yeah.