Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable site admins to override plugin localization strings in the backend or via rainlab.translate? #5354

Closed
lieszkol opened this issue Nov 15, 2020 · 8 comments

Comments

@lieszkol
Copy link

lieszkol commented Nov 15, 2020

Plugin localization strings stored in the lang subdirectory of a plugin directory can be overridden by devs by adding localization files to the app lang directory as described in the docs.

However, this is of little use to site owners/admins (who aren't devs). I've tried to find any posts on this without success, even though I would think many owners of translated sites would want to provide localized translations for strings used by plugins without having to learn ftp etc. I did find one similar question on StackOverflow.

Here is my use case: On one of my client's sites we are using the awesome offline.mall plugin. This plugin sends out many emails (order received, confirmed, payment failed etc.). The text for these emails makes use of strings stored in the plugins language files, for example the language file for hungarian is at: \plugins\offline\mall\lang\hu\mail.php

As a dev, I can override this file by copying it into this directory (in the site's web root dir): \lang\hu\offline\mall\mail.php

Ideally the rainlab.translate plugin could be expanded with functionality to scan for messages in a given plugin's language files and enable the backend user to override these strings in the "Translate messages" backend page. Or, if we don't want to overload the user with too many translatable strings, another option would be to expand rainlab.translate to scan for (and override) messages already translated by the site admin which are stored in the site root /lang/ subdirectory?

Or is there some other solution that I'm missing?

Thanks for considering my request.

Note: another option I considered was using the awesome Developer Tools or the Quick Edit plugins for this, but currently it's not possible either. I've created an issue to ask INDIKATOR if he'd be open to expanding his plugin in this direction.

@mjauvin
Copy link
Contributor

mjauvin commented Nov 15, 2020

The RainLab.Builder plugin does this for plugin developed with it. You could reuse this functionality in a custom plugin I guess.

@mjauvin
Copy link
Contributor

mjauvin commented Nov 15, 2020

Actually, RainLab.Builder is perfect for this. You can acually manage localization files for all installed plugins, I thought this was only for plugins developed with it, but no.

@mjauvin
Copy link
Contributor

mjauvin commented Nov 15, 2020

Well, you can modify the plugin localization strings, but this is not an override... it's actually overwriting the original values in the plugin lang folder.

@lieszkol
Copy link
Author

Thanks mjauvin for the ideas - yes, RainLab.Builder would be great if it would be possible to edit files stored in the site root /lang/ subdirectory, since then a dev could just copy any plugin language files there that the client wants access to.

@mjauvin
Copy link
Contributor

mjauvin commented Nov 15, 2020

I'm working on a new plugin that will do this. Will let you know when I have something working.

@lieszkol
Copy link
Author

Well alrighty then! Looking forward to it :-)

@mjauvin
Copy link
Contributor

mjauvin commented Nov 16, 2020

@lieszkol here is the new plugin:

https://github.com/mjauvin/oc-localize-plugin

Just install this under /plugins/r4l/localize and run php artisan october:up to activate

Note: you need to install RainLab.Builder plugin first.

@lieszkol
Copy link
Author

lieszkol commented Nov 16, 2020

That's fantastic Marc, thanks a million! It doesn't cover my use case 100%, but I've created an issue about that in your repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants