Subject: Strategic Partnership between hostingforum.ca and gnome.org - msg#00036

Previous Message by Date: click to view message preview

Re: wgo i18n

On Mon, 2006-11-06 at 11:53 +0100, Quim Gil wrote: > On Mon, 2006-11-06 at 01:43 +0100, Ramon Navarro Bosch wrote: >> > > * Can we define the exact workflow to use on translations ? I also think it is a good idea to think and talk about the i18n work flow. The reason for setting up a CMS was to avoid having to author content inside CVS. Currently AFAIK the xml2po work flow is still "optimized" for this CVS based work flow. It is also clear that the out-of-the-box support in Plone is not adequate. So the question is, how do we integrate? Things that are important: - what format does Plone export to? - how is data exchanged? (webdaw, http get / post?) - how are the change notifications syndicated? - authoring work flow Format ------ Some format requirements were already discussed in [1], stating that the markup should reflect structure. This of course goes for the served XHtml. But this is especially for import/export, because all relevant information must be conveyed in the markup, since the content will be exported in one language (English), and re-entered into the system as a new resource in another language. It is also up for discussion whether we exchange XML sources, or PO files ready for translation? How is data exchanged? / Change notification -------------------------------------------- This is a technical detail, but possibilities should be explored, and agreed upon. Both sides are "smart", so Plone can actively push out changed content, or the translation tools can poll for changes. E.g. Plone could provide RSS feeds for updates (even per language, per page, per priority, per author, etc). Authoring work flow ------------------- Last but not least the authoring work flow should be discussed, and if possible, improved. One aspect is that the existing translators are comfortable with their translation environment. The other is that we are looking for more translators. Since with the integration we are expanding the capabilities of the whole authoring system, changes to the current work flow should at least be considered. Maybe we can offer alternative work flows? cheers, Greg [1] http://live.gnome.org/GnomeWeb/WebPolicies > I'll also leave the details of this one. We should aim to integrate as > much as possible with http://progress.gnome.org (aka > http://cvs.gnome.org/viewcvs/damned-lies/ ) and the workflows they have > defined there. > > Some tips while the translators define their requirements/wishlist: > > - Translators love stats like > http://progress.gnome.org/releases/gnome-2-16 They help them catch the > remaining work and go for it. > > - Maybe it would be useful to have notifications of new/updated > translatable content to be sent to a mailing list (or the lists of each > language). > > - FWIW, well supported languages have a reviewing process of the > translations committed done by the language coordinators. Languages not > that well supported have their translations committed directly. > > - It would be useful to have at least 2 priority levels: pages that MUST > be translated and updated (most if not all the static pages) and > news-alike pages (i.e. case studies, gnome products...) > > - We need to define when a language becomes publicly available (i.e. > having >95% of priority pages and >50% of the rest. Maybe it's worth to > offer some kind of non-supported visibility to the languages with lower > levels of translation? Perhaps this would help them get more > volunteers... > > > On this part we will probably need some new code to adapt and I would > > like to know how much work is needed to estimate how many help we will need. > > I believe the tough bone is the integration with Damned Lies. If this is > achieved... translators shouldn't care if the source texts are in a CVS > or a CMS. > > _______________________________________________ > gnome-web-list mailing list > gnome-web-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gnome-web-list

Next Message by Date: click to view message preview

Re: wgo Iteration I

On 06 Nov 2006, at 03:04, Kevin Teague wrote: > [...] > >> One another question is GNOME Products, I've seen that is >> interesting to >> maintain some GNOME products information, there is a simple >> product on >> plone that allow managing products, ( easy so not difficult to >> maintain >> ). We can adapt the look&feel to enable store different products, it >> allow information about products, svn/cvs url, documentation, >> releases, >> author, .... You can see it at http://plone.org/products/ > > [...] > > If gnome.org is interested in using it though, you may want to > consider managing it in a separate Zope/Plone instance. Having used > Plone for a quite a while, I know for first hand experience that it > can be easy to build up a whole lot of Plone add-ons to a Plone site > over time. The more add-ons Plone has, the greater the chance for > headaches when it comes time to upgrade Plone itself. Also, the more > add-ons, the harder it can be manage the system, especially for a > volunteer run system where people can tend to come and go on the > project. Of course, if a Product is being used on Plone.org such as > PSC, then there will be a very strong incentive for the authors to > support the product in future versions of Plone (and I know the PSC > contributors have a lot of interesting ideas in the pipe that they > want to add to PSC). About Plone Software Center: I'm not sure you need another Plone instance for running PSC, as you wrote, PSC is deployed on plone.org and maintained by PloneSolutions. We can therfore make sure that it will comply with future versions of the Plone CMS. just my 0.2 € > > - Kevin Teague > _______________________________________________ > gnome-web-list mailing list > gnome-web-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gnome-web-list

Previous Message by Thread: click to view message preview

wgo i18n

hi ! i18n it's a really important part of this project, for that reason I would like to know what would you like to do : * we can use LinguaPlone translation system that generates translations for all the systems. It manages all translations and you can see original version while you are editing new translated version on the web. * we can use xml2po ?? how is the process to use it ?? as I understand it's a software that translate xml to po and after editing with your po-editor you transform again to xml. One great thing of Plone is that there is a webdav interface , so you can obtain the content by webdav/ftp and edit it using emacs ( or your preferit editor ) and automaticaly upload it after editing. What do you thing about that ? /Ramon

Next Message by Thread: click to view message preview

[wgo] Iteration I

Hey ! Some "little" points, * I've decided to use [wgo] tag name on the list for people that has subscribed only for helping on the implementation. * Plone Software Center (PSC) , it's a great idea to use it on the main instance of plone ( I don't doubt it will work on future versions, as you said is maintained by PloneSolutions... ). I've been looking at GnomeWeb/GnomeProducts and my proposal is to use PSC to maintain gnome products information, we can create a general translator than transform product information to a DOAP file ( and enable importing it ) as the same way we are going to do i18n ( webdav / FTP ) * I've created a project on lafarga.cpl.upc.edu gforge only for developing the needed products. You can go and sign up, and latter apply for wgo project. There is a svn repository there I've created the first schema of the skin product : GnomeSkin (copy of DIYPloneStyle). Now you can begin on skinning secondary pages. David, LeeTambiah and all XHTML/CSS lovers, can you create a main_template similar to http://live.gnome.org/data/GnomeWeb(2f)PageStructure/attachments/layoutPlanSecondary0.4.svg ?? * On few days ( I hope ) we will have the server with the Plone instance ready to be used so then we will begin testing the new skin. * About content layout we will use PloneArticle / RichDocument / .. to enable diferent content layouts inside the content macro. /Ramon