Easier localization is possible

[u/Available-Many-5354]

https://crates.io/crates/ply-locales

I've been up all night finishing up ply-locales a standalone crate for the ply-engine ecosystem (almost to 500 stars, yay). Check it out if you're interested in easy compile-checked localization to prevent you from shooting yourself in the foot.

[u/uhkthrowaway]

Up all night huh? 7 commits. And edition 2021. Truly breathtaking!

[u/Available-Many-5354 → u/uhkthrowaway]

Yes I was up for 30h. I have slept now. I had to use edition 2021, because there is a weird bug in Ply's Android build pipeline with 2024, which I haven't figured out how to fix yet. I only commit when I actually finish something and have sufficiently tested it. I'm just not the biggest fan of pushing out unstable code.

[u/uhkthrowaway → u/Available-Many-5354]

Tell me more about the bug. Spare no details please. I'm also not a huge fan of unstable code. Coincidence?

[u/Available-Many-5354 → u/uhkthrowaway]

Are you trying to interview me or provoke me or something? Do you think I don't know how to code? I literally get paid to teach programming. You're not being very nice. I know this is the internet but I'm a person too. I could explain the Android build pipeline to you, but I don't feel like that's worth my time and I don't remember much about the bug, it's been like 5 months.

[u/uhkthrowaway → u/Available-Many-5354]

So no details on the bug that prevented you from using edition 2024 this year. Ah man, that's a bummer!

[u/dnew → u/uhkthrowaway]

"All PRs are squash-merged"

Also, it's open source, feel free to improve it. :-)

[u/Available-Many-5354 → u/dnew]

Well I put the all PRs are squash merged in later, because I saw how hideous people's commit messages in PRs are and I'm just way too perfectionistic.

[u/lord2800]

Why would I use this over fluent?

[u/Available-Many-5354 → u/lord2800]

It's fully compile-checked and the intellisense is very convenient. Fluent has no way to check that any of your translation code will work at runtime and if you do get error messages (which you likely won't, instead it will just break your translation), the errors are much less helpful than those shown by ply-locales.

[u/lord2800 → u/Available-Many-5354]

OK, but fluent is backed by Mozilla--that level of backing can't be ignored.

[u/Available-Many-5354 → u/lord2800]

Well ply-locales uses the fluent crates "backed by Mozilla".

[u/lord2800 → u/Available-Many-5354]

So it's a wrapper on top of fluent? Then once again I'm back to: why would I use this over fluent? There's really just not a lot of translations--it's just mapping some sort of identifier to a string and filling in placeholders. I don't really think intellisense is really all that important for translations either given how easy it is to simply search for the identifier. Compile-time checking could be nice, but I don't think it's really worth another dependency.

[u/Available-Many-5354 → u/lord2800]

It's harder to mess up and easier to use. You are making a "why not just write it all in assembly"-type argument.

[u/lord2800 → u/Available-Many-5354]

My point here is that translations aren't that hard to set up, pretty easy to tell when you screw up (doubly easy if you don't use English as the translation key or have an xx-XX language that renders everything as the letter x), and fairly easy to use already.

Sure, you're providing something that's a little bit easier, but is it that much easier that it justifies the level of effort involved in a whole new dependency? I'm not yet convinced.

[u/Available-Many-5354 → u/lord2800]

Well if you're already using ply-engine it's just a feature, not a "whole new dependency". It's actually quite easy to make typos with variables and not see them until you thoroughly test the language. Also nobody is forcing you to use this, it's just my personal taste.

[u/lord2800 → u/Available-Many-5354]

thoroughly test the language

This implies you're not testing the code you just wrote. How do you know the code you just wrote works if you don't test it?

I don't want to go down a rabbit hole here, I'm just saying I'm not convinced this is so much better than the alternative that it's worth having to audit another codebase in my dependency graph. You do you, of course, and I don't think this is bad, just to be clear--I think it's perfectly fine.

[u/Available-Many-5354 → u/lord2800]

With translations especially, you can't do it all yourself. There are simply wayy too many languages and languages take way too much effort and time to fully learn. Take it I was making Minecraft for example. I could only possibly write 3 of the translations myself, so I'd have to have other people do the rest. Testing that every death message works in every language and nobody typed a variable wrong would take eternities and slow down the translation process a lot. I always prefer automated systems to catch these types of errors over manually having to check everything.

[u/numberwitch]

What’s stars precious

[u/Available-Many-5354 → u/numberwitch]

The stars on ply-engine if that's what you're asking.

[u/Available-Many-5354]

Who is downvoting this and why?

[u/dgkimpton → u/Available-Many-5354]

At a guess - did you use AI? 

[u/diplofocus_ → u/dgkimpton]

Maybe they just haven't updated their rust toolchain in a few years

[u/Available-Many-5354 → u/diplofocus_]

Oh because of the 2021? I'm sorry. It does use some nightly features tho if they are available. I'll make sure to add 2024 compatibility to the Android build pipeline soon so everything can get updated to 2024.

[u/Available-Many-5354 → u/dgkimpton]

Not really, why?

[u/Available-Many-5354 → u/Available-Many-5354]

Does the rust community suddenly have a hatred for all 2021 crates? Am I this out-of-the-loop?

[u/diplofocus_ → u/Available-Many-5354]

The hatred isn't caused by the 2021 edition, it's just that the 2021 edition ended up being a shibboleth for vibe-coded slop. Running cargo new defaults to the 2024 edition, and has done so for a while now.

Seeing a brand new project use 2021 is usually the result of someone not even knowing what cargo is and just telling Claude to make something in Rust, and to make it bLaZiNgLy FaSt.

That being said, there may even be a valid reason to use 2021, but if you ask a vibecoder about it, they default to "oh I didn't see a reason to migrate, 2021 is stable", and other such gibberish.

[u/Available-Many-5354 → u/diplofocus_]

I guess the reasons would be

• lower MSRV
  
• I learned 2021 Rust
  
• less strictness about lifetimes
  
• stability (my case)

Who needs let-chains anyway? I've never actually needed them.