فصل 15. Zend_Locale

قائمة المحتويات

15.1. Introduction
15.1.1. What is Localization
15.1.2. What is a Locale?
15.1.3. How are Locales Represented?
15.1.4. Selecting the Right Locale
15.1.5. ZF Locale-Aware Classes
15.2. Using Zend_Locale
15.2.1. Copying, Cloning, and Serializing Locale Objects
15.2.2. isEqual() - Equality
15.2.3. Default locales
15.2.4. Set a new locale
15.2.5. Getting the language and region
15.2.6. Obtaining localized name for languages, regions, and calendars
15.2.7. Get an translated string of an script
15.2.8. Get a list of scripts
15.2.9. Obtaining translations for "yes" and "no"
15.3. Normalization and Localization
15.3.1. Number normalization: getNumber($input, $precision = false, $locale = false)
15.3.2. Number localization
15.3.3. Number testing
15.3.4. Float value normalization
15.3.5. Floating point value localization
15.3.6. Floating point value testing
15.3.7. Integer value normalization
15.3.8. Integer point value localization
15.3.9. Integer value testing
15.3.10. Numeral System Conversion
15.4. Working with Dates and Times
15.4.1. Normalizing Dates and Times
15.4.2. Testing Dates
15.4.3. Normalizing a Time
15.4.4. Testing Times
15.5. Supported Languages for Locales
15.6. Supported Regions for Locales

15.1. Introduction

Zend_Locale is the Frameworks answer to the question, "How can the same application be used around the whole world?" Most people will say, "That's easy. Let's translate all our output to several languages." However, using simple translation tables to map phrases from one language to another is not sufficient. Different regions will have different conventions for first names, surnames, salutory titles, formatting of numbers, dates, times, currencies, etc.

We need Localization and complementary Internationalization . Both are often abbreviated to L10N and I18N. Internationalization refers more to support for use of systems, regardless of special needs unique to groups of users related by language, region, number format conventions, financial conventions, time and date conventions, etc. Localization involves adding explicit support to systems for special needs of these unique groups, such as language translation, and support for local customs or conventions for communicating plurals, dates, times, currencies, names, symbols, sorting and ordering, etc. L10N and I18N compliment each other. The Zend Framework provides support for these through a combination of components, including Zend_Locale, Zend_Date, Zend_Measure, Zend_Translate, Zend_Currency, and Zend_TimeSync.

15.1.1. What is Localization

Localization means that an application (or homepage) can be used from different users which speak different languages. But as you already have expected Localization means more than only translating strings. It includes

  • Zend_Locale - Backend support of locales available for localization support within other ZF components.

  • Zend_Translate - Translating of strings.

  • Zend_Date - Localization of dates, times.

  • Zend_Calendar - Localization of calendars (support for non-Gregorian calendar systems)

  • Zend_Currency - Localization of currencies.

  • Zend_Locale_Format - Parsing and generating localized numbers.

  • Zend_Locale_Data - Retrieve localized standard strings as country names, language names and more from the CLDR .

  • TODO - Localization of collations

15.1.2. What is a Locale?

Each computer user makes use of Locales, even when they don't know it. Applications lacking localization support, normally have implicit support for one particular locale (the locale of the author). When a class or function makes use of localization, we say it is locale-aware. How does the code know which localization the user is expecting?

A locale string or object identifying a supported locale gives Zend_Locale and it's subclasses access to information about the language and region expected by the user. Correct formatting, normalization, and conversions are made based on this information.

15.1.3. How are Locales Represented?

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 the Zend Framework are internationally defined standard abbreviations of language and region, written as language_REGION. Both the language and region parts are abbreviated to 2 alphabetic, ASCII characters.

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 the Zend Framework.

مثال 15.1. Choosing a specific locale

<?php
require_once 'Zend_Locale');
$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 ZF 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 ZF 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.

15.1.4. Selecting the Right Locale

For most situations, new Zend_Locale() will automatically select the correct locale, with preference given to information provided by the user's web browser. However, if new Zend_Locale(Zend_Locale::ENVIRONMENT) is used, then preference will be given to using the host server's environment configuration, as described below.

مثال 15.2. Automatically selecting a locale

<?php
require_once 'Zend/Locale.php';
$locale  = new Zend_Locale();
$locale1 = new Zend_Locale(Zend_Locale::BROWSER);     // default behavior, same as above
$locale2 = new Zend_Locale(Zend_Locale::ENVIRONMENT); // prefer settings on host server
$locale3 = new Zend_Locale(Zend_Locale::FRAMEWORK);   // perfer framework app default settings
?>

The seach algorithm used by Zend_Locale for automatic selection of a locale uses three sources of information:

  1. const Zend_Locale::BROWSER - The user's Web browser provides information with each request, which is published by PHP in the global variable HTTP_ACCEPT_LANGUAGE. If no matching locale can be found, then preference is given to ENVIRONMENT and lastly FRAMEWORK.

  2. const Zend_Locale::ENVIRONMENT - PHP publishes the host server's locale via the PHP internal function setlocale(). If no matching locale can be found, then preference is given to FRAMEWORK and lastly BROWSER.

  3. const Zend_Locale::FRAMEWORK - When the Zend Framework has a standardized way of specifying component defaults (planned, but not yet available), then using this constant during instatiation will give preference to choosing a locale based on these defaults. If no matching locale can be found, then preference is given to ENVIRONMENT and lastly FRAMEWORK.

15.1.5. ZF Locale-Aware Classes

In the ZF, locale-aware classes rely on Zend_Locale to automatically select a locale, as explained above. For example, in a ZF web application, constructing a date using Zend_Date without specifying a locale results in an object with a locale based on information provided by the current user's web browser.

مثال 15.3. Dates default to correct locale of web users

<?php
require_once 'Zend/Date.php';
$date = new Zend_Date('2006',Zend_Date::YEAR);
?>

To override this default behavior, and force locale-aware ZF components to use specific locales, regardless of the origin of your website visitors, explicitly specify a locale as the third argument to the constructor.

مثال 15.4. Overriding default locale selection

<?php
require_once 'Zend/Date.php';
require_once 'Zend/Measure.php';

$usLocale = new Zend_Locale('en_US');
$date = new Zend_Date('2006',Zend_Date::YEAR, $usLocale);
$temp = new Zend_Measure('100,10',Zend_Measure::TEMPERATURE, $usLocale);
?>

If you know many objects should all use the same default locale, explicitly specify the default locale to avoid the overhead of each object determining the default locale.

مثال 15.5. Performance optimization when using a default locale

<?php
require_once 'Zend/Date.php';
require_once 'Zend/Measure.php';

$locale = new Zend_Locale();
$date = new Zend_Date('2006',Zend_Date::YEAR, $locale);
$temp = new Zend_Measure('100,10',Zend_Measure::TEMPERATURE, $locale);
?>