On Jun 11, 2007, at 13:38:10, Tony Luck wrote:
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
-
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
