martin.kutschker-n0spam at no5pam-blackbox.net
Sun May 13 18:36:04 CEST 2007
Elmar Hinz schrieb:
> Am Sun, 13 May 2007 10:37:01 +0200 schrieb Martin Kutschker:
>> I don't get you point. The external XML strings in UTF8 are cached in
>> serialzed arrays for retrieval. Using XML makes it easy to handle the
>> actual trnalsatoin process (= creating and maintanin the text).
> The point: If you want to provide translations for your extension you
> either have to write PHP array and transform to XML to match the
> standards or you have to write XML by hand. If you once have transformed
> to XML you are forced to write XML for alterations and extendings.
Huh? YOu can use either locallang.php or locallang.xml for your
extensoins. The TYPO3 API supports both formats and you don't have to
worry about anything, let alone write transformation code.
> A don't follow you why XML should improve creation and maintainance of the
> translation process.
XML as external format is useful because it can be edited manually and
automatically quite easily.
>> What went wrong was that TYPO3 does now a double encoding thing. That's
>> just an implementation problem which can be solved (did that already for
>> the BE), this has nothing to do with XML or UTF-8 per se.
> If translations would be kept in UTF-8, there would only be one
> transformation UTF-8 > ISO or none at all. Guess that would have matched
> with the original one translation process without big alterations.
Currently the cache is in the "native" charset of the BE language (eg
latin1 for German) regardless of the BE charset (eg utf8) or the source
of the data (locallang.php or locallang.xml). This means if the "native"
charset differs from the BE charset (eg when you use UTF8 on a German
site) then TYPO3 will recode the strings every time.
The improved cache will store the data in the charset of the BE. So
there will a maximum of one recoding at cache time.
More information about the TYPO3-project-5_0-general