The ip_locator_country stores language names in capital letters.
$_SESSION['ip_locator_country'] gives "UNITED STATES US" and "GERMANY".

While this might have been a non-issue overall, it arises as a problem when used for a simple print.
Think, "And this is our nice guest userfoo from UNITED STATES US!".

It's even more of an issue when translating the country in the interface. As far as I know, this would create "UNITED STATES US" as the English string when using t($_SESSION['ip_locator_country']). Translators would not like that.
It is easier to capitalize the names after reading them from the database than to derive non-capitalized names from the current situation.

Before I start creating an additional 'english_name' field for the ''ip_locator_country' table that reads the country code as 'United States' and email the SQL to you:

a) Do you mind adding this additional field to the database table from a SQL file I send to you?
b) You may already have a non-capitalized list of country names?

Comments

he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented

There is line 

$country_name = $_SESSION['ip_locator_country'] = $row['country'];

My ip_locator_country table contains 'UNITED STATES', not 'UNITED STATES US'. Could you test it again on your side please? If your table also contains 'UNITED STATES' then the $_SESSION variable we talking about cannot be wrong.

PS: Sorry for the late response. I didn't observed this issue.

daniel_h’s picture

daniel_h commented

will do

daniel_h’s picture

daniel_h commented

There is "UNITED STATES" in my ip_locator_country table, too. As in the $_SESSION variable, consequently.
Funny, my fault. Didn't double-check, sorry :)

Still, there are country names like "PALESTINIAN TERRITORY, OCCUPIED" not suitable for output. A private filtering function will handle those easily, though, for people who need it. No need to change anything in the module, I think.

Someone might already be doing a

if ($country_name == "MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF") {...} else { fail; }

In this case, modifying those strings now might hurt someone's code. Maybe.
If you agree to this, then those strings should only be modified when there is actually a modification of the ISO code country names.

daniel_h’s picture

daniel_h commented

What remains, is the issue of "CHINA" versus "China".
Capitalized English strings are not suitable for $output= t($country_name) translation. That is because "UNITED STATES" is not the original name, obviously.
t('CHINA') would enter 'CHINA' as the English term into the database for translation. Correct?

So what do you think about adding the row 'country_name' to the ip_locator_country table. So we would end up with country_code ('CN'), country (CHINA, for ISO names), latitude, longitude, and country_name ('China').
Complete with a return value somewhere in ip_locator_country() or a new function.

This would enable developers to

ip_locator_country(..., $user_country, ...);
and then
print 'Name: ' . $username . 'Country: ' . t($user_country);
or
print 'Shipping is free in' . t($country);

I mean, wherever the $country_name needs to be actually printed, it can be t()-translated.
What do you think?

he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented

I think that will be better if we write a script which transforms the actual country names into the form you want.

he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented
Status: Active » Closed (won't fix)
he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented
Status: Closed (won't fix) » Fixed

Fixed in 6.x. Thanks.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Project: » Lost & found issues

This issue’s project has disappeared. Most likely, it was a sandbox project, which can be deleted by its maintainer. See the Lost & found issues project page for more details. (The missing project ID was 179598)