Re: pluralization idea that keeps bugging me
Larry Wall wrote:
Last night I got a message entitled: yum: 1 Updates Available.
Of course, that's probably just a Python programmer giving up on doing
the right thing, but we see this sort of bletcherousness all the time.
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
My first thought is that this is such a common idiom that we ought
to have some syntactic sugar for it:
say Received $m message\s.
which reads nicely enough since the usual case is plural.
Basically, \s would be smart enough to magically know somehow whether
the last interpolation was 1 or not. It would be particular nice when
the interpolation is a closure:
say Received {calculate_number_of_messages()} message\s.
I think the most general solution is a nice quoting construct.
So if you say
say qq:l10n(en)Received $m message\s;
the quote handler in l10n:en (or whatever) receives a list of pairs of
strings and variables to interpolate, ['$m' = $m, '\s' = undef].
It can then decide what to do with it.
Wait, that smells like macros, which are already specced - so never mind ;-)
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: pluralization idea that keeps bugging me
* Larry Wall ([EMAIL PROTECTED]) [080126 16:58]:
Last night I got a message entitled: yum: 1 Updates Available.
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
Any other cute ideas?
I totally agree with many responses, that special support for the English
language is not preferred, certainly when it bothers developers for
other natural languages. Imagin that you wrote your code this way for
a website, and then your boss (always blame your boss) decides that the
site must be ported to Chinese for expansion...
It would be nice if Perl joined nearly all other Open Source applications,
in being multi-languaged. During the lightningtalks of last YAPC::EU,
I called for localization of error messages in Perl 5.12, but Perl6
improvements are welcomed as well.
My idea: Recently, I released Log::Report, which is a new translation
framework. It combines exception-handling with report dispatch and
translations. What's new: some module produces a text, but that module
was found on CPAN. Only the author of the main program knows how to
handle the text. So, delay translations until an output layer is reached.
Locale::TextDomain and gettext translate immediately, as does $! They
translate on the location where the report emerges. Log::Dispatch and
Log::Log4perl cannot influence the text production process.
What my new Log::Report does, is delaying translations to the moment
it reaches the dispatcher. Like this:
package main;
dispatcher SYSLOG = 'syslog', language = 'en-US',
charset = 'ascii', facility = 'local4';
dispatcher STDOUT = 'website', language = 'cn',
charset = 'utf8';
run_some_code(); # text both to syslog and stdout
package Someone::Elses::Package;
use Log::Report 'translation-table-namespace';
sub run_some_code()
{ # Locale::TextDomain compatible syntax, info ~ print
info __nxReceived {m} messages, $m, m = $m;
}
To syslog in English (what I understand), and to the website in Chinese
(what I do not understand) Of course, there are quite some more features
in the module.
The translation tables can have gettext syntax, database driven, or maybe
a module with Perl routines from complex languages. (Only the first is
implemented on the moment, but the framework is present).
The provided try() is also implemented as dispatcher, which collects
the messages from the block, and has not yet been translated:
try { error __help! };
if($@) # an Log::Report::Dispatcher::Try object
{ my $exception = [EMAIL PROTECTED]wasFatal;
$exception-throw # re-cast
if $ex-message !~ m/help/; # ignore call for help
}
When someone starts coding, it is more and more uncertain in which
languages it will be used later. So, it would be nice to help people
to avoid mistakes which may block an easy conversion.
For instance, best if texts are produced in as large blocks as possible,
outside the program file. We know how to do that: a template system.
Templates themselves are easily translatable. About a zillion or two
CPAN modules implement a Locale::TextDomain-like HASH-based substitution
system in templates.
Translations are impossible for syntaxes like this:
print Received $m messages
because the $m is already filled-in before print is called. For this
reason, a lookup in the translation table is impossible.
It would be nice to not translate above string into
print 'Received '.$m.' messages'
but
report info = 'Received {m} messages', m = $m,
linenr = __LINE__, ..etc..
(of course, some \Q\E like meta-syntax, not {})
Print() works internally more like printf(). No problem. Without
translation tables defined, it just takes what it got as first argument.
In the infrastructure, we need a reason for each message, like syslog
levels. Print, warn, and die have implied reasons (resp info, warn
and error). Everyone is tricking trace and verbose levels, so we need
a few more useful levels.
Concluding:
- hopefully, there is a way to simplify the work for all of us who do
need to support many languages within one application
- create one standard, so all CPAN modules integrate in the same way
- let's try to get Perl to handle languages!
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
[svn:perl6-synopsis] r14496 - doc/trunk/design/syn
Author: larry Date: Sun Jan 27 14:49:15 2008 New Revision: 14496 Modified: doc/trunk/design/syn/S03.pod Log: Clarify range ending semantics for autoincrement sequences that will never match the to Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSun Jan 27 14:49:15 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 22 Jan 2008 + Last Modified: 27 Jan 2008 Number: 3 - Version: 127 + Version: 128 =head1 Overview @@ -2525,6 +2525,16 @@ An empty Range cannot be iterated; it returns a CFailure instead. An empty range still has a defined min and max, but the min is greater than the max. +If a range is generated using a magical autoincrement, it stops if the magical +increment would carry and make the next value longer than the to value, on the +assumption that the sequence can never match the final value exactly. Hence, +all of these produce 'A' .. 'Z': + +'A' .. 'Z' +'A' .. 'z' +'A' .. '_' +'A' .. '~' + =item * The unary C^ operator generates a range from C0 up to
Re: pluralization idea that keeps bugging me
Perl - when I first met it - was great because it handled text easily
and 'naturally'. I now use perl for everything, even when another
language would probably be better.
Perl6 has gone a long way to making things more universal by using
UNICODE, (The difficulties of non-Latin fonts and coding are horrendous).
Mark and chromatic are right that an ability to manipulate multiple
languages naturally and in core would be something no other
programming language does.
Perl6 seems to handle most of the necessary things, but not all - I
think. Hence Larry's original question.
There are - it seems to me - several different aspects to consider. My
breakdown would be:
a) having the language constructs that make text interpolation easy -
that is the *text* morphs itself to adjust to the context brought in by
the interpolated data. What is necessary is not a plurals fix for
English, but a mechanism for fixing that can be applied to other
languages. (Here I think perl6 grammars will help, but I am not sure,
and without proof of concept actually doubt the facility exists in perl).
b) Translating the perl core itself - the use of other languages to
write code in. Given perl6 grammar, and given that any programming
language is a rigidly circumscribed subset of words, I think this is
entirely possible in most natural languages. Clearly for the compiler to
work, an non-English coding language must uniquely map to and from an
equivalent English coding.
c) Having the mechanisms in perl6 core not just to interpolate text
contextually, but also for different texts to be used with the same
interpolations (when a text is translated, different sentence structures
result). As Mark pointed out, this can be accomplished with Templates.
d) Ensuring that different information streams can each be directed
through templates. As Mark pointed out, more is needed than standard
input, output, and errors. Moreover, it would be fantastic if the output
from the perl6 compiler could be constructed so that its information
streams (warnings, errors, etc) could be attached to translation filters.
I think item (a) is not quite there in perl6. But I really want to use
perl6 and I hope this line of development does not derail the fantastic
amount of momentum we have seen in recent months.
Mark Overmeer wrote:
* Larry Wall ([EMAIL PROTECTED]) [080126 16:58]:
Last night I got a message entitled: yum: 1 Updates Available.
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
Any other cute ideas?
I totally agree with many responses, that special support for the English
language is not preferred, certainly when it bothers developers for
other natural languages. Imagin that you wrote your code this way for
snip
To syslog in English (what I understand), and to the website in Chinese
(what I do not understand) Of course, there are quite some more features
in the module.
snip
Concluding:
- hopefully, there is a way to simplify the work for all of us who do
need to support many languages within one application
- create one standard, so all CPAN modules integrate in the same way
- let's try to get Perl to handle languages!
