Am I being stupid? Trying to do compile-time safe phrase localization

[maiden berry]

Wanna ensure it's impossible to misspell a phrase label or provide the incorrect number of params for that particular phrase.
The way I've currently done it requires overloading the translate() method for every possible param count, plus using interfaces (NoParams, OneParam, etc.) as type flags kinda makes me itch.
I'm sure there's a better way to do this, but I'm drawing a blank.

[compact lynx]

⌛ This post has been reserved for your question.

Hey @maiden berry! Please use /close or the Close Post button above when you're finished. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

[grim cave]

Are we in Spring Land?

[maiden berry]

Hell no.

[grim cave]

Gah

[maiden berry]

(No offense if you like Spring)

[grim cave]

Oh I love Spring

https://www.baeldung.com/spring-boot-internationalization We use message files to handle all of this.

I would say. I don't think you really need an interface for the PhraseTranslator

[maiden berry]

Looking at the docs, seems phrases are referred to using raw strings, which is expected for file based configuration. Would definitely violate the compile-time safety I'm after with phrase references. The arg counts seem to just be an array object, so similar lack of compile-time safety there.

[maiden berry]

I started with a regular class, but I figured I could make my base controller implement PhraseTranslator and then all of the code that'll be referencing the phrases can just do translate(Phrase.X) rather than me needing to create, maintain and call a separate instance like translator.translate(Phrase.X), just a quality of life thing to shave down dev time since it's something that'll need to be typed thousands of times throughout the project.

[grim cave]

Would static method be out of the question? Since then you could static import, and get the same impact, without needing to couple that tightly to the interface.

Since a default method that is never overriden is basically a Static Method with extra steps.

Regarding an "Elegant" way to handle the param count being compile time safe....
I don't got any good ideas :/

[maiden berry]

I agree, I'd prefer to get rid of the coupling if possible, but I don't think a static import would work.
The default method is overridden by my base controller and specifies the visitor's preferred language, which will be unique for every visitor, so I wouldn't be able to make it all static unless I added an additional param for passing in the preferred language, which would make translating a phrase even more verbose every time.

[grim cave]

Is the Visitor's Language stored in a Thread Local?

[maiden berry]

No, I'm using Undertow, so it's not a "one thread per request" situation. Everything uses dependency injection other than App.LOG.

[grim cave]

So no static global context we can draw from.

[maiden berry]

I've been very deliberate in absolutely never doing that.

[grim cave]

Well with all those constraints.. your current approach is basically the best one I can think of.

[maiden berry]

It's definitely funky...
But if it provides the long-term maintainability and compile-time safety I'm after, I think I'm fine with funky.

I just don't want someone to look at it some day and say "Wtf are you doing, you could have just done X" and then I'll have to redo the whole thing.

[grim cave]

That will happen regardless of what you do.

[maiden berry]

Way to crush my dreams, man.

[grim cave]

Look fam, I'm an Enterprise Java Developer, I've experienced this myself.

I'm currently refactoring my "golden" project from last year.
It's all trash to me now. You learn, you improve, and the old stuff is no longer as good.

[maiden berry]

@livid pagoda I saw you typing earlier and I know you're good at cutting through the bullshit. Am I missing anything obvious?

[maiden berry]

You hope it stops eventually, and you're able to look back on something and think "Damn, I was pretty smart".

[livid pagoda]

i was thinking of some rest/varargs/array args kinda thing but then i realized that would be very much not compile-time safe

[grim cave]

Yeah. There are "cleaner" methods.
Just not.... Compile-Time Safe methods.

[grim cave]

Oh I was pretty smart.
But now I'm smarter, and realize that being smart is sometimes a terrible idea.

[maiden berry]

Let's hope this isn't one of those cases. ;)
A year from now I'm going to change the param count for one of these phrases and thank my past self for being so overly-prepared.

[compact lynx]

If you are finished with your post, please close it.
If you are not, please ignore this message.
Note that you will not be able to send further messages here after this post have been closed but you will be able to create new posts.