On Thu, 2006-09-28 at 01:49 +0100, Dimitris Glezos wrote: The Docs Project folks have reached out for a number of Translation people, but with no luck -- -- UNTIL: Aman got back and checked in with us tonight. See his earlier message; the new POT is available which translators should merge and work on as soon as possible. We apologize for the short notice. We were about a day late or so with our output, which didn't help. Rest assured this is not the end of this particular story, and we are going to step up our efforts to jump-start improvement of this process. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

On Thu, 2006-09-28 at 21:52 +0200, Thomas Canniot wrote: I couldn't agree more, Thomas. The blame falls on a lot of different factors: 1. The wiki makes it easier for people to put up release notes, but it also makes them easier to change. A lot of these changes are minor or cosmetic, but they still result in untranslated strings. I watched the wiki all summer, and edited it constantly to make sure that the language was clear and easier to translate. But the result is that translators are not necessarily saving themselves work by translating early and often. And yes, too many beat writers are waiting until the last minute. 2. When we edited the test3 version of the release notes, we used our new wiki conversion engine, and then the editors (including primarily me) retagged things into proper DocBook. When we got the new POT ready for final, we realized that we were going to have to retag everything the same way to avoid creating brand-new untranslated strings. As I understand the issue, msgmerge thinks these are completely different strings: "Use the command <code>msgmerge -U</code>." "Use the command <command>msgmerge -U</code>." Or at least they're "fuzzy." Which means the numbers *look* inflated. Maybe there's less work than it looks like, but a string is still a string, and someone has to look at it. 3. No one from the Translation Project management responded to our email for some time to move the POT. We were very lucky that Aman stopped by IRC -- I think he's still on vacation, no less -- and helped us out. 4. Our normal editorial staff had some unplanned downtime as a result of "real-life" issues. Sometimes these things happen, it's just life. But on top of that, we have *VERY* few people actively helping on Docs Project. In fact, you can probably count them on two hands. I am very disappointed at the way this process went, but I feel that in a lot of ways, we really did do our best given the circumstances. However, that doesn't mean we can't improve. I would like to propose the following -- and I'm just brainstorming here: 1. No release notes translations to be done until test3, to minimize wasted effort from translators. *A LOT* changes from test1 until final, but not nearly as much from test3 until final. 2. Set the new deadline for translation *10 days* before the target date instead of 7. This gives us wiggle room, so at worst, if we're a day or two late, there's still more than a week to translate. 3. A sort of Docs/Translation "summit" meeting on IRC to work out a more rigorous scheduling routine, to avoid unnecessary delays. Your comments and thoughts are appreciated. I am setting the follow-up to fedora-trans-list. Any interested Docs people should be subscribed here as well. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject

On Sun, 2006-10-01 at 19:39 +0530, Rahul Sundaram wrote: Yes, I've been saying this for some time, too. We need some sort of central project planning system that integrates with our functioning desktops to remind people when things need to get done. The current system of writing it on the wiki and emailing people manually is neither sufficient nor scalable. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject