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!