Because of the changes of variables in the database to being stored in the configuration, the i18n and variable module approach won't work easily. There is work in progress to set up an alternative (easier to implement though): https://github.com/backdrop/backdrop-issues/issues/704. Hopefully we can get it implemented not too long.
I've tested out the approach outlined in https://github.com/backdrop/backdrop-issues/issues/704 and created a pull request (patch) https://github.com/backdrop/backdrop/pull/2397 with an experiment to make the registration emails translatables. It's a harder case than some configuration since locale needs the text to be visible on the screen. So I took the approach of adding sections below the form fields which will show the translation if the interface is set to the other language.
If you're comfortable testing you can go to the sandbox and try things out and provide feedback in github (or here).
Two issues would benefit from testing and code reviews; they've been around for a while and no takers. It would be a shame for these to miss the next releases.
View Table Headings...
Posted38 min 58 sec ago by Martin Price | System Horizons Ltd (yorkshirepudding) on:
For the dev meeting: Progress all over the place.
Nine pull requests are currently marked RTBC - time to consider merging? Bug fixes mostly, and not too complex.
Issue #6987: There's...
In a blog post titled "Github Tips and Tricks for Contrib Maintainers", I'd like to see some of the following topics:
When is the README sufficient for documentation? When should...
Posted1 day 17 hours ago by Olaf Grabienski (Olafski) on:
Have you tried uc_cart_add_item()? You need to provide the nid of the product. Then you can use backdrop_goto('cart/checkout'); to send the user to the checkout screen. uc_cart_add_item...
Posted1 week 6 days ago by Alejandro Cremaschi (argiepiano) on:
Comments
Because of the changes of variables in the database to being stored in the configuration, the i18n and variable module approach won't work easily. There is work in progress to set up an alternative (easier to implement though): https://github.com/backdrop/backdrop-issues/issues/704. Hopefully we can get it implemented not too long.
Well, site without language versions is pretty much useless in Europe, so I have to come up with some band aid solution...
Do You think that detecting language and using separate copy of the config files would make sense?
I need to localize whole registration form, too - with twenty or more fields. Made using 'profile' module.
Ok, so basically I came up with this:
global $language; $lang_name = $language->langcode; // translation if($lang_name == 'en'){ $form['profile_uczestnik']['field_faktura']['und']['#title'] = t(config_get('translation.pl', $form['profile_uczestnik']['field_faktura']['und']['#title'])); }Works for profile fields, should be adaptable for other parts of the site.
Mmmh, this is really a weak point in BD at the moment, and it might take some time so solve... also interested in helping/reporting/reviewing.
I think for the time being I'll just use hook_mail_alter and swap contents depending on language...
@akarso how is the hook_mail_alter working out?
I've tested out the approach outlined in https://github.com/backdrop/backdrop-issues/issues/704 and created a pull request (patch) https://github.com/backdrop/backdrop/pull/2397 with an experiment to make the registration emails translatables. It's a harder case than some configuration since locale needs the text to be visible on the screen. So I took the approach of adding sections below the form fields which will show the translation if the interface is set to the other language.
If you're comfortable testing you can go to the sandbox and try things out and provide feedback in github (or here).
@mazze are you interested in testing https://github.com/backdrop/backdrop-issues/issues/704? I'll add notes on how to test soon.