Florent Guillaume wrote:

Apparently Localizer (in fact, python gettext module) didn't correctly parse the charset of the .po files... Are they standard .po files? There should be a Content-Type: xxx; charset=foo header in them.

If you could add debug statements to /local/lib/python2.1/gettext.py to track this down it would be helpful.

Florent, why Zope Product would require Localizer to be installed to function correctly? We've just removed all gettext form .dtml files to make it work. ZMI is mainly in English and that is pretty good solution until Zope provide Basement for Product l10n. Until that time I see no reason to force users to install Localizer just to see ZMI of that one product (NuxDocument in our case) in other language. Note, there is no fallback mechanism to make it work without Localizer installed. And here is the case to mention our NuxDocument patch. We had to remocve all convesions because NuxDocument just corrupted generated HTML from wvWare which was perfect for use in our case (UTF-8 encoding). What maillist is correct place for discussion of NuxDocument? m.

In article <1043428979.268.35.camel@kermit> you write:

...

On FreeBSD 4.7 I'm running Zope 2.5.1 that I've patched with all the Unicode diffs from http://www.zope.org/Members/efge/i18n/Unicode-2.5.1. I've also installed Localizer 1.0.0. All in an attempt to get NuxDocument 1.1alpha functional. (I've installed all the necessary converter apps as well: wvWare, etc.) I *think* I've installed NuxDocument correctly, but the very first instruction is confusing:

"Install the product in Products (NOT lib/python/Products!). The ZNuxDocument product should appear in the ZMI."

Well, the *only* "Products" directory in existence on my system is lib/python/Products. So that's where I stuck it. Now I see a "NuxDocument" available as something I can Add in the ZMI (not "ZNuxDocument").

Problem is, whenever I try to Add a NuxDocument, I get the following Traceback from Localizer:

=-=-=-=-=-=-=-=-=-=

Error Type: LookupError Error Value: unknown encoding Traceback (innermost last): File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /usr/local/www/Zope/lib/python/Products/Localizer/__init__.py, line 58, in new_publish File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 114, in publish File /usr/local/www/Zope/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 98, in publish File /usr/local/www/Zope/lib/python/ZPublisher/mapply.py, line 88, in mapply (Object: addForm) File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: addForm) File /usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__ (Object: addForm) File /usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec (Object: addForm) File /usr/local/www/Zope/lib/python/Products/Localizer/LocalFiles.py, line 100, in _exec (Object: addForm) File /usr/local/www/Zope/lib/python/App/special_dtml.py, line 172, in _exec (Object: addForm) File /usr/local/www/Zope/lib/python/DocumentTemplate/DT_Util.py, line 179, in eval (Object: manage_form_title(this(), _, form_title=gettext('Add ZNuxDocument'))) (Info: this) File <string>, line 0, in ? File /usr/local/www/Zope/lib/python/Products/Localizer/LocalFiles.py, line 82, in gettext (Object: addForm) File /usr/local/lib/python2.1/gettext.py, line 195, in ugettext LookupError: (see above)

-- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua>

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. Florent On Tue, 2003-01-28 at 19:13, Damon Butler wrote:

On Tue, 2003-01-28 at 07:58, Florent Guillaume wrote:

...

Apparently Localizer (in fact, python gettext module) didn't correctly parse the charset of the .po files... Are they standard .po files? There should be a Content-Type: xxx; charset=foo header in them.

If you could add debug statements to /local/lib/python2.1/gettext.py to track this down it would be helpful.

The method in question is barebones:

----- def ugettext(self, message): tmsg = self._catalog.get(message, message) return unicode(tmsg, self._charset) -----

The line raising the error I noted is the 'return' statement.

With only two variables in question, I inserted a 'raise Exception' statement just prior to the problematic one containing the 'unicode' function to smoke out what their values were:

----- raise Exception, "tmsg: %s, self._charset: %s" % (tmsg, self._charset) -----

Here's what I got:

----- Error Value: tmsg: Add ZNuxDocument, self._charset: CHARSET -----

The problem appears to be with 'CHARSET' as a value. Looks like it ought to be the result of an environmental variable to me, but I don't see where in the code it gets set, except via the '_parse' method of the GNUTranslations class defined directly above this spot in the gettext.py code. The relevant section of that method:

----- [...] # See if we're looking at GNU .mo conventions for metadata if mlen == 0 and tmsg.lower().startswith('project-id-version:'): # Catalog description for item in tmsg.split('\n'): item = item.strip() if not item: continue k, v = item.split(':', 1) k = k.strip().lower() v = v.strip() self._info[k] = v if k == 'content-type': self._charset = v.split('charset=')[1] [...] -----

Any idea what's going on? I don't really know where to look next.

--Damon

========================

...

Florent

In article <1043428979.268.35.camel@kermit> you write:

...

On FreeBSD 4.7 I'm running Zope 2.5.1 that I've patched with all the Unicode diffs from http://www.zope.org/Members/efge/i18n/Unicode-2.5.1. I've also installed Localizer 1.0.0. All in an attempt to get NuxDocument 1.1alpha functional. (I've installed all the necessary converter apps as well: wvWare, etc.) I *think* I've installed NuxDocument correctly, but the very first instruction is confusing:

"Install the product in Products (NOT lib/python/Products!). The ZNuxDocument product should appear in the ZMI."

Well, the *only* "Products" directory in existence on my system is lib/python/Products. So that's where I stuck it. Now I see a "NuxDocument" available as something I can Add in the ZMI (not "ZNuxDocument").

Problem is, whenever I try to Add a NuxDocument, I get the following Traceback from Localizer:

=-=-=-=-=-=-=-=-=-=

Error Type: LookupError Error Value: unknown encoding Traceback (innermost last): File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /usr/local/www/Zope/lib/python/Products/Localizer/__init__.py, line 58, in new_publish File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 114, in publish File /usr/local/www/Zope/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 98, in publish File /usr/local/www/Zope/lib/python/ZPublisher/mapply.py, line 88, in mapply (Object: addForm) File /usr/local/www/Zope/lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: addForm) File /usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__ (Object: addForm) File /usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec (Object: addForm) File /usr/local/www/Zope/lib/python/Products/Localizer/LocalFiles.py, line 100, in _exec (Object: addForm) File /usr/local/www/Zope/lib/python/App/special_dtml.py, line 172, in _exec (Object: addForm) File /usr/local/www/Zope/lib/python/DocumentTemplate/DT_Util.py, line 179, in eval (Object: manage_form_title(this(), _, form_title=gettext('Add ZNuxDocument'))) (Info: this) File <string>, line 0, in ? File /usr/local/www/Zope/lib/python/Products/Localizer/LocalFiles.py, line 82, in gettext (Object: addForm) File /usr/local/lib/python2.1/gettext.py, line 195, in ugettext LookupError: (see above)

-- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

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

Damon Butler escribió::

It is definitely a bug, then. A rather serious one. Furthermore, there are a LARGE number of other problems, including not a few biggies:

* The ONLY way to change a NuxDocument's id, Title, or Description properties is via the ZMI. I have so far been unable to hack in a Python fix such that I can do this from within Plone. (I changed the ZPT such that it should be easily possible.) Major inconvenience: Help!

I sent to sf@nuxeo.com a patch to edit title and description in CMFNuxDocument (and also to preserve the original filename in case of modifications, since my users want that functionality). I'm using it with plone with no problems. In the same patch there's also something to make nuxdocument behave with ExternalEditor. I can send it to you if you're interested (but keep in mind that my coding skills with python/zope are not up to the level of the fine folks at nuxeo).

* CMF does not permit the uploading of NuxDocuments (i.e., actual Word, Excel, PPT, and PDF files). Similarly, one cannot upload a CMF

I don't have this problem, I can upload files ok. wvware rendering is not perfect but it's ok to have a quick preview.

NuxDocument from within the ZMI. This can be a show-stopper.

You shouldn't add *any* cmf object from the zmi.

* Zope, CMF, and Plone cannot find the various document icon graphics (icon_doc.gif, icon_pdf.gif, icon_ppt.gif, icon_xls.gif). This can cause Tracebacks when performing Finds or Searches (depending on which interface you are using). I was only able to solve this problem in CMF/Plone by manually Adding the four icons as Images to the custom folder in the various skins search paths; no fix for Zope yet. Most unstatisfactory.

The icons are not in the skin directory (zpt_NuxDocument). I just copied them over. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007