On Sat, 2007-07-14 at 16:18 -0700, Karsten Wade wrote: [...snip...] > > > 4) at stable, i assume only key members can edit... and this > > > is where we go to translations > > > > > > ## KW - This makes sense. Translators find mistakes or have > > > questions/clarifications for the original; an editor or original > > > owner needs to be able to fix those and push the content back > > > for translation (generate a new POT, alert translators with open > > > PO files, whatever.) How much of this can be done through > > > Plone? Through CVS? > > > > The more we can do through Plone, the easier it will be for non-techies > > to help with documentation. That's a major blocker for our subproject > > right now -- I suspect there are people out there who can correct > > grammar and write good standard English, but who are frightened of doing > > CVS because they think they might irreparably break something. (A silly > > or at least misplaced fear, but you have to respect the fact that they > > care.) So if they can do this with a pleasant, or at least > > comprehensible, web interface, that's a win in my book. > > +1 > > This particular question around translators might be a bit different. > By the time a translator has found an error, the content is in the > 'stable' workflow state, and resolution needs to be handled by a more > experienced team member (editor, writer) with sufficient permissions. A > decision has to be made (via bugzilla, mailing list) and a new POT > pushed (if needed), then some social work has to be done (alert > translators via mailing list, in addition to any workflow alerts they > receive.) In some cases, the error report was on a mailing list, where > the solution gets worked out, and the thread needs to be closed. > > So, there is going to be complexity and 'harder' here because of the > number of people affected. But I do agree that the tooling shouldn't be > difficult to match -- i.e., don't make an editor drop to the CLI to > handle this. BUT -- the editor should be able to do this from the CLI > (cvs + Jon's daemon). And there should be sufficient > checks-and-balances to ensure other contributors are not walked on by > the changes. :) How hard would it be for published/stable documents to have a standard toolbar such as "Report Problem" -> Bugzilla autofilled entry? And a POT push, for example, should trigger something automagically from the trans.fp.o app, right? I would think it's a good idea to cut down on multiplicity of error threading (mailing list, IRC, etc.) in favor of single channels that have wide reporting flexibility for subscribers. As a doc maintainer, I don't want to have to figure out which of four ways to "close out" an error report -- everything should go through Bugzilla, whether or not the reporter interacts with it initially in that particular way. Rather than making anyone join or post on a mailing list, the document should offer an easy way to report problems. > > Right. Part of the reason we want this is for good interaction with > > Dimitris' DL work, where fixes can be detected visually by L10N'ers... > > or by people who like detecting automagically against > > fedora-docs-commits. > > Detected one time and searched for in multiple instances? > > http://translate.fedoraproject.org/search I was talking just about simply detecting changes by looking at the completion graphs, but this is cool too. > > This does mean we have to get the Kupu-fu right, > > or at least to a point where people like Karsten, me, Dimitris, John, et > > al., can add styles to Kupu as needed to support all elements we use in > > DocBook XML. > > This is interesting to ponder. We'll have to first decide how we are > going from XHTML => XML, then test what that does with the various > styles. I reckon we can do a fair bit with CSS classes. Might need a > bit of custom work in between (XHTML => XML w/ classes => XML) to > interpret the classes into the specific XML elements. Or, you know, > maybe it will have been done by someone already? I would think that CSS classes would take care of this nicely, i.e. <section id="sn-foo"> <title>My Foo</title> <para>My foo is <emphasis>nice</emphasis>. I like foo. So will you.</para> </section> <div class="db.section" id="sn-foo"> <div class="db.title">My Foo</div> <div class="db.para">My foo is <span class="db.emphasis">nice</span>. I like foo. So will you.</div> </div> -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
