Skeleton App i18n issues

[Chris Testroet]

Hi,

I've had some thoughts/issues regarding the i18n (translations) in the
Zend Skeleton Application.

Currently the base Zsa fails if the use doesn't have ext/intl installed
with a fatal error (class not found). IMO the zsa should "just work" ,
whatever the configuration.

In searching for a solution in IRC, a remedy was suggested:

Create a "with-i18n" branch for Zsa that would have the translations,
but remove them from master. So people could have a choice.

I like that idea much better than just removing i18n from Zsa.

Chris

[Aboozar Ghafari]

Hi,
I agree with dear Chris.
I had the same problem in the first use of the ZSA and I think this problem can be confusing to beginners.

Aboozar

On Wed, Jul 18, 2012 at 12:44 AM, Chris Testroet <[hidden email]> wrote:

Hi,

I've had some thoughts/issues regarding the i18n (translations) in the Zend Skeleton Application.

Currently the base Zsa fails if the use doesn't have ext/intl installed with a fatal error (class not found). IMO the zsa should "just work" , whatever the configuration.

In searching for a solution in IRC, a remedy was suggested:

Create a "with-i18n" branch for Zsa that would have the translations, but remove them from master. So people could have a choice.

I like that idea much better than just removing i18n from Zsa.

Chris

[EvanDotPro]

On Tue, Jul 17, 2012 at 1:14 PM, Chris Testroet
<[hidden email]> wrote:

> Hi,
>
> I've had some thoughts/issues regarding the i18n (translations) in the Zend
> Skeleton Application.
>
> Currently the base Zsa fails if the use doesn't have ext/intl installed with
> a fatal error (class not found). IMO the zsa should "just work" , whatever
> the configuration.
>
> In searching for a solution in IRC, a remedy was suggested:
>
> Create a "with-i18n" branch for Zsa that would have the translations, but
> remove them from master. So people could have a choice.
>
> I like that idea much better than just removing i18n from Zsa.

As mentioned in IRC, I'm fine with this. As we approach RC / stable,
the skeleton will be changing less and less. Thus, separate branches
would not be a burden to maintain, as is usually the concern with such
a strategy.

--
Evan Coury

[Jonathan Maron]

Hello all

I also ran into this problem last week and posted about it here:

https://plus.google.com/100550744378810193205/posts/jfmFvyLoGGS

I was able to fix the problem, by installing the correction extension
("apt-get install php5-intl"), however, not very web developer runs
his/her own server.

I believe an error message, such as:

  Zend Skeleton Application requires the intl PECL
  extension for PHP. Currently this is not installed.
  Learn more at:
  http://www.php.net/manual/en/book.intl.php

would benefit many developers for the "with-i18n" branch.

What do you think?

Jonathan





On Wed, Jul 18, 2012 at 4:50 AM, Evan Coury <[hidden email]> wrote:

> On Tue, Jul 17, 2012 at 1:14 PM, Chris Testroet
> <[hidden email]> wrote:
>> Hi,
>>
>> I've had some thoughts/issues regarding the i18n (translations) in the Zend
>> Skeleton Application.
>>
>> Currently the base Zsa fails if the use doesn't have ext/intl installed with
>> a fatal error (class not found). IMO the zsa should "just work" , whatever
>> the configuration.
>>
>> In searching for a solution in IRC, a remedy was suggested:
>>
>> Create a "with-i18n" branch for Zsa that would have the translations, but
>> remove them from master. So people could have a choice.
>>
>> I like that idea much better than just removing i18n from Zsa.
>
> As mentioned in IRC, I'm fine with this. As we approach RC / stable,
> the skeleton will be changing less and less. Thus, separate branches
> would not be a burden to maintain, as is usually the concern with such
> a strategy.
>
> --
> Evan Coury

[Sascha-Oliver Prolic]

2012/7/18 Jonathan Maron <[hidden email]>:

> Hello all
>
> I also ran into this problem last week and posted about it here:
>
> https://plus.google.com/100550744378810193205/posts/jfmFvyLoGGS
>
> I was able to fix the problem, by installing the correction extension
> ("apt-get install php5-intl"), however, not very web developer runs
> his/her own server.
>
> I believe an error message, such as:
>
>   Zend Skeleton Application requires the intl PECL
>   extension for PHP. Currently this is not installed.
>   Learn more at:
>   http://www.php.net/manual/en/book.intl.php
>
> would benefit many developers for the "with-i18n" branch.
>
> What do you think?
>
> Jonathan
>
>
>
>
>
> On Wed, Jul 18, 2012 at 4:50 AM, Evan Coury <[hidden email]> wrote:
>> On Tue, Jul 17, 2012 at 1:14 PM, Chris Testroet
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> I've had some thoughts/issues regarding the i18n (translations) in the Zend
>>> Skeleton Application.
>>>
>>> Currently the base Zsa fails if the use doesn't have ext/intl installed with
>>> a fatal error (class not found). IMO the zsa should "just work" , whatever
>>> the configuration.
>>>
>>> In searching for a solution in IRC, a remedy was suggested:
>>>
>>> Create a "with-i18n" branch for Zsa that would have the translations, but
>>> remove them from master. So people could have a choice.
>>>
>>> I like that idea much better than just removing i18n from Zsa.
>>
>> As mentioned in IRC, I'm fine with this. As we approach RC / stable,
>> the skeleton will be changing less and less. Thus, separate branches
>> would not be a burden to maintain, as is usually the concern with such
>> a strategy.
>>
>> --
>> Evan Coury

Agree with Jonathan, just test if the extensions is installed, and if
not, throw an explaining exception. there is no need for a separate
branch without ext-intl, imo.

Best Regards

Sascha

--
Sascha-Oliver Prolic

[Jurian Sluiman-3]

2012/7/18 Sascha-Oliver Prolic <[hidden email]>

Agree with Jonathan, just test if the extensions is installed, and if
not, throw an explaining exception. there is no need for a separate
branch without ext-intl, imo.

I don't agree here. The purpose of the first post was two-fold as far as I understand:

1. Inform users the ext/intl needs to be installed when they try to load the "localized" version but do not have the ext/intl installed;

2. Give users without the extension loaded an opportunity to use a "non-localized" version, because they either do not want or are not able to install ext/intl.

Your suggested warning solves problem #1, but not problem #2.

--
Jurian Sluiman