Best approach to translations

[adrianrudnik]

Sorry to post this again, there are already some solved discussions at the kratos and cloud, but I have some problems with the approach.

I'm not sure how to approach it, but it seems like a small conflict in responsibility: Either kratos is responsible for handing out human readable versions of errors, in the language given by the Accept-Language header or it should focus on error codes and their payloads.

Right now it does both, but in a way that is not streamlined. As Kratos/Ory communicates errors that have implications to user behaviour and security relevant information,, I think a more streamlined way would currently be required.

As an example, based on my try to get the most basic messages for registration and login from en to de, the following issues appeared:

• It's a copy & paste effort from simple snippets on the documentation instead one big message catalogue you could plug into a translation system.
• The documentation seems to be lacking in various messages, like 1050014. There is a context {used_at} given, but the text node does not use the placeholder but mirros the actual output. Would I move it to something like weblate, the template would require extra work to make translators understand the context.
• Sometimes the messages are not even related to the context, like 1050018 where the we have {display_name}, which is given {name}, but should not be available, as only display_name is within the context, so where does {name} come from?
• Not sure what to do with 4000001, 5000001. What is the reason, how is that one translated? Is it another message from a different code that is injected?
• The 4000005 one was the one I struggled the most with. The {reason} can be something I can't translate. The reason can be anything raw, like password length must be at least 8 characters, but only got 3.. No context, just raw, variable, numbers that depend on many many things. I would need to parse the message, replace any number with a dynamic placeholder and reinject it back into my own translation mechanism, depending on the position within the reason itself. I could even dumb down the message to "too short/zu kurz", but that could remove / obfuscate security relevant message details sooner or later.

Right now I'm split between two decisions: Roll my own UI. Gives me the responsibility to monitor Kratos and Ory-releases and their bound translation setup, maybe breaking or missing contexts will mangle user visible errors or warnings. Or stick with the hosted self-service variant, but no way to translate it.

Are there any plans to improve and/or centralize the translations, maybe even take over the responsibility of ory-related humna-readable messages, even for the product of the ory cloud UI itself?

[kmherrmann]

Thanks so much for the detailed feedback.
We in fact just talked about this and we do have plans to handle translation in Ory cloud and the hosted UI out-of-the-box. We still have to work out the details (e.g. how to let you override and customize messages) and don’t have a timeline yet, though.
Please stay tuned!

cheers
Klaus

[adrianrudnik]

Cool! Looking forward to it.