richguy Posted September 21, 2017 Share Posted September 21, 2017 Hello We've made some alterations to the language files which are applied when a customer isn't logged in - smashing. However when the customer logs in these revert to default. An example: on the address page, we changed company_name from "Company Name" to "Company name (if needed)". This works when the customer isn't logged in, however should a registered customer want to add a new address when their logged in, the field says "Company Name". This goes for any changes we've made. It seems a remarkably similar issue to this poor person who translated his language strings into Lithuanian only for it to revert to English when a customer was logged in This didn't seem to get resolved so any help appreciated. Thanks T CubeCart Version 6.1.10 PHP Version (5.6 Recommended) 5.6.30-0+deb8u1 MySQL Version 5.5.5-10.1.26-MariaDB-0+deb9u1 Image folder size 15.91 MB Download folder size 0.00 KB Max. Upload filesize 30M Browser user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:55.0) Gecko/20100101 Firefox/55.0 Server Software Apache/2.4.25 (Debian) Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 21, 2017 Share Posted September 21, 2017 Please check the database table CubeCart_customer. You will need an external utility for this, such as phpMyAdmin. In the column 'language', it may contain a default value. When a customer first registers, or gets registered as a ghost when checking out as a guest, CubeCart uses the language currently in use (not necessarily the config default) to set the 'language' column. (I am not seeing any code on how the customer or admin can later change that.) Then, depending on certain conditions, a complete group of language strings could have been databased in CubeCart_lang_strings. These are loaded last, overwriting strings loaded from language files. (You mention making alterations to the language files. We recommend using CubeCart's admin Language editor.) Quote Link to comment Share on other sites More sharing options...
richguy Posted September 21, 2017 Author Share Posted September 21, 2017 Thanks - we'll have a look. (It is the language editor we use - please excuse my hamfisted terminology.) Quote Link to comment Share on other sites More sharing options...
nathanbright Posted September 22, 2017 Share Posted September 22, 2017 Yep, that's exactly what has happened. The _lang_strings table has 1669 entries, all en-GB The _customer table has en-US for all registrations until 6th June, after which all are en-GB That coincides exactly with the date we upgraded to 6.1.8 So, any suggestions what we do about it please? Quote Link to comment Share on other sites More sharing options...
keat Posted September 22, 2017 Share Posted September 22, 2017 (edited) Disregard the following, I misread your message. Was every customer en-US ? If so you may be able to use an sql script to change them from en-GB back to en-US. Using PHP MYAdmin, make a backup copy of the table CubeCart_customer. (very important to make a copy first) Then run the following sql script. UPDATE `CubeCart_customer` SET `language` = replace(language, 'en-GB', 'en-US') Edited September 22, 2017 by keat Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 22, 2017 Share Posted September 22, 2017 We would also like to know if: comparing the default language you have set in admin, Store Settings, and which of the languages you have enabled in admin, Languages, if the only enabled language is the same as the default language. Quote Link to comment Share on other sites More sharing options...
nathanbright Posted September 23, 2017 Share Posted September 23, 2017 I should have said, doh Default language (Store settings): English (UK) and fwiw that is the only language in the drop-down Admin->Languages has two entries. The master entry is read=only, nothing to selsect / change. The second is seclected Master Language File (definitions.xml) (tick) English (UK) So, yes, the only enabled language is the same as the default language (English(UK)) Checking my debug session variables I see that there are both en-GB and en-US in there '__client' => 'useragent' => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 'session_start' => 1506167490 'session_last' => 1506167513 'currency' => GBP 'admin_id' => 1 'language' => en-GB 'user_language' => en-US I wonder where it is getting en-US for user_language Thanks for the thought Keat. I expect we'll get to the point of doing something like that. But first we need to understand why this is happening, get to the cause as it were I have this all on a staging server that I can readily try things out on. I am tempted to try deleting all the _lang entries and see if they get re-created with the next order But before that I'd appreciate any further insights AHA - re-reading your first post bsmither (and thanks for the help) I just checked the default on the language field in the _customer table, it's en-US Could it be that a recent code change is now paying attention to that, triggering the DB language install? Quote Link to comment Share on other sites More sharing options...
nathanbright Posted September 23, 2017 Share Posted September 23, 2017 Right, a bit more info If I log in as a user registered last year, whose language is en-US, then the default text is displayed Logging in as a newly registered user, whose language is set as en-GB, things appear to work correctly, using the language overrides SO It appears that before June 6th users were being registered with en-US and it was using the (en-GB) language override when they logged in Since June 6th new registrations are being assigned language en-GB and are also using the en-GB language override The problem only arises when a prior-to-June-6th user logs in at which point they are seen as "normal" and do not get shown the language overrides Obvious solution steps include: (1) change all existing _customer language values from en-US to en-GB; (2) set the default on the _customer language field to en-GB (though I think this is what the new code is now doing, asserting this value rather than defaulting) My only question (assuming the above is correct) is "is there any way a new customer can get registered with any language other than en-GB?" (We don't have any other language enabled anywhere I know of) Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 23, 2017 Share Posted September 23, 2017 (edited) In the CC6110 code I have looked through, no, a newly registering customer will have the language being used set in their customer database record. That is to say, if you have en-GB and es-ES (Spanish) enabled, and the registrant is viewing the site in Spanish when the Submit button is clicked, then the customer's record is inserted into the database with Spanish as their language. (And no obvious way to change it later.) That does not answer the question (needs exploring) of, should the admin then disable es-ES, what will this registered customer see? Spanish, though disabled, it is still installed? It may be worth making the experiment of deleting all languages you do not want your store to have. Thus, what would happen if the Spanish customer logs in, but there is no Spanish language installed? What will that customer see? (I'll put that on my list of things to examine.) Edited September 23, 2017 by bsmither Quote Link to comment Share on other sites More sharing options...
nathanbright Posted September 26, 2017 Share Posted September 26, 2017 Agreed, those are interesting questions and relevant to on-going CC development But to be honest, my concern is working out how the change from en-US to en-GB in customer records arose? I assume the code is the function createUser() classes/user.class.php where the code sets the user language thus $data['language'] = $GLOBALS['language']->current(); Ah, yes, that line is not present in 6.1.7, new in 6.1.8, so the DB table field default en-US was being set Ok, now I am satisfied I understand the issue, I can readily fix up the DB Thanks again for your help Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.