I see that you rebuild res files. If you used anything newer than icu 4.2, then those are useless. There was binary format change in icu > 4.2.

I'm not sure I understand, but I used latest ICU data from svn as it says in UPDATE.txt. I tested it and it seem to work fine.

The data is unimportant, what is important is which version of icu was used to build the binary files. And it has to be 4.2 as this is what most LTS Linux distributions use.
Just run genrb -V and you'll see the ICU version.

genrb version 3.3 (ICU version 4.4.2).

Maybe update-data.php should be able to check this? Or it should be noted in UPDATE.txt

You must compile the files with the format version 1.2 not 2.0, update-data.php is for a local update

Where did you see 2.0?

I'm a bit confused, I just followed instructions.

I'm using Ubuntu 11.10, can someone help me how to update this files? I'm close to migrate to CLDR :)

Well you can use Ubuntu 10.04 for that, or build icu 4.2 from source just for building locale data.
As the version @stealth35 mentioned, that is the binary file version number.

Where did you see 2.0?

In the binary file

I'm a bit confused, I just followed instructions.

Like I said, update-data.php it's only for your local data/version, if you want to share this change the format version, with --formatVersion and choose 1.2

ICU <= 4.4 is buggy on localized date formats e.g. "FEBR." instead of "FEB" and have errors in countries list for russian/ukrainian lang. I don't know if this related to icu-data or icu itself, but i believe we need to generate ".res" from lastest ICU:

Compiled-Version: 4.8.1
Runtime-Version: 4.8.1
Compiled-Unicode-Version: 6.0
Runtime-Unicode-Version: 6.0
CLDR-Version: 2.0.1
ICUDATA: icudt48l

And rewrite code to support CLDR 2.0 format.
P.S. Stable debian do not have icu 4.8 package, it can be found at 'sid' repo.

Just noticed, genrb version 3.3 (ICU version 4.8.1). Have option ``` --formatVersion write a .res file compatible with the requested formatVersion (single digit);
for example, --formatVersion 1

@umpirsky The tests got broken with this update.

I've used some ICU data to check that the NumberFormatter::formatCurrency() is righly implemented. The problem is that with every CLDR update, some tests can broken because of changes in the currency symbol (example) and/or rounding rules. I've talked with @igorw about how to handle this and he gave a good idea that is to ship different yml files with the expected formatted values for specific ICU versions.

Then the tests would use the expected values for the current PHP ICU version. But for this we would need to ship with the stub data for the different ICU releases. This would add at least 4 new stub data files to the component for each ICU release. The only problem is that we don't have a special CI build setup to run the Locale tests for different PHP/ICU releases but we'll at least mitigate the need to adjust the tests because of ICU/CLDR updates. Then we will can focus only in implementing the changes introduced in the ext/intl NumberFormatter, IntlDateFormatter and Collator classes.

Unfortunatelly I will can not participate in the Symfony bug hunt days but I'll have free time on this weekend and I'll give some attention to the Locale component.

I've been playing with locale data a bit today as a part of bug hunt day.
Here is what I have done:

• upcoming Ubuntu 12.04 which comes with icu version 4.8
  • run the tests with data that comes with sf2 failing tests
• upcoming Ubuntu 12.04 which comes with icu version 4.8
  • updated the icu data according to UPDATE.md but added --formatVersion 1 to the genrb line
  • run the tests same failing tests as before + 3 additional CostaRicanColons (changed the monetary prefix from ₡ to CRC)
• updated sf2 data on Ubuntu 10.04 icu 4.2 with the data generated on Ubuntu 12.04
  • copied the updated data from 12.04
  • all tests that need locale data fail because locale is unable to load res file it seems that although the --formatVersion 1 switch was present the res files are still incompatible.
• updated sf2 data on Ubuntu 10.04 with icu 4.2
  • the only failing tests are CostaRicanColons (changed the monetary prefix from ₡ to CRC)

What solutions we have?

1. Support both versions.
2. Leave ICU 4.2 for Symfony 2.0 as legacy and use 4.8 for 2.1 release (already contain many BC breaks)
3. ???

@mvrhov @dr-fozzy I'm in debt with this Locale issue. Maybe we could ship with each major ICU release data. This way we could run the tests with the almost same version available in the environment. I found that Debian (for an example) sticky with a major version and apply only security patches to the code (ICU C source code or the makefile script).

CLDR data is updated at a incredible pace. Since the three chosen currencies helps to test the formatting implementation, I see no other way to dealt with this. Thoughts?

Updating the php code to match major icu versions shouldn't be the problem, but shipping res files for each version would greatly increase the symfony download size.
I'd rather update the cldr with every icu version and then skip the tests if the local icu is not the same version.
We also need to be aware of LTS Linux distributions that use ICU <4.4 and build the res files on that distribution while it's supported. Another option would be to detect the icu version in composer and then download appropriate res files?

@mvrhov

I'd rather update the cldr with every icu version and then skip the tests if the local icu is not the same version.

It would be good but this way we might use CLDR/ICU data that could be not available in a lot of Linux distros. If we shipped today with ICU 49.1.1 (and CLDR 21.0.1), our tests would not be executed in the CI environment, since Travis uses Ubuntu Oneiric (11.10) that ships with ICU 4.4 (they try to keep one release Ubuntu behind). With the next Travis update (to Ubuntu Precise with ICU 4.8) our tests probably would be skipped too.

The problems now are only some tests (specifically the ones that I coded for checking monetary values) but they are really easy to deal because basically they are just formatters.

We also need to be aware of LTS Linux distributions that use ICU <4.4 and build the res files on that distribution while it's supported. Another option would be to detect the icu version in composer and then download appropriate res files?

I did not understand the first point but I liked the second one. We could have a separated repository for the resource files.

@igorw - now that you're a Composer mage - do you think this is reasonable?

Is it still realistic to do that in 2.1? OR do we reschedule it for 2.2?

Yes, it is feasible. Sorry for the lack of feedback, I had issues with the genrb for the different ICU versions I have installed and almost none time for this in the last weeks but after solving it it is just a matter of updating some tests.

I will PR it as soon as possible for the 2.1 release.

@fabpot This issue can be closed.