intl 1.0.0RC1

[Stanislav Malyshev]

Hi!

I've uploaded 1.0.0RC1 version of intl extension on PECL. Please test it
and if you think anything has to be added/fixed for 1.0.0 please tell.
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Texin, Tex]

Hooray!

> -----Original Message-----
> From: Stanislav Malyshev [mailto:stas@...]
> Sent: Tuesday, May 27, 2008 2:27 PM
> To: php-i18n@...
> Subject: [PHP-I18N] intl 1.0.0RC1
>
> Hi!
>
> I've uploaded 1.0.0RC1 version of intl extension on PECL.
> Please test it and if you think anything has to be
> added/fixed for 1.0.0 please tell.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@...   http://www.zend.com/
> [phone]   MSN: stas@...
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/) To
> unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Darren Cook]

> I've uploaded 1.0.0RC1 version of intl extension on PECL. Please test it
> and if you think anything has to be added/fixed for 1.0.0 please tell.

It now refuses to install on php 5.2.3, i.e. ubuntu 7.10.  (Wasn't the
plan to include the required macros in the ./configure script (or
whatever) so that it could install on more PHP installations.)

Putting the latest acinclude.m4 in /usr/lib/php5/build/ and then doing:
   pecl install --ignore-errors intl

trips up at the same place it did before, with a ptrdiff_t problem [1].

If you need more information from me, let me know. Thanks,

Darren


[1]:
 gcc -I/usr/include -I. -I/tmp/pear/temp/intl -DPHP_ATOM_INC
-I/var/tmp/pear-build-root/intl-1.0.0RC1/include
-I/var/tmp/pear-build-root/intl-1.0.0RC1/main -I/tmp/pear/temp/intl
-I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM
-I/usr/include/php5/Zend -I/usr/include/php5/ext
-I/usr/include/php5/ext/date/lib -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -g -O2 -c
/tmp/pear/temp/intl/collator/collator_sort.c  -fPIC -DPIC -o
collator/.libs/collator_sort.o
/tmp/pear/temp/intl/collator/collator_sort.c:30: error: conflicting
types for 'ptrdiff_t'
/usr/lib/gcc/i486-linux-gnu/4.1.3/include/stddef.h:152: error: previous
declaration of 'ptrdiff_t' was here



--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> It now refuses to install on php 5.2.3, i.e. ubuntu 7.10.  (Wasn't the
> plan to include the required macros in the ./configure script (or
> whatever) so that it could install on more PHP installations.)

Well, I'm not sure how these macros can be included without conflicting
with 5.2.4 where these macros are already defined in system config. If
you know how to do it please send a patch.

> /tmp/pear/temp/intl/collator/collator_sort.c  -fPIC -DPIC -o
> collator/.libs/collator_sort.o
> /tmp/pear/temp/intl/collator/collator_sort.c:30: error: conflicting
> types for 'ptrdiff_t'
> /usr/lib/gcc/i486-linux-gnu/4.1.3/include/stddef.h:152: error: previous
> declaration of 'ptrdiff_t' was here

Something is wrong here - this line is specifically surrounded with
#if !defined(HAVE_PTRDIFF_T) && !defined(_PTRDIFF_T_DEFINED)
how happens it's executed?
My php_config.h has #define HAVE_PTRDIFF_T 1 - does yours? If not, does
your configure.in have check for ptrdiff?
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Darren Cook]

> Well, I'm not sure how these macros can be included without conflicting
> with 5.2.4 where these macros are already defined in system config.

Sorry, I don't know either. It seems like redefining a macro should be a
common need however.

> Something is wrong here - this line is specifically surrounded with
> #if !defined(HAVE_PTRDIFF_T) && !defined(_PTRDIFF_T_DEFINED)
> how happens it's executed?
> My php_config.h has #define HAVE_PTRDIFF_T 1 - does yours? If not, does
> your configure.in have check for ptrdiff?

The only ptrdiff reference in php_config.h is:

/* The size of `ptrdiff_t', as computed by sizeof. */
#define SIZEOF_PTRDIFF_T 4


I don't have a configure.in (under either /usr/include/php5 or
/usr/lib/php5), and no references to ptrdiff or PTRDIFF inside any file
in /usr/lib/php5/build.

Looking through cvs, it seems something ptrdiff-related was added to
configure.in 11 months ago:
 http://cvs.php.net/viewvc.cgi/php-src/configure.in?r1=1.628&r2=1.629

Is this another php 5.2.4 dependency? What do I need to add to
php_config.h, on a 32-bit OS, to get past this?

Thanks for your help,

Darren


--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> The only ptrdiff reference in php_config.h is:
>
> /* The size of `ptrdiff_t', as computed by sizeof. */
> #define SIZEOF_PTRDIFF_T 4

That's strange -

> I don't have a configure.in (under either /usr/include/php5 or
> /usr/lib/php5), and no references to ptrdiff or PTRDIFF inside any file
> in /usr/lib/php5/build.

You are supposed to have configure.in - it's part of PHP source. Do you
use binary install? If so, which version?

> Is this another php 5.2.4 dependency? What do I need to add to
> php_config.h, on a 32-bit OS, to get past this?

I guess adding correct definition for HAVE_PTRDIFF_T should be enough.
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Darren Cook]

> Well, I'm not sure how these macros can be included without conflicting
> with 5.2.4 where these macros are already defined in system config. If
> you know how to do it please send a patch.

A quick bit of study suggests it most likely "just works", as long as
you have square brackets around the macro name (see
http://ac-archive.sourceforge.net/doc/howto.html and search for word
"redefine").

As a quick test I added a 2nd copy of AC_DEFUN([PHP_SETUP_ICU],[...]) to
/usr/lib/php5/build/acinclude.m4 and it didn't cause an error.

Darren


--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Darren Cook]

>> I don't have a configure.in (under either /usr/include/php5 or
>> /usr/lib/php5), and no references to ptrdiff or PTRDIFF inside any file
>> in /usr/lib/php5/build.
>
> You are supposed to have configure.in - it's part of PHP source. Do you
> use binary install? If so, which version?

ubuntu 7.10, with php5 (i.e. 5.2.3) and php5-dev packages.

>> Is this another php 5.2.4 dependency? What do I need to add to
>> php_config.h, on a 32-bit OS, to get past this?
>
> I guess adding correct definition for HAVE_PTRDIFF_T should be enough.

OK, I added this line at the end of php_config.h:
#define HAVE_PTRDIFF_T 1

And "pecl install intl" now works!
A quick test of Normalizer::normalize() worked.

Thanks for your help,

Darren

--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
                        open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[David Zülke-2]

Hi Stas,

some things we noticed:

- I still think IntlDateFormatter vs the rest w/o Intl prefix is  
inconsistent. Can't we just prefix it with "Intl" across the board?  
Saves trouble down the road

- DateFormatter::parse() and DateFormater::localtime() should have the  
second argument ($parse_pos) as a reference - it is supposed to  
"return" the position where an error occured, in case it could not  
parse the given value. ICU does have it this way, and I think PHP  
should, too. It's pretty valuable information, and if only for  
debugging purposes.
- IntlDateFormatter::format() does not accept DateTime (I think that  
is a known issue)
- There is no way to use or retrieve milliseconds, so far

- What does Collator::sortWithKeys() do, exactly? Why not always have  
this one? Why does the API have a "normal" sorting function and an  
optimized one? Why not just always use the sorting with  
ucol_getSortKey() keys? And why is there no Collator::asortWithKeys(),  
to keep the API consistent?

- INTL_MAX_LOCALE_LEN is 64 - what if I have a longer locale string,  
with options?

- http://php.net/manual/en/intl.examples.php uses a  
"getLocaleByType()" method that does not exist

The only "critical" thing, I would say, is having the $parse_pos  
argument as a reference, as changing that in a later release would  
break code if people pass a value directly. The rest is pretty much  
just questions I'm hoping you could answer, not actual problems ;)

Cheers,

David


Am 27.05.2008 um 23:26 schrieb Stanislav Malyshev:

> Hi!
>
> I've uploaded 1.0.0RC1 version of intl extension on PECL. Please  
> test it and if you think anything has to be added/fixed for 1.0.0  
> please tell.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@...   http://www.zend.com/
> [phone]   MSN: stas@...
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> - I still think IntlDateFormatter vs the rest w/o Intl prefix is
> inconsistent. Can't we just prefix it with "Intl" across the board?
> Saves trouble down the road

Because frankly this prefix sucks and so do names like
IntlMessageFormatter. In order to avoid conflict with Date extension I
had to rename the date formatter, but I really don't want to make it
uglier than it must be.

> - DateFormatter::parse() and DateFormater::localtime() should have the
> second argument ($parse_pos) as a reference - it is supposed to "return"
> the position where an error occured, in case it could not parse the
> given value. ICU does have it this way, and I think PHP should, too.

Please add it as feature request bug report.

> - IntlDateFormatter::format() does not accept DateTime (I think that is
> a known issue)
> - There is no way to use or retrieve milliseconds, so far

And these too. First of these is planned as for the second one it
depends on if ICU allows that.

> - What does Collator::sortWithKeys() do, exactly? Why not always have
> this one? Why does the API have a "normal" sorting function and an
> optimized one? Why not just always use the sorting with
> ucol_getSortKey() keys? And why is there no Collator::asortWithKeys(),
> to keep the API consistent?

sortWithKeys generates collation keys for each entry prior to sorting,
which is supposed to speed it up. But it depends on how many entries
there are - it may prove not efficient to store all those keys.

> - INTL_MAX_LOCALE_LEN is 64 - what if I have a longer locale string,
> with options?

Well, do you? We can increase it, but we have to have some limit since
ICU can't stomach overlong locales.

> - http://php.net/manual/en/intl.examples.php uses a "getLocaleByType()"
> method that does not exist

Thanks. should be just getLocale().

--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[David Zülke-2]

Am 01.06.2008 um 07:43 schrieb Stanislav Malyshev:

> Hi!
>
>> - I still think IntlDateFormatter vs the rest w/o Intl prefix is  
>> inconsistent. Can't we just prefix it with "Intl" across the board?  
>> Saves trouble down the road
>
> Because frankly this prefix sucks and so do names like  
> IntlMessageFormatter. In order to avoid conflict with Date extension  
> I had to rename the date formatter, but I really don't want to make  
> it uglier than it must be.

What if there is a Number extension down the road. Or a Collator  
extension. Or what if people already have classes called  
NumberFormatter etc. That's not too unlikely. I agree that those  
prefixes are ugly, but I firmly believe that it is more important to  
have consistency across the board. "Intl" prefix for all classes just  
makes more sense.


>> - DateFormatter::parse() and DateFormater::localtime() should have  
>> the second argument ($parse_pos) as a reference - it is supposed to  
>> "return" the position where an error occured, in case it could not  
>> parse the given value. ICU does have it this way, and I think PHP  
>> should, too.
>
> Please add it as feature request bug report.

Okay.


>> - IntlDateFormatter::format() does not accept DateTime (I think  
>> that is a known issue)
>> - There is no way to use or retrieve milliseconds, so far
>
> And these too. First of these is planned as for the second one it  
> depends on if ICU allows that.

I believe it does, yeah.

>> - What does Collator::sortWithKeys() do, exactly? Why not always  
>> have this one? Why does the API have a "normal" sorting function  
>> and an optimized one? Why not just always use the sorting with  
>> ucol_getSortKey() keys? And why is there no  
>> Collator::asortWithKeys(), to keep the API consistent?
>
> sortWithKeys generates collation keys for each entry prior to  
> sorting, which is supposed to speed it up. But it depends on how  
> many entries there are - it may prove not efficient to store all  
> those keys.

But why are those internal differences exposed through the API. I  
think that is bad design. I as a caller should not have to bother  
thinking about the internal implementation of the two methods and then  
decide which to use. That's why I'm using the extension, after all, to  
have things convenient.

At least, there should be Collator::asortWithKeys().  But I really  
believe that both sort() and asort() should use the variant with  
generated collation keys, if that one becomes faster as the array size  
grows.

You're saying "it may not prove efficient"... did you or anyone  
benchmark it? ;) Having two methods with the same behavior, just  
different implementations due to a gut feeling might not be the best  
idea. I'm failing to get the extension compiled here on OS X, but will  
go ahead and do benchmarks ASAP


>> - INTL_MAX_LOCALE_LEN is 64 - what if I have a longer locale  
>> string, with options?
>
> Well, do you? We can increase it, but we have to have some limit  
> since ICU can't stomach overlong locales.

Absolutely...  
sr_Latn_RS_REVISED@currency=USD;collation=traditional;calendar=thai-
buddhist is what I could come up with right now... 77 characters.

The other question is what happens if the string is longer than that?  
Does it get cut off or something?

Assume this:

sr_Latn_RS_REVISED
@currency=USD;collation=traditional;mykeyword=myvalue;calendar=thai-
buddhist

That is, in theory, legal. "mykeyword" would be parsed by my custom  
message formatter implementation that can localize... ancient maya  
wall paintings. Or whatever. So locale identifier strings can be of  
any length.

Maybe ext/intl should do this:

- Accept locale strings of arbitrarys length
- Parse them and throw out any keywords ICU cannot handle (i.e.  
everything except "collation", "currency" and "calendar", AFAIK)
- Hand the resulting string over to ICU

What confuses me, in general, is why locales are not implemented as  
objects. Why do I have to pass a locale string to every locale-aware  
function?


Also... having uloc_acceptLanguageFromHTTP exposed in the API would be  
pretty neat ;) Since apparently, that does a mapping of e.g. "en-GB"  
to "en_UK" etc

And.. is there going to be Resources support in the future? AFAIK, the  
CLDR data is compiled to ICU resource bundles, right? That would allow  
reading and using the CLDR data of a locale. Like... reading localized  
country and language names. Yummy. We currently have all this stuff  
implemented in userland PHP code, which is, er, a bit slow :)


Cheers,

David

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Darren Cook]

> - I still think IntlDateFormatter vs the rest w/o Intl prefix is
> inconsistent. Can't we just prefix it with "Intl" across the board?
> Saves trouble down the road

I'd like to second this proposal. Consistency and
far-less-likely-to-clash-with-existing-code are more important (IMHO)
than slightly longer, slightly uglier names. It also makes it easier to
identify which code is coming from which library (*).


Namespaces were supposed to be in php5 but got pulled at the last minute
(IIRC), but I see they will be in php6. Perhaps the Intl prefix could be
used consistently on the php5 version, and not used at all (i.e.
IntlDateFormatter becomes DateFormatter) in php6? On the other hand,
having to rename functions to move from php5 to php6 would be unpopular?
Are any other php6 libraries planning to drop prefixes?


Darren

*: This is why I often use full names in C++, such as std::cout, instead
of "using namespace std;"


--
Darren Cook, Software Developer/Researcher
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
                        open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/  (My flash charting demos)

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> What if there is a Number extension down the road. Or a Collator
> extension. Or what if people already have classes called NumberFormatter

Well, what if they have classes named IntlNumberFormatter? There can be
all kinds of classes, and until we have standard namespace for internal
classes we have to live with names being global and make them
sufficiently distinct to avoid collisions. I think NumberFormatter is
sufficiently distinct.

> But why are those internal differences exposed through the API. I think

Because there are cases when either one of them can be used, IMO.

> At least, there should be Collator::asortWithKeys().  But I really

Current implementation doesn't allow to do asort with keys easily, but
this can be improved. Contributions welcome btw ;)
Also, asort seems to be less frequent use case for the data that require
collation. That doesn't mean it shouldn't be done, just from priority
point of view.

> idea. I'm failing to get the extension compiled here on OS X, but will

What's the problem on OS X? I'd like having it building on any OSes
supported by PHP, so could you provide more info on this?

> sr_Latn_RS_REVISED@currency=USD;collation=traditional;calendar=thai-buddhist
> is what I could come up with right now... 77 characters.

That's really not a frequent case - especially taking into account that
there's no function that needs currency, collation and calendar at the
same time. But for the main reason see below.

> The other question is what happens if the string is longer than that?
> Does it get cut off or something?

No, the function getting overlong locale name would fail.

> paintings. Or whatever. So locale identifier strings can be of any length.

Please tell that to the ICU library developers. 98-byte long locale
provably crashes ICU libraries. I didn't want to take chances so I chose
smallest "round" number for the limit that works reliably. I'd be happy
to raise it if I could be sure ICU would work OK with it.

> Maybe ext/intl should do this:
>
> - Accept locale strings of arbitrarys length
> - Parse them and throw out any keywords ICU cannot handle (i.e.
> everything except "collation", "currency" and "calendar", AFAIK)
> - Hand the resulting string over to ICU

Well, maybe, but not in 1.0 :) Note that this will also significantly
slow down the functions and introduce dependency in PHP code for locale
formats.

> What confuses me, in general, is why locales are not implemented as
> objects. Why do I have to pass a locale string to every locale-aware
> function?

Because locale is essentially the string. There's nothing in the locale
that isn't in the string, so you don't need any specific object for that
- it wouldn't give you any value.

> Also... having uloc_acceptLanguageFromHTTP exposed in the API would be
> pretty neat ;) Since apparently, that does a mapping of e.g. "en-GB" to
> "en_UK" etc

Feature request on pecl.php.net? ;) It'd be really easier to keep track
of it that way.

> And.. is there going to be Resources support in the future? AFAIK, the

Yes, it's planned.
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...



--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Lars Strojny-2]

Hi Stas,

Am Montag, den 02.06.2008, 08:36 +0300 schrieb Stanislav Malyshev:
> Well, what if they have classes named IntlNumberFormatter? There can
> be all kinds of classes, and until we have standard namespace for
> internal classes we have to live with names being global and make them
> sufficiently distinct to avoid collisions. I think NumberFormatter is
> sufficiently distinct.

There might be classes like IntlNumberFormatter and someones business
could be set at risk by a nuke but both are not very likely, so people
normally ignore the nuke scenario. In the same way I think it is not so
realistic to have a IntlNumberFormatter but a NumberFormatter is much
more realistic. Would you accept a patch to prefix everything with an
intl-Prefix?

cu, Lars

[Lars Strojny-2]

Hi Stas,

(sorry for the cluttered reply)

Am Montag, den 02.06.2008, 08:36 +0300 schrieb Stanislav Malyshev:
> Because locale is essentially the string. There's nothing in the
> locale that isn't in the string, so you don't need any specific object
> for that - it wouldn't give you any value.

Except that it is easier to validate with object setters than to parse a
locale string.

$locale = new IntlLocale();
$locale->setCurrency(IntlCurrency::USD);
$locale->setCollation(IntlCollation::TRADITIONAL);

or

$locale = new IntlLocale('en_US', IntlCurrency::USD, IntlCollation::TRADITIONAL, IntlCalendar::THAI_BUDDHIST);

Creating the locale programatically, which might be a common use case
for the web, is much easier with a well defined object than with a
somehow concatted string.

cu, Lars

[Stanislav Malyshev]

Hi!

> $locale = new IntlLocale();
> $locale->setCurrency(IntlCurrency::USD);
> $locale->setCollation(IntlCollation::TRADITIONAL);

You have functions for that in Locale class.
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[David Zülke-2]

Am 02.06.2008 um 07:36 schrieb Stanislav Malyshev:

> Hi!
>
>> What if there is a Number extension down the road. Or a Collator  
>> extension. Or what if people already have classes called  
>> NumberFormatter
>
> Well, what if they have classes named IntlNumberFormatter? There can  
> be
> all kinds of classes, and until we have standard namespace for  
> internal
> classes we have to live with names being global and make them
> sufficiently distinct to avoid collisions. I think NumberFormatter is
> sufficiently distinct.

Obviously, it is less likely that someone who wrote a Collator called  
their class "IntlCollator" instead of "Collator".

Consistency is important. The lack of it is also often what PHP users  
complain about. This should really be changed to be consistent across  
the board, Stas.


>> But why are those internal differences exposed through the API. I  
>> think
>
> Because there are cases when either one of them can be used, IMO.

I don't think that's a valid argument. Why does the API have to expose  
the internal implementation differences?


>> At least, there should be Collator::asortWithKeys().  But I really
>
> Current implementation doesn't allow to do asort with keys easily, but
> this can be improved. Contributions welcome btw ;)
> Also, asort seems to be less frequent use case for the data that  
> require
> collation. That doesn't mean it shouldn't be done, just from  
> priority point of view.

Again, I think it should be consistent :) Why not just toss out  
sort(), rename sortWithKeys() to sort(), and the optimize asort() later.


>> idea. I'm failing to get the extension compiled here on OS X, but  
>> will
>
> What's the problem on OS X? I'd like having it building on any OSes
> supported by PHP, so could you provide more info on this?

Can't quite remember, but will let you know ASAP. Probably a problem  
on my side.


>> sr_Latn_RS_REVISED@currency=USD;collation=traditional;calendar=thai-
>> buddhist is what I could come up with right now... 77 characters.
>
> That's really not a frequent case - especially taking into account  
> that
> there's no function that needs currency, collation and calendar at the
> same time. But for the main reason see below.

Waitwaitwait. The entire point of doing internationalization properly,  
using ICU and the CLDR, is that even seemingly obscure cases are  
possible.

I mean who are you/we to decide that someone from the Republic of  
Serbia, who speaks Serbian, may not view sales numbers for last week's  
month in the thai-buddhist calendar in USD and sorted "traditionally"?

You think that is unrealistic? Maybe. Then what about this:

zh_Hans_CN@currency=USD;collation=traditional;calendar=gregorian

China, simplified Han, List of quarterly sales, Gregorian calendar,  
normal collation for sorting person names.

65 characters. And this is not unrealistic.

Stas, internationalization is not about neglecting edge cases. It has  
to be done properly. That's the whole point of it.

>> The other question is what happens if the string is longer than  
>> that? Does it get cut off or something?
>
> No, the function getting overlong locale name would fail.
>
>> paintings. Or whatever. So locale identifier strings can be of any  
>> length.
>
> Please tell that to the ICU library developers. 98-byte long locale
> provably crashes ICU libraries. I didn't want to take chances so I  
> chose
> smallest "round" number for the limit that works reliably. I'd be  
> happy to raise it if I could be sure ICU would work OK with it.

97? ;)

>> Maybe ext/intl should do this:
>> - Accept locale strings of arbitrarys length
>> - Parse them and throw out any keywords ICU cannot handle (i.e.  
>> everything except "collation", "currency" and "calendar", AFAIK)
>> - Hand the resulting string over to ICU
>
> Well, maybe, but not in 1.0 :) Note that this will also significantly
> slow down the functions and introduce dependency in PHP code for  
> locale
> formats.
>
>> What confuses me, in general, is why locales are not implemented as  
>> objects. Why do I have to pass a locale string to every locale-
>> aware function?
>
> Because locale is essentially the string. There's nothing in the  
> locale that isn't in the string, so you don't need any specific  
> object for that - it wouldn't give you any value.

But you have to parse the locale string each time, right? That is  
overhead. It would be much more logical to pass it around as a  
resource/object. ICU does it the same way.


>> Also... having uloc_acceptLanguageFromHTTP exposed in the API would  
>> be pretty neat ;) Since apparently, that does a mapping of e.g. "en-
>> GB" to "en_UK" etc
>
> Feature request on pecl.php.net? ;) It'd be really easier to keep  
> track of it that way.

That was more of a joke ;) But I will add all those to the issue  
tracker, yes.

>> And.. is there going to be Resources support in the future? AFAIK,  
>> the
>
> Yes, it's planned.

Awesome.


David

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[David Zülke-2]

You mean http://docs.php.net/manual/en/locale.composelocale.php ?

I just looked at that for the first time.

It is utterly frightening. You can't possibly be serious about this:

$arr = array(
   'language' => 'en',
   'script'   => 'Hans',
   'region'   => 'CN',
   'variant2' => 'rozaj',
   'variant1' => 'nedis',
   'private1' => 'prv1',
   'private2' => 'prv2'
);
echo Locale::composeLocale($arr);

I may use private0, private1, ... private14?

How about

$arr = array(
   'language' => 'en',
   'script'   => 'Hans',
   'region'   => 'CN',
   'variants' => array(
     'rozaj',
     'nedis',
   ),
   'privates' => array(
     'prv1',
     'prv2',
   ),
);
echo Locale::composeLocale($arr);


- David



Am 03.06.2008 um 12:50 schrieb Stanislav Malyshev:

> Hi!
>
>> $locale = new IntlLocale();
>> $locale->setCurrency(IntlCurrency::USD);
>> $locale->setCollation(IntlCollation::TRADITIONAL);
>
> You have functions for that in Locale class.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@...   http://www.zend.com/
> [phone]   MSN: stas@...
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> How about
>
> $arr = array(
>   'language' => 'en',
>   'script'   => 'Hans',
>   'region'   => 'CN',
>   'variants' => array(
>     'rozaj',
>     'nedis',
>   ),
>   'privates' => array(
>     'prv1',
>     'prv2',
>   ),
> );
> echo Locale::composeLocale($arr);

Nice idea, please add a feature request. Maybe even better would be to
allow "private"/"variant" to be both string and array (now it can be
only string).
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stanislav Malyshev]

Hi!

> Obviously, it is less likely that someone who wrote a Collator called
> their class "IntlCollator" instead of "Collator".

But we want to use Collator name, because we want to use these classes
in PHP 6, and we want PHP collation be called Collator, just as PHP date
functions are called DateTime and PHP's COM handling class is called
COM, even though somebody could have their own implementation of COM and
date/time handling.

> complain about. This should really be changed to be consistent across
> the board, Stas.

I don't see why adding unnecessary prefixes to function names would add
anything. When you want to do collation, you expect your class to be
named "collator", and when you want to deal with locales, you want the
class to be named "locale". What's "inconsistent" in that - that they
start from different letters?

> I mean who are you/we to decide that someone from the Republic of
> Serbia, who speaks Serbian, may not view sales numbers for last week's
> month in the thai-buddhist calendar in USD and sorted "traditionally"?

I don't decide anything on which locales people use. Though people that
actually work in the i18n field says using such locales are extremely
rare, and I believe them.
But in any case, you don't need yo use calendar for collator, and you
don't need to use currency for date/time formatting.

>> Please tell that to the ICU library developers. 98-byte long locale
>> provably crashes ICU libraries. I didn't want to take chances so I chose
>> smallest "round" number for the limit that works reliably. I'd be
>> happy to raise it if I could be sure ICU would work OK with it.
>
> 97? ;)

I can't be really sure any other ICU function wouldn't crash on any
other OS on 97. I could raise it, but how 97 is that better than 64? If
you suppose people stuff everything and a kitchen sink there, 97 could
be as easily overrun. If you base on most frequent usage, 64 is more
than enough. If there's a case to be made for making it not 64 but any
other number, I'm ready to hear it - but I want some real-life data on it.

> But you have to parse the locale string each time, right? That is

No, I don't. ICU API takes char*.
--
Stanislav Malyshev, Zend Software Architect
stas@...   http://www.zend.com/
[phone]   MSN: stas@...

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php