#No, that's not at all what I mean

1 messages · Page 1 of 1 (latest)

tropic pier
#

So I'm doing some refactoring, and I'm interested as to how I'm supposed to best involve usage of LocalisedString. What I'm failing to mentally compute....is the reason for me to jump the extra hoop to use it, instead of just directly using my mergemap values.

It doesn't help for me to use LocalisedString if can only get 1-2 "proper" values, but I still have to directly use the portal_blob derived value for, say, author and description

uneven fossil
#

To support other languages

#

That's reason enough

#

(and to be accurate when people overwrite them using locale)

tropic pier
#

But...are mod titles called any different in other languages?

uneven fossil
#

They might

tropic pier
#

Well...I'll put that into the future-consideration pile, its at the moment a nice-to-have. I was under the impression you suggested it because it was an antipattern to derive strings in the manner I am, or more usefully that the LocalisedStrings prototype/object had access to 3rd party mod info that I otherwise had to scrape for.

uneven fossil
#

I personally think this is less of a matter of "is it worth it" and more "you are just wrong if you don't"

And LocalisedStrings are one of those things you should be using pretty much everywhere when making gui anyways, so
Hard-coded strings are just bad manners

#

And they're not prototypes

#

They're literally just an alternate type that you replace strings with so they can get translated

#

And by God I would expect it to only take 2 lines in your function for merging the full list of data and active mods

#

I would even do it for you if you'd want

Being localisable is a pretty strong passion of mine

tropic pier
#

I'll hit you up for that once I get this one styling update out of the way, promise.