Separate country table

[wking]

Instead of trusting airport.country and site.country to avoid duplicates, its easier to just have a country table that can be referenced from other tables. This also makes it easier to enforce canonical spelling (e.g. by requiring admin credentials to add new countries).

[rbeagrie]

I agree with this, and I've had good results with the 3rd party package django-countries (https://pypi.python.org/pypi/django-countries) on some of my other django sites.

[gvwilson]

As long as the mapping from country names in the database to flag files in site/img/flags//.png remains the same - I do not want to have to either rename flag files (since they're from a third party) or adjust a couple of hundred old workshop websites.

[wking]

On Sun, Dec 14, 2014 at 02:54:52PM -0800, Greg Wilson wrote:

I do not want to have to either rename flag files (since they're from a third party) …

It looks like django-countries comes with flag icons 1.

… or adjust a couple of hundred old workshop websites.

A one-off cost. I'm happy to do this automatically if it lets us use a popular external package instead of rolling our own country implementation.

[gvwilson]

As long as workshop website creators keep putting full country names in their pages (i.e., nothing there needs to change), this one sounds good. Let's defer 'til key features are in place then revisit.

[wking]

On Sun, Dec 14, 2014 at 03:45:50PM -0800, Greg Wilson wrote:

As long as workshop website creators keep putting full country names in their pages (i.e., nothing there needs to change), this one sounds good.

We used to use Jekyll and YAML metadata for this. Is the idea that we're going to pull it out from the workshop's metadata (swcarpentry/lesson-template#80)? Why don't we replace the workshop-template's:

1. Edit index.html. Hints are embedded in the file, and full instructions are in CUSTOMIZATION.md.

and:

1. Send the workshop coordinators the URL for your GitHub repository.

With “badged instructors can log into amy.software-carpentry.org and register their workshops.” Then folks can select the country from the dropdown list, and add a URL for their website if they have one, and nobody needs to care what our backend representation looks like. That lets you centralize metadata validation in amy, instead of duplicating code in amy and lesson-template's tools/check.py. It also means central SWC coordinators don't need to get involved in this stage, which should reduce the burden on the central administration.

Requiring folks to fill in a web form may be a bit tedious, but how many workshops will one instructor be registering? If we really want to automate this, we can always give amy a JSON API.

[gvwilson]

OK, but let's defer until the features that the admins need to organize workshops are in place - regularizing country name management is less of a priority to them than being able to match instructors by location and skill, upload of attendance lists from CSV files, etc.

[gvwilson]

@wking was right: we should add a country table so that when we're editing a site, we can select its country from a pulldown instead of typing it in. These are the country names that match the flags we have:

Abkhazia
Afghanistan
Aland
Albania
Algeria
American-Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua-and-Barbuda
Argentina
Armenia
Aruba
Australia
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Basque-Country
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia
Bosnia-and-Herzegovina
Botswana
Brazil
British-Antarctic-Territory
British-Virgin-Islands
Brunei
Bulgaria
Burkina-Faso
Burundi
Cambodia
Cameroon
Canada
Canary-Islands
Cape-Verde
Cayman-Islands
Central-African-Republic
Chad
Chile
China
Christmas-Island
Cocos-Keeling-Islands
Colombia
Commonwealth
Comoros
Cook-Islands
Costa-Rica
Cote-dIvoire
Croatia
Cuba
Curacao
Cyprus
Czech-Republic
Democratic-Republic-of-the-Congo
Denmark
Djibouti
Dominica
Dominican-Republic
East-Timor
Ecuador
Egypt
El-Salvador
England
Equatorial-Guinea
Eritrea
Estonia
Ethiopia
European-Union
Falkland-Islands
Faroes
Fiji
Finland
France
French-Polynesia
French-Southern-Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
GoSquared
Greece
Greenland
Grenada
Guam
Guatemala
Guernsey
Guinea-Bissau
Guinea
Guyana
Haiti
Honduras
Hong-Kong
Hungary
Iceland
India
Indonesia
Iran
Iraq
Ireland
Isle-of-Man
Israel
Italy
Jamaica
Japan
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Kosovo
Kuwait
Kyrgyzstan
Laos
Latvia
Lebanon
Lesotho
Liberia
Libya
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Mars
Marshall-Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia
Moldova
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
NATO
Nagorno-Karabakh
Namibia
Nauru
Nepal
Netherlands-Antilles
Netherlands
New-Caledonia
New-Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk-Island
North-Korea
Northern-Cyprus
Northern-Mariana-Islands
Norway
Olympics
Oman
Pakistan
Palau
Palestine
Panama
Papua-New-Guinea
Paraguay
Peru
Philippines
Pitcairn-Islands
Poland
Portugal
Puerto-Rico
Qatar
Red-Cross
Republic-of-the-Congo
Romania
Russia
Rwanda
Saint-Barthelemy
Saint-Helena
Saint-Kitts-and-Nevis
Saint-Lucia
Saint-Martin
Saint-Vincent-and-the-Grenadines
Samoa
San-Marino
Sao-Tome-and-Principe
Saudi-Arabia
Scotland
Senegal
Serbia
Seychelles
Sierra-Leone
Singapore
Slovakia
Slovenia
Solomon-Islands
Somalia
Somaliland
South-Africa
South-Georgia-and-the-South-Sandwich-Islands
South-Korea
South-Ossetia
South-Sudan
Spain
Sri-Lanka
Sudan
Suriname
Swaziland
Sweden
Switzerland
Syria
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad-and-Tobago
Tunisia
Turkey
Turkmenistan
Turks-and-Caicos-Islands
Tuvalu
US-Virgin-Islands
Uganda
Ukraine
United-Arab-Emirates
United-Kingdom
United-Nations
United-States
Unknown
Uruguay
Uzbekistan
Vanuatu
Vatican-City
Venezuela
Vietnam
Wales
Wallis-And-Futuna
Western-Sahara
Yemen
Zambia
Zimbabwe

[pbanaszkiewicz]

I'm suggesting using django-countries for this task.

The issue with flags can be solved by symlinking country name to it's ISO 3166-1 ID (for example Poland.png → PL.png, United-States.png → US.png).

Any thoughts, anyone?

[gvwilson]

Yeah, I've been trying to avoid having to rename (and then manage) a few hundred flag files, but if we have a script, and we trust it...

[wking]

On Thu, May 21, 2015 at 11:26:07PM -0700, Piotr Banaszkiewicz wrote:

I'm suggesting using django-countries for this task.

Yes, please.

The issue with flags can be solved by symlinking country name to it's ISO 3166-1 ID (for example Poland.png → PL.png, United-States.png → US.png).

Why symlinks? Can't we just migrate the existing country links and invalidate new events that don't use ISO country abbreviations?

[pbanaszkiewicz]

I started thinking about these flags and I'm a little bit confused. Why do we need to take care of the flags? Why does something internal to Amy affect something external (@swcarpentry/site)? In what ways are country names used within Software Carpentry? And where are they used?

[gvwilson]

1. The home pages for workshops have a 'country' field in their YAML header.
2. When we rebuild the main website, we harvest that and add an <img> on the home page that points to img/flags/16/COUNTRY.png to show where each workshop is.
3. The country names we require people to use in their home pages were selected based on the names of those image files, e.g., United-States.png (with a hyphen).

[wking]

On Fri, May 22, 2015 at 10:57:38AM -0700, Piotr Banaszkiewicz wrote:

I started thinking about these flags and I'm a little bit confused. Why do we need to take care of the flags? Why does something internal to Amy affect something external (@swcarpentry/site)? In what ways are country names used within Software Carpentry? And where are they used?

I'm not sure what the current state of Amy is in this respect, but the idea was that a bunch of event metadata is encoded in the configuring YAML in an event-website repository (e.g. 1). Existing workshops will be using the old names, so the importer (if we have one) will either have to accept them or translate to the new ISO names. We can deprecate (but still support) the old names for a transition period, and then remove compatibility with the old names and require ISO abbreviations for new events.

[pbanaszkiewicz]

Hi @wking and @gvwilson, thank you for answers. I think I get it now.

I think I'd like us to follow a standardized way (ie. ISO 3166-1), but I'm too lazy to change all the past events.

@gvwilson:

1. When we rebuild the main website, we harvest that and add an <img> on the home page that points to img/flags/16/COUNTRY.png to show where each workshop is.

Does this mean that every time the main website is rebuild, we harvest metadata from ALL past events?

[gvwilson]

We only harvest metadata from GitHub for events in the last few weeks, and all upcoming - everything else is cached (see config/archived.yml in the site repo). It would be easy to change the country field for archived sites, and add a lookup table to the harvester as people are transitioning from United-States to us.

[wking]

On Fri, May 22, 2015 at 11:36:29AM -0700, Piotr Banaszkiewicz wrote:

I think I'd like us to follow a standardized way (ie. ISO 3166-1), but I'm too lazy to change all the past events.

We'll need the old-style-name → ISO mapping either way. I think using that map in the database migration to populate the new country foreign keys and then using it again to handle backwards-compatible event imports during a deprecation period don't sound too bad. I'll take a stab at this (at some point in the next two months ;) if you're too busy ;).

[pbanaszkiewicz]

@gvwilson is the harvester written in Python? Can you point it to me?

@wking I'd like to close #288 as soon as possible, because it migrates the database and I don't like to juggle databases when I checkout different branches. And by the way – I was surprised by this – django-countries doesn't use foreign keys. It uses CharField with limited choice, it's working pretty good.

[gvwilson]

Look at bin/workshops.py in the site repository.

[pbanaszkiewicz]

Closed via #288.