Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> * The series is too long to read in one sitting.
>
> Suggested fix: deal with some arbitrary early subset (35 patches?
> I'd even prefer around 20) first.
Let's concentrate on making sure that the first four (i18n foundation, no
markings) gets merged to 'master' first, using the early ones (say,
"init", "clone", "add" and "branch") as a sanity checks.
And then we can stagger the remainder, perhaps at most 10 in one batch but
preferrably smaller, two to three batches a week merged to 'next' and then
down to 'master', over a few weeks.
> * Patch 2 (add GETTEXT_POISON) is conceptually complicated since
> its arbitrary string is not arbitrary.
>
> Suggested fix: split it into two patches. But I am still not sure
> if that's considered acceptable?
See bottom.
> * Patch 2 squats on a valuable use_poison() identifier space.
>
> Suggested fix: rename it to gettext_poison().
For this, I can just "rebase -i"; I don't think there is anything
controversial nor tricky.
> * Patches 5 (i18n: git-init basic messages) and onward do not
> explain "we are marking strings for translation, in
> preparation for translating them later" in their commit messages.
>
> Suggested fix: use titles like Âi18n: mark some "git init" messages
> for translationÂ. Or ignore the problem --- it's not a big deal.
If you want to see a mixed patch that has both logic reorganization and
message marking in one change, e.g. i18n: git-revert split up "could not
revert/apply" message, split into one that only reorganizes the code
structure and the other that only marks literal string, your "mark for
translation" would start making sense. The other half won't even have
"i18n:" prefix in that case. If we go that route, it would be better to
have the code restructuring patches merged to 'master' before (and
independent from) i18n. But the ones I took a look at didn't seem too bad
(e.g. i18n: git-revert "Your local changes" message). I think Ãvar did a
good job splitting the changes into a reasonably small bite-sized chunks
in this round.
Assuming that we are not going to do that "even finer" split, I think the
patches we have on 'pu' are descriptive enough already. They look like
this:
i18n: git-tag tag_template message
i18n: git-mv "bad" messages
> Does that sound like a fair summary?
To me it does. Thanks.
> I'd be happy to reroll the first 30 or so patches following whatever
> approach is the consensus for these things to move this forward.
I tend to think that except for the GETTEXT_POISON bit what we have is
mostly fine.
Can you give two weather-balloon counterproposal patches for "add
GETTEXT_POISON" and "i18n: git-status "Changes to be committed" message"
to illustrate what you have in mind, and perhaps list the patches in
Ãvar's series that need similar changes as you would need for the latter,
to illustrate the extent of damage a careless translator can cause by
omitting '#' from the beginning? Would that help the topic get unstuck?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html