El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
Hi,
the data in 1.2 and older is totally outdated from 2006.
1.3 will have up to date data. I will likely reimport the current
stuff before we release.
You can provide a patch or proposal for your data and we can check if
we can include them
should not be a big problem as the structure of the icu data is
already slightly different
On Tue, Oct 27, 2009 at 6:23 PM, nervo <nervo....@gmail.com> wrote:
> Are there any plans to introduce ICU supplemental data in symfony i18n
> layer ?
> They give access to needful informations, such as currency/country
> relations, language/country relations, currencies digits/rounding,
> etc...
> As i need these relations for one of my projects, i also wonder wich
> version of ICU's data is currently used (in case i need to set them
> manually).
Hi again,
I just updated symfony 1.3 branch to use version 1.4.2 of the icu
data. (corresponds to CLDR 1.7.1)
I will happily work on supporting your use case. Mastering these
beasts of stuff isnt easy, and I am glad I solved all utf-8 issues so
far.
<fabian.la...@symfony-project.com> wrote:
> Hi,
> the data in 1.2 and older is totally outdated from 2006.
> 1.3 will have up to date data. I will likely reimport the current
> stuff before we release.
> You can provide a patch or proposal for your data and we can check if
> we can include them
> should not be a big problem as the structure of the icu data is
> already slightly different
> Fabian
> On Tue, Oct 27, 2009 at 6:23 PM, nervo <nervo....@gmail.com> wrote:
>> Are there any plans to introduce ICU supplemental data in symfony i18n
>> layer ?
>> They give access to needful informations, such as currency/country
>> relations, language/country relations, currencies digits/rounding,
>> etc...
>> As i need these relations for one of my projects, i also wonder wich
>> version of ICU's data is currently used (in case i need to set them
>> manually).
Nice to hear symfony 1.3 i18n data will be based on last ICU release.
I just want to point out something about this stuff.
I've red your posts about the relative diffculty of parsing ICU data,
and i don't konw if you have checked the pre-release of their next
version (4.4) but it appears that they have changed their data format.
I understand that using ICU is an inheritage of prado, but ICU is
itself a parsing of CLDR data which is purely XML based.
Zend framework has made the choice of using directly xml cldr data,
and i have to admit its much much easier to deal with (with the price
of some labels changes. ie. a "country" is a "region", a "culture" is
a "locale", ...)(for this last point, i totaly agree with the usage of
"locale" instead of culture, but it's another debate).
Anyway :)
I've already checked your tool to see if i can use it to parse the
file "supplementalData.txt" (in data/misc).
After 5 minutes, i clearly realized, that things would be easier if i
took the same file from CLRD ('supplementalData.xml').
And they did :)
Basically, the plugin i'm working for has some Doctrine tables, with
fixtures auto-generated from culture infos.
A "Culture" class with all supported cultures, a "Currency" class with
all supported currencies, etc...
To make the things glued together, it just missed some "supplemental
data", that i finally get from cldr.
I can work on a patch to include supplemental data, but i definitively
think it would be better/simplier from CLRD.
Just have a look by yourself :)
And maybe we can make a pre-discussion on irc, no ? (you're french
too, don't you ?)
Oh, last thing about #7451, what's your opinion about no alias
inclusion in getCultures ?
From my point of view, if such aliases are clearly tagged as is in
data (like a flag, an attribute, or anything else), i should be nice.
If not, it could be a nightmare toi maintain.
On 27 oct, 22:55, Fabian Lange <fabian.la...@symfony-project.com>
wrote:
> Hi again,
> I just updated symfony 1.3 branch to use version 1.4.2 of the icu
> data. (corresponds to CLDR 1.7.1)
> I will happily work on supporting your use case. Mastering these
> beasts of stuff isnt easy, and I am glad I solved all utf-8 issues so
> far.
> <fabian.la...@symfony-project.com> wrote:
> > Hi,
> > the data in 1.2 and older is totally outdated from 2006.
> > 1.3 will have up to date data. I will likely reimport the current
> > stuff before we release.
> > You can provide a patch or proposal for your data and we can check if
> > we can include them
> > should not be a big problem as the structure of the icu data is
> > already slightly different
> > Fabian
> > On Tue, Oct 27, 2009 at 6:23 PM, nervo <nervo....@gmail.com> wrote:
> >> Are there any plans to introduce ICU supplemental data in symfony i18n
> >> layer ?
> >> They give access to needful informations, such as currency/country
> >> relations, language/country relations, currencies digits/rounding,
> >> etc...
> >> As i need these relations for one of my projects, i also wonder wich
> >> version of ICU's data is currently used (in case i need to set them
> >> manually).
You are totally right with your point on the CLDR xml data. Before
going into that let me just justify why I use the ICU stuff.
I wanted to update the date symfony uses. I was outdated and it needed
an update. So I tried to find out how prado got their data, but did
not succeed. The only thing I know was that they seemed to have used
ICU.
When I checked the ICU files I noticed the similarity to yml, which is
why my hacky converter makes yaml out of it. Then I figured out how
the data was stored inside the arrays and I was done.
I did talk to Fabien quite much about it, and we both thought we don't
have the time to do a proper rewrite.
So I would say we are due to lack of time bound to the ICU stuff for
1.3. and in fact it is quite ok. Much better than the previous data.
but for Symfony 2, I am very open for ideas:
- Shall we take another 3rd party component for i18n? (perhaps)
- Shall we rewrite a parser that reads CLDR xmls and outputs prado? (nah)
- Shall we rewrite the backend of sfCultureInfo so that it takes an
enhanced data structure that is easy to create from CLDR xml? (that is
some work, but if we try to recycle much from the current solution
then it might be ok)
With regard to #7451 i think that aliases should not be listed as
available "culture". it is ok if we can understand them and redirect,
but we shouldn't advertise them. So they should be excluded.
Fabian
PS: I am not French, and especially not the same person as Fabien
(just to remind a few people :-))
> Nice to hear symfony 1.3 i18n data will be based on last ICU release.
> I just want to point out something about this stuff.
> I've red your posts about the relative diffculty of parsing ICU data,
> and i don't konw if you have checked the pre-release of their next
> version (4.4) but it appears that they have changed their data format.
> I understand that using ICU is an inheritage of prado, but ICU is
> itself a parsing of CLDR data which is purely XML based.
> Zend framework has made the choice of using directly xml cldr data,
> and i have to admit its much much easier to deal with (with the price
> of some labels changes. ie. a "country" is a "region", a "culture" is
> a "locale", ...)(for this last point, i totaly agree with the usage of
> "locale" instead of culture, but it's another debate).
> Anyway :)
> I've already checked your tool to see if i can use it to parse the
> file "supplementalData.txt" (in data/misc).
> After 5 minutes, i clearly realized, that things would be easier if i
> took the same file from CLRD ('supplementalData.xml').
> And they did :)
> Basically, the plugin i'm working for has some Doctrine tables, with
> fixtures auto-generated from culture infos.
> A "Culture" class with all supported cultures, a "Currency" class with
> all supported currencies, etc...
> To make the things glued together, it just missed some "supplemental
> data", that i finally get from cldr.
> I can work on a patch to include supplemental data, but i definitively
> think it would be better/simplier from CLRD.
> Just have a look by yourself :)
> And maybe we can make a pre-discussion on irc, no ? (you're french
> too, don't you ?)
> Oh, last thing about #7451, what's your opinion about no alias
> inclusion in getCultures ?
> From my point of view, if such aliases are clearly tagged as is in
> data (like a flag, an attribute, or anything else), i should be nice.
> If not, it could be a nightmare toi maintain.
> On 27 oct, 22:55, Fabian Lange <fabian.la...@symfony-project.com>
> wrote:
>> Hi again,
>> I just updated symfony 1.3 branch to use version 1.4.2 of the icu
>> data. (corresponds to CLDR 1.7.1)
>> I will happily work on supporting your use case. Mastering these
>> beasts of stuff isnt easy, and I am glad I solved all utf-8 issues so
>> far.
>> <fabian.la...@symfony-project.com> wrote:
>> > Hi,
>> > the data in 1.2 and older is totally outdated from 2006.
>> > 1.3 will have up to date data. I will likely reimport the current
>> > stuff before we release.
>> > You can provide a patch or proposal for your data and we can check if
>> > we can include them
>> > should not be a big problem as the structure of the icu data is
>> > already slightly different
>> > Fabian
>> > On Tue, Oct 27, 2009 at 6:23 PM, nervo <nervo....@gmail.com> wrote:
>> >> Are there any plans to introduce ICU supplemental data in symfony i18n
>> >> layer ?
>> >> They give access to needful informations, such as currency/country
>> >> relations, language/country relations, currencies digits/rounding,
>> >> etc...
>> >> As i need these relations for one of my projects, i also wonder wich
>> >> version of ICU's data is currently used (in case i need to set them
>> >> manually).
Let's just start with a little observation around #7451.
Symfony assume a valid language in a culture is strictly 2 chars
length (see the preg_match of sfCultureInfo::validCulture()).
That respects RFC 1766, ok.
But ICU data are not web-only, they handle "locales", where a language
parameter could be 3 chars (ISO 639-1 vs ISO 639-2).
At this time sfCultureInfo::getCultures() return cultures (such as
"kok_IN") which are not valid from the point of view of the same
class :)
Others like "sr_Cyrl" or "en_US_POSIX" are unusable as symfony does
not handle "script" and "variant" aspect of locales (though
sfCultureInfo has a getScripts() method).
Also, note that sfCultureInfo::getLanguages() returns 2 or 3 chars
languages (and "root" too).
You said nightmare :) ?
That said, if you exclude aliases, you should also filter data to have
a coherent set.
As i understand, there is no way that "supplemental data" support
would be included in sf1.3, is that right ?
If so, that's not a really big problem for me.
For symfony 2 and your ideas :
- i think there is a place to stop using "culture" term (who the hell
using "culture" ? everybody talks about "locale")
- Using cldr is definitively a good idea. I did'nt read all the code,
but it should be pretty easy to keep prado layer (or not), and just
take the data from cldr instead of icu (tools/i18n-cldr2dat/cldr-
converter.php)
- sfCultureInfo could definitively be extended to be more opened, and
handle supplemental data (supplemental meta data could be also a good
idea to keep things coherents)
- last thing wich could be REALLY usefull : implement a way to
natively use constant i18n strings.
For this last point, situation today is :
echo __('my name is') --> fr --> "mon nom est"
echo __('my name is') --> de --> "mein name ist"
if you have to change to original sentence in english, you have to
update all its subsequent traductions.
A better approach would be :
echo __('my_name') --> en --> "my name is"
echo __('my_name') --> fr --> "mon nom est"
echo __('my_name') --> de --> "mein name ist"
where 'my_name' is a kind of constant, which will (well, almost) never
change.
I see number of ways to achieve this.
Oh, and last thing, could you bring up your current parsed icu data,
or they are already in svn ?
On Oct 28, 12:14 am, Fabian Lange <fabian.la...@symfony-project.com>
wrote:
> You are totally right with your point on the CLDR xml data. Before
> going into that let me just justify why I use the ICU stuff.
> I wanted to update the date symfony uses. I was outdated and it needed
> an update. So I tried to find out how prado got their data, but did
> not succeed. The only thing I know was that they seemed to have used
> ICU.
> When I checked the ICU files I noticed the similarity to yml, which is
> why my hacky converter makes yaml out of it. Then I figured out how
> the data was stored inside the arrays and I was done.
> I did talk to Fabien quite much about it, and we both thought we don't
> have the time to do a proper rewrite.
> So I would say we are due to lack of time bound to the ICU stuff for
> 1.3. and in fact it is quite ok. Much better than the previous data.
> but for Symfony 2, I am very open for ideas:
> - Shall we take another 3rd party component for i18n? (perhaps)
> - Shall we rewrite a parser that reads CLDR xmls and outputs prado? (nah)
> - Shall we rewrite the backend of sfCultureInfo so that it takes an
> enhanced data structure that is easy to create from CLDR xml? (that is
> some work, but if we try to recycle much from the current solution
> then it might be ok)
> With regard to #7451 i think that aliases should not be listed as
> available "culture". it is ok if we can understand them and redirect,
> but we shouldn't advertise them. So they should be excluded.
> Fabian
> PS: I am not French, and especially not the same person as Fabien
> (just to remind a few people :-))
> On Tue, Oct 27, 2009 at 11:59 PM, nervo <nervo....@gmail.com> wrote:
> > Nice to hear symfony 1.3 i18n data will be based on last ICU release.
> > I just want to point out something about this stuff.
> > I've red your posts about the relative diffculty of parsing ICU data,
> > and i don't konw if you have checked the pre-release of their next
> > version (4.4) but it appears that they have changed their data format.
> > I understand that using ICU is an inheritage of prado, but ICU is
> > itself a parsing of CLDR data which is purely XML based.
> > Zend framework has made the choice of using directly xml cldr data,
> > and i have to admit its much much easier to deal with (with the price
> > of some labels changes. ie. a "country" is a "region", a "culture" is
> > a "locale", ...)(for this last point, i totaly agree with the usage of
> > "locale" instead of culture, but it's another debate).
> > Anyway :)
> > I've already checked your tool to see if i can use it to parse the
> > file "supplementalData.txt" (in data/misc).
> > After 5 minutes, i clearly realized, that things would be easier if i
> > took the same file from CLRD ('supplementalData.xml').
> > And they did :)
> > Basically, the plugin i'm working for has some Doctrine tables, with
> > fixtures auto-generated from culture infos.
> > A "Culture" class with all supported cultures, a "Currency" class with
> > all supported currencies, etc...
> > To make the things glued together, it just missed some "supplemental
> > data", that i finally get from cldr.
> > I can work on a patch to include supplemental data, but i definitively
> > think it would be better/simplier from CLRD.
> > Just have a look by yourself :)
> > And maybe we can make a pre-discussion on irc, no ? (you're french
> > too, don't you ?)
> > Oh, last thing about #7451, what's your opinion about no alias
> > inclusion in getCultures ?
> > From my point of view, if such aliases are clearly tagged as is in
> > data (like a flag, an attribute, or anything else), i should be nice.
> > If not, it could be a nightmare toi maintain.
> > On 27 oct, 22:55, Fabian Lange <fabian.la...@symfony-project.com>
> > wrote:
> >> Hi again,
> >> I just updated symfony 1.3 branch to use version 1.4.2 of the icu
> >> data. (corresponds to CLDR 1.7.1)
> >> I will happily work on supporting your use case. Mastering these
> >> beasts of stuff isnt easy, and I am glad I solved all utf-8 issues so
> >> far.
> >> On Tue, Oct 27, 2009 at 7:08 PM, Fabian Lange
> >> <fabian.la...@symfony-project.com> wrote:
> >> > Hi,
> >> > the data in 1.2 and older is totally outdated from 2006.
> >> > 1.3 will have up to date data. I will likely reimport the current
> >> > stuff before we release.
> >> > You can provide a patch or proposal for your data and we can check if
> >> > we can include them
> >> > should not be a big problem as the structure of the icu data is
> >> > already slightly different
> >> > Fabian
> >> > On Tue, Oct 27, 2009 at 6:23 PM, nervo <nervo....@gmail.com> wrote:
> >> >> Are there any plans to introduce ICU supplemental data in symfony i18n
> >> >> layer ?
> >> >> They give access to needful informations, such as currency/country
> >> >> relations, language/country relations, currencies digits/rounding,
> >> >> etc...
> >> >> As i need these relations for one of my projects, i also wonder wich
> >> >> version of ICU's data is currently used (in case i need to set them
> >> >> manually).
> - last thing wich could be REALLY usefull : implement a way to > natively use constant i18n strings.
> For this last point, situation today is : > echo __('my name is') --> fr --> "mon nom est" > echo __('my name is') --> de --> "mein name ist"
> if you have to change to original sentence in english, you have to > update all its subsequent traductions.
> A better approach would be : > echo __('my_name') --> en --> "my name is" > echo __('my_name') --> fr --> "mon nom est" > echo __('my_name') --> de --> "mein name ist"
You can already do that if you want ! The documentation does not advocate this usage, but it's cleary something you must do on large project.
A nice improvement will be to use some kind of namespacing for constant, ie : frontend.module1.my_name ...
so the __() function will not required a third parameter.
I think the most widely understood coding is the "en_US" varient - LANG_TERRITORY where LANG & TERRITORY are 2 chars. I think it's possible to derive anything else from it (currency, cities, etc).
Well, today, this way give little problem, as if a translation is
asked in a culture which does'nt exists, the source is returned,.
You may guessed to be returned the target in the default culture as a
fallback, instead of the source.
Of course, the same thing happend if the culture exists, but not the
target.
But maybe i missed something.
About that, something confuse me : you are said to give a "source-
language" in the i18n file.
Apparently, the source culture is the default culture (defined in
settings.yml), and the target culture the current culture (set in
session).
But things works even if no "source-language" is defined...
The doc is not very clear on that point.
Maybe i missed everything :)
@david :
just be careful, as the term "territory", stricto senso, also includes
wide things like "Africa" (code 002) or "North America" (code 003).
Also, things like currencies and cities must be based on what you
called "territory", and not "lang_territory"
On Oct 28, 4:28 pm, david <da...@inspiredthinking.co.uk> wrote:
> I think the most widely understood coding is the "en_US" varient -
> LANG_TERRITORY where LANG & TERRITORY are 2 chars.
> I think it's possible to derive anything else from it (currency, cities,
> etc).
> just be careful, as the term "territory", stricto senso, also includes > wide things like "Africa" (code 002) or "North America" (code 003). > Also, things like currencies and cities must be based on what you > called "territory", and not "lang_territory"
:) It's just semantics - it just needs to be defined somewhere for everybody to have the same meaning.
The complete code <lang>_<lang territory> is what will be enough to provide details for things like currencies. The lang element is only good enough for presentation related tasks.
Well, if your application is not available in one language, then you should
change the default language of your user to the default one (where
translation is available).
On Wed, Oct 28, 2009 at 6:41 PM, nervo <nervo....@gmail.com> wrote:
> @Thomas Rabais :
> Well, today, this way give little problem, as if a translation is
> asked in a culture which does'nt exists, the source is returned,.
> You may guessed to be returned the target in the default culture as a
> fallback, instead of the source.
> Of course, the same thing happend if the culture exists, but not the
> target.
> But maybe i missed something.
> About that, something confuse me : you are said to give a "source-
> language" in the i18n file.
> Apparently, the source culture is the default culture (defined in
> settings.yml), and the target culture the current culture (set in
> session).
> But things works even if no "source-language" is defined...
> The doc is not very clear on that point.
> Maybe i missed everything :)
> @david :
> just be careful, as the term "territory", stricto senso, also includes
> wide things like "Africa" (code 002) or "North America" (code 003).
> Also, things like currencies and cities must be based on what you
> called "territory", and not "lang_territory"
> On Oct 28, 4:28 pm, david <da...@inspiredthinking.co.uk> wrote:
> > I think the most widely understood coding is the "en_US" varient -
> > LANG_TERRITORY where LANG & TERRITORY are 2 chars.
> > I think it's possible to derive anything else from it (currency, cities,
Hi David,
if en_US is enough for you then it is ok.
But we were talking about enhancing the current implementation to
provide more details
Countries with the languages, currencies, timezones, calendars,
scripts, rounding modes etc.
each of these information then additionally translated into every
possible language.
This is how the current implementation is set up. You find most of the
stuff already in root.
Then you find for almost everything the same in en.
if there are local differences then these are in en_US en_UK....
and as pointed out by nervo there might be differences for scripts.
This is a really big amount of data. and we just need to make it
available in a better way.
The term culture was discussed and I think it is ok. because it
describes the local language specifics.
I wouldn't debate around this too much.
I really spent some time with the stuff and I actually started to like
the way Prado dealt with the challenge to make the data available.
There are a few defects (like the root culture being available) but
those should be addressed, rather than trying to rewrite everything
and claiming simplifying will help.
the locale data topic is very complicated by nature and we can try for
a simple and good solution, but overly simple ones will not help
anybody.
>> just be careful, as the term "territory", stricto senso, also
>> includes
>> wide things like "Africa" (code 002) or "North America" (code 003).
>> Also, things like currencies and cities must be based on what you
>> called "territory", and not "lang_territory"
> :) It's just semantics - it just needs to be defined somewhere for
> everybody to have the same meaning.
> The complete code <lang>_<lang territory> is what will be enough to
> provide details for things like currencies.
> The lang element is only good enough for presentation related tasks.
|
