Re: [RFD] Documentation/HOWTO translated into Japanese

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux