This one will be tricky. Everywhere inside the API, at really any arbitrary place, I'm going to need to be able to send translated strings. I don't know what the solution for this is. Some static service available everywhere, totally ruining dependency injection? A requirement to hold onto some language service at EVERY corner in every service? Mmmm I just don't know... furthermore, complicating every single service with language just sounds unfun, I'd rather do it somewhere at the top, but... Ah gosh, I know that won't work for every occasion, especially with stuff that outputs lots and lots of generated data inside the string.
It's mostly exceptions and emails. And how do we handle threading if it's static? It'll HAVE to be a service, AND it'll have to be... how will the one instance for this one call have the language set? This is such madness, I don't know. All the services are generated well in advance of the controller action starting, especially the ones that are static themselves. A static service cannot hold onto a non-static entity. So what, the other solution, which is to output format strings rather than the actual strings, and have somebody at the top parse it for us? I mean, that's doable, I'm pretty sure all exception handling checks the type, not the string. It's just such a nightmare... especially to test.
Make all language strings an enum, then make all your custom exceptions (the ones we'll actually show users) derive from a "Language" exception, which will have a constructor and fields with the enum and a dictionary of string to objects. Then in MatchExceptions, you just check for those fields and use a language conversion rather than the string in the exception.
This one will be tricky. Everywhere inside the API, at really any arbitrary place, I'm going to need to be able to send translated strings. I don't know what the solution for this is. Some static service available everywhere, totally ruining dependency injection? A requirement to hold onto some language service at EVERY corner in every service? Mmmm I just don't know... furthermore, complicating every single service with language just sounds unfun, I'd rather do it somewhere at the top, but... Ah gosh, I know that won't work for every occasion, especially with stuff that outputs lots and lots of generated data inside the string.
It's mostly exceptions and emails. And how do we handle threading if it's static? It'll HAVE to be a service, AND it'll have to be... how will the one instance for this one call have the language set? This is such madness, I don't know. All the services are generated well in advance of the controller action starting, especially the ones that are static themselves. A static service cannot hold onto a non-static entity. So what, the other solution, which is to output format strings rather than the actual strings, and have somebody at the top parse it for us? I mean, that's doable, I'm pretty sure all exception handling checks the type, not the string. It's just such a nightmare... especially to test.
Make all language strings an enum, then make all your custom exceptions (the ones we'll actually show users) derive from a "Language" exception, which will have a constructor and fields with the enum and a dictionary of string to objects. Then in MatchExceptions, you just check for those fields and use a language conversion rather than the string in the exception.