On Wed, May 25, 2005 at 02:22:32PM +0200, Piotr Szotkowski wrote:
Gabor Hojtsy:
Piotr Szotkowski:
What do you think about the whole idea of forcing this overload on Drupal? Is it feasible and I should pursuit the warning (and any other that follow), or should I simply drop this idea, as it will break Drupal and/or any popular modules anyway?
IMHO one should hunt down and fix the empty haystack errors.
I agree that these warning should be fixed anyway. I'd give them a go without any hesitation, but I'd like to know whether Drupal is fully UTF-8-aware and whether UTF-8 support is a requirement for the modules - i.e., whether my work would be useful in the end.
Drupal works with UTF-8 only. It is a requirement for contributed modules as well; but, like other contributed module requirements, it is a loose reequirement as there isn't a formal review process.
Adding
php_value mbstring.func_overload 7 php_value mbstring.internal_encoding UTF-8
affects everything just for CiviCRM's use, and if it's known that Drupal would break (in some non-obvious way, perhaps), or there's a popular module that could stop working when we're overloading all of the string manipulating functions under its feet then I'd rather concentrate on other solutions to my problem...
Since Drupal is meant to run on many platforms we can't depend on the libraries we want being present. So Drupal has implemented specific UTF-8 functionality as needed. For example, truncate_utf8() is implemented using pure PHP and drupal_convert_to_utf8() is implemented by attempting to use any of the potentially availiable libraries. -Neil