Locale::Maketext::Cookbook(3p) Perl Programmers Reference Guide #
Locale::Maketext::Cookbook(3p) Perl Programmers Reference Guide
NNAAMMEE #
Locale::Maketext::Cookbook - recipes for using Locale::Maketext
IINNTTRROODDUUCCTTIIOONN #
This is a work in progress. Not much progress by now :-)
OONNEESSIIDDEEDD LLEEXXIICCOONNSS #
_A_d_a_p_t_e_d _f_r_o_m _a _s_u_g_g_e_s_t_i_o_n _b_y _D_a_n _M_u_e_y
It may be common (for example at your main lexicon) that the hash keys
and values coincide. Like that
q{Hello, tell me your name}
=> q{Hello, tell me your name}
It would be nice to just write:
q{Hello, tell me your name} => ''
and have this magically inflated to the first form. Among the advantages
of such representation, that would lead to smaller files, less prone to
mistyping or mispasting, and handy to someone translating it which can
simply copy the main lexicon and enter the translation instead of having
to remove the value first.
That can be achieved by overriding "init" in your class and working on
the main lexicon with code like that:
package My::I18N;
...
sub init {
my $lh = shift; # a newborn handle
$lh->SUPER::init();
inflate_lexicon(\%My::I18N::en::Lexicon);
return;
}
sub inflate_lexicon {
my $lex = shift;
while (my ($k, $v) = each %$lex) {
$v = $k if !defined $v || $v eq '';
}
}
Here we are assuming "My::I18N::en" to own the main lexicon.
There are some downsides here: the size economy will not stand at runtime
after this "init()" runs. But it should not be that critical, since if
you don't have space for that, you won't have space for any other
language besides the main one as well. You could do that too with ties,
expanding the value at lookup time which should be more time expensive as
an option.
DDEECCIIMMAALL PPLLAACCEESS IINN NNUUMMBBEERR FFOORRMMAATTTTIINNGG #
_A_f_t_e_r _C_P_A_N _R_T _#_3_6_1_3_6 _(_<_h_t_t_p_s_:_/_/_r_t_._c_p_a_n_._o_r_g_/_T_i_c_k_e_t_/_D_i_s_p_l_a_y_._h_t_m_l_?_i_d_=_3_6_1_3_6_>_)
The documentation of Locale::Maketext advises that the standard bracket
method "numf" is limited and that you must override that for better
results. It even suggests the use of Number::Format.
One such defect of standard "numf" is to not be able to use a certain
decimal precision. For example,
$lh->maketext('pi is [numf,_1]', 355/113);
outputs
pi is 3.14159292035398
Since pi ≈ 355/116 is only accurate to 6 decimal places, you would want
to say:
$lh->maketext('pi is [numf,_1,6]', 355/113);
and get "pi is 3.141592".
One solution for that could use "Number::Format" like that:
package Wuu;
use base qw(Locale::Maketext);
use Number::Format;
# can be overridden according to language conventions
sub _numf_params {
return (
-thousands_sep => '.',
-decimal_point => ',',
-decimal_digits => 2,
);
}
# builds a Number::Format
sub _numf_formatter {
my ($lh, $scale) = @_;
my @params = $lh->_numf_params;
if ($scale) { # use explicit scale rather than default
push @params, (-decimal_digits => $scale);
}
return Number::Format->new(@params);
}
sub numf {
my ($lh, $n, $scale) = @_;
# get the (cached) formatter
my $nf = $lh->{__nf}{$scale} ||= $lh->_numf_formatter($scale);
# format the number itself
return $nf->format_number($n);
}
package Wuu::pt;
use base qw(Wuu);
and then
my $lh = Wuu->get_handle('pt');
$lh->maketext('A [numf,_1,3] km de distância', 1550.2222);
would return "A 1.550,222 km de distância".
Notice that the standard utility methods of "Locale::Maketext" are
irremediably limited because they could not aim to do everything that
could be expected from them in different languages, cultures and
applications. So extending "numf", "quant", and "sprintf" is natural as
soon as your needs exceed what the standard ones do.
perl v5.36.3 2023-02-15 Locale::Maketext::Cookbook(3p)