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 ;-) ).
The problem with that approach, as you've found out, is that the actual
changes are lost in the numerous line number changes in the .pot and .po
files.
> Would it be possible to keep the updates to translations in separate
> changesets, so as to increase the signal-to-noise ratio on "functional"
> changesets?
>
When you work on the i18n side, you also try to validate your changes to
see how well they work out in a translation.
You have then this work sequence:
1. edit .py/.html
2. setup.py extract_messages => new trac/locale/messages.pot
3. setup.py update_catalog => updated
trac/locale/*/LC_MESSAGES/messages.po
4. edit messages.po
5. setup.py compile_catalog => trac/locale/*/LC_MESSAGES/messages.mo
6. run tracd, test the change in browser
If you'd commit once after 1. (functional change), a second time after
3. ("noisy" changeset) and a last time after 6. (translation change),
then the situation would indeed be a bit better. On the plus side, you
have the functional and translation changes in clean changesets, on the
minus side, you still have the noisy changeset that you have to ignore
and mentally skip, and you don't have the logical grouping of the text
change with its i18n validation, as discussed previously.
The problem is that it rarely work out that way and a real workflow
actually implies *several* iterations of steps 1. to 6., until the
result is found to be satisfying. So you can work with MQ for example to
manage patches for 1., 3. and 6., and that works but due to the nature
of the second patch (i.e. produced by update_catalog), you more often
than not end up with conflicts when pushing the translation patch. And
that's painful, compared to simply working iteratively on the same
all-in-one patch, in which case update_catalog (step 3.) is smart enough
to merge the line number updates with the translations added or edited
during step 4. of the previous iteration.
Another possibility would be to keep the all-in-one approach but before
committing, doing a selective commit of only the "interesting chunks"
(using qrecord). I think I'll try out this approach next time.
But the ideal solution would be to have the uninteresting changes (the
line number noise) simply /hidden/ from the display, which will also
solves the problem of the noisy changeset. And that's probably doable by
implementing pluggable diff renderers (#53) and a special .pot/.po
renderer which simply remove the line noise chunks from the diff output...
-- Christian
--
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.
