On Do, 2008-07-17 at 10:04 -0400, Suresh Chandrasekharan wrote: > All, > This is in reference to the discussion that happening around > Bug 434 "updatepofile/commitpofile needs to be moved to translate toolkit" > trying to think about how the code move should be done according to > translation workflow and also in alignment with Pootle strengths.
Hi Suresh. Thank you for your thoughts and thorough reasoning. I can't comment on everything now, but I'll add some comments inline. > > This attempts to focus on the general guidelines on how we should > base our decisions on code move rather than the specific > updatepofile/commitpofile APIs discusses > > When trying to automate some of the current manual steps in translation > workflow like connect to the project po directory from Pootle (see the > patch for http://bugs.locamotion.org/show_bug.cgi?id=452), one thing > that came to mind is, as a result of configuring a "Project L10N directory" > (See the screenshot > http://bugs.locamotion.org/attachment.cgi?id=167&action=view ) > from Pootle, if the project po directory is sufficiently large, the pootle > sort of freezes while the server is initially indexing the .po files and > creating .stats and .prefs files. (I have observed that if I configure > all the languages used by a Gnome application like gedit in Pootle, > create a link to gedit po directory, then the server virtually freezes > when it's initially indexing the whole files for 4-5 minutes in my > machine) The indexing and quality checks take quite a bit of time, and the "plain" statistics (word counts) take time anyway, since we have to read the files. This can already take some time in a large project. > Once we initially create these needed indexes and other files, the > incremental > updates to these files are done as the translation process progresses > and is less resource intensive. So I thought the logical place of initial > operations will be outside Pootle. Similarly I was thinking about the > the final commit after the translations are done and are approved, also > server intensive and can be done outside Pootle. > > During the translation workflow the following actions typically take place. > > 1. Initial creation of project > 2. Addition of new languages of the project in Pootle. > 3. Pootle initial indexing and creating .prefs/.stat files > 3. Translation assignments and actual process of translation > 4. Updating the translations from RCS periodically during the translation > cycle > 5. Translation review/approval > 6. Final update/commit of the translations > > It seems to me that steps 1-3 and step 6 are best handled in an outside script > as these are intensive operations. These can be best done during the scheduled > downtime of the PootleServer > > While it's beneficial to have the functionality both in Pootle and in an > external > script, some operations like externally adding po files etc needs server > restart > so within the current framework these are best addressed from a outside script > > So doesn't it make sense to base the code move decisions from Pootle to > translate > toolkit based on this ? I agree that for larger projects it will simply make more sense to do some of the work at scheduled times, or simply at a much lower priority by an external script. So although I like to keep this optional for the sake of small installations, I think it is good to give the power to administrators of the larger projects. About 3: this is partly what can be done already by running pocount from the Translate Toolkit over the files. This does not perform the error checking or indexing, but does compute the word counts, which is all that is necessary to display the basic statistics pages. Another related point is discussed here: http://bugs.locamotion.org/show_bug.cgi?id=429 We probably want to ensure that we have a way to externally trigger both updates for new/changed files (in the case of external change to files, for example), and a complete recalculation (new version of Pootle/Toolkit, for testing, etc.) In terms of your candidates for external helper scripts, I think number 6 is the most important / useful at the moment. Also, this can actually be tested well in isolation, whereas 1 and 2 can only really be tested in Pootle. Furthermore I think such scripts that can meaningfully interact with version control systems in a way that makes sense to translators will be useful for more people than just Pootle administrators :-) This one isn't quite trivial, but you have already made good progress on this, so I think we can achieve this one, and I'm all in favour of it. I hope this helps a bit. Keep well Friedel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
