Intl extension

[José Lorenzo]

Hey guys, what do you think about replacing our implementation of CakeTime, CakeNumber and I18n with the functions provided by the intl extension?

It seems like a common extension that is available in shared hosts like dreamhost and would really solve tons of problems in our own implementation. Now that we are taking the leap on 5.4, I don't think that introducing a dependency like this would hurt.

[Graham Weldon]

+1 from me. It's common enough as far as my exposure to extensions. 

On 29/05/2013, at 6:28 PM, José Lorenzo <jose...@gmail.com> wrote:

Hey guys, what do you think about replacing our implementation of CakeTime, CakeNumber and I18n with the functions provided by the intl extension?

It seems like a common extension that is available in shared hosts like dreamhost and would really solve tons of problems in our own implementation. Now that we are taking the leap on 5.4, I don't think that introducing a dependency like this would hurt.

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[mark_story]

I like the idea of using Intl as well. It reduces the code we have to maintain and removes a bunch of edge cases. Intl doesn't seem to be a built in package for ubuntu or centos, or homebrew from what I can see. However it is available for all 3. In light of that requiring it to do formatting/i18n doesn't seem crazy. 

How would people be handling po files in a world where we use intl?

-Mark

[José Lorenzo]

Well, the .po files would not go away, they would just be enhanced to have smarter replace variables (http://www.php.net/manual/en/messageformatter.formatmessage.php). If we choose to improve it, the we just need to alter the i18n class to delegate the variable interpolation to the MessageFormatter intl class.

What intl provides is a solid implementation of language detection, locale selection, date and number formatting, which are things we don't have a need to re-do on our own. It would also eliminate the need to have our own list of locales in the L10n class.

On Thu, May 30, 2013 at 8:41 PM, Frank de Graaf (Phally) <phall...@gmail.com> wrote:

Yes please. There are some BC issues with the current implementation that make stuff a bit confusing and overly complicated.

On Wednesday, May 29, 2013 11:28:30 AM UTC+2, José Lorenzo wrote:

Hey guys, what do you think about replacing our implementation of CakeTime, CakeNumber and I18n with the functions provided by the intl extension?

It seems like a common extension that is available in shared hosts like dreamhost and would really solve tons of problems in our own implementation. Now that we are taking the leap on 5.4, I don't think that introducing a dependency like this would hurt.

--

[Saleh Souzanchi]

+1 Even the idea of ​​using intl is a pleasure for me.

     Best Regards
   Saleh  Sozanchi
 * * * * * * * * * * * * *

Mobile : +98 918 111 7209

Phone : +98 811 823 4448

http://soozanchi.ir
http://cakephp.ir

On Wed, May 29, 2013 at 1:58 PM, José Lorenzo <jose...@gmail.com> wrote:

Hey guys, what do you think about replacing our implementation of CakeTime, CakeNumber and I18n with the functions provided by the intl extension?

It seems like a common extension that is available in shared hosts like dreamhost and would really solve tons of problems in our own implementation. Now that we are taking the leap on 5.4, I don't think that introducing a dependency like this would hurt.

--

[mark_story]

What kind of API changes would be required to the __* methods to make this transition if any? Also would we be able to migrate existing PO files with a tool or would people have to manually change their translations?

Offloading the plural rules and improving the functionality around number and date formatting sounds quite useful to me, and totally worth investigating.

-Mark

[mark_story]

It looks like the symfony - which also uses intl has had to re-implement intl in PHP as the extension is difficult/painful to install. 

 The intl PHP extension and the ICU library are great tools, but they are also a nightmare to install. To ease things a little bit, Bernhard created two new components: Icu and Intl.

See http://symfony.com/blog/new-in-symfony-2-3-what-else and https://github.com/symfony/symfony/pull/7386

-Mark 

On Wednesday, 29 May 2013 05:28:30 UTC-4, José Lorenzo wrote:

[Jose Diaz-Gonzalez]

Yeah I've had issues with intl in homebrew-php such that it can no longer be installed as compiled into php, but as an extension. Just a note on my own experiences.

--