On Fri, Dec 18, 2009 at 09:37:32AM +0100, Christian Boos wrote: > Hello Remy, > > Remy Blank wrote: > > A few recent changesets updated a translation at the same time as they > > made a change to a functionality. For example: > > > > http://trac.edgewall.org/changeset/8918 > > > > This has the disadvantage that the functionality change is "hidden" in > > the noise due to the many line number changes in the translation. > > > > Right, that's not ideal. > > I nevertheless think it's a good idea to have in one changeset the > original text change, an extraction and an update of at least one > translation, because this validates the i18n "completeness" of the > application, the same way we commit in the same changeset a functional > change and the corresponding test (well, when we have a test ;-) ).
That seems to call for some sort of changeset filtering - maybe some functionnality to classify changeset contents to eg. code/i18n/tests would be useful, so one could easily filter out one or the other depending on his role in the project ? Maybe that could just be configurable as regexps on changed paths, with a fallback "unclassified" category in case of an incomplete set of regexps ? That way, people could also define filters for various components they are interested in in the project (eg. core/plugins/specific-plugin/etc.) How does that sound ? -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
