On Wed, May 25, 2011 at 01:47:34PM -0700, Junio C Hamano wrote: > I am reluctant to do this (including the rewording of the end-user facing > message) until we decide what to do with the reflog. Right now, I think no > tool looks at the reflog, but contaminating the reflog with translatable > messages mean that we will never be able to support "3 merges ago" just > like we support "the previous branch". The reflog messages look like: merge $branch: Merge made by recursive. So it seems to me that we could localize everything after the colon and still do "3 merges ago". The only thing you would be losing is a machine-readable description of which strategy was used. In practice, I'm not sure how much it matters. But for others, like: checkout: moving from $old to $new a localized version loses useful information. > Either we split the messages into two, one translatable and given to the > end user and the other untranslatable and sent to the reflog, That seems like the safe choice for now, as it still opens the possibility of localizing reflogs later if people care to do so. Being a native English speaker, I have no clue how much people actually care about localized reflog entries. > place in reflog entry where we can hide machine readable and stable > representation of what happened and store both the end-user facing message > and the machine readable one separately. In the longer term I would prefer > the latter. If we assume that reflog entries are machine-readable (or at least _some_ of them that are generated by a few well-known git programs), you could always translate on the fly while displaying them. That solves the storage question, and it allows two people with different language preferences to both read the same reflog. And the implementation probably wouldn't be too hard, since we'd only have to match a few well-known strings, and we could display anything we didn't match as it appears in the reflog. -Peff -- 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