I'm using the latest VM, and for my VAT rule, I defined a language constant in English and Portuguese: COM_VIRTUEMART_VATRULE="VAT (23%)" (and for the PT: "IVA (23%)").
I placed this language constant into the VAT rule, the .ini files for my template and at the language override for the admin in both languages.
When I go to the rule definition, it is correctly trranslated in the back-end.
At the front-end it is correctly translated.
The issue is when the checkout is done and the system sends the email, the column for the VAT displays the constant (COM_VIRTUEMART_VATRULE) and not the translated value!
The same happens at the order edit at the back-end (at the details table) and also at the product edit (the caption at the price "Tax Affecting:") although the VAT rule at the dropdown is translated!
I even placed the constant + value at the language override of the front, but no luck!
How can this be solved?
Another unknown Vm version and perhaps unknown template overrides ?
Jörgen @ Kreativ Fotografi
I'm using the latest VM: 3.8.8 10472
Joomla 3.9.25
I don't have any overrides for the email product list, nor the admin template.
I'm using the new admin template. I know it's a beta, but the same happened with the original template, I just tested it.
Have you tried it yourself?
QuoteI even placed the constant + value at the language override of the front, but no luck!
What does this mean ?
Jörgen
Are you using <?php echo vmText::_('COM_VIRTUEMART_VATRULE') ?> to display the text in the templates?
No, only. place in DB as name of rules and into ini file for template, isn't it? :)
The best is to show you:
When I create the VAT rule, I place the constant at its title field, and it displays correctly at the back-end:
(https://i.ibb.co/KbprnGR/back-end-field.png) (https://imgbb.com/)
The list of the VAT rules prove that it is translated (I have it translated in all languages at my .ini files for the overrides and front language .ini files):
(https://i.ibb.co/1r7h3tB/back-end-field-2.png) (https://ibb.co/5rGtdgC)
At the front it displays correctly:
(https://i.ibb.co/kyx5ss1/front.png) (https://ibb.co/VNtJccm)
It's when it sends the email that it starts to show the issue:
(https://i.ibb.co/7VHLVZb/email.png) (https://imgbb.com/)
Also at the product details setup at the back-end (Note that at the dropdown it is translated, but the caption on the right is not):
(https://i.ibb.co/7xmm5XR/back-end-product.png) (https://ibb.co/nqJJvbn)
At the orders, not translated:
(https://i.ibb.co/LYJXhCg/order.png) (https://ibb.co/fqnzGCN)
Also I found out that even if I change the translation, or even remove the constant, the emails sent for this order (if I change the state of the order I have it set-up to send an email), it always sends with the original (in this case) issue (not translated)!!
Can anyone help me, please?
for virtuemart exist more then one ini file
But the language override for the admin should be enough, it overrides everything in the back-end.
What other overrides are there for the back-end?
(note that I don't want to touch the original language ini files, as soon as the component is updated, the changes are gone).
IVA 27% an VAT is not the same language key. It is hard to follow your example.
I would guess that You should check Your overrides to see if this is included correctly:
<td style="text-align: right;width: 11%;"><strong><?php echo vmText::_('COM_VIRTUEMART_ORDER_PRINT_SUBTOTAL_DISCOUNT_AMOUNT') ?></strong></td>
Jörgen @ Kreativ Fotografi
If you translate in the right language in front+admin. It should be right
Adding a language key in the template is not always used, so use standard Joomla override for each language.
Quote from: Jörgen on April 05, 2021, 22:46:36 PM
IVA 27% an VAT is not the same language key. It is hard to follow your example.
My example at the back-end is in English and the Front is in Portuguese.
All is working as expected in the front! Sorry for not having it in English, I assure you the translation also works in the front for every language.
Also, how can you explain that the constant is correctly translated in the back-end in the VAT rule definition (I've switched my language to see it in Portuguese and English and it is translated).
What I've found is that VM saves the VAT rule into this table: #__virtuemart_order_calc_rules and in the column calc_rule_name it places my constant and not the translated value.
Quote from: Studio 42 on April 06, 2021, 09:02:21 AM
If you translate in the right language in front+admin. It should be right
Adding a language key in the template is not always used, so use standard Joomla override for each language.
That's what I'm doing, as explained, I have used the labguage override for the admin in every language (stored in /administrator/language/overrides), and it partially works (as explained and detailed in my examples), and also at my template language files (in my template files), and as shown, it works.
The only thing that doesn't work is at the email, orders and partially at the product edit.
The key is where VM updates the db with the constant for the VAT rule, it is ignoring the translation.
Could any of you try it by yourself? it doesn't even need to be multi-language. Just place a constant into the VAT rule and translate it in the language overrides and in your template language, then see what happens.
QuoteThe key is where VM updates the db with the constant for the VAT rule, it is ignoring the translation.
Why should is store the translated value ? And if it did in which language, the calcs table should be for all languages right ?
Jörgen
Quote from: Jörgen on April 06, 2021, 10:29:26 AM
QuoteThe key is where VM updates the db with the constant for the VAT rule, it is ignoring the translation.
Why should is store the translated value ? And if it did in which language, the calcs table should be for all languages right ?
Of course not, I just pointed out the place where the constant is saved in that particular table, and it may help the devs. I don't appreciate your sarcasm.
Also, did you read that even if I change the VAT rule name (can even be something not to be translated), it will always use the initial one that the order used? (the initial one saved in the database table for that order).
Have you tried it yourself? I'm curious to see your findings.
I'm positive this is not working correctly and either there is a place for this kind of translation (which may not be standard, because I'm more than used to do this kind of translations with the ini files and ini overrides), or there is a different techinque to translate these elements? (like the one for the products, where VM has a table for each language).
I know when I am not wanted, this is not sarkasm ...
Jörgen
Quote from: Jörgen on April 07, 2021, 08:17:22 AM
I know when I am not wanted, this is not sarkasm ...
This not a matter of not being wanted, I just want to stick to the topic and get this fixed.
What I would like is to understand if there is a way to translate this kind of elements. Either the constant is not the way to go, or there is another way to do it.
I could override it in the code (when VM reads it from the db I would make sure it would translate it), but that would be destroyed each time VM is updated.
"Could any of you try it by yourself? it doesn't even need to be multi-language. Just place a constant into the VAT rule and translate it in the language overrides and in your template language, then see what happens."
It is clear that the order edit and some other areas use the function "getTaxNameWithValue"
This simply uses the stored calc_rule_name value so - you could adjust the function to translate if it finds the appropriate Language key
BUT - this does not take into consideration the tax country of the sale - which would need to be considered for Tax name disclosure.
I am also not certain that it considers the customer language for multi country sales - and the shipping country to which the tax charge is relevant
The first place to "adjust" for a translation is:
\components\com_virtuemart\helpers\shopfunctionsf.php
static public function getTaxNameWithValue($name, $value){
$value = rtrim(trim($value,'0'),'.');
// quorvia attempt to translate the name
$name = vmText::_($name);
if(empty($value)) return $name;
if(strpos($name,(string)$value)!==false){
$tax = $name;
} else {
$tax = $name.' '.$value.'%';
}
return $tax;
}
You should see that this function is used in a number of VM views - including invoices - carts - mail etc
Add the variable to your language files for FE and Admin
I have shown the translation working in BE and the value that is stored in the calc_rule_name
I have also shown you the customer email for an order update
Quote from: AH on April 07, 2021, 11:54:58 AM
It is clear that the order edit and some other areas use the function "getTaxNameWithValue"
(...)
Great find and update AH, thank you!
I'm going to test it, but from what you've shown, it works.
Any chance for this updated function to go into production in the future?
I have asked the devs to look at this option for future releases
I cannot confirm that it will definitely make the release
Thank you AH, I'm going to change this topic into [SOLVED]