Cart popup only taking text from default language

[six gun]

i have a Joomla! 3.8.6 site with VirtueMart 3.2.12
The site template is a Virtual Planet Smart.

i have several languages on the site. I do not have the language selector published as i have not finished translation but can switch between languages by changing the url
The site translates ok in the main.

i find when i click the add to cart tab the popup appears.
When the site is in say German i get this


The untranslated text in the case of 'Continue Shopping' is coming from COM_VIRTUEMART_CONTINUE_SHOPPING="Continue Shopping" in en-GB.com_virtuemart.ini in the language folder of components/com_virtuemart
If i alter this text in this file the text on the popup changes, say to 'Continue Shoppingxx'  .
The other language files are there but the site is not accessing these files for the popup.

i have looked through various forums and threads but i find no solution.
Any advice

[Jörgen]

Is the key found COM_VIRTUEMART_CART_PRODUCT_ADDED in Your language file ? Have You tried adding the key COM_VIRTUEMART_CART_PRODUCT_ADDED  as replacement text for BOTH front end and backend with Joomla language manager? This goes for the other two keys as well.

regards

Jörgen @ Kreativ Fotografi

[six gun]

i made a copy of the website on my PC and xampp - i was trying it out and noticed the pop-up translated.
i noticed the url had index.php in it - for some reason the url rewrite was not set to yes.

So when the site is set to url rewrite YES the pop does not translate.
When it is set to url rewrite NO the pop up translates.

Is this an issue with the .htaccess file?

##
# @package    Joomla
# @copyright  Copyright (C) 2005 - 2018 Open Source Matters. All rights reserved.
# @license    GNU General Public License version 2 or later; see LICENSE.txt
##

##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of mod_rewrite, but it may have already been set by your
# server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##

## No directory listings
<IfModule autoindex>
  IndexIgnore *
</IfModule>

## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes

## Mod_rewrite in use.

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site then comment out the operations listed
# below by adding a # to the beginning of the line.
# This attempts to block the most common type of exploit `attempts` on Joomla!
#
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

##
# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /

## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.

[six gun]

Well i finally worked out what was going on.
With URL Rewriting turned OFF - so we had index.php tagged onto the end of the URL's the popup would translate.
i did not want index.php on url's so this was a problem i was stuck with.
Along the way i had a backup site and i uninstalled sh404SEF - i had URL Rewriting turned ON.
The popup translates.
i am taking sh404SEF off the website b/c it is generated MASSIVE numbers of url's in the shop. There are only 6 items and a few other pages. Over 2600 url's built up. This is just stupid and it appears this is what happens so despite it being great for sorting out metadata it will have to go.

[jenkinhill]

i am taking sh404SEF off the website b/c it is generated MASSIVE numbers of url's in the shop.

There is absolutely no reason to use sh404SEF on a Joomla/VM website. Joomla's native SEF is all you need to get "good" URLs.

[six gun]

i got rid of sh404SEF and put the metadata directly into VM.

The site rocked a bit - quite a bit but i think (touch wood) i am through it now.

i hit a problem ditching sh404SEF. This component takes over the website - it becomes the command centre for URL's.
i also run another command centre for translations. Falang a fork of Joomfish. i used Joomfish in the old days and liked it - so when i came back to Joomla to have one of its replacements was natural.
The only multilingual associated part of the site was the homepage menu items. Everything ran off translated url's in sh404SEF and Falang.
This system can work really well except when Virtuemart visits the party. Then sh404SEF starts saving every url VM can potentially create. Six products in 2 categories and 4 languages - i hit over 2600 url's....and seemingly growing. No good.

When i removed Mission Control (sh404SEF) all seemed well except i ran into a problem switching between languages inside the shop. The url's were all over the place. i got 404's and page configurations i had never seen before.

After digging in the forum i found a potential solution. i bought the Studio42's Module Language switch for Virtuemart. After some stumbling i created brand new shop menu items and submenu items for all the language and associated all of them. With the Studio42 language switch published and this traditional setup for Joomla languages, it was sorted. i could switch between languages inside the shop and the pages look as i intend and no 404's.

Getting there - one step and a stumble at a time.

[six gun]

To finally round this one off.

In the end i took the Falang translation system off completely.
The shop was working a treat but the rest of the site was a mess with 404's all over the place when i switch between languages.
Running both the associated menu and unassociated menu items did not work. It was a mess.

So in the end i ditched sh404SEF and Falang. i am running with the Studio42 plugin so i can switch between languages in the shop perfectly and now everything is cool.

You either run with sh404SEF which takes over all the url's - it all works well except expect 1000's of links if you have a shop and if you have more than a handful of products expect 10's of thousands of links.
OR do it the basic Joomla way - a pain with so many menu's, cats and articles but it all works. Big plug for the Studio42 plugin.