Provide frontend translations ?

[aurelien-roy]

I know that frontend translations are normally defined in the theme files (with the Translate plugin), however I think translating the different frontend forms and mails is something that many october users will do when starting a new project, and it is time consuming.

It would be great and reaaally time-saving to have a localized user plugin "out of the box" (just like the backend is).

Couldn't backend translation system be used as well for frontend localization ? (Backend translations can be accessed in frontend with the |trans Twig function)

Alternatively, the Translate plugin could be refactored to support frontend localizations provided by plugins and overridable by themes).

[bennothommo]

@aurelien-roy There has been talk about theme internationalisation (for example: octobercms/october#4308) which is somewhat related to this request, however, given people generally style or design their front-end user forms per site, it's probably not been that critical to allow translation of the default partial templates for the front-end forms.

[aurelien-roy]

Well I think, while most developers will, indeed, design their front-end themes, common elements like login form or password reset form don't differ that much from one site to another. Thus, simply include the default login/reset/register partial in a custom theme may be sufficient most of the time : that's very quick to do, functional and let developper focus on other things. The benefit of adding localization is that it will cover other use case (non-english websites and multi-lingual website) that the default partials do not support today. And thus, many more website projects could rely on these default partials.

Of course default partials do not fit for every website, but sometimes, only minor changes are needed (for instance adding a few fields in the registration form, or change the CSS classes for using another CSS framework). In these scenarios, I just duplicate the default partials and make the appropriate changes (because why re-invent the wheel ?). Thus, if localization was built in to default partials, I would still benefit from it.

PS: I think the issue you refered is not really related as it talks about backend settings of themes, not frontend.

[LukeTowers]

@aurelien-roy I'm not opposed to the idea. If someone submitted a PR I wouldn't mind reviewing it.

[aurelien-roy]

So, here is an example with a partial on what it may looks like.

What's great here is :

• most labels already have a translation available (I only had to add translation for input placeholders)
• ajax error messages were already translated

What's less great :

• Repeating the plugin name is verbose... but it's already what is done in the component file for ajax messages localization. So I guess we'll keep it that way ?
• Another solution would be to add "rainlab.user::lang." as a constant in every component file (thought initially to add it in the Plugin.php file, that way it would not be repeated for each component, but I can't find a way to access the plugin object from component's twig templates)

What do you think @LukeTowers ?

Edit : I may also add a twig comment in front of translated text for readability :

{{ 'rainlab.user::lang.account.email_placeholder'|trans }}
⬇️
{# Enter your email #}{{ 'rainlab.user::lang.account.email_placeholder'|trans }}

[LukeTowers]

twig comment sounds good to me. Only other request is space before and after pipe character: 'string' | trans

[alxy]

Wouldn't it make sense to source these translation out to a separate lang file, like lang/xx/frontend.php? First of all, that would be easier to override if necessary (otherwise one would manually need to look for the language keys specfic to the frontend) and on the other hand for users that only need the backend translated, they will have an easier job when there are fewer strings to translate (if they were to add a new language version).

[aurelien-roy]

Thought that initially, but it seems there are many translations in common between front and backend. So how do you deal with that ? Either you will end up with a lot of duplicated strings in frontend.php and lang.php, or you'll have templates with a mix of frontented/backend translation keys.

[alxy]

Yeah, you will certainly have duplicates. But frontend strings are far more likely to be customized, as it is the one the client sees. From my experiences, backend administrators do not care too much about wordings...

[LukeTowers]

@alxy if backend administrators do not care too much about wordings... is the case then I don't see any problem with having the backend's translations change along with the frontend's whenever people customize them.

[alxy]

@LukeTowers Yeah, this is not the problem. The situation is I want to change the translation for signup form in German. Now, what I need to do is look up all the strings in the (large) language file to find the ones I want to change (and they are not even concentrated at a single location, but all over the file, as we reuse some strings on multiple locations). If we had a separate file, I would just take this and its obvious that I need to change exactly these values (or leave them as is).

[LukeTowers]

@alxy I'm not too concerned about that particular use case because what you could do instead is just look at the twig file for the view that you want to translate and pull the keys out of that instead, which is what I would probably be doing in the first place.

[aurelien-roy]

Is this "mess" acceptable ? (for lack of a better solution)

[LukeTowers]

@aurelien-roy what are we looking at exactly?

[aurelien-roy]

@LukeTowers Sorry ^^ I should have explain my thought:

So, I enabled localization for mail templates. Problem is after that, the mail template editor in the backend do not look really clean anymore (for instance, on the first screenshot, the subject column is barely readable because of the Twig markup introduced by localization).
My question was : is it okay to keep it "as is". As I don't see any other solution that wouldn't require some edits in october core, my question is: it is okay to keep it as is?

[LukeTowers]

@aurelien-roy I don't think it makes sense to provide translations to the mail templates out of the box. I believe the translate plugin provides support for translating mail messages, so if a developer needs that they can just use the translate plugin instead.

[aurelien-roy]

Well technically the Translate plugin could also be used with "standard" partials. I'm not sure to get what is different with mail templates^^ (Though, I agree, mail templates are more likely to be changed anyway than other templates from the user plugin. Maybe is it your point?)

My point is that once the translation for one language has been made, it could be re-used with 0-cost by every other developper who need to support that language.

[LukeTowers]

My main issue with the translating of the mail templates in this manner is that it over complicates the user interface for seemingly little benefit.

[daftspunk]

This is by design, we want the source templates to be in English without complex translation keys getting in the way of learning the system itself.

Translation of emails should be similar to how content files are translated. You should have a single template for each language, detect the users language and send them a template in that language. Rather than trying to translate the template itself.

Ultimately the system has no opinion on how you approach this and we want to keep it that way.

[daftspunk]

As a heads up, a ticket has been created for this proposed mail approach: rainlab/translate-plugin#533

Translating mail template content itself will create problems when queuing the mail message. The server that processes the queue will lose the context of the user's locale preference. Sending a different, specific template for that language resolves this problem