For most common requirements -- especially multi-lingual sites -- the Location package is not a good solution for locative data in Drupal 6. The Location package does not handle i18n well and has l10n problems without simple or general solutions with translation sets. The recommendation for most cases where locative data is stored in Drupal 6, is to and migrate the data to taxonomy vocabularies and CCK fields. Both of these options have general solutions for most common i18n issues which make it more flexible for a variety of possible i18n requirements.

The primary general design problem with the Location package are that it stores a location as a first-class object. Locations have their own table with their own ids ('lid' for "location id"). Even though locations are first-class objects, an existing location can not easily be re-used or re-referenced from multiple nodes or other first-class objects.

Other general design problems which are primarily a result of a legacy design inherited from older versions of the module for older versions of Drupal, are that the Location package has no CCK integration, the Location package is unaware of i18n translation sets, and that locations are linked to users, nodes and other entities in a relationship table which is not flexible nor easily extensible (This is the case in version 3's schema. Version 2 had a different schema for relationships that was similarly restrictive).

The Location package expects locative data to have specified and consistent levels of geographic data, e.g. "Name", "Street", "Town/City", "Zip code", and "Country". This assumption results in the data being inflexible and not easily localizable;

• A significant number of countries don’t have postcodes or zip codes, don’t use them, or have another name for them (in English). For example, as a result of most New Zealanders not knowing their own postcode, NZ Post has recently launched a large campaign to educate New Zealanders about NZ's postcodes -- "The $10,000 question". Most personal mail is not sent with a postcode and this is not necessary for the mail to arrive at it's destination.
• Many countries and cities have different names in different languages. For example;
  • “The Ivory Coast” is “Côte d’Ivoire” in French and German and “Costa de Marfil” in Spanish.
  • “Germany” is “Alemania” in Spanish and “Deutshland” in German.
  • “Munich” is “München” in German
  • “London” is “Londres” Spanish.
  Monolingual speakers often do not recognize names of cities and countries in foreign languages. For example, a native Spanish speaker who knows little or no English will not likely recognize “The Ivory Coast” untranslated in English. They will however recognize “Costa de Marfil” and possibly “Côte d’Ivoire”.

Because the locative data is all stored in one row it is very difficult to translate the city and/or country of a location object in a translation set, without duplicating the non-translatable data, such as the place name, zip/post code, street address, latitude and longitude. It is also very difficult to localize form elements for the nuances of a region's addresses so that, for example, the "Zip code" field is called "Post code" and is not required in NZ, and so that the "State" field does not exist.

For most locative data requirements, CCK text fields, taxonomy, CCK fields specifically designed for latitude and longitude and geocoded latitude and longitude usually provide sufficient data collection and storage methods and abstract the data into more smaller entities that are re-usable, reference-able, discourage duplicate data and are far more flexible for multi-lingual sites. Requirements for most multi-lingual sites already have very good flexible and general solutions for CCK fields and taxonomy.

The specific solution for upgrading to Drupal 6 with the Location package is best determined for each website one at a time, depending on how the Location package is used and how this data should be localizable. Some recommended general solutions for common locative data requirements follows.

If only the latitude and longitude needs to be stored, there are modules that provide this as a CCK field which should provide sufficient simplicity and flexibility for most multi-lingual sites. e.g. CCK Latitude Longitude and GMap Lat/Lon (I haven't tried these modules out yet).

If only regional data such as the province, state, country or continent are required, a taxonomy vocabulary or CCK text/select field is recommended. Hierarchical Select module can enhance the user interface for such hierarchical locative data.

For very granular address data, a text field is usually sufficient; a multi-line text field if a suburb or post/zip code is required. Normally this will not be a translatable field. Town/City applies in almost any locale, and since this field will normally need to be translatable (e.g. "London" is "Londres" in Spanish) it is usually best as a single-line translatable CCK text field. Country is usually best as a vocabulary or CCK text/select field -- localizable at a site-level rather than per node.

I do not know of any support for geocoding the latitude and longitude from text addresses in CCK fields, however it is not difficult to add this feature to an existing contributed module or a new custom/glue module. If both granular locative data and geocoding is required, then the Location package may be worth reconsidering, since it is comprehensive in this regard.

• Version 3 is not yet well tested and is most likely buggy.
• Translations are incomplete.
• The Location package version 3 has a location_cck module which I have not yet tried out.
• I believe I have been told that Geo package ambitiously tries to solve many of the problems outlined here but is far from stable and only usable by developers who want to get their hands greasy.
• GMap Addons package has a gmap_cck module which I also haven't tried out yet. It's listed as "ready for testing".