I understand the reason but I think create a "fork" of ocsreports is a bad idea.
I prefer have persons working on libserver php and inventory plugin in GLPI than loose time on this. I think it coul be ready for october, so if we haven't any peopple working on this it will be released in january or more later. I repeat, I understand your reasons but not very enjoy on our project. David Le Fri, 20 Aug 2010 17:38:55 +0200 Gonéri Le Bouder <[email protected]> a écrit: >2010/8/3 Gonéri Le Bouder <[email protected]>: >> 2010/8/1 Denis Linvinus <[email protected]>: >>> 2010/8/1 Gonéri Le Bouder <[email protected]> >> Ok, so I fixed most of the UTF-8 issues thanks to the RDP access to >> your Russian Windows (thank you!). >> It remains a strange problem with the software list: >> http://nana.rulezlan.org/~goneri/ocsreport-utf8.png >> >> What I do (and Why I don't understand): >> I get the standard code page from the registry from >> HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\Nls\Codepage\ACP. >> I use it to do ACP → UTF8 conversion on every string I grab from the >> registry. The XML file looks OK! I wonder if OCS suppose I use latin1 >> and try to do some latin1 → UTF8 conversion in my back ? >> >> Any opinion? The XML file is avalaible there: >> http://nana.rulezlan.org/~goneri/russian-linvinus.xml >I understood the issue finally. ocsreports is broken and assume the >content from the DB is Latin1. It sent ISO-8859-1 charset in the HTTP >header. I suppose the sole option is to use your ocsreport patches. > >I wonder if we should maintain a fork of ocsreports with your patches >because of that. Any opinion? > >Cheers _______________________________________________ Fusioninventory-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/fusioninventory-devel
