Re: [RFD] Documentation/HOWTO translated into Japanese

From: Kyle Moffett <mrmacman_g4@mac.com>
Date: Jun 15, 2007, 00:29 UTC
Message-ID: <29741172-099F-499B-8A73-A85C6360129D@mac.com>
In-Reply-To: <12c511ca0706111038j37e188b6n2677b1789d14de23@mail.gmail.com>

On Jun 11, 2007, at 13:38:10, Tony Luck wrote:

Show 14 quoted lines

>> I'd rather have a single file, marked "Japanese" (in Japanese),  
>> that had pointers to current translations. These will always be at  
>> least as current as whatever we have in the tree, if not more so.  
>> Especially when someone is trying to figure out how to work based  
>> on the year-old kernel their embedded vendor gave them.
>
> Knowing whether a translation is current or not would be useful ...  
> perhaps the translated files could include the GIT blob SHA1 of the  
> version they were translated from (and some human readable version  
> string too :-) This would allow someone reading the documentation  
> to know whether is really was current.  If it isn't, it provides an  
> easy path to see what changed in the source document since the  
> translation was made. This same diff should lighten the load for  
> people maintaining the translation.

Well, actually, if you're going that route then extend GIT to have support for "related" files. Essentially you should be able to add metadata to a git tree which says: "files $SHA1-$PATH1, $SHA2-$PATH2, [...], are related". Then there would be a "git list-related" command with a "--mismatch" option which would list paths for which $SHA1 doesn't correspond to $PATH1 or $SHA2 doesn't correspond to $PATH2, etc. Some clever updating of related-status during commit/ clone/pull/etc could store information in the index about whether or not any given file is up-to-date with respect to its co-related files.

For translations, when the English version of a document is updated it will automatically result in a "mismatch", allowing translators to do a simple git-diff and see what happened. Likewise, if the Japanese document is updated without changing the relationship then it might mean that somebody should see what changed and update the English version as well. If you determine that the change was irrelevant for the other language (spelling/grammar fixes, etc), then you just update the relationship and commit that change.

It would probably be pretty trivial to implement a prototype using a '.gitrelated' file in the root of the git tree, although better integration with the index would really speed handling with lots of related files; instead of linear searching just iterate over the prepared-during-checkout "out-of-date" list.

Cheers, Kyle Moffett