Cross-linking between families...

FI : for Finland please...

don't use NL; the international genealogy standard for the Netherlands is NLD. Tis is a USA site, so, if you upload NL you get Netherlands, but the inernational English name is the Neterlands, Every country should be mentioned in the own language, so if you want to take the time for that USE NEDERLAND

Your are right, Fred Bergman, in text circumstances, but it does NOT work in the country-field for input of profile-birth-death-marriage-&-burried-places. I experienced a lot with the possibilities and had to change a lot of profile, for it did NOT work with NLD, you see?

I ask this ONLY to have the geni-search-engines work properly to help us find the right profiles in the right localities, would be very pleased if it would be also possible to use a scroll-field for the country in the INPUT-page, for that would make a lot less faults, like for our NLD:

* Pay-ba
* Pays-BAS
* HOLLANDE
* niederland
* Netherland
* lage landen

Just to give some examples of FAULT-input that make the profile NOT TO FIND ever again on his right territory....

I knew, but do we have to follow wrong codes? No, then better just the Netherlands as google maps automatic does in the fields

question of double click after NL you get Netherlands and clicking on Netherlands you get the Netherlands

And then I forget to mention all those users who ONLY USE the first input field to place every information.... When also for our countrie the PROVINCIE-namen correctly are written, it is for us so much easier to search also with only f.e. Zeeland, Friesland, Limburg, etc. and that's why I think we should use the DUTCH PROVINCIE-namen to make it nice for Dutch users to search for their relatives in a easy way...

yes, but we can also do what USA users do, abbreviations: NH,ZH,ZE,NB,LI,GE,OV,UT,FL,DR,FR,GR

VERY GOOD IDEA, we can start, but there is -for me- another reason not to be TOO enthusiastic.....

Personaly I am ----i have made so many publications outsourced by f.i. governemental institutions & worked in that respect nearly all my curriculum as fulltime publisher too--- very focused on a nice and easy readible and quickly understandible overview of the PROFILE-page and then I think we must avoid abbreviations, but also try to get a shortest as possible location direction, but most complete and also for average-users immediatedly to understand... I do NOT plee to avoid the names of our provinces, for it is such a important clue to search in what region you should visit archives etc. In spite of modern ideas about governemental management, the origine of a province is still very important in families...

I had really a hard time to understand all those American abbreviations, for I never travelled to that area and why should I know in a glance tha MIN is Mineapolis or something like that.... That was my main objective to start those projects 'Circles of etcetera.....' We should NOT do the same in reverse for our American users, but I think they should learn easy only TWELVE or THIRTEEN names like GRONINGEN - FRIESLAND - DRENTHE - OVERIJSSEL - GELDERLAND - FLEVOLAND - UTRECHT - NOORD-HOLLAND - ZUID-HOLLAND - ZEELAND -NOORD-BRABANT en LIMBURG.... don't you think?

I tend to take what Geni's implemention of Google Geocoding gives me automatically - and I only use the first field to add something specific (such as a merged village or a specific place (cemetery, church, street...).
Even though the automatic fill-in doesn't look nice to non-English users, my feeling is that it will make it easier if there is ever going to be an automatic conversion into the local language (for instance, function the the user's language preferences). Anything that we customize may make automatic conversion difficult. But, that's just a thought (as I don't even know if there will be such a conversion, ever :-) )

I think we should FIRST customize to our NEEDS and then to what might be technically possible and implementable....

...And we need mutual understanding of our needs & 'toepassingen' to make 'local' appointments about the way we work in-or-with the geni-applications that vary fast, but sometimes without any consultation of what we need in our own family-research... I think, might be wrong, that priorities are given to expanding the amount of users and not the conveniance of a regional part of paying members. We are a just a little spot on the earth-globe, so I think we can only START to do it in the same way as much as possible and conveniant for users and readers...

Conversion is possible, an unknown user earlier made the automatic conversion from NL to Netherlands

so it must also be possible to convert NLD to Nederland, NH and North_Holland to Noord-Holland, etc

international NL is New Foundland and Labrador!

well.... work to be done for GENI-specialists, don't you think?

software manipulante Job Waterreus?

we can ask some helpyo/ from our friends, maybe we need DUTCH DESIGN intelligence to understand our needs.....

Job Waterreus

I Think George may be right. The fields are using Google GeoCoding data.
I do not know if Geni also records the coordinates. If so, it would be easy for Geni to translate the data in those fields.

This is what Geni states:

We’ve mapped “Establishment” returned from the Geocoding API to “Place Name”.

We’ve mapped “Locality” returned from the Geocoding API to “City”. Google defines this level as an incorporated city or town political entity.

We’ve mapped “Administrative Level 2” returned from the Geocoding API to “County”. Google defines this level as a second-order civil entity below the country level. Within the United States, these administrative levels are counties. Not all nations exhibit these administrative levels.

We’ve mapped “Administrative Level 1” returned from the Geocoding API to “State”. Google defines this level as a first-order civil entity below the country level. Within the United States, these administrative levels are states. Not all nations exhibit these administrative levels.

We’ve mapped “Country” returned from the Geocoding API to “Country”. According to Google, this type indicates the national political entity, and is typically the highest order type returned by the Geocoding API.

And this is part of the Google documentation:

Geocoding is the process of converting addresses (like "1600 Amphitheatre Parkway, Mountain View, CA") into geographic coordinates (like latitude 37.423021 and longitude -122.083739), which you can use to place markers or position the map.

Note: the Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited. For complete details on allowed usage, consult the Maps API Terms of Service License Restrictions.

From that last condition it looks likely that when we use the filed in data from Google Geni would also would have to record the coordinates.

this is also mentioned by Google:
Reverse geocoding is the process of converting geographic coordinates into a human-readable address. The Google Geocoding API provides a direct way to access a these services via an HTTP request.

So if you have the coordinates you can get a readable address from Google.

Google also states:

Optional parameters

language — The language in which to return results. See the list of supported domain languages. Note that we often update supported languages so this list may not be exhaustive. If language is not supplied, the geocoder will attempt to use the native language of the domain from which the request is sent wherever possible.

So it would be possible to get an answer in different languages
Meaning Geni could use it to search independent of language as long as we use the information provided by Google.

If Geni would use this method, it would not matter in which language to fields are filled as long as Google would understand it.

But I really do not know if Geni does it this way.

It seems Geni uses the user input to get coordinates from Google and then uses the coordinates to get the default value for the fields from Google.In this way the user input can be translated to English.

e.g. when a user enters the city name Den Haag, Geni gets the coordinates from Google and then asks Google to return the fields in English for the coordinates they got for the first request. So the city name gets filled The Hague and the Country with the Netherlands.

For searching they could also use the same method, but then they would only find data that is in English. If they store the coordinates, they could search more language independent. (and it would be easier to get a match for different spellings or have a different names in different periods)