On Thu, 2009-02-26 at 10:02 +0100, Samuel Murray (Groenkloof) wrote: > G'day everyone > > Please let me know your thoughts on this suggestion. > > Problem: There is currently no way to combine Quick Translate with the > Search function. If a user wants to translate all strings that match a > certain search, he can only do it in Translate All mode. A search will > always go to the first instance of the search result in the file, > regardless of whether it is translated, fuzzy, incomplete or suggested. > > This means that the Search function is great for editing existing > translations and for doing contextual research in a file, but it is not > suited for doing new translations or updating partially translated files. > > Suggested solution: Enable users to filter strings in any mode, using a > filter field similar to the Search function. > > In other words, put another search box next to the current search box, > and call it "Filter". This filter box should have the same advanced > search options as the existing Search box. The filter should be applied > regardless of what mode the translator is in (eg Quick Translate, > Translate All, one of the Checks, etc). > > So the Filter function will be mode-independent, and the Search function > will be (as it currently is) a mode of its own. > > If we simply change the operation of the existing Search function so > that it respects the current mode, then it will be rendered less useful > (or even useless) for users using it to do contextual searches, because > they would have to leave their existing mode first, and go to the > Translate All mode, before doing the search. > > The thing that prompted this suggestion of mine was that I had wanted to > use the Search function to virtually split the source text file into > smaller sections based on the Locations field. So translators who want > to translate the GUI first, would be able to filter on the "/gui" > location (and other locations relevant for the GUI of that project). > Then there would be no need to split files manually any more, as we have > done with WordPress and VLC on the Locamotion Pootle server. > > Your comments?
We've had to think of a similar problem in Virtaal and I don't think we've got the solution yet. One quicker fix might be to allow the current search to understand the concept of state so you can search for /gui and incomplete (i.e. fuzzy and untranslated) -- Dwayne Bailey Associate +27 12 460 1095 (w) Translate.org.za +27 83 443 7114 (c) Recent blog posts: * Fixes for Skype Video, Webcam on Fedora http://www.translate.org.za/blogs/dwayne/en/content/fixes-skype-video-webcam-fedora * libtranslate, TM plugins and Virtaal * Localisation Information Language - preventing mistakes and increasing the richness of localisation Stop Digital Apartheid! - http://www.digitalapartheid.com Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/ African Network for Localisation (ANLoc) - http://africanlocalisation.net/ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
