Locale identifiers consist of information about the user's language and preferred/primary geographic region (e.g. state or province of home or workplace). The locale identifier strings used in Zend Framework are internationally defined standard abbreviations of language and region, written as language_REGION. Both the language and region parts are abbreviated to alphabetic, ASCII characters.
Note
Be aware that there exist not only locales with 2 characters as most people think.
Also there are languages and regions which are not only abbreviated with 2
characters. Therefor you should NOT strip the region and language yourself, but use
Zend_Locale when you want to strip language or region from a
locale string. Otherwise you could have unexpected behaviour within your code when
you do this yourself.
A user from USA would expect the language English and the region
USA, yielding the locale identifier "en_US". A user in Germany
would expect the language German and the region Germany,
yielding the locale identifier "de_DE". See the list
of pre-defined locale and region combinations, if you need to select a
specific locale within Zend Framework.
Example 521. Choosing a specific locale
<?php
$locale = new Zend_Locale('de_DE'); // German language _ Germany
A German user in America might expect the language German and the region
USA, but these non-standard mixes are not supported directly as
recognized "locales". Instead, if an invalid combination is used, then it will
automatically be truncated by dropping the region code. For example, "de_IS" would be
truncated to "de", and "xh_RU" would be truncated to "xh", because neither of these
combinations are valid. Additionally, if the base language code is not supported (e.g.
"zz_US") or does not exist, then a default "root" locale will be used. The "root" locale
has default definitions for internationally recognized representations of dates, times,
numbers, currencies, etc. The truncation process depends on the requested information,
since some combinations of language and region might be valid for one type of data (e.g.
dates), but not for another (e.g. currency format).
Beware of historical changes, as Zend Framework components do not know about or attempt to track the numerous timezone changes made over many years by many regions. For example, we can see a historical list showing dozens of changes made by governments to when and if a particular region observes Daylight Savings Time, and even which timezone a particular geographic area belongs. Thus, when performing date math, the math performed by Zend Framework components will not adjust for these changes, but instead will give the correct time for the timezone using current, modern rules for DST and timezone assignment for geographic regions.