Damon Butler wrote:
On Tue, 2003-01-28 at 12:45, Florent Guillaume wrote:
Thanks for the debugging.
It's what I thought: the .po file you're using (created as a .pot by zgettext) has an incorrect line like: Content-Type: text/plain; charset=CHARSET but CHARSET here should be the charset of the file, for instance iso-8859-1, or maybe utf-8 or any other valid charset. The .pot was a template, that must be edited to fill-in this kind of info that it can't guess, to give a .po file.
I tried editing Products/NuxDocument/locale/en.po to reasonable values (charset=UTF-8; Content-Transfer-Encoding: 8-bit) which I took from the file Products/Localizer/locale/en.po. Nothing changed ... Localizer still complains that 'CHARSET' is an unrecognized encoding.
I noticed that there is an en.mo file that strongly resembles en.po, but it was uneditable. (Well, actually, when I edited the 'charset' and 'Content-Transfer-Encoding' bits as above the program complained that en.mo had been "corrupted".)
I even uninstalled the NuxDocument product, packed the Zope database, deleted the original install from the filesystem, created a fresh install of it, edited en.po again, and then restarted Zope, and still the error returns. What's a fellow to do? How can this be fixed?
--Damon
The MO file is used at run time, you have to: 1. fix the charset in the PO file as you already did; 2. re-generate the MO file from the PO file (from the NuxDocument product directory run zgettext: "../Localizer/zgettext -m"); 3. re-start Zope Note that if the "locale/en.po" file of the NuxDocument product does not have the right charset, then it is a bug. Regards, -- J. David Ibáñez, http://www.j-david.net Software Engineer / Ingénieur Logiciel / Ingeniero de Software