Some fix to merge

[François]

Hello archetype ;)

I fixed one bug in Archetype.i18n with Internet Explorer in
db86b28142fb

And I added a parameter for define default charset for load javascript
files in 555e71039266

If your are interest about that, you can merge from http://hg.2metz.fr/archetypejs/

Regards,
François

[Florian Traverse]

HI françois :)

I've looked at the i18n compatibility patch (http://hg.2metz.fr/archetypejs/rev/db86b28142fb , for others than Francois, just have a look at the last line).
It's great to fix this, this isn't a very used feature right now, but I think we should move to an "Archetype.i18n.getLanguage" method in order to return the language : in fact in JS we do not have the whole language support datas (which is delivered through Accept-Language header in any server request).

I do not even know a browser that gives the full information through a proprietary API. We just have the browser language, which may not be accurate.

I saw one time some people that has made agoogle appengine API that just mirrors those header in a json server reponse, but I don't find it anymore :( . It may be a good idea to rely (if available on the network) on such an API in order to get the user language (list !).

It would be a good idea to vote for or make some new report on the major browsers bugtrackers about this issue. Anyone has those url (bugzilla is easy to find, but others ?)

Moreover, our API should able to force the current language (for example using small flags links in the page), and the language should remain next time. That means probably cookie, or browser storing (through embedded database if available ?)

Any idea is welcome about i18n and l10n because there is almost nothing in js currently. The simplest way to deal with it in js is just using apache multiview by default on the js translation files: in my browser, toto.fr_fr.js would be read before toto.fr.js, toto.en.js and toto.js if I request toto.js. Using this we can get also directly toto.en-US.js if we want.

This is not a bad solution, however this will lead to problems when not using apache httpd server :(

So I'll merge your patch but we have to do it go further !!! :)
 

For the second patch, we have to deal with a very annoying bug in IE : defining a script charset different from the page one is just ignored by IE, and this can even lead to a browser crash ! We have seen it several time when making UTF-8 pages and using the default iso8859-1 on js scripts :-/

I've seen you've just added a configuration in order to define it in the conf whether hardcoded. I think we should just remove this parameter and explain why in the documentation or FAQ.

What do you think of that ? giving the ability to configure something that is unusable if plan to support IE in the webapp, or not ?

I don't remember if this bug affects IE7 (or above), anyone knows ?

Cheers,
Florian

2009/1/26 François <fran...@2metz.fr>

[Florian Traverse]

As those patch are at least better than actual code, even if they aren't the perfect solution I merge them for a soon 0.9.2 release :)

2009/1/26 Florian Traverse <florian....@gmail.com>

[Francois]

Le 26.01.2009 17:12, Florian Traverse a écrit :
> HI françois :)
>
> I've looked at the i18n compatibility patch
> (http://hg.2metz.fr/archetypejs/rev/db86b28142fb , for others than
> Francois, just have a look at the last line).
> It's great to fix this, this isn't a very used feature right now, but I
> think we should move to an "Archetype.i18n.getLanguage" method in order
> to return the language : in fact in JS we do not have the whole language
> support datas (which is delivered through Accept-Language header in any
> server request).
>
> I do not even know a browser that gives the full information through a
> proprietary API. We just have the browser language, which may not be
> accurate.
>
> I saw one time some people that has made agoogle appengine API that just
> mirrors those header in a json server reponse, but I don't find it
> anymore :( . It may be a good idea to rely (if available on the network)
> on such an API in order to get the user language (list !).

Like you, my plan is to use an server side script and mimeparse
(http://code.google.com/p/mimeparse/) for choose the best language.

>
> It would be a good idea to vote for or make some new report on the major
> browsers bugtrackers about this issue. Anyone has those url (bugzilla is
> easy to find, but others ?)

See http://ejohn.org/blog/a-web-developers-responsibility/

I will take a look this evening.

>
> Moreover, our API should able to force the current language (for example
> using small flags links in the page), and the language should remain
> next time. That means probably cookie, or browser storing (through
> embedded database if available ?)
>
> Any idea is welcome about i18n and l10n because there is almost nothing
> in js currently. The simplest way to deal with it in js is just using
> apache multiview by default on the js translation files: in my browser,
> toto.fr_fr.js would be read before toto.fr.js, toto.en.js and toto.js if
> I request toto.js. Using this we can get also directly toto.en-US.js if
> we want.
>
> This is not a bad solution, however this will lead to problems when not
> using apache httpd server :(
>

I prepare an i18n enhancement. I will push when it's almost done.

> So I'll merge your patch but we have to do it go further !!! :)
>
>
> For the second patch, we have to deal with a very annoying bug in IE :
> defining a script charset different from the page one is just ignored by
> IE, and this can even lead to a browser crash ! We have seen it several
> time when making UTF-8 pages and using the default iso8859-1 on js
> scripts :-/
>
> I've seen you've just added a configuration in order to define it in the
> conf whether hardcoded. I think we should just remove this parameter and
> explain why in the documentation or FAQ.
>
> What do you think of that ? giving the ability to configure something
> that is unusable if plan to support IE in the webapp, or not ?
>
> I don't remember if this bug affects IE7 (or above), anyone knows ?

Ok, my bad. I reproduce this bug with IE6.

>
> Cheers,
> Florian

[Florian Traverse]

Hi François,

I've done some little fix/enhancements in 0.9.2 and we'll can release a 0.9.3 soon. Do you need any help for you i18n fixes and improvements ?

0.10.0 is almost ready now, there are only 2 fixes + user documentation to go :
Slidy is now working on the "jquery branch", at the cost of scriptaculous effects (but I hope to replace them with some css-transition later, using binding language to map firefox & ie, other will support them).

As unit tests do depends on scriptaculous, running on jquery just make them crash :(

So after a "market study" we're planning to move on DOH from the dojo framework (but not linked to dojo itself) as it's better than what we have now in multiple ways : test can be run & checked from a script, and asynchronous method can now be tested in a far better way (if I well understood how it works).

Another small fix is not to rely on an insertion object from prototype in components : they are deprecated and we have to offer a common interface between jQuery and Prototype.

Regards,
Florian

2009/1/27 Francois <fran...@2metz.fr>