Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
As per http://drupal.org/project/variable can we get multi-lingual variables defined here.
Comment | File | Size | Author |
---|---|---|---|
#20 | variable-support-for-uc_quote-1533286-20.patch | 2.24 KB | nerdcore |
#18 | 1533286-i18n-variable-uc_stock.patch | 1.87 KB | mandreato |
#12 | 1533286-i18n-variable-uc_cart.patch | 1.93 KB | mandreato |
#10 | 1533286-i18n-variable-uc_payment_pack.patch | 1.81 KB | mandreato |
#6 | 1533286-i18n-variable-uc_cart.patch | 3.9 KB | longwave |
Comments
Comment #1
TR CreditAttribution: TR commentedSeems like a lot more trouble than it's worth, and not necessary if multi-lingual variables is all you need since Ubercart already defines i18n_variables for the Internationalization module.
You could always write your own hooks for the Variable module - this doesn't have to be in Ubercart core, and my inclination is to not put it in unless there's a good use-case for doing so.
Comment #2
mgiffordI'm pretty sure that this is how user defined custom variables are being handled in D7. It's very much related to:
#582044: Checkout messages not available as multi-lingual values
Comment #3
TR CreditAttribution: TR commentedThe Variable module is 9 years old - it's certainly not the new, D7 way of doing things. D7 core doesn't address internationalization of variables or database values. There was an aborted effort to make this happen in core, but it wasn't implemented and may not even get into D8. At least, I haven't seen anyone working on it. Ubercart uses a lot of variables, unlike core, so this is an issue that affects Ubercart more than others. We rely on the i18n module to handle our multi-lingual variable needs because there's no sense in trying to implement our own solution for what really should be a core Drupal capability.
Comment #4
mgiffordI overlooked the start date & just saw that it only had a D7 version.
In D7 this would be done with $conf['i18n_variables'] - and ya, you're absolutely right that there was an effort to bring variables into D7 that wasn't successful. Think there's bigger thinking afoot for D8. Absolutely, gotta rely on other modules and not build a UC specific solution. That being said, i18n has a lot of modules within it or associated with it. It's a pretty complex beast. I just see Variables as a module associated with i18n that you need if you want to have control of user defined variables like say the maintenance module's messages (from core).
I do acknowledge that I need to dig into this a bit further so will push to see if we can get a best practice clarified & then get back here when this is better defined.
Comment #5
mgiffordJust adding 2 links for the use of the Variable module:
I'd still like to see something in the handbook, but in the interim the project page of i18n is pretty definitive - http://drupal.org/project/i18n
Comment #6
longwaveThis patch is a proof of concept that will let you translate the six checkout completion message variables using i18n_variable.
You will need to apply the patch, download i18n and variable modules, and enable i18n_variable. Then at /admin/config/regional/i18n/variable select the variables you want to translate such as "Completion message header", and finally you will be able to change these variables per language at /admin/store/settings/checkout
Comment #7
longwaveClosed #582044: Checkout messages not available as multi-lingual values as duplicate as I think this can be solved here.
Comment #8
longwave#834290-47: Address fields are no longer multilingual variables and cannot be translated has a patch to add address field support for the Variable module as well.
Comment #9
longwaveCommitted #6.
Back to active, as all instances of i18n_variables in 7.x are obsolete and should be replaced with Variable hooks.
Comment #10
mandreato CreditAttribution: mandreato commentedHere's a patch to manage COD and checks policies of uc_payment_pack via i18n variables.
I've successfully tested COD.
Comment #11
longwaveThanks for working on this. I committed this with some minor changes; I set the actual defaults in uc_payment_pack.variable.inc, and removed uc_payment_pack_init() entirely as it is obsolete now.
Back to active to deal with the remaining cases.
Comment #12
mandreato CreditAttribution: mandreato commentedHere's a patch to manage two strings of uc_cart from #1893776: Can't change New account details help message in customer information pane of checkout settings.
Comment #13
longwaveThanks. Committed, with the addition of the other checkout instructions message.
I wonder if we should remove the alternative "Continue shopping" text option entirely, as you can translate that in the normal way already.
Comment #14
mandreato CreditAttribution: mandreato commentedTo which "Continue shopping" text do you refer ?
There is the custom continue shopping text in admin/store/settings/cart (continue shopping element) which is the label used in the cart page to let the user return to the product list after adding one product.
This is not translatable.
There is the just patched Continue shopping message in admin/store/settings/checkout (completion messages) which is the text shown after the checkout is complete.
I think both are useful.
Comment #15
longwaveI meant the "Custom continue shopping text". If you leave this field blank, the default text "Continue shopping" is used, and this is then translatable through the interface translation UI at /admin/config/regional/translate/translate (or through String Overrides, if you are only using English) - so it seems like we don't need to allow custom text here.
Comment #16
mandreato CreditAttribution: mandreato commentedI see. Well, it depends if someone needs to put there a text different from "Continue shopping", maybe "Go back to catalog" or something like that. In that situation it would not be correct to translate "Continue shopping" to a localized text with different meaning.
But this is not my case... so feel free to remove the "Custom continue shopping text"...
Comment #17
longwaveThe better supported way of changing any module-supplied text is String Overrides, that works without having to provide individual settings as Ubercart does here.
Looking through git history, it seems this feature was added in D5, along with custom text fields for various other snippets such as the Next and Submit buttons that have since been removed.
Comment #18
mandreato CreditAttribution: mandreato commentedHere's a patch to manage two strings of uc_stock.
Comment #19
longwaveThanks again. Committed, with an additional description for the notification subject variable, and the complete removal of uc_stock_init().
Comment #20
nerdcore CreditAttribution: nerdcore at OpenConcept Consulting Inc. commentedSame, for two string in shipping/uc_quote
Comment #21
nerdcore CreditAttribution: nerdcore at OpenConcept Consulting Inc. commentedComment #22
rfayIMO these should be rolled into a single patch and just get on with it. Without hook_variable_* we don't have any multilingual support.
Related patch to remove all the hook_init() cruft from D6: #2577915: Remove D6 cruft i18n_variables references in D7 version
Comment #24
longwaveCommitted #20. This only leaves: