In many files there are about 80-100 references to $GLOBALS['charset'] (or just $charset) variable, which is always set to 'utf-8'. It is not a change that should go now, but after 3.4 is released I propose to: - remove all references where it is used to generate HTTP headers and HTML (we already have it hardcoded in many places) - remove this variable and introduce it as a constant or, if only a few references remain, just use string literals
A quick glance at code also revealed some a possible bug in comparison with $charset_of_file - this var stores one of MySQL compatible charset names, while our variable stores "utf-8", not "utf8".
I can prepare an appropriate patch and commit it after 3.4 is released.
Piotr Przybylski a écrit :
In many files there are about 80-100 references to $GLOBALS['charset'] (or just $charset) variable, which is always set to 'utf-8'. It is not a change that should go now, but after 3.4 is released I propose to:
- remove all references where it is used to generate HTTP headers and
HTML (we already have it hardcoded in many places)
- remove this variable and introduce it as a constant or, if only a
few references remain, just use string literals
Looks like a good cleanup for 3.5.
A quick glance at code also revealed some a possible bug in comparison with $charset_of_file - this var stores one of MySQL compatible charset names, while our variable stores "utf-8", not "utf8".
Better fix this one for 3.4, can you work on this?
I can prepare an appropriate patch and commit it after 3.4 is released.
2011/3/10 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
In many files there are about 80-100 references to $GLOBALS['charset'] (or just $charset) variable, which is always set to 'utf-8'. It is not a change that should go now, but after 3.4 is released I propose to:
- remove all references where it is used to generate HTTP headers and
HTML (we already have it hardcoded in many places)
- remove this variable and introduce it as a constant or, if only a
few references remain, just use string literals
Looks like a good cleanup for 3.5.
Yes - too risky for 3.4, unless somebody finds enough time to test all cases in which it is used.
A quick glance at code also revealed some a possible bug in comparison with $charset_of_file - this var stores one of MySQL compatible charset names, while our variable stores "utf-8", not "utf8".
Better fix this one for 3.4, can you work on this?
Not during this week, but I will be able to look into this on Monday.
2011/3/10 Piotr Przybylski piotr.prz@gmail.com:
2011/3/10 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
In many files there are about 80-100 references to $GLOBALS['charset'] (or just $charset) variable, which is always set to 'utf-8'. It is not a change that should go now, but after 3.4 is released I propose to:
- remove all references where it is used to generate HTTP headers and
HTML (we already have it hardcoded in many places)
- remove this variable and introduce it as a constant or, if only a
few references remain, just use string literals
Looks like a good cleanup for 3.5.
Yes - too risky for 3.4, unless somebody finds enough time to test all cases in which it is used.
A quick glance at code also revealed some a possible bug in comparison with $charset_of_file - this var stores one of MySQL compatible charset names, while our variable stores "utf-8", not "utf8".
Better fix this one for 3.4, can you work on this?
Not during this week, but I will be able to look into this on Monday.
My mistake, it works ok :)
-
Marc Delisle -
Piotr Przybylski