Linux Certif

Toute la documentation sur la certification Linux LPI

Locales.3pm

NAME

Locales - Methods for getting localized CLDR language/territory names (and a subset of other data)

VERSION

This document describes Locales version 0.15

SYNOPSIS

     use Locales;
 
     my $locale = Locales->new('en_gb');
     
     print $locale->get_locale(); # 'en_gb'
     print $locale->get_language(); # 'en'
     print $locale->get_territory(); # 'gb'
     
     print $locale->get_language_from_code('fr'); # 'French'
     print $locale->get_code_from_language('French'); # 'fr'
     
     print $locale->get_territory_from_code('us'); # 'United States'
     print $locale->get_code_from_territory('Australia'); # 'au'
 
 

DESCRIPTION

Locales lets you create an object for a certain locale that lets you access certain data harvested directly from CLDR.

<http://cldr.unicode.org/index/downloads>

Currently the data/methods include translated locale names and territory names.

For simplicity Locales does not work with or know about Variants or Scripts. It only knows about languages and territories.

Also it does not conatin all the data contained in CLDR. For example, DateTime's localization already has all the calender/date/time info from CLDR. Other information has not had any demand yet.

For consistency all data is written in utf-8. No conversion should be necessary if you are (wisely) using utf-8 as your character set everywhere (See <http://drmuey.com\/?do=page&id=57> for more info on that.).

Note: You probably [don't need to/should not] use utf8 in regards to the data contained herein.

Based on CLDR 1.7.1

You can learn about the Unicode Common Locale Data Repository at <http://cldr.unicode.org/>

INTERFACE

new()

Takes one argument, the locale tag whose CLDR data you want to use.

No argument defaults to 'en'.

It is an argument based singleton so you can call it more than once with out it having to rebuild the object everytime.

It returns false if a locale given is not vailable. $@ should have been set at that point by eval.

     my $en = Locales->new('en') or die $@;
 
 

Object methods

Misc methods

get_locale()

Takes no arguments.

Returns the normalized locale of the object, this is the same as the argument to new()

get_language()

Takes no arguments.

Returns the language portion of the object's locale.

get_territory()

Takes no arguments.

Returns the territory portion of the object's locale if any (e.g. 'en_au'), undef if there is none (e.g. 'it').

numf()

Takes one optional boolean argument.

Returns 1 if the object's locale's number format is comma for thousand separator, period for decimal.

Return 2 if the object's locale's number format is period for thousand separator, comma for decimal.

Otherwise it returns a 3 element array containing this CLDR data: number format, separator character, decimal character.

The boolean argument, when true will do it's best to determine and return a 1 or a 2.

Territory methods

get_territory_codes()

Take no arguments.

Returns an unsorted list of known territory codes.

get_territory_names()

Take no arguments.

Returns an unsorted list of the display names for each known territory code.

get_territory_from_code()

Takes one argument, the locale code whose territory name you want to find. Defaults to the territory of the of object's locale, if any.

Returns the name of the given tag's territory or, if not found, the territory portion (if any), returns false otherwise.

An optional second argument, when true, will force it to return the normalized tag if nothing else can be figured out.

get_code_from_territory()

Takes one argument, the territory name whose locale you want to find.

Returns the locale tag if found, false otherwise.

code2territory()

Alias for get_territory_from_code()

territory2code()

Alias for get_code_from_territory()

Language Methods

get_language_codes()

Take no arguments.

Returns an unsorted list of known language codes.

get_language_names()

Take no arguments.

Returns an unsorted list of the display names for each known language code.

get_language_from_code()

Takes one argument, the locale code whose language name you want to find. Defaults to the object's locale.

Returns the name of the given tag's language, returns false otherwise.

An optional second argument, when true, will force it to return a properly formatted CLDR format display based on if we know the langauge and/or territory if nothing else can be figured out.

get_code_from_language()

Takes one argument, the language name whose locale you want to find.

Returns the locale tag if found, false otherwise.

get_native_language_from_code()

Like get_language_from_code() except it returns the name in the given locale's native language.

get_character_orientation_from_code()

Like get_language_from_code() except it returns the character orientation identifier for the given locale.

Typically it will be the string 'left-to-right' or 'right-to-left'.

See <http://unicode.org/repos/cldr-tmp/trunk/diff/by_type/misc.layout.html> for more information.

code2language()

Alias for get_language_from_code()

language2code()

Alias for get_code_from_language()

Utility functions

These are some functions used internally that you might find useful.

Locales::normalize_tag()

Takes a single argument, the locale tag to normalize.

Returns the normalized tag.

    print Locales::normalize_tag("  en-GB\n "); # 'en_gb'
 
 

Locales::split_tag()

Takes a single argument, the locale tag to split into language and territory parts.

Returns the resulting array of 1 or 2 normalized (but not validated) items.

    my ($language, $territory) = Locales::split_tag("  en-GB\n "); # ('en','gb')
    
    my ($language, $territory) = Locales::split_tag('fr'); # ('fr');
    
    my ($language, $territory) = Locales::split_tag('sr_Cyrl_YU'); # ('sr','cyrl_yu'), yes 'cyrl_yu' is invalid here since Locales doesn't work with the Script variants, good catch
 
 

Locales::get_i_tag_for_string()

Takes a single argument, the locale tag string to tranform into ``i'' notation.

Returns the resulting normailzed locale tag.

The standard tag for strings/tags without a standard is an ``i'' notation tag.

For example, the language ``Yoda Speak'' does not have an ISO code. You'd have to use i_yoda_speak.

     # assuming $string = "Yoda Speak"; you;d get into the if(), assuming it was 'Spanish' or 'es'
     if (!$en->get_language_from_code($string) && !$en->get_code_from_language($string) ) {
         # it is not a code or a language (at least in the language of $en) so lets create a tag for it:
         _create_locale_files( Locales::get_i_tag_for_string($string) ); # i_yoda_speak
     }
     else {
         # if it is a language name then we fetch the code otherwise, at this point, we know it is a code, so return a normailized version
         _create_locale_files( $en->get_code_from_language($yoda) || Locales::normalize_tag($yoda) );
     }
 
 

Locales::normalize_for_key_lookup()

Takes a single argument, the phrase string normalize in the same way the names are stored in each locale's lookup hash.

Returns the resulting normailzed string.

This is used internally to normalize a given name in the same manner the name-to-code hash keys are normalized.

If said normalization is ever improved then using this function will ensure everything is normalized consistently.

That allows $en->get_code_from_language($name) to map to 'afa' if given these various variations of $arg:

   "Afro-Asiatic Language"
   "afroasiatic\tLanguage"
   "AFRO-Asiatic Language"
   "  Afro_Asiatic    Language"
   "afro.Asiatic Language\n"
 
 

DIAGNOSTICS

Throws no warning or errors of it's own. If any function or method returns false then the arguments given (or not given) were invalid/not found.

CONFIGURATION AND ENVIRONMENT

Locales requires no configuration files or environment variables.

DEPENDENCIES

None.

INCOMPATIBILITIES

None reported.

TODO

   - CLDR builder TODOs
   - more CLDR version/misc-info fetchers
   - generally improve get_code_from_* lookups
   - tests that misc info doesn't get odd structs from XML instead of a string
 
 

DEPRECATED MODULES/INTERFACE

The original, non CLDR based, '::Base' based modules/interface in this distribution were deprecated in version 0.06.

These modules were removed in version 0.15.

BUGS AND LIMITATIONS

No bugs have been reported.

Please report any bugs or feature requests regarding the Locales modules to "bug-locales@rt.cpan.org", or through the web interface at <http://rt.cpan.org>.

Please report any bugs or feature requests regarding CLDR data as per <http://cldr.unicode.org/index/bug-reports>.

BEFORE YOU SUBMIT A BUG REPORT

Please read TODO, DESCRIPTION, and the information below thouroughly to see if your thought is already addressed.

•

A non-English object returns English names.

Data that is not defined in a locale's CLDR data falls back to English.

Please report the missing data to the CLDR as per <http://cldr.unicode.org/index/bug-reports>.

•

I am using a locale code that I know exists in the CLDR but I can't use it anywhere in Locales

Only locales and territory codes that 'en' knows about are used. Only locales that have their own data set in CLDR are able to be objectified.

Additions or updates can be request as per <http://cldr.unicode.org/index/bug-reports>.

•

A name is misformatted, incorrect, etc.

The data is automatically harvested from CLDR. So if there is really a problem you'll have to report the problem to them. (as per <http://cldr.unicode.org/index/bug-reports>)

Here are some things to check before submitting a report:

•

Corrupt text

•

Is your charset correct?

For example, viewing UTF-8 characters on a latin1 web page will result in garbled characters.

•

It still looks corrupt!

Some locale's require special fonts to be installed on your system to view them properly.

For example Bengali (bn) is like this. As per <http://www.unicode.org/help/display_problems.html> if you install the proper font it renders correctly.

•

Incorrect data or formatting

•

Is it really inaccurate?

It could simply be an incomplete understanding of the context of the data, for example:

In English we capitalize proper names (e.g. French).

In other languages it may be perfectly acceptable for a language or territory name to not start with upper case letters.

In that case a report about names not being capitalized like we do in English would be unwarranted.

•

Is it really mis-formatted?

Sometimes soemthing might look strange to us and we'd be tempted to report the problem. Keep in mind though that sometimes locale nuances can cause things to render in a way that non-native speakers may not understand.

For example Arabic's (ar) right-to-left text direction can seem strange when mixed with latin text. It's simply not wrong. You may be able to improve it by using the direction data to render it better (e.g. CSS or HTML attributes if the output is HTML).

Also, CLDR pattern formats can differ per locale.

In cases like this a report would be unwarranted.

AUTHOR

Daniel Muey "<http://drmuey.com/cpan_contact.pl>"

LICENCE AND COPYRIGHT

Copyright (c) 2009, Daniel Muey "<http://drmuey.com/cpan_contact.pl>". All rights reserved.

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.

DISCLAIMER OF WARRANTY

BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE SOFTWARE ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.