Michael Bell wrote:
Future ------
The optimal solution would be if we have only to deal with UTF-8. This means the user would only receive HTML data which is UTF-8 encoded. The databases would be happy. Perl is already aware of UTF-8.
The language databases are the biggest problem. There are several open issues because I'm a beginner on this stuff:
1. How can we migrate the existing translations to UTF-8?
iconv
2. We need a howto about the editing of the translations. Can somebody describe a working UTF-8 environment for translating?
This is not needed because we can convert translation dynamically via iconv.
3. Does it be possible to convert between the encodings automatically?
Yes, iconv.
Does this solve perhaps all known issues? We simply switch to UTF-8. If we make OpenCA an UTF-8 only application then there should be no longer any open issues with i18n, SQL databases and HTML representation.
Comments about this? Martin, Janez?
Michael
P.S. I see this solution during compiling dia. A diagram editor which supports ER schemas.
--
_______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
