linux-kernel - Re: [RFD] Documentation/HOWTO translated into Japanese

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <29741172-099F-499B-8A73-A85C6360129D@mac.com>
Date:	Thu, 14 Jun 2007 20:29:09 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Tony Luck <tony.luck@...il.com>
Cc:	Matt Mackall <mpm@...enic.com>, Greg KH <gregkh@...e.de>,
	Matthias Schniedermeyer <ms@...d.de>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Tsugikazu Shibata <tshibata@...jp.nec.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	m-ikeda@...jp.nec.com, git@...r.kernel.org
Subject: Re: [RFD] Documentation/HOWTO translated into Japanese

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/