so there are a few topics about localization and I also know the docs where it tells me that localization in email is supposed to be done with a lot of if/else on the user language. That somehow does not feel right to me, as a standard email has about 5/10 text blocks, we have around 35 languages in our platform and with 3 lines for each translation we easily blow up the email template to 3k lines. That does not seem to be maintainable at all to me. Is there really no way to upload a translation json or use the auth0 translations? It also seams, that I have to do this if/else stuff if I want to implement my own custom page, as I can not access the auth0 translations from the custom templates?
Also, how do people add the language to their metadata? Is there a way to enforce that when a user registers or to save the browser language of the user when he registers? At first auth0 seamed like a very neat out of the box solution but having to do the translation on our own and having to create a service that localizes our users seams like a very hacky solution to a very basic feature…
For your second question on “how do people add the language to their metadata?”,
This is how you can generally add information to user_metadata from the signup form.
You can customise your signup form to have a hidden field which can capture a value like user browser language by reading it from navigator.language at runtime. This information will then be added to that user’s user_metadata . https://auth0.com/docs/libraries/lock/lock-configuration#hidden-field
Note: The additionalSignUpFields are intended for use with database signups only. If you have social sign ups too, you can ask for the additional information after the users sign up (see this page about custom signup for more details).
About the issue with multiple if/else, I get your pain point. It would be nice to have an easy way to pass a JSON for each locale and use the values from that.
Maybe you can look at this as part of your build pipeline and write some code that generates the liquid template. So you can still have your code organisation with using different JSONS for each locale and use something like TypeScript/NodeJS to generate the email template.
This way you can have modular/reusable code and add/remove new locale as required.
After each build you can take the result and paste it in Auth0 dashboard.
As I understand the documentation, the solution of adding a hidden field or a visible drop-down field to the signup page will not work when using a social signup, only the Auth0 database signup. Without a consistent solution for both types of signup, this is no solution at all.
Perhaps a post-signin API call to update the user’s locale? Delay the sending of the sign-up confirmation email (by 5 minutes? ) allowing time for the web app to establish the user locale via the API and update the database. In this manner, the web app could use whatever means they want to determine (browser language or even ask the user) what their preferred language is and then store it in the Auth0 database against the user login profile.
Of course, this is a different issue than the email still having to use the Liquid syntax.
Has there been any progress on this issue? I can’t work out how to save the user’s language using the new universal experience. Is this even supported?
