[Zope3-dev] Re: RFC: zopeproject
Hi again. Hanno Schlichting wrote: > Philipp von Weitershausen wrote: >> I wonder, if done correctly (and I believe some people, e.g. Andreas >> Jung, have managed to get mingw to build binary eggs for them), are >> mingw-based eggs any worse than Visual C ones? > > A few years ago, MinGW (the native port is still based on GCC 3.4) > compiled C extensions were a bit slower than those compiled with Visual > C. But I haven't tried this in recent years. > > My knowledge of C compilation is too limited to judge if there are some > hidden pitfalls here, though. In order to let some people judge the result of eggs built based on my howto I made one example egg for zope.interface 3.4.0. The egg is available from http://www.hannosch.de/zope.interface-3.4.0-py2.4-win32.egg The relevant log from the bdist_egg looks like this: running build_ext building '_zope_interface_coptimizations' extension creating build\temp.win32-2.4 creating build\temp.win32-2.4\Release creating build\temp.win32-2.4\Release\src creating build\temp.win32-2.4\Release\src\zope creating build\temp.win32-2.4\Release\src\zope\interface C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python24\include -IC:\Python24\PC -c src\zope\interface\_zope_interface_coptimizations.c -o build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.o writing build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.def C:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.o build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.def -LC:\Python24\libs -LC:\Python24\PCBuild -lpython24 -lmsvcr71 -o build\lib.win32-2.4\zope\interface\_zope_interface_coptimizations.pyd Python is version 2.4.4, GCC is 3.4.2 (mingw-special). If someone tells me, that the eggs I generate this way are valid and of some use, I'm happy to help to build some more ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
Hi,
Philipp von Weitershausen wrote:
> On 18 Jul 2007, at 19:25 , Kent Tenney wrote:
>> on my W2K machine
>>> zopeproject MyZopeProject
>>
>> fails because I don't have Visual Studio installed and it wants
>> to compile extensions for ZODB
>
> Right. Something seems to depend on ZODB 3.9.0-xyz now and we have no
> binary for that (yet). Sadly enough, I recently asked Jim to make
> Windows eggs and they've all become useless because at least half of the
> packages now have newer releases (which buildout insists on using).
>
>> I've heard that mingw can substitute, but I've never succeeded in
>> configuring it.
Have you seen my instructions for a Plone 3.0 buildout at
http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt ? This is the
most reliable and easiest way I could find to compile C extensions on
Windows without having to have any special M$ compiler.
> Well, I managed to install it (you need cygwin, then install the
> gcc-mingw-core package from the 'devel' section). And with 'python
> setup.py build -c mingw32', it seems I can even build Windows eggs,
> though I can't get them to work. I get some a DLL error ("Access denied.")
>
> What's more, there seems to be now way to tell zc.buildout to pass the
> '-c mingw32' option to setup.py when building eggs.
My instructions tell you to use MinGW directly without all that Cygwin
junk which only tends to make things more complicated and often
introduces an undesired runtime dependency on Cygwin. The nice thing as
noted in my howto is that you can change a distutils option to say all
build commands should use mingw32 and so all buildout recipes will pick
this up.
> I wonder, if done correctly (and I believe some people, e.g. Andreas
> Jung, have managed to get mingw to build binary eggs for them), are
> mingw-based eggs any worse than Visual C ones?
A few years ago, MinGW (the native port is still based on GCC 3.4)
compiled C extensions were a bit slower than those compiled with Visual
C. But I haven't tried this in recent years.
My knowledge of C compilation is too limited to judge if there are some
hidden pitfalls here, though.
Hanno
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Problems with zope3 on windows
Benji York wrote: > João Paulo Fernandes Farias wrote: >> I'm not sure if this is enough info to get stuff fixed, just wanted to >> tell about my experiences so far. > > Reproduction steps would be helpful, as well as full tracebacks of the > various exceptions. Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Hi, Philipp von Weitershausen wrote: > > I tried to follow instructions from the web on how to get such a > toolchain running on my Windows machine (see post scriptum to my very > first email). It failed with an obscure error when compiling the > extension. So, it seems at the moment there's no easily deployable > toolchain. Having Windows test alphas and betas that they compile > themselves is all fine and dandy, but unless we have a way for them to > do that, this remains all but a pious wish. Have you seen my instructions for a Plone 3.0 buildout at http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt ? They are based on the MinGW C compiler and I and quite a lot other people have successfully built all of Zope's C extensions this way. The important parts are the 'MinGW' and 'Configure Distutils to use MinGW' sections. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: translation of zope3
Hi. Dmitry Vasiliev wrote: > Philipp von Weitershausen wrote: > >> You bring a good point to my attention. Now that each package is its >> own project with a separate release cycle, we should split up the >> translations and maintain them for each package. Mostly 'zope.app.*' >> packages (with a few exceptions such as zope.formlib) will have >> translations. >> >> Given that the extraction tool left source markers in the translation >> files, I think this task could be automated. Would be a fun project >> for somebody :) > > I've already thought about it and I think the following steps should be > performed: > > 1. Move all Python modules from zope.app.locales to zope.i18nmessageid > (or maybe to zope.i18n?). I'd prefer zope.i18n as these scripts are more general. The zope.i18nmessageid package is really just about messageid's and useful without zope.i18n. > 2. Write a tool for splitting up translations. I think the tool will be > useful not only for the case and it would be cool if the tool could > extract, split and merge translations. You should also be able to run the extract tool on each individual package (probably you would want to script that considering the number of packages). For extra functionality make sure you look at the various msg* tools available in the gettext package first. msgmerge and msggrep probably do quite a lot of what you are looking for. My i18ndude package also has some of these options and is meanwhile based on the same extraction logic as the scripts in zope.app.locales. > 3. Split up the existing translations. > 4. Remove zope.app.locales altogether. > > If nobody objects I can perform the steps above. > > Open questions: > > - What about translations.launchpad.net? Is there are way to create > templates for all translated packages in the zope3 project? AFAIK you need to upload each individual pot file yourself or a zip file containing both the template and the po files. If the security settings haven't changed yet, each new template needs to be reviewed by some person from launchpad, which could take some time. In my experience there aren't that good at supporting non-ubuntu-included projects. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zc.zope3recipes not working on Windows
Tres Seaver wrote: > Jim Fulton wrote: >> On May 31, 2007, at 1:59 AM, Stephan Richter wrote: > >>> Hi Jim and other zc.zope3recipes experts, >>> >>> I have had some reports from Windows users that the z3c.formdemo -- >>> which is >>> built with zc.zope3recipes -- is not working on Windows. The >>> reported error >>> was as follows: >> The instance recipe should advertise that it only works on Windows, >> because it is based on zdaemon. I tend to forget that zdaemon >> doesn't work on Windows. :/ > >> This isn't easy for *me* to fix because I don't have enough Windows >> foo. I'd be happy to work with someone who knew Windows well, >> especially services (or other long-running process options, if >> any). If anyone like that is going to be at the sprint at the >> upcoming DZUG meeting, I'd be very happy to work with them there. > >> A partial fix that only supports the ctl 'fg', 'run', and 'debug', >> commands should be fairly easy, although I'm a bit hesitant without >> understanding how we might want this to work in the long run. > > Hanno has checked in a Zope2 patch which makes 'zopectl' work on > Windows, and adds two new Windows-specific commands to install and > remove the Zope servvice: > > http://svn.zope.org/Zope/trunk/lib/python/Zope2/Startup/zopectl.py?rev=75066&view=rev The Zope Windows service installation and all the start/stop/restart commands are just calling the already existing zopeservice.py (mentioned by Adam Groszer). I'm already at the DZUG sprint location (we just got the wireless working) and I'm happy to explain the changes I did or help in applying them to any other script / recipe or whatever :) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zc.zope3recipes not working on Windows
Hi. Stephan Richter wrote: > Hi Jim and other zc.zope3recipes experts, > > I have had some reports from Windows users that the z3c.formdemo -- which is > built with zc.zope3recipes -- is not working on Windows. The reported error > was as follows: > > E:\formdemo>.\bin\demo fg > Traceback (most recent call last): > File "E:\formdemo\bin\demo-script.py", line 14, in ? > zc.zope3recipes.ctl.main([ > File > "e:\formdemo\eggs\zc.zope3recipes-0.5.1-py2.4.egg\zc\zope3recipes\ctl.py", > line 47, in main > zdaemon.zdctl.main(args, None, Cmd) > File > "e:\formdemo\eggs\tmp9ghl8n\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", > line 626, in main > File > "e:\formdemo\eggs\tmp9ghl8n\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", > line 125, in __init__ > File > "e:\formdemo\eggs\tmp9ghl8n\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", > line 185, in get_status > File > "e:\formdemo\eggs\tmp9ghl8n\zdaemon-2.0a6-py2.4.egg\zdaemon\zdctl.py", > line 165, in send_action > AttributeError: 'module' object has no attribute 'AF_UNIX' > > Is there any chance we can fix that? I'm not sure if there is a general solution for this problem, as this would involve making zdaemon aware of and run on Windows, which isn't a target platform for this particular package for what I witness. If you want to look for a non-general solution, you can take a look at the zopectl implementation of Zope2 on the trunk (svn://svn.zope.org/repos/main/Zope/trunk/lib/python/Zope2/Startup/zopectl.py), which I made Windows compatible by adding a bit of platform specific code. I'm sure this can be easily ported to the ctl.py class in zope3recipes or the zopectl implementation of Zope3. One of the most basic things you need to do, is to provide a 'get_status' method which doesn't call send_action on Windows... effectively disabling the checks for a running daemon manager. I replaced the daemon manager support with support for starting and stopping a Windows service instead which can also be easily installed via ./bin/zopectl install Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3.1
Hi. Michael Kerrin wrote: > On Tuesday 13 February 2007 10:00, Philipp von Weitershausen wrote: >> On 13 Feb 2007, at 00:20 , Michael Kerrin wrote: >>> On Monday 12 February 2007 10:41, Philipp von Weitershausen wrote: > [snip] > >>> Althoug I had a slight problem starting Zope because of >>> ZODB.winlock not >>> working but considering all the problems I ran into to get the damn >>> thing to >>> compile I put this down to my lack of experience with Windows. >> How did you compile Zope on Windows? I assume you used some version >> of Visual Studio? > with lots of fun:-) > > I compiled it with MinGW. I couldn't find Visual Studio 2003 and it refused > to > work with VS 2005. I also had to hack distutils to get around a problem where > it couldn't find msvcr71 (???). So I am surprised I got this far to be > honest. While I haven't build Zope3 on Windows with MinGW yet, I assume it's quite similar to Zope2. For the latter I have written down some instructions as part of ploneout (the zc.buildout configuration for Plone) at http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt While most of it should be known to you, the paragraph 'Configure Distutils to use MinGW' might be of some interest. This should prevent you from having to hack distutils and all 'python setup.py' commands that involve building C extensions should use MinGW automatically. At least 'python setup.py build_ext --inplace' works for Zope2 then. All of the other stuff mentioned at http://www.mingw.org/MinGWiki/index.php/Python%20extensions should not be necessary anymore for recent versions of MinGW and Python 2.4. HTH, Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Use launchpad ! (was Re: the maintenance of change logs)
Hi. Carlos de la Guardia wrote: > > Please play around with it a little. Jeff has mentioned some of the good > things trac offers, so I will not bore you. There are a lot of details > that would have to be defined for this to really work, but you can get a > pretty good idea of how it would go. Just as a side note on one of the details that would have to be worked out. We still have the export/import scripts around (http://antiloop.plone.org/migration/) which we used to migrate the Plone collector to trac. While these scripts would surely have to be adjusted a bit, that should be rather easy and at least I would be willing to spent some time on this, should their be an interest in switching to trac. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release schedule for Zope 2.11/3.4?
Hi. Martijn Faassen wrote: > Andreas Jung wrote: >> --On 12. September 2006 13:06:05 +0200 Martijn Faassen >> <[EMAIL PROTECTED]> wrote: > >> Another point with this whole half-yr release cycle: we're going to >> confuse >> more and more professional users about which Zope version to use for >> what. >> I've heard from my major customer but also from other ppl. IN December >> we would have *three* maintained versions 2.9, 2.10 and 2.11. We >> definitely >> can't deprecate Zope 2.9 in December because this version is required >> by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate >> from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for >> the >> mid-future. So my personal impression right now is: we're flooding the >> community with new major releases and the community does not adapt those >> releases. My theory: a major part of the ppl running Zope are running >> Plone. >> on top of Zope...so with have to deal with this fact somehow. As Plone was mentioned as a an argument for scheduling releases, I should probably explain our current release strategy. Similar to Zope 2.8 we had a Plone 2.1 release that took more than 18 months to complete. After that we aimed for the next release (called 2.5) to ship six month after that. Here we tried to copy the new Zope release schedule. But while we tried hard to get a release out in time, we did not succeed with it and ended up with a 9 month release cycle. Now we again aimed for a release six month after 2.5 but we had to adjust our roadmap already and right now we aim for another 9 month release cycle. > That is a good argument for lengthening the release cycle. (as opposed > to say, people will fix more bugs if the release cycle is longer) > > What do you think about a 9 month release cycle? Based on the Plone experience I think this is a good compromise, between release often and stable releases. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.2 maintenance
Hi. Philipp von Weitershausen wrote: > Tres Seaver wrote: >> >> That is an enormous amount of effort: major kudos to him for being >> willing to tackle it. I think that in some cases, such a practice will >> not necessarily going to give the highest-quality result: the >> "backporter" won't always have as much context about the bug as the >> original "fixer", and may not be able to ensure that it is fixed >> properly. > > Yes. We don't have a Hanno for Zope 3. And even if there would be someone willing to do this job, a good understanding of most of the internals would be a prerequisite, as merging something which you do not understand is indeed potentially extremely harmful. The number of people that have a deep understanding of most internals of Zope3 is fairly limited and I think their time is better spent on fixing the bugs in the first place. >> I'm actually arguing against calling it "backporting" at all: the point >> is that it is *more* urgent to fix the bug on a release branch than to >> do so on the trunk, so we should refer to the process as >> "forward-porting". > > +1 +1, as mentioned in my other post, in Plone we do not do any backporting >> Pragmatically, it is typically *easier* to forward-port a bugfix than to >> backport it, because the "common ancestry" in the merge is more likely >> to be helpful. >> >> Of course, some kinds "janitorial" practices (e.g., tidying up >> whitespace, imports, etc.) can make this harder if done only on the >> trunk. That sort of friction is one of the reasons why change velocity >> drops off on successful projects. > > Well, the moving around stuff in Zope 3.3 (and the more moving that's > expected in the future wrt more egg-friendliness) will make such merges > harder, but not impossible. This certainly makes it more time consuming but not really any harder ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.2 maintenance
Hi. Rocky Burt wrote: > On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote: > > I've only ever worked on one open source project where I was not > supposed to backport my fixes to the maintenance release branches and > that is Plone. For Plone we have someone responsible for back-portting > that stuff in bulk. It makes his job harder if we manually back-port > fixes as then he has to be more selective with the patches he backports. > > Thanks Hanno! > > But my point is it is pretty standard behaviour to have to backport > fixes to all actively maintained branches. You got it backwards ;) I only forward-port any changes from older branches to the more recent ones, but never do any backports. The reason I do this is because before this, Plone developers tended to only fix a bug on the trunk or the latest stable release. My hope was that by lowering the bar by only requiring developers to fix a bug on the oldest maintained release branch, more people would actually do this and in fact I think this strategy has worked out. This works in conjunction with our quite well-maintained bug-tracker where bugs get assigned to the release they should be fixed in by a small group of people. But two things to keep in mind that differentiate Plone from Zope3 in this regard are, that most of the fixes in Plone are template issues or minimal changes that apply cleanly on the newer branches and when they don't or I do not understand them I ask the bug fixer to forward port it. Also maybe more importantly we only really have three changing packages (CMFPlone, ATContentTypes and Archetypes) which do not require things to be merged from one to another - we havn't yet started to move things around ;) For Zope3 the only sensible option IMO is, as others already mentioned it, to have a fix-on-the-oldest-maintained-branch-first bug fixing policy which requires to forward port these fixes to all branches up to the trunk. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Unused local variable?
Hi. As far as I understand there is really a bug. The code should deal with the situation where msgid is a Message object. What it does right now is to look up a translation for that Message object in the translation domain of the current TranslationDomain (self). The line you mention is part of the code that should make sure that the Message object is looked up in its own domain instead, but as you noticed this never happens. There is even a test for this in tests/test_translationdomain.py testMessageIDTranslateForDifferentDomain but it seems, it doesn't find the problem. Hanno Chris Withers wrote: > Hi All, > > Puzzling as to what this chunk of code: > > if msgid.domain != self.domain: > util = getUtility(ITranslationDomain, msgid.domain) > > ..from: > http://svn.zope.org/Zope3/trunk/src/zope/i18n/translationdomain.py?rev=68771&view=auto > > ...is supposed to do? util isn't used anywhere as far as I can see... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Hi. Chris Withers wrote: > Been looking more into getting lists of available languages for a domain > out of Zope 3. Just curious, do you use only the zope domain or some other domains as well? > Philipp pointed me to zope.i18n.interfaces.ILanguageAvailability, which > appears to be a tiny interface that's not used anywhere. It's just an interface for which you can write your own implementation. > What I'd like to do as give ITranslationDomain a getAvailableLanguages() > method and get rid of ILanguageAvailability. > > Would anyone have any problems with this? > Is there a procedure for deprecating interfaces and adding methods to > existing interfaces? Personally I think you are mixing responsibilities here. Available languages might have something to do with registered translation domains in your case, but that's not an assumption that holds in general. For instance if I have quite a lot of different domains for various products which one would be the "master domain" that defines if a language is available? Or you might want to have some criteria that only lists translations which are complete and not list those which are just registered but have no real translations available... What I would do in your case is to write a small global utility that implements ILanguageAvailability and returns the list of registered languages for the domain you had in mind. If you should ever need to filter the list according to some criteria this utility would be the right place to do it. > Right, regardless of the above, I'd like > zope.i18n.translationdomain.TranslationDomain to grow a > getAvailableLanguages method. Is anyone working on this? If you follow my suggestion you could use the getCatalogsInfo method implemented for translationdomains, no need to add this to the official interface. I would rather try to keep the interface small and a basic domain should know how to translate text, not anything more. Just my humble opinion, Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 2.9 and Zope 3 i18n, more questions...
Chris Withers wrote: > Is he not on this or any of the other zope3-related lists? Hi Chris, of course I'm reading this list, but sometimes I'm quite overworked and don't answer on the same day ;) >From reading your questions and the code Martijn posted I get the feeling that we all have quite some use-cases we try to solve in common which might indicate that these should be solved on the framework level. My idea for my Google Summer Of Code project (read: I'm currently getting paid by Google to do this stuff) so far has been to re-implement all the features of PlacelessTranslationService and PloneLanguageTool based on Zope3 and put some of them directly into Zope3 core and provide the rest and some more in a pure Zope3-style plone.i18n package. Amongst the features I was planning to implement are: - configurable language negotiation based on a set of registered extractors - extractors: browser language, cookie and URL segment (maybe member property but this is probably impossible in pure Zope3 right now) - possibility to restrict allowed languages, so one can force sites into English only mode or allow only a subset of available languages. For the Zope3 core I so far had in mind to implement: - Automatic generation of Gettext mo files from all registered po files on server start or explicit refresh. - if time permits implement a "tracker mode" (this is the PTS term, Localizer has the same feature) which if turned on, collects and stores all yet untranslated messages. While I still think the last two should make it into Zope3, there is one other major drawback right now, which I would like to solve. This is the half-hearted implementation of the INegotiator, as it is even mentioned in the interface description. Right now there are two interfaces IUserPreferredLanguages and ILanguageAvailability of whom only the first one is used by the Negotiator, whose responsibility it should be to negotiate between the preferred and available languages. Right now the available languages are hard-coded as all languages which exist for a TranslationDomain, which let to the hacky work-around code Martijn has written ;) As I guess not all of you already spent some hours looking through the Zope3 code I'll stop here for some meta comments :) My current roadmap is to implement all of the above mentioned in the next two to three months so it will be available as part of Zope 3.4 / Zope 2.11. Personally I'm not looking for a solution for Zope 2.9 or 2.10 as PTS and PloneLanguageTool solve all these use-cases right now, but are hard to extend, impossible to re-use and you know Zope2 ;) If people think these are good ideas and want to help, this would be much appreciated, for instance the mo-file compilation could be done as an add-on first, so it is also available for Zope 2.9 and latter be rolled into the core. Comments and cheerleading are also welcome ;) Hanno P.S. Can somebody point me to the Zope Foundation Contributer Agreement or do I still have to sign the old one? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: selecting the translation domain in ZCML
Wichert Akkerman wrote: > Previously Jean-Marc Orliaguet wrote: >> this is OK for most use cases because packages manage their own domain, >> but there is a case which I don't know how to solve, i.e. when a >> package is supposed to register translations into another package's >> translation domain?. > > A po file includes its domain in its header; I'm assuming zope is smart > enough to extract and use that. If not - please fix that :) This is one of the non-standard headers Zope2 (probably PlacelessTranslationService) invented to use if the also non-standard i18n folder layout is used for translation files. The standard way as implemented in Zope3 is to get the translation domain from the filename itself. I would have thought, that by registering translations via: all of the files would be found in there. For example this could look like: locales/LC_MESSAGES/de/mydomain.mo locales/LC_MESSAGES/fr/mydomain.mo locales/LC_MESSAGES/de/myseconddomain.mo locales/LC_MESSAGES/pt_BR/myseconddomain.mo All these files are uniquely identified and should be registered without any problem. A problem arises only when there is already a utility registered for that particular domain. I think there are different use-cases that we need to consider here: 1. A package author just doesn't like the translation files provided by the original package for some reason. This could be solved by using i18n:registerTranslations in an overrides.zcml which should replace all existing translation domain utilities. 2. A site administrator wants to change only some of the messages of a translation domain, as they might conflict with a company policy or are inappropriate for the audience of a specific site. This is a use-case often requested in the Plone world and which PlacelessTranslationService currently solves by yet another evil hack providing a global folder in the instance home of a zope site, whose translation files are queried before all other translation files. But these fall back to all the normally registered translation files. I think this use-case in Zope3 is better solved by creating local translation domain utilities which act in the same way of a semi-transparent proxy of existing translation domains. That is if a message is not found in the local utility it should fall back to the global one. For translation domains it makes sense to do this on the message level and not only the domain (utility) level. 3. A package author wants to change only some messages of an existing package. Actually I have no good idea how this could be solved and if this is even a legitimate use-case that Zope should support in the core. Arguments and examples would be welcome :) I should probably note that while I didn't found the time yet to write a mail to this list about my plans, I'm currently working on a Google Summer of Code project for the Plone Foundation whose goal it is to port all existing i18n/l10n infrastructure used in the Plone world to Zope3 technologies. My current plan is to get some of these, which aren't CMS specific, into Zope core. So if nobody has time to work on the use-cases mentioned in this mail I might end up having time for them ;) Cheers, Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: selecting the translation domain in ZCML
Wichert Akkerman wrote: > Previously Jean-Marc Orliaguet wrote: >> this is OK for most use cases because packages manage their own domain, >> but there is a case which I don't know how to solve, i.e. when a >> package is supposed to register translations into another package's >> translation domain?. > > A po file includes its domain in its header; I'm assuming zope is smart > enough to extract and use that. If not - please fix that :) This is one of the non-standard headers Zope2 (probably PlacelessTranslationService) invented to use if the also non-standard i18n folder layout is used for translation files. The standard way as implemented in Zope3 is to get the translation domain from the filename itself. I would have thought, that by registering translations via: all of the files would be found in there. For example this could look like: locales/LC_MESSAGES/de/mydomain.mo locales/LC_MESSAGES/fr/mydomain.mo locales/LC_MESSAGES/de/myseconddomain.mo locales/LC_MESSAGES/pt_BR/myseconddomain.mo All these files are uniquely identified and should be registered without any problem. A problem arises only when there is already a utility registered for that particular domain. I think there are different use-cases that we need to consider here: 1. A package author just doesn't like the translation files provided by the original package for some reason. This could be solved by using i18n:registerTranslations in an overrides.zcml which should replace all existing translation domain utilities. 2. A site administrator wants to change only some of the messages of a translation domain, as they might conflict with a company policy or are inappropriate for the audience of a specific site. This is a use-case often requested in the Plone world and which PlacelessTranslationService currently solves by yet another evil hack providing a global folder in the instance home of a zope site, whose translation files are queried before all other translation files. But these fall back to all the normally registered translation files. I think this use-case in Zope3 is better solved by creating local translation domain utilities which act in the same way of a semi-transparent proxy of existing translation domains. That is if a message is not found in the local utility it should fall back to the global one. For translation domains it makes sense to do this on the message level and not only the domain (utility) level. 3. A package author wants to change only some messages of an existing package. Actually I have no good idea how this could be solved and if this is even a legitimate use-case that Zope should support in the core. Arguments and examples would be welcome :) I should probably note that while I didn't found the time yet to write a mail to this list about my plans, I'm currently working on a Google Summer of Code project for the Plone Foundation whose goal it is to port all existing i18n/l10n infrastructure used in the Plone world to Zope3 technologies. My current plan is to get some of these, which aren't CMS specific, into Zope core. So if nobody has time to work on the use-cases mentioned in this mail I might end up having time for them ;) Cheers, Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Zope 3 startup message
Tres Seaver wrote: Heh, only with Plone, where PTS spews tons of useless gunk at INFO level. Let's fix the spew in PTS instead (which should be at BLATHER or DEBUG level). Note, that I fixed this in PTS svn, releases after Plone 2.1.2 will be quiet ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
