UTF-8 and i18n

thread: 2 messages  |  last: about 7 years ago  |  started: wednesday, june 6, 2007, 12:01 pm pdt

#1  |  VexedPanda (Calgary, AB) Canada
Wednesday, June 6, 2007, 12:01 PM PDT

It appears that QCodo's  po parser fails when provided with a utf-8 encoded .po file.

This is an issue since if the file is encoded in say, the standard Western encoding, then the translation provided by QApplication::Translate is also provided in Western, meaning that the entire text of the page no longer matches the EncodingType specified, and you get odd symbols instead of the characters in the .po file.

You appear to have gotten around this by escaping all the text in the .po file, but that doesn't work in some situations (Such as using that translation in an external app, or in areas of the application doing their own escaping.)

The limitation seems to be simply one in the validation check for the po file format. Once I comment out those checks (the regex line compares), the translation works beautifully with UTF-8 encoded .po files, and the browser displays everything correctly with an automatically chosen UTF-8 encoding type.

I'm quite surprised I can't find other cases of this in the forums, since I would have thought this would be quite common.

#2  |  Igor Butuc (Bucharest) Romania
Wednesday, December 21, 2011, 9:31 PM PST

Your workaround didn't work for me (or I didn't understand it well). But what worked was to add on every preg_match_all /u flag (in QI18n::ParsePoData() function). For example:
// before
$intCount = preg_match_all('/msgid(_[a-z0-9]+)?[\s]+”([\S     ]*)”/i', $strPoLine, $strMatches);
// after
$intCount = preg_match_all('/msgid(_[a-z0-9]+)?[\s]+”([\S     ]*)”/iu', $strPoLine, $strMatches);

Copyright © 2005 - 2019, Quasidea Development, LLC
This open-source framework for PHP is released under the terms of The MIT License.