summaryrefslogtreecommitdiff
path: root/Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod
diff options
context:
space:
mode:
Diffstat (limited to 'Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod')
-rw-r--r--Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod150
1 files changed, 150 insertions, 0 deletions
diff --git a/Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod b/Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod
new file mode 100644
index 00000000000..3457f7ca12a
--- /dev/null
+++ b/Master/tlpkg/tlperl/lib/Locale/Maketext/Cookbook.pod
@@ -0,0 +1,150 @@
+# This document contains text in Perl "POD" format.
+# Use a POD viewer like perldoc or perlman to render it.
+
+=encoding utf-8
+
+=head1 NAME
+
+Locale::Maketext::Cookbook - recipes for using Locale::Maketext
+
+=head1 INTRODUCTION
+
+This is a work in progress. Not much progress by now :-)
+
+=head1 ONESIDED LEXICONS
+
+I<Adapted from a suggestion by Dan Muey>
+
+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 C<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 C<My::I18N::en> to own the
+main lexicon.
+
+There are some downsides here: the size economy
+will not stand at runtime after this C<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.
+
+=head1 DECIMAL PLACES IN NUMBER FORMATTING
+
+I<After CPAN RT #36136 (https://rt.cpan.org/Ticket/Display.html?id=36136)>
+
+The documentation of L<Locale::Maketext> advises that
+the standard bracket method C<numf> is limited and that
+you must override that for better results. It even
+suggests the use of L<Number::Format>.
+
+One such defect of standard C<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 C<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
+C<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 C<numf>,
+C<quant>, and C<sprintf> is natural as soon
+as your needs exceed what the standard ones do.
+
+