Code Monkey home page Code Monkey logo

perlcldr's People

Contributors

ehuelsmann avatar haarg avatar hakonhagland avatar lrocha-bcom avatar lucrocha avatar lyzzard avatar mariabarnard avatar patch avatar perlover avatar thepilgrim avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar

Forkers

wollmers davidegx mariabarnard perlover tbrowder manwar hakonhagland lyzzard ehuelsmann lucrocha haarg

perlcldr's Issues

Warnings/errors while running `mkcldr.pl`

Using Perl 5.30.0:

$ perl mkcldr.pl 
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.
Hexadecimal number > 0xffffffff non-portable at (eval 251) line 4.

And in the phase where the dists are being generated:

WARNING: Possible missing or corrupt 'MANIFEST' file.
Nothing to enter for 'provides' field in metafile.
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Bundle-Locale-CLDR-Te' version '0.34.0'
File 'MANIFEST.SKIP' does not exist: Creating a temporary 'MANIFEST.SKIP'
Added to MANIFEST: Build.PL
Added to MANIFEST: lib/Bundle/Locale/CLDR/Te.pm
Added to MANIFEST: MANIFEST
Created META.yml and META.json
Creating Bundle-Locale-CLDR-Te-0.34.0
Creating Bundle-Locale-CLDR-Te-0.34.0.tar.gz

There's apparently a bug in the generated MANIFEST filesand the 'provides' data seems to be missing from Makefile.PL or Build.PL, because there's a warning about that too.

CLDR v32 Released

2017-11-01 | CLDR v32 Released, and includes, among other things “Many fixes and small additions to certain preexisting data”.

as Locale::CLDR is at version 0.29, does this mean that CLDR data it uses is also at v29?

Bundle Everything is broken 

$ cpanm Bundle::Locale::CLDR::Everything
--> Working on Bundle::Locale::CLDR::Everything
Fetching http://www.cpan.org/authors/id/J/JG/JGNI/Bundle-Locale-CLDR-Everything-0.29.0.tar.gz ... OK
Configuring Bundle-Locale-CLDR-Everything-v0.29.0 ... OK
==> Found dependencies: Locale::CLDR::Locales::World, Locale::CLDR::Transformations
! Finding Locale::CLDR::Locales::World on cpanmetadb failed.
! Finding Locale::CLDR::Locales::World (0.29.0) on mirror http://www.cpan.org failed.
! Couldn't find module or a distribution Locale::CLDR::Locales::World (0.29.0)
Found Locale::CLDR::Transformations  which doesn't satisfy 0.29.0.
! Installing the dependencies failed: Missing version info for module 'Locale::CLDR::Transformations', Module 'Locale::CLDR::Locales::World' is not installed
! Bailing out the installation for Bundle-Locale-CLDR-Everything-v0.29.0.

Locale-CLDR-Locales-En-v0.40.0: Failed test 'Installed Locales'

t/13-Installed-Locales.t fails on most of my smokers:

#   Failed test 'Installed Locales'
#   at t/13-Installed-Locales.t line 14.
#          got: '106'
#     expected: '107'
# Looks like you failed 1 test of 2.
t/13-Installed-Locales.t .... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests

I cannot see a perl version or OS pattern which could cause this test to fail.

default currencies for locales

This is in reference to commit 3241a53 included in Locale::CLDR v0.25.1.

Defaulting to unspecified currencies can be pretty dangerous. If I have a product for 399 USD, format it using the ja_JP locale, and have a bug where my currency code is undefined, I'd never want it to fall back to formatting as 399 JPY instead. That's not what the payment system is going to do when attempting to process a charge. Passing the currency code is just as important as passing the number—without both you have an unknown value.

UTS #35, Part 3, §4 (emphasis theirs): “Note: Currency values should _never_ be interchanged without a known currency code. You never want the number 3.5 interpreted as $3.5 by one user and ¥3.5 by another. Locale data contains localization information for currencies, not a currency value for a country. A currency amount logically consists of a numeric value, plus an accompanying currency code (or equivalent). The currency code may be implicit in a protocol, such as where USD is implicit. But if the raw numeric value is transmitted without any context, then it has no definitive interpretation.”

Constructor new("yi") dies

Version 0.34
Perl version 5.20.1

After

$ cpanm Locale::CLDR
$ cpanm Bundle::Locale::CLDR::World
$ cpanm Locale::CLDR::Locales::Yi

the constructor

$ perl -e 'use Locale::CLDR;Locale::CLDR->new(language_id=>"yi");'
Invalid variant at /Users/helmut/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 1383.
$ perl -e 'use Locale::CLDR;Locale::CLDR->new("yi");'
Invalid variant at /Users/helmut/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 1383.

dies.

I assume the same behaviour for language codes eo, io, ia, jbo, prg, vo, because maybe it is related to issue #25 or depends on a similar condition. See also #13 which is not solved completely.

Bundle World doesn't install yi, eo, io, ia, jbo, prg, vo

Version 0.34
Perl Version 5.20.1

These language codes are associated with region '001' => 'World', but not installed by Bundle::Locale::CLDR::World:

yi
eo
io
ia
jbo
prg
vo

The codes en and ar associated with World are installed, but en is as special case. For ar I assume it defined as fall back for other locales, or associated directly to smaller regions like countries.

Direct installation of e. g.

$ cpanm Locale::CLDR::Locales::Yi

works. It is in the lib-path and

use Locale::CLDR::Locales::Yi;

doesn't fail.

Something is wrong in mkcldr.pl.

Pod coverage test fails

My smokers report the following failure for Locale-CLDR-v0.28.4-TRIAL:

#   Failed test 'Pod coverage on Locale::CLDR'
#   at t/pod-coverage.t line 18.
# Coverage for Locale::CLDR is 88.0%, with 9 naked subroutines:
#   default_ca
#   default_cf
#   default_cu
#   default_fw
#   has_likely_subtag
#   has_region
#   has_script
#   has_variant
#   likely_subtag
# Looks like you failed 1 test of 1.
t/pod-coverage.t ............ 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

For-cash rounding problem

Hi,

First of all, thanks a lot for this library! There's a problem with "for-cash" rounding, though. The following script demonstrates the problem:

use v5.14;
use Locale::CLDR;

say "Perl $^V";
say "Locale::CLDR: $Locale::CLDR::VERSION\n";

my $l = Locale::CLDR->new(language_id => 'en', region_id => 'ca');
say $l->format_currency(1.03, 1);

Locally, this generates the following output:

Perl v5.32.1
Locale::CLDR: v0.34

CA$0.00

Please note that the last line should have reported CA$1.05 instead of 0.00.

I think the problem is in Locale::CLDR::NumberFormatter::get_formatted_number (line 237) where the following debug trace demonstrates the problem:

$ perl -d t.pl

Loading DB routines from perl5db.pl version 1.57
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(t.pl:5):	say "Perl $^V";
  DB<1> c Locale::CLDR::NumberFormatter::get_formatted_number
Perl v5.32.1
Locale::CLDR: v0.34
Locale::CLDR::NumberFormatter::get_formatted_number(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:261):
261:		my ($self, $number, $format, $currency_data, $for_cash) = @_;
  DB<2> c 284
Locale::CLDR::NumberFormatter::get_formatted_number(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:284):
284:			my $decimal_digits = 0;
  DB<3> p $decimal_digits

  DB<4> p $number
1.03
  DB<5> n
Locale::CLDR::NumberFormatter::get_formatted_number(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:286):
286:			if (defined $for_cash) {
  DB<5> n
Locale::CLDR::NumberFormatter::get_formatted_number(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:287):
287:				$decimal_digits = $self->_get_currency_digits($currency_data, $for_cash)
  DB<5> p $decimal_digits
0
  DB<6> p $number
1.03
  DB<7> n
Locale::CLDR::NumberFormatter::get_formatted_number(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:290):
290:			$number = $self->round($number, $format->{$type}{rounding}, $decimal_digits);
  DB<7> p $format->{$type}{rounding}
5
  DB<8> s                
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:234):
234:		my ($self, $number, $increment, $decimal_digits) = @_;
  DB<8> p $number

  DB<9> n
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:236):
236:		if ($increment ) {
  DB<9> p $number
1.03
  DB<10> p $increment
5
  DB<11> n
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:237):
237:			$number /= $increment;
  DB<11> p $number
1.03

So: before execution of line 237, $number is still 1.03.

  DB<12> n
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:238):
238:			$number = int ($number + .5 );
  DB<12> p $number
0.206

And after execution of line 237, $number is 0.206, which is then rounded down to 0.00. The problem is that the CLDR specifies the increment as 5. However, these are not 5 currency units, but 5 subunits, or 0.05 for CA$.

  DB<13> n
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:239):
239:			$number *= $increment;
  DB<13> p $number
0
  DB<14> n
Locale::CLDR::NumberFormatter::round(/usr/local/share/perl/5.32.1/Locale/CLDR/NumberFormatter.pm:242):
242:		if ( $decimal_digits ) {
  DB<14> p $number
0

certain locale strings have broken single quoting

First off: I'm using 0.25.4 in an old dusty distribution, cannot trivially see whether the newest version addresses these cases. But just in case:

Locale/CLDR/Ha.pm
Locale/CLDR/Mgh.pm
Locale/CLDR/Teo.pm

Ha.pm has the issue in its 'nostr':

    default         => sub { qr'^(?i:a'a|a|no|n)$' }

Mgh.pm has the issue in its 'nostr':

    default         => sub { qr'^(?i:akin'tuna|a|no|n)$' }

Teo.pm has the issue in its 'calendar_months':

                                                    'Omodok\'king'ol',

The first two look like a problem of not using e.g. {} as the qr delimiters; the third one looks like a problem with a missing 'g' in a s{}{}? (just guessing)

The split_grapheme_clusters & split_words doesn't work?

Hi,

Your method doesn't work (perl v5.26.0 for example)?
Example

use utf8;
use strict;
use Data::Dumper;
use Locale::CLDR;

my $locale = Locale::CLDR->new('cs_CZ');
print Dumper($locale->split_grapheme_clusters(q{Chlopec})), "\n";

$VAR1 = 'C';
$VAR2 = 'h';
$VAR3 = 'l';
$VAR4 = 'o';
$VAR5 = 'p';
$VAR6 = 'e';
$VAR7 = 'c';

But 'Ch' - one letter and grapheme in Czech language

Other example, here is already the split_words:

use utf8;
use strict;
use Data::Dumper;
use Locale::CLDR;

my $locale = Locale::CLDR->new('fr_FR');
print Dumper($locale->split_words(q{celui qui l’écoute})), "\n";

$VAR1 = 'celui ';
$VAR2 = 'qui ';
$VAR3 = "l\x{2019}";
$VAR4 = "\x{e9}coute";

But i see there three words. I don't understand these functions... I see there simple splitting words without rules of languages

use utf8;
use strict;
use Data::Dumper;
use Locale::CLDR;

my $locale = Locale::CLDR->new('en_US');
print Dumper($locale->split_words(qq{In messaging message it's written})), "\n";

$VAR1 = 'In ';
$VAR2 = 'messaging ';
$VAR3 = 'message ';
$VAR4 = 'it';
$VAR5 = ''';
$VAR6 = 's ';
$VAR7 = 'written';

Using Locale::CLDR corrupts CLDR::Number

In a project I am using CLDR::Number for quite some time to format numbers in the right locale. Updating them all to use the number formatters of Locale::CLDR would mean a lot of work, I preferrably not want to.

Now I want to use Locale::CLDR to get country names in the correct language. However, as soon as I use Locale::CLDR, formatting an integer number via CLDR::Number fails with the message:
Can't locate object method "ffround" via package "Math::BigInt" at <path_to>/perllib/CLDR/Number/Role/Format.pm line 260

I can easily reproduce this using the following script:

#!/usr/bin/perl

use strict;

use CLDR::Number;
use Locale::CLDR;

my $cldr = CLDR::Number->new(locale => 'en');
my $formatter = $cldr->decimal_formatter(minimum_fraction_digits => 2, maximum_fraction_digits => 2);
print 'Success: ', $formatter->format(15.23), "\n";
print 'Fail: ', $formatter->format(42.0), "\n";

Here, the formatting of the number 42 will fail with the indicated message. As soon as I remove the line use Locale::CLDR, the formatting works as expected.

Do you know why using Locale::CLDR causes CLDR::Number to break? I know that the latter is a somewhat older module, but I do not want to let go of it. If there is a more up-to-date module with a similar interface as CLDR::Number, then I will definitely check it out.

Translations for North Macedonia and Eswatini

I noticed that in Locale::CLDR 0.34.4 the translations for MK and SZ still were based on the old names Macedonia and Swaziland. These countries were renamed to North Macedonia and Eswatini. It looks like the name changes have been included in CLDR 35.
http://blog.unicode.org/2019/03/unicode-cldr-version-35-languagelocale.html .

The current version of Unicode CLDR is 0.44.1. I suggest that a new release of Locale::CLDR based on the current version should be made.

where are the locale bundles?

The Locale::CLDR v0.26.2 Changes file says:

  • Break data into bundles so you don't have to download all the data

I see the Locale::CLDR::Locales::En bundle for various English locales, but the other languages seem to have disappeared from CPAN. Am I missing something?

I was writing a Perl Advent article about CLDR-based CPAN modules and wanted to include Locale::CLDR but my example doesn't run with the latest version.

$ perl -MLocale::CLDR -e 'Locale::CLDR->new("ja")->all_territories'
Attribute (module) does not pass the type constraint because: Validation failed for 'Object' with value undef at reader Locale::CLDR::module (defined at /home/patch/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 602) line 15
        Locale::CLDR::module('Locale::CLDR=HASH(0x1dcf268)') called at /home/patch/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 1428
        Locale::CLDR::_find_bundle('Locale::CLDR=HASH(0x1dcf268)', 'display_name_territory') called at /home/patch/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 1678
        Locale::CLDR::all_territories('Locale::CLDR=HASH(0x1dcf268)') called at -e line 1

Can't find Unicode property definition "Emoji" in regex

The t/06-Segmentation.t test fails with perl 5.27.9:

Wide character in regexp compilation at (eval 391) line 26.
Can't find Unicode property definition "Emoji" in regex; marked by <-- HERE in m/�-�-����-�-��-��-��-�-��-����-��-�-���-��-��-��-��-�-�-�    ��-�-�
-�-�
    �
     ��
�-�
��-�-��-�-�-��-�-��-��-����-��-��-��-�-� at (eval 391) line 26.
# Looks like your test exited with 2 just after 1.
t/06-Segmentation.t .........
Dubious, test returned 2 (wstat 512, 0x200)
Failed 4/5 subtests

Locale::CLDR::Locales::* modules load `bignum`, breaking every project which sets `$Math::BigFloat::downgrade` or `$Math::BigInt::upgrade`

As discussed in pjacklam/p5-Math-BigInt#11 and also reported in #36, with recent improvements in down- and upgrading in Math::BigInt/Math::BigFloat (released as part of Perl 5.36+), there are now more operations which correctly return the upgraded/downgraded result. However, this also makes it more visible that this project is overriding the up- and downgrade selections of the projects it's embedded in.

What's more: it overrides the selection in the project it's part of, not right from the start, but only once the first Locale::CLDR::Locales::* module is loaded (which happens dynamically). This behaviour makes the type failures, e.g. in LedgerSMB seem random.

Why does this module use bignum itself? why doesn't it advise users to do that or failing that, take other measures?

Bundle dist Europe doesn't list dependencies

Generating the "Europe" bundle using mkcldr.pl yesterday, I think there's a bug in the Bundle dists (using Europe as a showcase). The following Build.PL output is what I get for Locale-CLDR/Distributions/Bundles/Europe (please note the empty row after the "perl" dependency):

use strict;
use warnings;
use utf8;

use Module::Build;

my $builder = Module::Build->new(
    module_name         => 'Bundle::Locale::CLDR::Europe',
    license             => 'perl',
    requires        => {
        'version'                   => '0.95',
        'DateTime'                  => '0.72',
        'Moo'                       => '2',
        'MooX::ClassAttribute'      => '0.011',
		'Type::Tiny'                => 0,
        'perl'                      => '5.10.1',
        ,
    },
    dist_author         => q{John Imrie <[email protected]>},
    dist_version        => '0.34.0',
    build_requires => {
        'ok'                => 0,
        'Test::Exception'   => 0,
        'Test::More'        => '0.98',
    },
    add_to_cleanup      => [ 'Bundle-Locale-CLDR-Europe-*' ],
	configure_requires => { 'Module::Build' => '0.40' },
	release_status => 'stable',
	dist_abstract => 'Locale::CLDR - Data Package (  )',
	meta_add => {
		keywords => [ qw( locale CLDR locale-data-pack ) ],
		resources => {
			homepage => 'https://github.com/ThePilgrim/perlcldr',
			bugtracker => 'https://github.com/ThePilgrim/perlcldr/issues',
			repository => 'https://github.com/ThePilgrim/perlcldr.git',
		},
	},
);

$builder->create_build_script();

Since the Europe.pm module contains a series of bundle references, I'd expect those to be listed in the "requires" section above on the empty line below the "perl" requirement:

package Bundle::Locale::CLDR::Europe;

use version;

our $VERSION = version->declare('v0.34.0');

=head1 NAME Bundle::Locale::CLDR::Europe

=head1 CONTENTS

Bundle::Locale::CLDR::Easterneurope 0.34.0
Bundle::Locale::CLDR::Westerneurope 0.34.0
Bundle::Locale::CLDR::Northerneurope 0.34.0
Bundle::Locale::CLDR::Southerneurope 0.34.0

=cut

1;

No data for language yi - Yiddish

Just freshly installed:

$ cpanm Locale::CLDR
Locale::CLDR is up to date. (v0.29.0)

This fails:

$ perl -e 'use Locale::CLDR;print Locale::CLDR->new("yi")->likely_script(),"\n";'
Invalid variant at /Users/helmut/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Locale/CLDR.pm line 1284.

This works:

$ perl -e 'use Locale::CLDR;print Locale::CLDR->new("de")->likely_script(),"\n";'
Latin

Unicode/CLDR has it on Languages and scripts:

Yiddish	yi		N	Hebrew	Hebr

Deep recursion when creating objects for specific regions

I added translation of country names to a web application using Locale::CLDR. Testing with BV, Bouvet Island, caused high processor load on the web server.

This can be reproduced with a simple script.

$ perl bouvet.pl 
Deep recursion on subroutine "Locale::CLDR::new" at /usr/local/share/perl/5.34.0/Locale/CLDR.pm line 1456.
Deep recursion on subroutine "Locale::CLDR::BUILD" at (eval 444) line 1520.
Deep recursion on anonymous subroutine at (eval 425) line 16.

The debugger shows that the recursion occurs when the likely subtags are determined. I suppose that an infinite loop is entered because of some specific likely subtags.

$ grep -r "=> 'und_" local/lib/perl5/Locale/CLDR/LikelySubtags.pm 
		'und_AQ'	=> 'und_Latn_AQ',
		'und_BV'	=> 'und_Latn_BV',
		'und_CP'	=> 'und_Latn_CP',
		'und_GS'	=> 'und_Latn_GS',
		'und_HM'	=> 'und_Latn_HM',

The regions AQ, BV, CP, GS, and HM all show the deep recursion.

bouvet.pl.txt

Is likely_language() not correct?

Hello!

From documentation:
likely_language() Given a locale with no language passed in or with the explicit language code of und, this method attempts to use the script and region data to guess the locale's language

But quick test shows that it's not correct:

use utf8;
use strict;

binmode STDOUT, ':utf8';
binmode STDERR, ':utf8';

use Locale::CLDR;

my $locale = Locale::CLDR->new('und_FR');

print $locale->likely_language, "\n", $locale->likely_script, "\n", $locale->likely_region, "\n",
$locale->native_name, "\n", $locale->native_language, "\n";

prints:

Unknown Language
Latin
France
Unknown Language (France)
Unknown Language

use utf8;
use strict;

binmode STDOUT, ':utf8';
binmode STDERR, ':utf8';

use Locale::CLDR;

my $locale = Locale::CLDR->new('und_Latn_FR');

print $locale->likely_language, "\n", $locale->likely_script, "\n", $locale->likely_region, "\n",
$locale->native_name, "\n", $locale->native_language, "\n";

prints:

Unknown Language
Latin
France
Unknown Language (France{0}, {1}Latin)
Unknown Language

So even if i specify explicitly the Latin script there no guessed language...

Problem installing lanuguage packs with cpanm

Hi,

I get errors when installing some language packs for 0.44.0. Here is an example for Portuguese:

$ cpanm -l local Locale::CLDR::Locales::Pt
--> Working on Locale::CLDR::Locales::Pt
Fetching http://www.cpan.org/authors/id/J/JG/JGNI/Locale-CLDR-Locales-Pt-v0.44.0.tar.gz ... OK
Configuring Locale-CLDR-Locales-Pt-v0.44.0 ... OK
==> Found dependencies: Locale::CLDR, Locale::CLDR::Locales::Pt::Latn::Pt
--> Working on Locale::CLDR
Fetching http://www.cpan.org/authors/id/J/JG/JGNI/Locale-CLDR-v0.44.0.tar.gz ... OK
Configuring Locale-CLDR-v0.44.0 ... OK
Building and testing Locale-CLDR-v0.44.0 ... OK
Successfully installed Locale-CLDR-v0.44.0 (upgraded from v0.40.1)
! Installing the dependencies failed: Module 'Locale::CLDR::Locales::Pt::Latn::Pt' is not installed
! Bailing out the installation for Locale-CLDR-Locales-Pt-v0.44.0.
1 distribution installed

In 0.40.0 the localisation for Portugal was listed as a provided module in META.json:

 "provides" : {
      ....
      "Locale::CLDR::Locales::Pt::Any::Pt" : {
         "file" : "lib/Locale/CLDR/Locales/Pt/Any/Pt.pm",
         "version" : "v0.40.1"
      },
      ....
}

In 0.44.0 it is listed as a required module in META.json:


   "prereqs" : {
      "build" : {
         "requires" : {
            "Test::Exception" : "0",
            "Test::More" : "0.98",
            "ok" : "0"
         }
      },
      "configure" : {
         "requires" : {
            "Module::Build" : "0.40"
         }
      },
      "runtime" : {
         "requires" : {
            "DateTime" : "0.72",
            "Locale::CLDR" : "v0.44.0",
            "Locale::CLDR::Locales::Pt::Latn::Pt" : "v0.44.0",
            "Moo" : "2",
            "MooX::ClassAttribute" : "0.011",
            "Type::Tiny" : "0",
            "perl" : "v5.10.1",
            "version" : "0.95"
         }
      }
   },

Undeclared dependency Unicode::Regex::Set

Tests fail if Unicode::Regex::Set is not installed:

#   Failed test 'use Locale::CLDR;'
#   at t/00-load.t line 3.
#     Tried to use 'Locale::CLDR'.
#     Error:  Can't locate Unicode/Regex/Set.pm in @INC (you may need to install the Unicode::Regex::Set module) (@INC contains: /home/cpansand/.cpan/build/2018030415/Locale-CLDR-v0.32.0-TRIAL-7/blib/lib /home/cpansand/.cpan/build/2018030415/Locale-CLDR-v0.32.0-TRIAL-7/blib/arch /home/cpansand/.cpan/build/2018030415/LWP-UserAgent-Caching-Simple-0.06-7/blib/arch /home/cpansand/.cpan/build/2018030415/LWP-UserAgent-Caching-Simple-0.06-7/blib/lib /home/cpansand/.cpan/build/2018030415/LWP-UserAgent-Caching-Simple-0.06-7/blib/arch /home/cpansand/.cpan/build/2018030415/LWP-UserAgent-Caching-Simple-0.06-7/blib/lib /opt/perl-5.26.0/lib/site_perl/5.26.0/x86_64-linux /opt/perl-5.26.0/lib/site_perl/5.26.0 /opt/perl-5.26.0/lib/5.26.0/x86_64-linux /opt/perl-5.26.0/lib/5.26.0) at /home/cpansand/.cpan/build/2018030415/Locale-CLDR-v0.32.0-TRIAL-7/blib/lib/Locale/CLDR.pm line 66.
# BEGIN failed--compilation aborted at /home/cpansand/.cpan/build/2018030415/Locale-CLDR-v0.32.0-TRIAL-7/blib/lib/Locale/CLDR.pm line 66.
# Compilation failed in require at t/00-load.t line 3.
# BEGIN failed--compilation aborted at t/00-load.t line 3.
# Testing Locale::CLDR , Perl 5.026000, /opt/perl-5.26.0/bin/perl
# Looks like you failed 1 test of 1.
t/00-load.t .................
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

get_installed_locales() returns empty list

Hi,

I have been trying to use Locale::CLDR for getting translated language names. This works fine when the language pack is installed. When a language pack is not installed I'm getting the English language name. For distinguishing between the two cases it tried to call installed_locales(). However, in my case I'm getting an empty list, even if I have language packs installed.

The reason seems to be that I have installed Locale::CLDR and the language packs with local::lib. So the check in CLDR,pm is always false. See

perlcldr/Locale-CLDR/lib/Locale/CLDR.pm

Line 786 in 76f91a8

return $locales if join ('/', @path) !~ m#/lib/Locale/CLDR/Locales#;

My installation looks like:

otobo@c480dcdf5152:~$ perldoc -l Locale::CLDR
/opt/otobo_install/local/lib/perl5/Locale/CLDR.pm
otobo@c480dcdf5152:~$ ls /opt/otobo_install/local/lib/perl5/Locale/CLDR/Locales/
Ar  Ar.pm  De  De.pm  En  En.pm  Es  Es.pm  Hu  Hu.pm  Ko  Ko.pm  Nb  Nb.pm  No.pm  Pt  Pt.pm  Root.pm  Ru  Ru.pm  Sr  Sr.pm  Zh  Zh.pm

Note that the dir Locales is in perl5, not in lib.

Locale release procedures

Why is each locale released as a separate distribution when it has no dependencies besides Locale::CLDR and it's dependencies?

chansen

Can't find Unicode property definition "Grapheme_Cluster_Break=ZWJ"

On a perl 5.20.0 system the t/06-Segmentation.t test fails:

Can't find Unicode property definition "Grapheme_Cluster_Break=ZWJ" at /usr/home/eserte/.cpan/build/2018030418/Locale-CLDR-v0.32.0-TRIAL-0/blib/lib/Locale/CLDR.pm line 2394.
# Looks like your test exited with 2 just after 1.
t/06-Segmentation.t ......... 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 4/5 subtests

Wrong diagnostics in t/00-load.t

In Locale-CLDR-Locales-Ksh-v0.29.0's t/00-load.t I see:

diag( "Testing Locale::CLDR v0.29.0, Perl 5.018002, D:\strawberry\perl\bin\perl.exe" );

which is apparently wrong --- it probably should not be hardcoded.

Minimum perl version 5.14 for Locale::CLDR 0.44.0

Locale::CLDR version 0.44.0 uses the non-destructive substitution "r" modifier, requiring perl minimum version 5.14 if we trust https://www.perl.com/pub/2011/05/new-features-of-perl-514-non-destructive-substitution.html/ .

C.f. https://www.cpantesters.org/cpan/report/e376ad6c-d539-11ee-a9cd-8673b46fd3dd

that contains:

Error: syntax error at /export/home/jddurand/.cpan/build/Locale-CLDR-v0.44.0-jbpkwP/blib/lib/Locale/CLDR.pm line 1630, near "s/^[uU][-_]//r"

distributions include both Makefile.PL and Build.PL

Providing both files is generally not a good idea -- e.g. see http://neilb.org/2015/05/18/two-build-files-considered-harmful.html

Module::Build::Compat especially is a giant bag of razorblades and best avoided. The easiest thing to do is to drop the use of the 'compat' option in Module::Build, but since you're providing a Makefile.PL with no evident loss of functionality, even better would be to drop the use of Module::Build entirely and just use ExtUtils::MakeMaker in Makefile.PL.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.