Weston Ganger is a Software Architect and an Expert in Ruby-on-Rails. He joins the show to discuss "rails_i18n_manager". He starts off by discussing his professional career and projects. He talks about translations, some of his approaches, and  the challenges he encountered

Hey everybody, welcome back to another episode of the RubyRogues Podcast. I'm your host today, Valentino Stoll, and we're joined by a very special guest today, Weston Gagnier? How do you pronounce that?

 

Ganger. G-A-N, Ganger. So I usually say gangster

 

GANGER

 

without the ST.

 

Okay. I was going to say it's French for winning, right?

 

Ah, yeah, exactly.

 

Well, you know, welcome to the show where we brought you on today. You wrote this kind of awesome project, Rails IE10n Manager. For those not familiar with IE10n, it's the translation mechanism that Rails takes advantage of. Do you want to talk maybe? a little bit about yourself, introduce yourself, what got you started into this and where you're coming from.

 

Yeah, yeah, so I'm just a Ruby developer. I mean, I work in other stuff, but Ruby is the passion. I work for Braintree. So we have a Ruby on Rails stack and they love Ruby there too. So that's a really nice place to work. Yeah, I like doing open source. That's it's been. It's been a passion of mine since I started a gem back in the day called Spreadsheet Architect. And all I wanted to do was just take tabular data and output it as a CSV or xlsx or ods. And it should just be simple. I have an array of data. Put it out. And so you couldn't do that thing. And so I was like, well, this is weird. You know, what you think you should be able to do. You can't do it. So that started the long haul of, well, let's build open source libraries. Okay. That was fun. I just made the world a better place. What's next? So I got sucked into this whole open source rabbit hole.

 

That's how it starts, right?

 

That's nice.

 

You

 

Alright,

 

get

 

see

 

excited

 

you.

 

about something and then you're like, what else can I make?

 

Yep, yeah, exactly. So yeah, I'm pretty happy to continue working with the Ruby language, Ruby community. That seems to be my passion. I'm glad that it's there. It removes a lot of the barriers to coding. You're not caught up in things that don't matter to humans. It's things that do matter to humans when you're working with Ruby, which is, I find that to be a joy.

 

Yeah, I do as well. I have to think a lot less about the syntax,

 

Yeah.

 

which I'm not happy to dive back into JavaScript for.

 

Yeah, no, no, exactly.

 

So. Um. So what's your favorite open source project that maybe triggered your itch here?

 

Um... externally to me or of my own.

 

I mean either really.

 

Um

 

What got you curious like you seem to be very passionate about open source like what started that right? Like

 

I think it was creating that gem. Obviously open source is built into the Rails community. And so I guess you're just like, well, other people are doing it, how can I do that stuff? And actually I was a contractor when I first started out after getting out of school. So I had my own business and so not filled up with 100% of the time. you're trying to press in and get better, you know, grow and learn and be more capable in your free time. So basically I spent some of that time, you know, contributing and doing what I can, building out little projects. Oh, you find something that you can help out with. So create a repository for that. I think that free time was, I was able to pour a lot of that into open source. And I think that was beneficial to my career and gaining skills as a developer and stuff. So it was, you know, well, you're not just scratching an itch just to do stuff. You know, you're actually, you're building yourself to be better.

 

Yeah, totally. I feel the same way. I mean, I just remember, what was it? Spree is basically how I came about finding Rails,

 

Mm-hmm.

 

right? Where I was like, oh, I'm looking for like an open source ecommerce system, like what's out there. And I uncovered that. And then I was just like, wow, like people are just like giving this up for free. And I hear I submitted a It's kind of exciting once you like realize like what you're getting into.

 

Yeah, yeah,

 

Right.

 

it really is. It really is a joy. Yeah, and then you had the Salvatus-Sprit split. So that was always, you know, something to

 

That's

 

do.

 

right. Not that there aren't issues, right?

 

Yeah. Yeah.

 

So what got you onto the translation route? What kind of prompted this need for you to be able to manage all your translations?

 

So we had this, you know, working on a project and, okay, it needs to be translated into other languages. That's the requirement. And you're like, oh yeah, sure. I-18, you know, like, why not? Everybody does it, you know? Like, this will be easy, you know? Like it's standardized. It's just a normal thing. Let's go, let's do it. So you hop into the I-18 thing, you know, thinking, oh, I'll just manage these files and all as well, you know? Well, you get into the workflow and you find out that, okay, that's fine if you're a solo developer and, like, you remember to translate all your different languages. And there's just so many different pitfalls that you can miss when you're doing translations. And the particular one that started to bother me when we were working on this stuff, okay, Basically, we would just. When you have the file-based approach, you expect that to just only work at a small scale if you're just thinking about it, I18 for your first time. And so you might wanna reach for the database, what you're used to in Rails. So you say, okay, let's store these translations in the database where this makes sense. Now we can have a UI and... the product folks could manage these translations and all as well. So as soon as you go to do it on the database level, you now have performance issues. You're loading every little string from the database. There's all this question of caching and a whole headache of things you can get yourself into once you go to the database route. And so I wanted to find a way to do Oh, and even with the database route, you end up with drift between development and production. So your development files might say one thing and your production might say something else. And so you're like, well, in development, you know, the strings were all just as the spec intended, and then you get to production. And I think Starbucks had an incident recently where they said, hello world to everybody. So it's that sort of thing. Uh, well, it was fine in development, you know, I, it was, everything was up to snuff. Well, now there's environmental differences. And so you're working with two different copies of the software and. With translations that could be a, if you change the translations a bunch, it could be a wildly different experience in your app, you know, like two totally different experiences, uh, so you want to solve that drift between, between dev and production. And so. If you're using a file-based approach for your translations, then now your translations are tied directly to your repository. They're version controlled. They're directly one-to-one. So it's always the same between development and production. And so you want to have that file-based approach. That's going to lead to a lot less headaches. You don't have to worry about things like... major caching and all the database performance concerns. It's all just a simple solution. And so I think there's a lot to be said about that, because yeah, it's a shame to get tripped up on all the logistics just trying to translate your app. There's many other things to focus on.

 

Yeah, you know, my, you know, again, back to spree, like that was kind of my first foray into like heavy translation usage, right? Where everything is tied to the database. It's also tied to a very specific business unit, right? Like a product in that case. Uh,

 

Mm-hmm.

 

and so, yeah, it's very easy. Like, like that drift you're talking about, you know, Oh, like, well, we didn't have the products that are in production seated. Uh, so like. It's going to be different, right? Like, how do you handle that best, right? It's hard. And we definitely went back to a file-based approach for a lot of the main interface stuff, right? Because it does it. It's just so much easier to work with. You get that version control. And if something's not right, you know why, right?

 

Yeah. Yeah. No, exactly. And.

 

So what kind of issues do you see having that file-based approach on a larger scale? Is there any concerns from using it on a larger scale? Do you have to think about how you're organizing those files? Do you not have as much automation you can do with it because it's split across so many things?

 

mean, there are limitations to any approach at scale. But I think the file based approach is ready to handle a lot of what you're going to need until you reach a point where it should be valuable enough to you to sink time into it. So I, I, I would say, don't think about that until you get there, you know, right? Like,

 

Yeah.

 

that's a problem for later. I think there, you're going to have big big changes to make probably once you get, once you have started to have those issues. So maybe you move to a proper service or something, third party service. I don't know what the case might be, but yeah. So I think this is more about getting people moving, from a smaller scale, this will get you going and keep you going for a long time.

 

So what's the workflow look like using this tool? Is this for a case where you're starting from scratch with your translations? Or you already have some? Does it cover all these cases?

 

Yeah, you could start from scratch. But the idea is that you would have existing files, and you want to import them. So you can import those. Basically, we provide a flow. There's various edge cases with importing your importing files into your translation list in the database at the time. So you have to make sure that you which source of truth, you know, takes over. And so there are various different features during your import that you can use to avoid issues with one source being out of date compared to the other. So, yeah, definitely I think the point is, is that you wanna be able to import what you already have, start with what you already have and be able to go from there. what this tool really does after the fact of you getting it imported is that now you can probably expose this to someone who's translating this. And now basically you're just going to, now they can see all the translations that are untranslated, you know, that's an easy thing to miss if you're running a file-based approach. It's like, oh yeah, I looked through the EN file, the English file, but oh, I didn't look through this other file and I didn't notice that this key was missing. So this provides you, you've got a UI where you can easily see, okay, which translations have been missed, what do we need to fill in? You can use Google Translate, which could probably be adopted to other things. Like I saw a cool thing for Chat GPT for translations this week. thought that was interesting. But so you could hook it up with various different backends. But it's just basically right now it's with Google Translate, which obviously serves the job. And so yeah, product folks can manage it through the UI on their end, or they can do it through Google Translate. And so once you have all your translations filled in and you're happy with everything, you can export. back to YAML, JSON. You can even export to CSV, which is of limited usefulness. But basically, yeah, so you have a whole workflow, import, export, and UI management to keep you running. So I think that's all the tools you need.

 

Yeah, that's awesome that Google Translate is super helpful. Is it is it possible to like mass translate for a particular language using it?

 

Yeah, basically you can filter down any list and based on the app name, the keys, a variety of filters. And yeah, you can translate them all in batch. Basically, the functionality is that it will translate whatever is missing. So if you have something that's already filled in, it's not going to try and translate that because that's wasted effort. It's only going to translate whatever's missing and fill those in. and then you can go from there. So yeah, that's the big thing, be able to do it all in a batch quickly and easily. It's very helpful.

 

That's awesome.

 

Yeah. So, and the situation around this sort of stuff is like, well, prior to this gem being created is that it hasn't been a good situation. So like, yeah, like I was saying earlier, it's like, Oh, I'm just going to add I18 to my project, add translations all as well. Yeah. So now you've got to build a UI for it. And it's like, somebody else hasn't done this before. What? You know, like. How many people have done this over time? Why isn't there just like a, we're so good at gemmifying everything in the Ruby world. Why hasn't somebody done this? It's just, how many people need to do this? You're solving the problem of doing things over and over and over again. And so that's perfect. So basically, I guess there was one existing project that sort of matched it similarly. Um, which would be the talk project, T O L K. Um, and so that, that project is actually, um, was the closest thing that I had found similar to, um, what I had, what I envisioned here. And the problem with talk was that it's got about, you know, 580 stars. It looks like here. So pretty popular. Um, but it hadn't seen some activity in quite some time. A lot of the popularity comes from older versions of Rails, I guess there was a particular point in time when it was very popular. However, I went through and I was, you know, you expect a project with 580 stars, hopefully you could just, you know, flash it up and get it running. Well, didn't seem to be the case. There was, it seemed to be broken all over for me. Um, I don't know how other people were, are, or were managing, but it was unusable for me. Uh, and, and so I went through, I was like, well, I'll just fix this. Popular repository up and, you know, push up a PR and, and we'll, we'll get things running, you know, get things in a better state. I don't like to see things die. Um, I like to keep a project going if it's, if it's a good project. And so I started out small, you know, try and just fix what I needed. And things snowballed and snowballed, snowballed, ended up with this giant PR, uh, you know, fixing, trying to just get the project in a decent state. Cause by the time I got through it all, I was like, this is, this project is just in rough shape. Uh, so I sort of overhauled it for what I did. I dropped my PR and I said, you know, here's what I got done. You know, could. appreciate a little bit of help on the last little stretch here, you know, struggling, but like, I've really sunk a lot of time into this, you know, I'm hoping to share with people and, you know, kind of just got struck down. It's like, oh, well, we don't, you know, lack of priority and whatever. So I was like, well, I've sunk too much time into this project to continue any further. There's, and what do I get out of it? We still, it still has all its legacy. things going on. So all the different decisions they made in the past, it still hangs on to all those. So there are, let's say it was 80% of what I'm looking for, the other 20% adds confusion and complexity to people. And so that that's one way I thought it could be better. So other other translation implementations, you'll see a lot of things like and same with talk, you'll see a lot of things like there's a whole bunch of different rake tasks that you need to run to keep everything in synchronization. And so like the idea of having to do that on the command line just is like, you gotta go do it all in the right order, this step first, this step first, and remember, you know, hopefully your cookbook's all written up right. So I don't like to have that rake task approach. It's just too, it seems too error prone. So... basically try to do away with rake tasks and that sort of stuff. Yeah, the idea of this is to make it simple, something that you can continue to do. And something that hopefully maybe a developer, a non-developer could maybe get away with updating the translations or something like that. It's possible in this scenario, whereas with rake tasks, I don't think so. So yeah, the situation in the ecosystem definitely wanted to be better. So it was a shame that it couldn't revive that popular old project. But it's fine. We can have new things. Old things do die sometimes. So hopefully, they can get that up to snuff. I think I saw a recent PR that they had a Rails. seven support to it and I was like, that's weird. I thought the project didn't really work, but okay. So it's interesting to see how that shakes out. Yeah, I don't like to see projects die like Tok. It's got a huge legacy, very popular. It's a shame for me to see that stuff. I've picked up a variety of open source projects just from seeing them. Okay, they're in disarray. They're have, you know, there's too many open issues. Uh, that can be a common one, too many open issues and it's just sort of drowns itself. Um, so you can help out open source in that way, or you just see that the maintainers just sort of walked away and it's just not accepting PRs, not doing the things they need to do to keep the project up to snuff. And so in those scenarios I've seen, I've just reached out, okay, so you probably curate a bunch of issues to help. help out a particular project. That's one easy way to get started and build some street creds with the maintainer so that he trusts you. And then you can, and hopefully you can do some contributions as well with the PRs. Ideally, you don't just wanna be doing issues, but between the two of those things, contributions and stuff, then once you get, once you become the expert in the field, you now can reach out to the maintainer. you know, chase down their email addresses out of the commit messages and send them an email. You're like, hey, you know, I see you abandoned this project, you know, like, I'd really love to see it go forward. I'd be happy to help maintain it and stuff. And so I've done that at least two notable times, probably three times with different maintainers. So and I've gotten now the main maintainer, if you will. core maintainer, if you will. So yeah, it has been something that's worked. So I managed the RODF gem, that's the, for developing ODS spreadsheets in Ruby. So basically somebody had written an awesome spec and then sort of walked away. And I was so happy that with the work he had done, that I wanted to... pick up the maintenance. And so I like to leave, even if they've abandoned the project, sometimes the maintainer will suggest, well, why don't we transfer it into your name or something like that, transfer the repo in your name? I'm like, no, no, no, that's not cool. I like to leave it in the original owner's name. This like, chances are they put in like tons of lines of code. You know, the initial stuff is usually so big. And so whatever happens after that is like easy, if you will. So I want to give them the cred. I like to give, let them have the creds for that, you know? But then even over time, they'll just say, no, no, you need to have it. We will transfer it. And it's like, okay, fine. But I do like trying to leave it in the original maintainer's name. But yeah, it's, it's, that's, that's a fun one. R O D F. Another big one that I picked up was, that's from spreadsheet architect. Basically, there's a few dependent gems for spreadsheet architect, and RODF is one for dealing with the ODS spreadsheets. ODS is a format that's popular, I think, in Europe. But another gem that I picked up from that was a gem called AXLSX. That's a mouthful. AXLSX Styler. And basically, that gem just allows you to add, or used to, allow you to add styles to your Excel spreadsheet after you've already added the rows. And so it gives you this nice sort of workflow, like CSS style, where you could just do it after. And that's cool. And that gem was really, really helpful for AXLSS in general. it recently actually we merged that into CA that there's a community version of AXLSX called CA-L-I I don't even want to keep saying this C-A-L-S-S-X but yeah we actually merged that that gem up to core and so now it's actually in the project itself and it's now the legacy just lives on just as a a gem page that's no longer used, hopefully anymore. So both of those projects were, yeah, just reaching out to the maintainer over email and just saying, hey, I'd love to carry this forward. And they've been ecstatic from both sides about the work they've been doing. So I would say that to other people as well. Like it's... If you see a project rotting and it's cool, chances are like, try and go the extra mile and get that thing maintained again. Try and, you could be that guy if you need to be, you know? Like, so reach out and do those things. It could just be little things like opening issue or creating issue management. Like I've done that for other projects. Like it could be a domain you're not familiar with. Let's say I worked with Cordova apps for a while there. And you only have so much knowledge into the native Android or iOS. And so the problem with that ecosystem is it deals with web, which is JavaScript, and then you've got Android and iOS. And so it runs people pretty thin. People aren't usually experts in all three. Chances are they're just an expert in JavaScript or just an expert in iOS. And so the problem with those repositories is simply people are creating issues, bug reports and stuff. And the quantity that comes in versus the people who offer to maintain it is just totally out of balance. And so certain repositories, just to keep them alive, you'll need to just. curate the issues, close things down every so often, try to identify duplicates, a lot of issue management. And that, if you don't do that, the project can just fall away and be unconsiderable. If someone was to look at it, they'll be like, oh, I wouldn't use that. It looks like it's in poor state. So that can be one way to revive. life to projects. That's happened on a few different occasions for a few different projects. I worked with the Chameleon CMS when I was trying to figure out how to make a good CMS solution back in the day, which never worked out. But yeah, I worked a lot with issues and just like, didn't really work a lot with the code in that code base, but I worked a lot on their image, issues and I felt like I brought that project back from the dead. Made it considerable again to people. Now you can look at it and say, okay, I might use this, you know, there's not a thousand open issues, right? There's some hope here. But

 

That's awesome.

 

yeah. I don't know if

 

Yeah,

 

I would

 

I mean,

 

say

 

it's.

 

it's chameleon CMS.

 

Ha ha ha.

 

most un-Ruby thing I've ever experienced.

 

It's such a crowded space CMS in general, right?

 

I tried to build a new phone and, uh, time lost. I don't know if you call it that. Brain

 

I

 

cycle,

 

mean,

 

brain

 

if you,

 

cycle used.

 

that's kind of my default trying out a new Rails project or a new feature, right? Like I'll just create a CMS, right? Like, you know, if I'm like, oh, hey, what's new in like, you know, Rails 7, like, let me spin up a new Rails app and start making pages, I guess, like, right? Like,

 

Yeah, yeah, yeah.

 

it's different every time, a little bit, you know? And you're like, oh, I shouldn't do that because I know eventually I'll get down a rabbit hole doing. You know, XYZ with it.

 

Yeah,

 

Uh...

 

I worked a lot with these different CMS maintainers and stuff. And I got pretty deep into a bunch of them. Like locomotive CMS was seeming pretty attractive to me. And then

 

Oh

 

I

 

yeah.

 

got, you get pretty deep into these, like you're invested. You've already got your project. You're like, I'm going for this. I'm going to finish this project. And then you get hung up by the CMS is simply incapable of doing the next phase of things that you need to do. And you're not even, you know, not even at the end game yet. And so I start creating all these issues. You know, it's like, how do we do this? How do we do that? How do we do this? And

 

All

 

like,

 

right.

 

trying to be real detailed and like, I'm happy to open PRs. No problem. But it's like, my head was just hurting and then, you know, these, there's no solution, those issues will still, still be open today because yeah, it's an infinite issue, you go, you solve one problem, you've built another problem with CMSs.

 

Yeah.

 

That's how it works.

 

I mean, that's kind of a good analogy of like open source in general, right? Like where you've made this thing and like, OK, lots of people start using it, gets a community. And then like you hit these limitations where, OK, well, the way it's built, like, doesn't really fit in this feature. That's like a lot of people are starting to request. And then you're like, well, I know I want it right. Like, well, do we start looking at something else? Like, do we try and like rewrite this thing? Right.

 

Yeah.

 

And it is, it's a tricky balancing act for sure. It just reminds me of Mike Perham's, focus on the very niche thing specific and be as small as you can and then just add on other things to it. So I try and think about that, but when you're just having fun and doing, that's the problem with open source, it's people's fun time. So when you... When you get to the point where you're like, you need to start depending it for the non-fun time, like it starts

 

Yeah.

 

to like, the lines start blurring, right?

 

Yeah, no, I know, I know. Yeah,

 

But

 

I do.

 

that's awesome that you go and like curate issues and stuff. You know, that's one thing I'm terrible at with all my open source projects. I'm getting better, but like, yeah, I mean, when I go to other projects, I'll go and look at the issues and be like, you know, I'll be getting the, some of the older ones would be like, I don't think this makes sense anymore and just leave a comment, right? Like, Hey, should we close this? Like, seems like it's not, and you know, sometimes it'll get closed, right?

 

Yeah.

 

a lot of times you go and you'll see like okay this one has like 200 issues and like really it's 200 issues and like you know 90 percent of them are from like two or more years ago and you're

 

exactly

 

like do this

 

here.

 

really count right like Yeah. Yeah. I remember listening to Jose Valim talk about how he manages his... Because at one point, he just had so many open source projects that he was literally burning out from just managing all the ones that he had. And he made this strict thing where it was just quick to close. Like, okay, if somebody has an issue with it, they'll reopen it with why they think it should be a valid issue. And so I took that to heart. A lot of people do, they just make an issue for logging, right? Like, okay, like this is an issue. This is what I experienced. And sometimes it's not really worth pursuing. Not even a fix, but like maybe it's like a feature or something else. And you do, you just end up with these things where, okay, like as a maintainer, the issue stays open because you want to be considerate to the person that opened it and also expose it to other people that may submit the same thing. At the same time, you don't want to have an open issue that you know you're not going to fix anyway. And you're like waiting for community feedback that just never comes. Right. And so, you know, like do you auto expire issues then after a certain time? You know, I'm curious, what's your method for like managing the insanity? Yeah, for sure. I could see that. It it makes me wonder like. You know, I know that there's like a OK, this is unmaintained. You know, you add some slogan to to your repo. You know, I've checked out, you know, you know, I wonder if there's a more elegant solution to that, right, like where, you know, you can flag it. OK, this project, you know, it is not going to be worked on anymore. If if you're interested, you know, submit it here and it would just like start a ranking and then you could just click. OK, like this guy looks good. Or girl, right? Right. Yeah, when I first saw this Rails translation manager, it made me think of Thoughtbot's old copycopter. I don't know if you're familiar, but it was basically like a very generic like text management server that you can then query against. So they had like two parts, like a copycopter server, and then the client where it would just use the translations to like. pull some other server for that data, right? Like, and it reminded me of that, but like they abandoned that. And you know, ThoughtBot's a pretty like big, you know, consultancy company, especially in the Rails community. And when I saw they were like, yeah, we're not really interested in managing this anymore. And I just thought, man, like, okay, like anything could evaporate, right? Like, it's the wild west of the open source world. Yeah, but I mean, you know, it just goes, it's not necessarily, you know, against the norm, right? Like, it's not just, you know, personal projects. It's like also bigger companies too, right? Like eventually the need dries up and they don't have a need for the product or, you know, maybe there's other better alternatives that come up and then they just abandon them, right? And so it's hard to like, I guess for me, it's hard to know when to quit. I just, I have them open just like, you know, projects that I have just open all the time or sometimes I'll pick up, I'll be like, oh, this looks like an interesting project and I'll start to like get involved. And then I just stop. I'm sorry, you know, my mind just like wanders too much, I think. And I'm wondering if like, maybe that's just like. how it happens, right? Like things just organically like move directions in the open source world. And maybe that's a good thing, right? Ha ha ha. Passions change. Yeah. Yeah, we're kind of seeing that come out from like, I would say Rails as a framework kind of firming up, right? Like it's matured, it's not really changing that much, right, like some newer features come in, but for the most part, like a lot of the active record stuff is kind of the same, right, like it hasn't really changed too much. And if you were a Rails developer 10, 15 years ago, you're seeing very similar like, you know, structure to how it works, right? And so I think we're starting to see a lot of like these newer very niche things that are just plug-in and drop-in using, right? Where like you have here where it's like, okay, use it for this purpose and it's going to work great, right? And I think you're right. I think having a very, you know, adding too much can definitely like kind of be the downfall of that onslaught of issues, right? Yeah, that's awesome. You know, Rails engines are definitely like one of the most underutilized things, I would say, in Rails, right? Because they are, you just plug them in and then they just magically work with your app, right? And they can be completely separate in their own external repo even. And it's great. So what's your experience been like building that and like maintaining the engine over a longer period of time? Like... Is it pretty straightforward? Like once you have like kind of the nuts and bolts like locked in, is it pretty like straightforward as far as like updating with the latest, you know, Rails versions and stuff? So what is that process? Ha ha. Copy them. That is a shame. Right? Well, to be honest, CSS should support it out of the box. Right, right, right, I know. Yeah, the third party's really by you. Yeah. Right. Right. Yeah. Right. Right. Yeah, I know a lot of people like to use engines even internally to help move apps out of a giant monolith, right? But yeah, I mean there are so many limitations. you know, with anytime you need data sharing, I feel like that's definitely... The cross app communication barrier is always just like, never a fun thing to play with. Ha ha ha ha. It really is. The more you break out, yeah. Right, I know. You're like, oh wait, how do I get this thing into that new app now? Yeah, months later, months later. It's already happened, you know. That's funny. It's like when tests fail on a leap year or something, right? Like, oh, I forgot about that case. time fun. Oh, that's funny. Oh, it does. Oh my gosh, especially like, yeah, I mean, especially in the States, right, where we have the, you know, the daylight savings time. It really like, we're the only ones, you know? And like, you deal with any other country and, you know, they're just like, why is it an hour less again? Wait, what month is it, you know, like? Oh my gosh. No. Well, thank you, Weston, for coming on and for this translation manager. I'm definitely going to use this going forward for translations. It looks super simple. And yeah, I hope you get help so that it stays up. You know? Right. Right. It seems like you keep it small and you never know. Well, uh... Yeah. So at the end of the show, we always like to kind of give something that we're really excited working on or interested in or even just we called it picks before, but I feel like it's transitioning. So anything at all you want to share, you know, as your chance. I don't envy that. It is fun. It is fun. Right, right. Oh, that's funny. Well, on topic here, and you did briefly mention it while we were talking, but the guy from, I don't know if he's still at HashiCorp, but Obi Fernandez, he has this Instant IATN gem that does instant translations based on your translation file. Super cool project. So, Yeah, I would totally try this in combination with your app and see how it works out. Right. Right? Right. Yeah, I mean, I think it's fun. I agree with you. Maybe it's overhyped all this, you know, large language model talk, but, you know, it's just a toy at this point, right? So have fun with it while it lasts, you know? Well, Wes and thanks for coming on. It was great talking to you. And I hope everything goes smooth with your projects. And until next time, folks, Valentino out.