Posted by mstrelan on January 14, 2010 at 5:19am
| Project: | Ubercart 2 VAT support |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Renaming the tax to, for example, GST, does not replace VAT consistently throughout the site, particularly the admin interfaces. This is fine for web developers however when we provide sites to clients it can be confusing as to why there is GST and VAT.
Attached is a patch that fully supports the tax name.
| Attachment | Size |
|---|---|
| uc_vat_tax_name_full.patch | 10.05 KB |
Comments
#1
Agreed this is an issue, if 'VAT' is changed to 'GST', 'MwSt' or whatever the new tax name should be used consistently.
Attatched is a reroll against 1.x-dev.
Fixed the use of format_plural which should pass in args and not translated string already run through t().
I also left the permission as 'show prices excluding VAT'. Variable permission names create havock when exporting, e.g. a view which use this permission which is then exported as a feature.
#2
Unfortunately the above patch (which I can see is applied in 1.0 release) does not work with translations - ie. one cannot translate the VAT name - which is needed for multi-lingual sites.
I've attached a patch to latest release, which alters each to have t() around the variable_get() - inside the variable_get won't work.
#3
@klavs: You are not allowed to pass variables through t(). See http://api.drupal.org/api/function/t for details.
#4
Are VAT, GST and MwSt intended to be translated to other languages? As far as I know when referring to a proper noun or acronym it is generally kept in English.
#5
Hmm, the proverbial translation can of worms.
Not being an expert in translations all I can go on is the t() docs which, as longwave stated, show that variables cannot be passed through t().
Besides which the patch in #2 doesn't actually add consistent support for the VAT name (which is the point of this issue).
Any feedback on on #1?
#6
Sorry, I haven't had a chance to look at it.
#7
You are correct that the word: moms (danish), Value Added Tax (VAT - uk), Mehrwertsteuer(MwSt - german) etc. refers is the "official"name for the tax, in the respective country - but either there should be a way to show a question mark (to popup an explanation for the line item - with translatable text) - otherwise it needs to be translated somehow. In my case, atleast it would be "moms" in danish, and I'd probably call it "danish VAT" in english - so people understand what it is. Nothing pisses customers off more, than paying for something they don't know what is :)
I can see that you aren't suppose to pass variables to t() - and that makes sense.
I haven't found an example of a usersupplied string, that is translatable - but shouldn't the user-supplied name "feature" just be removed - since translations system will handle this through t() ?
Or perhaps there should be a translation popup somehow - however ubercart does not seem to have anything in place for describing line items.
I'll gladly whip up a patch with t('VAT') - instead of the user supplied string. This would IMHO be the best short term solution.
#8
Perhaps t() description needs to describe how you're suppose to translate user-supplied text - as I can find no mentioning of this.
But as VAT is the official short-name for it in english - and drupal is in english by default - I would think it would be okay to use that.
Afterall - if you want it to say MwSt (german) - you'd want to have german text as well - and if you want to talk to english speaking - you'd go i18n - and then you would just translate VAT into MwSt as you do with every other english string and content.
I can't imagine a usecase for the user-supplied VAT name - unless you want to use something like "Value Added Tax" instead of VAT. ?
#9
In Australia (and Canada) we call it GST (Goods and Services Tax), so that's my use case.
#10
Then the only solution seems to be translatable user-supplied text - right?
Who do you ask in drupal devel - to get an answer as to how this should be done - if not by using t() ?
#11
Support for translatable user defined strings requires http://drupal.org/project/i18n. You will need to add the required variable names to $conf['i18n_variables'] in hook_init, check how uc_store and uc_cart already do this.
edit: note that I only know this from looking at uc_cart code in the past, I have no idea how you go about actually translating the strings using i18n module - if someone can document this so I can include it in the module, that would help!
#12
See also http://drupal.org/node/313293
#13
@fenstrat: Thanks for your patch, I've finally found time to review and commit it. I made a few changes:
#14
Thanks longwave.
I now understand the use case for 'title callback'!
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
Hi,
i tried to translate the tax name in a multilanguage site by using module I18n (6.x-1.5).
On the page "admin/store/settings/taxes/vat" there is a hint "This is a multilingual variable" near the "tax name". But if i switch the language, i can't add another name for this variable.
For example it should be (in my case):
english: VAT
german: MwSt
spain: IVA
How can i change the tax name for different languages? Or is there any patch for 6.x-1.1?
Thank you very much for any help or hint,
Tobias
#17
Forgot to set the status from "closed" to "active" ...
#18
This issue was committed March 5th 2010 and so is already part of uc_vat-6.x-1.1
Like longwave in #11 I'm not familiar with i18n, but this issue made sure uc_vat supports it for the tax name. Have a look at http://drupal.org/project/i18n, and if you have success report back here and it could be incorporated into this module's documentation.
#19
I succeeded in changing the tax-name in "admin/store/settings/taxes/vat" by including the following line in the settings.php:
$conf['i18n_variables'] = array('uc_vat_name'
);
Now i have on the german admin-page:
YES: Add "including MwSt" or "excluding MwSt" to product prices.
YES: Add "excluding shipping costs" to shippable product prices.
"MwSt." is the changed Name for "VAT" – so it seems to work here ...
But if i go to "admin/store/settings/taxes" i can't see the changes in the table anymore:
There it still is "Name: VAT" and not "Name: MwSt"
I wouldn't bother about that, but the same behaviour unfortunately is on the product-pages (after flushing all caches):
English: Price: 0,00€ including VAT excluding shipping costs
German: Preis: 0,00€ inklusive VAT zzgl. Versandkosten
... it should be (in my opinion):
German: Preis: 0,00€ inklusive MwSt zzgl. Versandkosten
And on the german cart-page it says:
Subtotal excluding MwSt: 0,00€
VAT: 0,00€
Why is it translated on one place, but not on the other? Bug or feature? ;-)
Thanks for your help!
Tobias
#20
Shouldn't all of this go in a new issue called "variable tax name is not translatable"?
Personally if I was in Australia browsing a European website and the site mentioned GST instead of VAT I would find it rather odd, because as far as I know GST is an Australian/Canadian thing and it doesn't apply to orders I make from international stores.
Also I'm not sure how VAT and MwSt work, but in Australia GST is not applicable to international buyers so if my website mentioned that there was 10% VAT my European customers might expect to pay it.
#21
@tfranz You don't need to add
$conf['i18n_variables'] = array('uc_vat_name'
);
That was already added in when this issue was committed. So simply update to uc_vat-6.x-1.x-dev.
As for the other issues you're having I'm afraid I'm not sure.
@mstrelan I'd agree with you on a European store saying "GST" for Australian/Canadian customers would be wrong. But (from my limited knowledge of European VAT) this is how it works within the EU, i.e. it is a common VAT applied across EU countries, it's just that that VAT is called different things for each county, VAT, WmSt, etc
And yes, as mstrelan said, it'd be better to open a new issue called "Variable tax name is not translatable" and leave this one as closed.
[edit] @tfranz Try your translation again with uc_vat-6.x-1.x-dev - it should work.
#22
Thanks for your help: i tried uc_vat-6.x-1.x-dev, but it's not working either ...
I opened a new issue for that: http://drupal.org/node/898274