Hi,
I did search, but perhaps badly.
I would like the cart to automatically enter the correct localization based on the country the customer is visiting from. Right now it seems to be random chance what localization any given customer will see when visiting our store.
Right now (visiting from Taiwan) I am given our “Spain” localization which is clearly incorrect.
Can anyone suggest a way to make the localizations perform as expected, or is there an addon that can do this a bit better?
V.
It doesn’t work that way. Tech Support says there is no claim that it is supposed to work in that fashion. It doesn’t even read a registered user’s country and assign the localization correctly that way.
I wrote my own code using the Maxmind GeoIP PHP API to do it for my site and a customer’s site. It isn’t fool-proof but it works for my needs.
[quote name=‘vmajor’]Hi,
Can anyone suggest a way to make the localizations perform as expected, or is there an addon that can do this a bit better?
V.[/QUOTE]
I have been looking for the same thing, it is plain silly to expect that every customer visiting your shop would check and change the localization to their location this should be an automatic feature based upon visiting IP or their account shipping country. That is simple logic for a customer friendly site.
The closest thing that I can find in terms of a mod is this;
[url]Search results
Now what we need is some clever coders to take that mod a step further and extend it to automatically set the localization based on the visitors IP.
Not too difficult I would think for an experienced coder, their is an obvious need for this and I am ready to pay a reasonable cost for the mod and I am sure others are too!
I have done this for a customer, but only for currency. I’d assume that to have it work for “localization” would be quite different.
The issue comes into the mapping of countries (or even states/provinces/counties) to the correct localization. I.e. if their IP comes from somewhere in The Congo, do they get the FR localization or do they get EN or ?? Other subtlties exist like places where language varies from province to province but currency and weight remain the same or could even be dual (like Great Britan where Euro and Pound are both accepted).
Since this was done for currency for my customer, it came down to only 3 currencies that they wanted to support. USD, EUR and AUS. Basically we created a longitude/lattitude box that would be for EUR. Obviously if IP was from Austrailia they would get AUS and everything else was USD. But it doesn’t seem to be that simple for localizations.
Localizations can be very powerful, mixing currency, language and weights in any combination. Unfortunately, there’s a missing mapping of Country (or any other entity) to Localization…
[quote name=‘tbirnseth’] I have done this for a customer, but only for currency. I’d assume that to have it work for “localization” would be quite different.
The issue comes into the mapping of countries (or even states/provinces/counties) to the correct localization. I.e. if their IP comes from somewhere in The Congo, do they get the FR localization or do they get EN or ?? Other subtlties exist like places where language varies from province to province but currency and weight remain the same or could even be dual (like Great Britan where Euro and Pound are both accepted).[/QUOTE]
I am not sure why these factors would be an issue, Localization parameters for those factors are set by the shop owner within the Localization settings once the owner decides what language and currency etc for the geographical location they set them as required.
The issue here is not what options to select for each country the issue is that once the localization feature is enabled every time a visitor visits the store they have to manually select their own Localization option.
An automatic setting of mapping IP to country is what is required.
So if the visiting IP is the Congo as in your example then the localization option needs to be set to what ever localization option has been set for the Congo within the shop settings and of course currency and language would be what ever have been selected.
I honestly don’t think this would be hard for a experienced coder to set up, if
[url]Search results
Can detect visiting country from the IP and set the registration page country option accordingly then how hard would it be to set the Localization option to the one that has same country within the settings.
Localization option relates to selected ‘countries’ other options such as language and currency are simply user options that can be assigned as required.
If have my shop set up with a Localization options of;
Local - MY own country
International - Most other countries
Special - a few other countries
And of course I would set up the required parameters for each of those options, the problem is the customer has to select Local/International/Special themselves from the localization drop down list.
What we need is for the visiting IP to be detected and country to be determined and localization option Local/International/Special to be automatically selected based upon the countries assigned to those options within the localization settings.
I am not a PHP coder but even I can see this is not rocket science.
Getting the country of an IP is easy (and free for up to 2500 request/month) via ipinfodb.com.
One still has to figure out which localization to apply based on the country/state returned from the IP address (first match would make sense but might not always be correct).
You’re correct, it is probably reasonable to do. But I would assume that most (like myself) would have to research and become familiar with how localizations are used to do the work. It all just takes time.
I don’t know if a a location (country or state) can be in more than one localization. If so, then that would make doing a mapping based on IP ambigious. I.e. can Congo be in 2 localizations, one that has language=EN and one that has language=FR (or multiple currencies)? Unlike “locations”, I think it can since the DB table does not have a UNIQUE index, only the PRIMARY.
[quote name=‘tbirnseth’]Getting the country of an IP is easy (and free for up to 2500 request/month) via ipinfodb.com.
One still has to figure out which localization to apply based on the country/state returned from the IP address (first match would make sense but might not always be correct).
You’re correct, it is probably reasonable to do. But I would assume that most (like myself) would have to research and become familiar with how localizations are used to do the work. It all just takes time.
I don’t know if a a location (country or state) can be in more than one localization. If so, then that would make doing a mapping based on IP ambigious. I.e. can Congo be in 2 localizations, one that has language=EN and one that has language=FR (or multiple currencies)? Unlike “locations”, I think it can since the DB table does not have a UNIQUE index, only the PRIMARY.[/QUOTE]
I would have thought that query to a local data base would make more sense
[url]http://www.phptutorial.info/iptocountry/the_script.html[/url]
Having the same country set in different localization options would obviously have to default to one selection or another but I would think that most would not find the need for countries being allocated to multiple localizations if so then that clearly would be a unique or custom requirement.
All I, and I think many others, require are a basic features from the localization facility and of course for it to auto select at the initial connection.
Of course one possible hurdle would be to ensure that the auto-selection does not override the customers manual selection.
In your script, the mapping info must maintained as local data. Why not use a service that does this for you (and it’s their business) and can keep up with any industry changes that might occur.
You seem to know what you want done so all you have to do is hire someone to do it.
There are several of us on here who can do this work and do it in a maintainable manner with as much upgrade independence as possible. But it all takes time.
PM me and I’d be happy to give you a quote for either custom development or as an licensed addon. Creating a valid test environment is part of the overhead of doing the work unless you have a test environment setup already.
I’m sure there are others who will also PM you with a quote or to open dialog for the work.
Actually it appears that cs-cart already keeps an IP/country mapping data file. It can be accessed by the function fn_get_country_by_ip($ip).
How accurate it is, I don’t know.
The localization data is stored as a serialized array. Hence you can’t simply search for a localization that contains a country code. You will have to expand all the localizations and then search each to find one that contains the country you’re looking for.
Hmm… It appears as if the cart is already setup to do this.
In core/fn.init.php in the function fn_init_localization(), it does the following:
- Checks if a REQUEST param of ‘lc’ exists and if it’s value is in the set of localizations. If so, use it. Else check the cookie for the localization,
If the above fail, then get the country from the IP.
Get the languages from the DB.
Get the language of the Browser
Lookup the localization based on the Browser language AND the country
My guess this isn’t working for most because the user’s browser language doesn’t match what is set in the localization… Just a guess.
But for all intents and purposes, it does seem to be implemented to set the localization when the user first comes to the site and saves that info in a cookie for future use.
You can modify a couple of lines in core/fn.init.php by commenting out the browser language line and changing the query to not have language as a parameter, only use country.
[quote name=‘tbirnseth’]Hmm… It appears as if the cart is already setup to do this.
In core/fn.init.php in the function fn_init_localization(), it does the following:
- Checks if a REQUEST param of ‘lc’ exists and if it’s value is in the set of localizations. If so, use it. Else check the cookie for the localization,
If the above fail, then get the country from the IP.
Get the languages from the DB.
Get the language of the Browser
Lookup the localization based on the Browser language AND the country
My guess this isn’t working for most because the user’s browser language doesn’t match what is set in the localization… Just a guess.
But for all intents and purposes, it does seem to be implemented to set the localization when the user first comes to the site and saves that info in a cookie for future use.
You can modify a couple of lines in core/fn.init.php by commenting out the browser language line and changing the query to not have language as a parameter, only use country. [/QUOTE]
LOL kind of funny that various ppl have said they have been informed by CS Cart that Localizations are not meant to work that way, so it appears it was meant to work that way but it just does not because of a bug.
Well if you can come up with a working mod and you put it on your site for sale I am sure their are a number of ppl who would be interested.
Cheers
Obviously tbirnseth is far more fluent in CS-Cart than I am and could probably get this working much faster, but I am hot on the trail of setting the localizations up to work in a intuitive fashion.
I think I missread the code. Looking at 2.0.15, it ‘should’ work as it’s written. The key is the “OR (element=?s” in the following line:
$cart_localization = db_get_field("SELECT localization_id, COUNT(localization_id) as c FROM ?:localization_elements WHERE (element = ?s AND element_type = 'C') OR (element = ?s AND element_type = 'L') GROUP BY localization_id ORDER BY c DESC LIMIT 1", $_country, $_language);
I have not implemented a localization to review what’s actually written to the DB. If someone has localizations defined and Active, and can give me phpMyAdmin access to their DB, I’d be happy to try and figure this one out. I’m already invested at this point! 
Not quite sure what to say… I did the following to test this functionality.
I created 2 localizations:
USA (lang=EN, country=US, currency=USD) This is the “default”
Mexico (lang=EN, country=MX, currency=EURO)
(Mexico is just junk so I could see what’s happening)
I then went into core/fn.init.php and modified the function fn_init_localization() as follows:
- Made a change so the cookie is not loaded (wipes out any prior localizations)
- Forced $_country=“MX”
When I load my home page all works as I’d expect. The localization selector has Mexico selected.
So it appears that it’s working correctly but once you load with one localization that will become “YOUR” default…
You might try deleting your cookies for cs-cart.
Another way to test it is to set it to a localization that you would not normally use, then exit your browser and start a new one so that you are getting a clean initialization. It should come up with the last localization that was set.
Since I bypassed the geoip stuff in the above test, it might be that the problem is there for non-US IP addresses.
[quote name=‘tbirnseth’]
So it appears that it’s working correctly but once you load with one localization that will become “YOUR” default…
You might try deleting your cookies for cs-cart.
Another way to test it is to set it to a localization that you would not normally use, then exit your browser and start a new one so that you are getting a clean initialization. It should come up with the last localization that was set.
Since I bypassed the geoip stuff in the above test, it might be that the problem is there for non-US IP addresses.[/QUOTE]
Hmm well it sounds as if it is intended to set localization automatically but they just have not worked out all the bugs. I did note previously that the default localization in my shop was not loading as the default it was loading the 3rd created localization instead and even after manually setting the default on returning to the shop the 3rd created localization was still loading. I disabled the third localization in the shop admin and then re enabled it and then the default selection loaded normally, not sure if that was a persistent cookie issue or just a bug.
As far as auto setting based on IP I have tested several times via proxies from different geographical IP’s and it does not work.
Just emptied my cache and tested again via two international proxies and the default localization loads not the one for the proxies IP country setting. You would think at the very least that localization could auto set upon account login based on the shipping country but it seems not.
Here is another idea for a Mod that could be sold.
How about adding an admin option to set the default localization for each individual user account in the user accounts area, that way at the very least shop admin could specify which localization the shop should load for a specific user.
If you’d like to work together to diagnose this, PM me and I’ll work with you to figure it out.
At this point, I know enough about how it should work and simply need to add a little deugging output to see what’s going on. Since you have proxies from other countries, we should be able to figure it out in an hour or so.
I am starting to wonder if there is a problem with my setup.
It seems as if whenever a guest visits the store and either changes the Localization or CS cart changes it then that Localization becomes the new default for the next guest visitor.
The KB on both Locations and Localizations is VERY deficient.
On reviewing my set-up TBO I don’t really understand what the point of Location is because the options seem to just duplicate the countries in Localization.
Localization can be linked to pretty much everything within the store including Locations which seems pointless as you nominate countries in Localizations anyway.
Locations on the other hand don’t appear to be linked to products etc.
So what is the purpose of Locations?
Do these fields need to completed for each defined location, currently I have left them blank?
Zip/Postal codes
Cities
Addresses
Presently I have 3 Localizations and 3 corresponding identical Locations with the same countries and states in each (seems like pointless duplication to me).
So what am I missing?
Do I even need to have any locations configured to use Localizations?
Not sure you’re missing anything… As I understand it:
Localizations - used for setting the default language, currency and optionally a special weight method.
Locations - used to determine shipping and taxes only. I.e. they are much more granular than Locallizations. Localizations only deal with language and currency and DRIVEN by country (and browser language).
Once a Localization is selected, it is stored in a cookie in your browser so that you get the same localization on the next page load. However, it should not change the default of the system, but without using separate browsers to test, it will be very difficult.
It took me a long time to really internalize Locations. I only started looking at Localizations when exploring this thread, mostly because it sounded interesting…
Still having ongoing issues with this faulty feature in CS Cart.
I have three very simple Localization settings
1 - Australia [default and all products]
2 - International [Some products to most international destinations]
3 - International (Our Students) [All products to a few international destinations]
Regardless of the fact that Australia is set as the default localization every time a shop visitor changes the Localization to a new localization then Australia ceases to be the default localization for all visitors. The only way to rectify it is to disable the “phantom default” localization for a day or two.
When you have product restrictions to certain destinations due to contractual obligations it is incredibly annoying that those restrictions end up apply to all customers incorrectly because CS cart localization feature simply does not work properly.
It has nothing to do with browser cache etc as I am clearing cache and have tried all sorts of things to get this to work properly consistently but its just faulty.
I just don’t see that in the code. Localization is only kept in a cookie What’s your URL, I’ll try to access it (since I’ve never been there before) and tell you what I see as a default. Or send me an email at XXtonyb@XXez-ms.comXX without the X’s and we’ll synchronize the test. I.e. you can set it to something other than Austrailia and then I’ll go to your site and tell you if the default is Austrailia. My bet is that it will be.