On Wed, Oct 31, 2012 at 05:34:15PM -0400, Theodore Ts'o wrote: > On Wed, Oct 31, 2012 at 12:06:19PM +0100, Dave Martin wrote: > > > > What's the best way of making sure that changes in the source document > > propagate to translated versions? > > > > It might be enough to put a note in the source document to remind people > > to check for the extistence of translated versions and CC the relevant > > translation maintianers with any patches affecting the source document. > > What I was suggesting was even more light-weight. Just include at the > very beginning or the very end of the the file the last time the > translation was updated, and either the kernel version (i..e, v3.6) or > the git commit ID (i.e., df981d03eeff) that was used for the source > document. > > That way, someone who reads the file will know how "fresh" the > document is, and the reader can do a "git log -p > Documentation/arm/kernel_user_helpers 1234567890abcd.." to see all of > the changes made to the file since the last time the translation was > updated. > > People will inevitably remember to forget to notify the translation > maintainers, and as the number of translations go up, the more > workload we put on the everyone else. If we simply mark the > translation, then the translators can poll to refresh the document at > their leisure, or perhaps this allows anyone who is using the > translated documentation file and who has a reasonable command of > English to do the "git log -p ..." command and perhaps contribute a > patch to update the translation. So I think this approach would scale > much better. The only potential issue I see here is that the final commit ID may not be known at least until the patch is applied in a maintainer tree. But I guess this is not a different problem from existing practices where a patch references commit IDs. It sounds like a reasonable, practical approach to me. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
