I understand that the CLDR only provides translations for the names of regions, continents and countries, but shouldn't it then be Zend_Locale's job to make them available in a usable manner?
Just create another XML-file(or even 3 separate files) that hierarchically links continents, regions and countries to their codes. Otherwise - as Ian already mentioned - those functions will remain useless, which would be a waste of time. Btw.: North America actually is a continent. At least that's what they taught _me_ back in school ;) PS: If you want me to compile a list like this that wouldn't be such a big deal. Just ask. On 2/22/07, Ian Warner <[EMAIL PROTECTED]> wrote:
-----Original Message----- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: 22 February 2007 14:20 To: Ian Warner; [email protected] Subject: Re: [fw-general] Zend_Locale > My question though pointed at the fact that I have these three digit > elements mixed in within the 2 char country codes, with no discernable way > to sort what countries belong to what 3 digit group. To be clear: The functions name is getRegionList() A region is not a country... a region can also include several countries. The original term is "territory". So all returned values are regions... countries are only the 2 lettered ones. >> Yes I suppose this is the confusion - why does Region include countries then? Also there is not always a relation between Region and Country. f.e. Czechoslovakia - region 200 is wether a country nor a region which includes several countries. It is standalone. >> But the United Kingdom is in the same boat then and thus breaks this above rule also. I simply thought Czechoslovakia was a dead entity also? And the 3 digit codes are also no continents. Or do you believe that "Caribbean" (029) is a continent ??? :-)) >> No I don't believe this, but then I don't know where you are breaking down this region then - it does not seem logical that you are not implementing the real world, with your structure you could add in 'South West Europe' as a region, it may do some good but having real world elements that can be listed and sorted by makes more sense for this method and the class in general. > Wouldn't it be better to create a separate method that returned these like > getContinentList() > > It returned: > > [002] => Africa > [003] => North America > [005] => South America > [009] => Oceania > [00?] => Europe Nice feature but not possible... Is Northern America or Eastern Asia a continent ?? > I only copy and pasted - why is it not possible please? Also several 3 digit territories also contain other 3 digit territories... f.e. 001 contains 150 (world -> europe) 150 contains 151 (europe -> eastern europe) 151 contains PL (eastern europe -> poland) There is no good way to seperate between continents and non continents. Also 2 digit regions can contain other regions... f.e. QO contains BV >> Again having real world entries would be a better start I.e. I could offer a multi drop down with continents then countries - surely this is more appropriate for this method > And then we marked the relation in the country array as below: > And also that I wanted the option to have the countries use there ISO 3 > char > elements i.e. > > United Kingdom GB GBR > > The 3 char in my experience is always better to use, also maybe the dial > code is a nice option. > > So array may be [GB] => array(00?(Europe), United Kingdom, GBR, 44) We can only work with informations which we have. We only have the ISO abbreviation codes for all regions, this means 3 digit and 2 char. We do not have the informations for country dialing code (44) or 3 letter abbreviations (GBR) nor 2 letter non standard abbreviations (UK). It would be no good way to have multidimensional arrays. For simplification and easy handling the returned values are always plain arrays. > Again very new so would like to here from people who can comment on these > ideas, or indeed use this package to create simple hier selects for > continent, country, town etc selections. Territory select : $data = $locale->getRegionList(); foreach ($data as $key -> $territory) { if (is_int($key)) { print "\nMultiple:$territory"; } } foreach ($data as $key -> $territory) { if (!is_int($key)) { print "\nSingle:$territory"; } } To clearify things: This data is avaiable through the localization library which was included within the framework. Therefor we can f.e. display the name of countries in every language. But the negative thing is that we can only display and return data which is avaiable through the library. For now the zend framework is the only one which gives the possibility to have such data simply avaiable within one single function. >> Ahh ok - should have stated that at the start :) So you are working with a fixed file, it does however seem to me that this file has some issues regarding ease of use. I understand I can do the loops above and have already implemented these - but what would be better is if I can extract the information from the class while it loops over this file, you will increase performance and ease of use for developers. >> Thanks for your help I understand now - and it is probably better if I compile my own country lists which is a shame. Btw: This discussion is very close to I18N problems / components. You should reply to fw-i18n instead of fw-general for all i18n components to keep fw-general clean for non specific problems :) Greetings Thomas I18N Team Leader
-- best regards, André Hoffmann
