On Wed, 2010-12-08 at 23:20 +0100, Gil Forcada wrote: > > seems like, that you didn't move the > > https://svn.plone.org/svn/collective/gnomeweb-plone/wgo.linguasync/ > > repository, which implemented all the translation sync stuff to reflect > > the gnome language translation workflow. > > I just imported that one [1] and wgo.mainpage [2]. > > For the first, at least looking at the source code, doesn't look like > it's a regular submodule you put under src/ right? It's just an external > module not tied-up with the other modules? no, wgo.linugasync has a setup.py which makes it a normal python package and it uses configure.zcml, which let it play together with zope/plone. so it's safe to put it into buildout's src directory.
> For the later, do you remember if it's still valid or wgo.theme [3] > super-seeded it? yes, forget wgo.mainpage. wgo.installsite configures Products.Collage which replaces functionality defined in wgo.mainpage. > > > i *think* that collective.plone.gsxml, which was used for importing > > content, isn't used anymore. i'm not very sure about that, but i guess > > so. but if it's working, it might be ok to leave it where it is. i have > > developed the create_item functions as an alternative to define a > > content structure as dictionary which can then be used to create content > > in a plone site (see: wgo.installsite.setuphandlers-basic_content). this > > tool lead into the development of > > https://github.com/collective/collective.setuphandlertools/ > > which may be used for importing content and other stuff, if needed. > > Nice to know about it. btw. wgo.policy is just configuring the diff_tool. i'm not sure if we need it (if, i guess for translating). anyways, we can drop it and put the diff_tool configuration - if really needed - into wgo.installsite. then we should also drop collective.plone.gsxml since it's a legacy package. we should clean up everything... there are a lot of questionmarks arising in my head and i'm asking myself what we did there back then... e.g. collective.indexing... do we need that? guess not. btw.2: are you planning to use plone4 instead of plone3? if yes, i'll support that decision. plone4 is just better. JUST IGNORE THE FOLLOWING IF EVERYTHING IS FINE: btw.3 instead of using submodules, wouldn't it better to use the buildout extension mr.developer? i'm not very familiar with git submodules, but i guess it won't automatically configure the python path to each package in buildout's src dir? anyways, then you can set it via buildout.cfg manually and get the same effect. but for doc see here: http://pypi.python.org/pypi/mr.developer for an example here: https://github.com/thet/thet.grak.buildout/blob/master/sources.cfg and https://github.com/thet/thet.grak.buildout/blob/master/buildout.cfg > > Since you have some prior knowledge about the past efforts on bringing > Plone to GNOME would you mind coming to the upcoming IRC meeting about > it? > > It will be on Sunday December 19th at 20:00 GMT on > #[email protected] yes, i've marked my calendar and try to be there. cheers, ,,,hannes > > Cheers, > > [1] http://gitorious.org/gnomeweb/linguasync > [2] http://gitorious.org/gnomeweb/mainpage > [3] http://gitorious.org/gnomeweb/theme > > > > -- johannes raggam / thet python plone zope development http://johannes.raggam.co.at/ mailto:[email protected] http://bluedynamics.com/ _______________________________________________ gnome-web-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-web-list
