Allow tax titles to be translated through i18n

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.

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.

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

Has this ever been solved? (maybe in another issue.. wishfull thinking? :))

I am having the same problem, is this issue solved?

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.

Here is a revised version of the patch that makes translation of tax rates and tax types independent from each other.

IMHO this is (no longer) a support request.

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.

Thanks for this patch, @cspitzlay. I've made a few changes:

1. commerce_tax.i18n.inc: Added a @file docblock and a newline at EOF.
2. Updated a couple inline comments to match coding standards (capitalization, periods).
3. Kept the blank line intact in commerce_tax_rates().
4. Added the sanitize => FALSE option 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.

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.

Sorry for the noise! I found one more instance to be capitalized, and replaced the double quotes in 'description' at the same time.

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:

1. Apply the latest patch.
2. Translate a tax rate's display title to another language.
3. Edit the original language's display title to something else.
4. Return to the edit tax rate form, the translation entered in step 2 is displayed in the admin interface for both languages.

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.

the issue with last patch is that use the translation values in all cases, including the Tax forms - inside commerce_tax_types() and commerce_tax_rates() functions.
i also found that the Commerce Tax (groups) strings are not updated.

here is patch that should fix these issues.

Should be rerolled on top of #1121722: Improve DX of instance translation since it has a commerce_i18n_object function that you can use to translate an entire object, instead of doing things like:

+  // Translate user-defined strings.
+  if (module_exists('i18n_string')) {
+    global $language;
+    $tax_type = i18n_object('commerce_tax_type', $tax_type)->translate($language->language, array('sanitize' => FALSE));
+  }

We should also try to use the "commerce" group (introduced by #1196488: Allow checkout completion message to be translated) instead of defining a "commerce_tax" group.

of course mister bojanz. it was only an intermediate step.
here is a patch that uses both commerce_i18n_object() function and "commerce" as translation group from the other issues patches.

#19: commerce_tax_i18n-1270624-19.patch queued for re-testing.

Just tagging this

For the record this issue also relates to shipping titles not being passed through the translate interface either... just thought I might mention it.

Sorry I just saw this was reported earlier

Patch #19 works for me with Commerce 7.x-1.8

#19 Worked for me too using Commerce Kickstart

#19 worked for me too. I also included the patch for the shipping service translation (https://drupal.org/node/1480654). Both are working fine now although in my first try, the shipping service didn't appear in the summary cart. Many thanks!!

When I try to Patch using #19, it asks me what file to patch, as far as I noticed from the Patch it also tries to create a new file called commerce_tax.i18n.inc

Can anyone explains the patching process here since it doesn't really make any changes to the current files?

and also is this issue fixed on latest commerce release ?

With the patch from #19 applied, my PHP goes out of memory when I refresh my site. My PHP memory is currently set at 512M.

Does anyone else experience this issue?

I'm getting the following error message after applying this patch and trying to save a tax:

PHP Fatal error: Call to undefined method i18n_object_wrapper::strings_update() in .../profiles/kepler/modules/contrib/i18n/i18n_string/i18n_string.module on line 851, referer: .../admin/commerce/config/taxes/rates/swedish-vat-25/edit

This patch is in conflict with rules_i18n. This make an infinite loop : commerce_tax_commerce_price_component_type_info() call commerce_i18n_object() which call rules_i18n module which call commerce_tax_commerce_price_component_type_info() too.

Seeing this too... flush cash and view your cart triggers infinite loop. Not sure it is this patch that is doing anything wrong. Disabled rules_i18n and everything works.