Zend Framework

Return full locale instead of language code when locale has one region only

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 1.10.6
  • Fix Version/s: 1.10.7
  • Component/s: Zend_Locale
  • Labels:
    None

Description

I've found one annoying thing, when using Zend_Currency, which requires whole language+region locale.

In my situation, when trying:
$currency = new Zend_Currency(array('value' => 12.34), new Zend_Locale());
$currency = new Zend_Currency(array('value' => 12.34));

...and using browser with:
Accept-Language: pl,en-us;q=0.7,en;q=0.3
pl has default 1.0 quality factor.

...and having:
Environment language pl_PL, pl
Default language en_US

I get that languages returned:

browser array(3) { ["pl"] => float(1) ["en_US"] => float(0.7) ["en"] => float(0.7) }

environment array(2) { ["pl_PL"] => int(1) ["pl"] => int(1) }

default array(1) { ["en"] => bool(true) }

auto array(4) { ["pl"] => float(1) ["en_US"] => float(0.7) ["en"] => float(0.7) ["pl_PL"] => int(1) }

Issue:
When it comes to choose, 'pl' is returned as locale, which disallows directly using Zend_Currency().

Solution (request):
When there are two languages with the same, highest quality factor, return more detailed one.

General idea:
When language has only one region (it's not only Poland, there are more countries/locales like this) there should be returned more detailed locale string ('pl_PL' instead of 'pl', 'lv_LV' <= 'lv').

Activity

Hide
Thomas Weidner added a comment -

Locale Upgrading is another issue which is already worked on.

Show
Thomas Weidner added a comment - Locale Upgrading is another issue which is already worked on.
Hide
Marcin Wójcik added a comment -

Great, thanks.

Another thing that bothers me is when using Zend_Dojo_Form_Element_CurrencyTextBox with currency set to, let's say 'PLN', it's displaying well, with all advantages of dijit.form.currencytextbox, but this element actually returns not-localized, plain float to form field.

What makes the problem is Zend_Validate_Float, which is using Zend_Locale. When it receives float string, not number, it does not recognize it as dotted float is not compliant with Polish locale.

Reproduction:
1. Set Zend_Dojo_Form_Element_CurrencyTextBox 'value' to 12.34 and 'currency' to 'PLN'.
2. While displaying dijit.form.currencytextbox it displays locale-aware value ('pl_PL' - 12,34), but imput holds '12.34'
3. Zend_Validate_Float gets string '12.34' and does not recognizes it as float, and tries to use Zend_Locale_Format::isFloat($value, array('locale' => $this->_locale)) - but fails to recognize, because value returned from dijit has dot instead of comma.

I had to create my custom float validator that is exact copy of Zend_Validate_Float but has one more check between is_float() and try{} section - if (is_string($value) && is_numeric($value)) - but that is not elegant way, isn't it?

Do I miss the way to force dijit to return localized float value?

Show
Marcin Wójcik added a comment - Great, thanks. Another thing that bothers me is when using Zend_Dojo_Form_Element_CurrencyTextBox with currency set to, let's say 'PLN', it's displaying well, with all advantages of dijit.form.currencytextbox, but this element actually returns not-localized, plain float to form field. What makes the problem is Zend_Validate_Float, which is using Zend_Locale. When it receives float string, not number, it does not recognize it as dotted float is not compliant with Polish locale. Reproduction: 1. Set Zend_Dojo_Form_Element_CurrencyTextBox 'value' to 12.34 and 'currency' to 'PLN'. 2. While displaying dijit.form.currencytextbox it displays locale-aware value ('pl_PL' - 12,34), but imput holds '12.34' 3. Zend_Validate_Float gets string '12.34' and does not recognizes it as float, and tries to use Zend_Locale_Format::isFloat($value, array('locale' => $this->_locale)) - but fails to recognize, because value returned from dijit has dot instead of comma. I had to create my custom float validator that is exact copy of Zend_Validate_Float but has one more check between is_float() and try{} section - if (is_string($value) && is_numeric($value)) - but that is not elegant way, isn't it? Do I miss the way to force dijit to return localized float value?
Hide
Thomas Weidner added a comment -

Dojo uses it's own validation. It is not combined or related to Zend_Validate.

The main problem is that Dojo converts all input values to english locale. But when your system uses polish locale you will have problems as you noted because polish is not compatible with english notation.

To make this working you simply have to set english as locale to Zend_Validate_Float when you are using Zend_Dojo as input within your form.

Something like

new Zend_Validate_Float(array('locale' => 'en'));
Show
Thomas Weidner added a comment - Dojo uses it's own validation. It is not combined or related to Zend_Validate. The main problem is that Dojo converts all input values to english locale. But when your system uses polish locale you will have problems as you noted because polish is not compatible with english notation. To make this working you simply have to set english as locale to Zend_Validate_Float when you are using Zend_Dojo as input within your form. Something like
new Zend_Validate_Float(array('locale' => 'en'));
Hide
Marcin Wójcik added a comment -

It is good solution when you know that client browser has javascript enabled, but what if you/me/anyone need it working in both situations?

If javascript is disabled, dijit won't convert it to English locale, and there will be message: '12,34' does not appear to be a float.

So still, possible solutions are:

1. find out how to force dijit to return localized value and make Zend_Dojo_Form_Element_CurrencyTextBox to do that (if Zend_Locale is enabled, otherwise it will be ok)

2. use is_numeric() in Zend_Validate_Float() after is_float() and before Zend_Locale_Format::isFloat() - not elegant way, might pass not only floats, but does not break app

Show
Marcin Wójcik added a comment - It is good solution when you know that client browser has javascript enabled, but what if you/me/anyone need it working in both situations? If javascript is disabled, dijit won't convert it to English locale, and there will be message: '12,34' does not appear to be a float. So still, possible solutions are: 1. find out how to force dijit to return localized value and make Zend_Dojo_Form_Element_CurrencyTextBox to do that (if Zend_Locale is enabled, otherwise it will be ok) 2. use is_numeric() in Zend_Validate_Float() after is_float() and before Zend_Locale_Format::isFloat() - not elegant way, might pass not only floats, but does not break app
Hide
Thomas Weidner added a comment -

Closing as duplicate of ZF-6862 for Zend_Locale (locale upgrading).

For your reply which is not related to the issue:

Please open a new issue when you have problems with Zend_Dojo with code for reproduction. Same applies for Zend_Validate when you have problems with this component

Thank you for your report

Show
Thomas Weidner added a comment - Closing as duplicate of ZF-6862 for Zend_Locale (locale upgrading). For your reply which is not related to the issue: Please open a new issue when you have problems with Zend_Dojo with code for reproduction. Same applies for Zend_Validate when you have problems with this component Thank you for your report

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: