Compatibility issue

Maybe I should post this in Internationalization section, but think this might be a good place since this is a generic one for languages with a mutli byte scheme.

I just posted a question regading Ajaxseach not working with Chinese. I am a little bit worried with move delve into the system I might encount more such situations so here is my question:

In general how hard to adapt Modx modules/snippets for them to work with above-mentioned languages? for example Chinese in my case.

Which version are you referring to? There’s been a ton of work on Ajaxsearch lately and I think that’s a non-issue now. Review the last few pages of the Ajaxsearch thread.

Thanks for the info you might be right on the Ajaxsearch part. My initial motivation to start the thread is to raise the concern  on how Modx could be truely ready as an universal platform in terms of it’s architecuture design. I have another example here, the other day I downloaded the TvTagCloud snippet and found some Chinese has been incorrectly changed in the tag cloud. A quick debug showed  the source is from a strtolower($tag) which can incorrectly handle utf8 encoding without the right locale setting. One can argue here this is a snipplet thing, yes it is but it can also be said as an architecuture thing, there could possibly be a module that dose all the dirty thing with compatibility support and then could be clearly written in the sinppet developement guidline as how and when to use such a library. This is only a case study and I am sure with lots of smart people in this community there could be a better solution on this one.

Quote from: jimpsr at Mar 30, 2008, 08:44 AM

Thanks for the info you might be right on the Ajaxsearch part. My initial motivation to start the thread is to raise the concern on how Modx could be truely ready as an universal platform in terms of it’s architecuture design. I have another example here, the other day I downloaded the TvTagCloud snippet and found some Chinese has been incorrectly changed in the tag cloud. A quick debug showed the source is from a strtolower($tag) which can incorrectly handle utf8 encoding without the right locale setting. One can argue here this is a snipplet thing, yes it is but it can also be said as an architecuture thing, there could possibly be a module that dose all the dirty thing with compatibility support and then could be clearly written in the sinppet developement guidline as how and when to use such a library. This is only a case study and I am sure with lots of smart people in this community there could be a better solution on this one.

Teaching folks how to develop their add-ons in PHP to international standards is not really our core competency, but we’re learning. It’s a difficult situation at best, and currently (and until PHP 6 is out and people stop using PHP 5, lol), lowest common denominator dictates that not everyone is going to be able to use Unicode-safe functions (i.e. having mb_string extension properly configured) in their MODx add-ons. We are certainly trying to work around the unsafe functions in the core code for lowest common denominator usage, and you getting involved and posting more details about things like this (perhaps in the Wiki?) would be a start on defining those add-on development guidelines with a focus on i18n.