On 2011-02-14 17:02, Chris Leonard wrote: > On Mon, Feb 14, 2011 at 4:08 AM, Dwayne Bailey<[email protected]>wrote: > >> Hi Chris, >> >> A few ideas off the top of my head without spending too much thought on >> the matter. >> >> 1) Delete unchanged entries when compiling. Problem if there is any >> inheritance within the PO files. >> 2) Marking something as translated even when it isn't. We've thought >> about this but it would require quite a bit of coding. We experience >> the same problem in Mozilla strings where msgid and msgstr are blank and >> you can optionally translate them. I think that would align with your >> idea. >> 3) We've had some bug requests for subsets or inheritance within PO >> files. The PT, PT_BR comes to mind. Haven't thought too much about how >> that could be implemented though. >> >> The last two require coding, the first one can be a simple hack. >> >> > Dwayne, > > I'd thought of the simple hack, but I'm not sure how our build generators > would implement it. It would probably require some coding on the back end. > If there were a "delete" entry option, the lang-admins could handle it by > reviewing "unchanged" strings before doing a commit, but I don't know of a > mechanism to clear an entry once it has been made. Simply blanking and > attempting to submit an entry does not accomplish an overwrite and returns > an error, I believe. You should be able to blank entries. > As for adding coding for the "do not translate" flagging, I would think the > coding would fairly closely parallel that for handling fuzzy strings. They > don't get committed (or at least used) in the PO. It could even be > implemented with a check box next to the fuzzy box on the translation UI. > It would probably need to be added to the pofilter checks as a distinct > category. The bigger problem is the limitation of PO. We've mostly tracked our features against PO features. We are slowly moving away from that but since there is no way to store that type of info in PO it means quite a lot more thought and coding to ensure that the PO files are valid PO but also contain what you want.
In the simple hack approach it would be easy to remove any units that are direct translations. That would happen before the files are compiled to .mo > I work a lot with clinical research electronic data capture systems and this > is an important concept. There is always a need to be able to flag an entry > as having been human-reviewed and an affirmative action taken to leave a > data field blank when data is expected (usually with some explanation like > not applicable or not available). This distinguishes that field from one > that has merely been skipped over when the data-set undergoes QA review. I > guess I would have to say this is a feature request. Yes, very aware of that. We've started to implement more advanced workflows in Virtaal to test some of these ideas of proper review cycles. But it again hits the problem that this is a layer on top of PO. > I realize that the sub-setting or inheritance poses a more substantial > issue, but it seemed related and has been the topic of recent discussion > among the Spanish-speaking Sugar community so I thought I would raise it, > but I knew there would not be a simple answer. The bigger problem is probably coders to code it :/ > cjl > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Translate-pootle mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/translate-pootle ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
