Posted by jserveaux on September 6, 2011 at 9:12am
10 followers
| Project: | Drupal Commerce |
| Version: | 7.x-1.x-dev |
| Component: | Tax |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
When you create a custom tax, the display title is not translated. I assume you can translate it by using hook_commerce_price_formatted_components_alter() but imagine a user who need to add a tax rule temporarily, he can't translate it without developpement.
Comments
#1
The patch above considere the tax title translation.
#2
Hmm, well, we cannot translate it by wrapping a variable with t(), as that function is reserved for string literals. What we'll need is some way to integrate with a translation module to expose those fields to translation interfaces. I don't have a lot of experience here, but you might ping das-peter in IRC about it.
#3
Since taxes aren't entities ( or do I miss something - there's no hook_entity_info()) we can't use the entity_translation / title team.
Looks like a case for i18n / i18n_strings - but my experience with this modules is very limited.
#4
subscribing.
It seems the best solutions (Title or Entity Translation) modules will not be able to help here, because the Taxes are no entity (?) or if they are, not a fieldable entity.
Edit:
Didn't see peter's reply yet. I'll check how we can translate this. http://drupal.org/project/variable perhaps, but I don't think it's a variable either.
Will have to dive into the code some more
#5
Has this ever been solved? (maybe in another issue.. wishfull thinking? :))
#6
I am having the same problem, is this issue solved?
#7
This patch implements translation of user-defined strings in tax rates and tax types via i18n_string.
Make sure you check "Commerce tax" and hit "Refresh strings" on the string admin page:
admin/config/regional/translate/i18n_string
Then you should be able to translate the strings on the regular interface at:
admin/config/regional/translate/translate
Please let me know if it works for you.
#8
#9
Here is a revised version of the patch that makes translation of tax rates and tax types independent from each other.
#10
IMHO this is (no longer) a support request.
#11
Fair enough, but let's categorize it as a feature request, as there is no actual bug in the code, just lack of integration with a third party module.
#12
Thanks for this patch, @cspitzlay. I've made a few changes:
sanitize => FALSEoption to prevent double encoding. Without this, I think tax rates and types end up going through check_plain() twice and if you have an apostrophe, ampersand, etc. in your translation it will be double encoded.#13
Actually, I think "Tax" should be capitalized on the string refresh page because it refers to the module - "Commerce Tax" instead of "Commerce tax". I've left "Commerce tax rate" and "Commerce tax type" as is.
#14
Sorry for the noise! I found one more instance to be capitalized, and replaced the double quotes in 'description' at the same time.
#15
Unfortunately this seems to have a similar bug as reported in #1480654-5: Use i18n string to translate the title or display_title of the flat rate shipping services. where the translated values are sometimes displayed in the tax rate/tax type edit form. The edit forms should always contain the untranslated values, so setting to CNW for now.
Steps to reproduce:
#16
See http://drupal.org/node/1534468 for more information about why the double encoding is happening. Internationalization's i18n_string() API changed in i18n 1.5.