Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46401
Return-Path: <chrisstocktonaz@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 5719 invoked from network); 11 Dec 2009 04:45:37 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 11 Dec 2009 04:45:37 -0000
Authentication-Results: pb1.pair.com smtp.mail=chrisstocktonaz@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=chrisstocktonaz@gmail.com; sender-id=pass; domainkeys=bad
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.211.202 as permitted sender)
DomainKey-Status: bad
X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01
X-PHP-List-Original-Sender: chrisstocktonaz@gmail.com
X-Host-Fingerprint: 209.85.211.202 mail-yw0-f202.google.com  
Received: from [209.85.211.202] ([209.85.211.202:39759] helo=mail-yw0-f202.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id AB/20-04078-07EC12B4 for <internals@lists.php.net>; Thu, 10 Dec 2009 23:45:36 -0500
Received: by ywh40 with SMTP id 40so565093ywh.26
        for <internals@lists.php.net>; Thu, 10 Dec 2009 20:45:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        bh=3JRGRbz2thtHBcYx6NlKqJe2ynk7Vht+ElsFyxPt998=;
        b=vS3qomB29sRLgvaGnubP7VDfHZw7OLVev9WxfaT2kCysnEkle4GvRulsXloj2iTlQ/
         E/pLBH7iuNcsAkmBWHEdNNWlnzvjFNYmw7g85KLncQ3Duj10Y650l3XP1mqHldXIl1Se
         ML6qlf/sJfo+AgLZhokB1iA9NR4khq/6JurxA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=Sqh8QlBCtZ2Qt8tWZucw4gFP6xVSsimcPG1+Idfe6x7n5mcmw5DJvy7ln1wQwgn2xK
         da8p9OY4Ijj8kOZr/Hbt5+BgJnT0IVmiTVRWygeuOautr4Ni5G1QPXiGCw8Sq719Hc1S
         c0ialHs2q0/HLaalmuWS0AzB7Hi/eHhGbp36w=
MIME-Version: 1.0
Received: by 10.150.38.30 with SMTP id l30mr1665172ybl.284.1260506734120; Thu, 
	10 Dec 2009 20:45:34 -0800 (PST)
In-Reply-To: <4491.c316b4e9.1260426794.nsm@avilys.eik.lt>
References: <e2e02fe0912091238k7431249cnfb564adf0eecd408@mail.gmail.com>
	 <4491.c316b4e9.1260426794.nsm@avilys.eik.lt>
Date: Thu, 10 Dec 2009 21:45:34 -0700
Message-ID: <e2e02fe0912102045s1529e1dfmeb8034bd440b41d7@mail.gmail.com>
To: Tomas Kuliavas <tokul@users.sourceforge.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Intl extension class MessageFormatter instantiation 
	returns NULL
From: chrisstocktonaz@gmail.com (Chris Stockton)

Hello,

2009/12/9 Jared Williams <jared.williams1@ntlworld.com>:
> Try...
>
> $fmt =3D MessageFormatter::create('en_GB', 'There are {0,choice,0#are no
> files|1#is one file|1<are many files} ok');
> ...

Thank you, the piece I was missing is "{0,choice ... " I appreciate
the response and the link.


On Wed, Dec 9, 2009 at 11:33 PM, Tomas Kuliavas
<tokul@users.sourceforge.net> wrote:
> What's the point of using i18n code for basic "zero, one and many"
> decision. Your sample text does not have numbers and does not use plural
> forms. If that function can handle plural forms, then it should know

My example was straight from the documentation [1] but I missed a key
piece, as mentioned above
  -> $r =3D new MessageFormatter("en", "There are {0=E2=89=A4are no files|1=
=E2=89=A4is
one file|1<are many files} ok");
  -> $r =3D new MessageFormatter("en", "There are {0,choice,0=E2=89=A4are n=
o
files|1=E2=89=A4is one file|1<are many files} ok");

This was non-obvious based off the research I did, a overlook perhaps
on my part. Furthermore NULL was not the expected result from a object
instantiation; hence my mail to this list. Obviously my snippet was
reduced from within a more complex internationalisation
implementation.

> formating rules based on language set in first argument and second
> argument should only set array of strings formated according to language
> rules. Second argument should not have to evaluate number every time
> translator wants to use plural form.

Pluralism is definitely a legitimate use case that is required within
my employers application; most seamlessly integrated by translation
services at the message formatter level. But hey, maybe your right...
ICU should just remove pluralism all together and we should use
arrays. Thanks for your useless response!

-Chris

[1] http://icu-project.org/apiref/icu4c/classChoiceFormat.html