Minor edits to Chapter 3

[johnnymugs]

I'm about a third through editing this chapter but I figured I'd put this PR out there. I'll keep adding to this branch but feel free to merge in whatever you think is appropriate.

[johnnymugs]

pssst @markburns mind if I pull this in? I'm not going to have time to work on this for a couple days.

[markburns]

Sure

[ocha-]

I think it should not be merged, we need some discussions.

[ocha-]

I think the chapter 03 of the original svn repository has especially good quality, we should preserve the original sentences as much as possible. Some parts became not accurate as a translation because of this commit. I'm sorry for being late to check this...

[markburns]

@ocha- you spoke a little too late in this case. But what exactly is the issue with the pull request? Perhaps I scanned too briefly but it looked OK. Can you be more specific?

[markburns]

Sorry just got your reply at the same time

[markburns]

OK, so can you give examples? As far as I can see this is just giving a more natural phrasing

[ocha-]

I have not read through it but I'll point out one by one.

What I know the most is how much unnatural the original translation. is it unacceptable?

This is the beginning of the original translation.

st_table has already been mentioned as a method table and instance table. In this chapter let us look at the detailed mechanism of the st_table.

This is the sentences of this commit.

We've already examined st_table as a method table and an instance table. In this chapter let's look at the inner workings of st_table.

actually, the accurate translation for this is probably "appeared" rather than "been mentioned" and not "examined". but "been mentioned" is close. And does "the detailed mechanism" have a problem? The original text is "詳しい作り".

I hope sentences are overwritten only when it is really necessary or preferable.

[ocha-]

It means "a linked list", but "a list of the following data structure" is close to the expression that the author used. Maybe it was written as "a list of the following structs". Cutting the used words out is not a good idea.

[ocha-]

It seems most of lines are changed in order to change the number of characters per line. But I think we need to discuss about its necessity. It makes hard to figure out which sentence is actually modified.

[markburns]

@ocha- I greatly value your input to this project and I wish to take on board your concerns about tweaking something beyond it's original meaning until it is no longer correct. There also needs to be a balance. There is a balance in expressing something well, with risking expressing it incorrectly. I'm certain that Aoki-san's Japanese is impeccable native level Japanese. In order to accurately reflect his abilities, I think it is important that a translation is as close as possible to a native level of communication, otherwise it makes the phrasing sound at times awkward and child-like. If you are really suggesting that the original is awkwardly phrased or sounds foreign, or childish, then I would certainly want to consider reflecting that tone. However, I very much doubt that you are saying Aoki-san's Japanese sounds imperfect. Staying close to original phrasing is very difficult as you know the two languages are so vastly different. I think it's also important that you can entrust a certain amount of making something sound of a high quality to a native speaker. Doing any less could seem disrespectful in both directions, I.e. suggesting that perfect English is not required or superfluous is insulting to the English speaking world. Suggesting that the original Japanese does not need be conveyed in anything less than perfect English is also insulting to the original Japanese. I think we can learn to cooperate and entrust each other's judgement in our native languages and find a balance. What I think there could be a significant danger of, which I'm sure is your main concern, is that in changing phrasing slightly in occasional places, it is harder to follow and see that it does closely match the original. I'm very conscious of this, and do not wish to alter the meaning. To take your example on the linked list. I had to double then triple read it, then glance at the Japanese too to make sure it didn't look to be altering the meaning. I also am entrusting a certain amount to @johnnymugs ability, and would also entrust that future sets of eyes will be trying to pick up on any translation errors that occur. With this in mind I've been wondering about having something like Literate coffeescript documentation style for comparing translations side by side. http://coffeescript.org/documentation/docs/grammar.html

Minor mistakes may be made of that sort, but I don't think any have been in this case. As for "a list of the following data structure" Actually sounds like what will follow is multiple different data structures, but that 'data structures' has forgotten to be pluralised. Either way, it is awkward phrasing and confusing for the reader to see a single data structure, and then realise that it is a linked list afterwards.

Actually though I do agree about whitespace changes and translation changes. I think that fitting the translations within 80 characters makes reviewing much easier. However, only if they are done in separate commits, so that actual translation commits can be reviewed separately.

[ocha-]

I come to feel like some wrong parts are results of trying to convert tiny mistakes in translation to natural expressions.

-key is limited to positive integers, then if the key is divided by 64 then
-the remainder will always fall between 0 and 63. This method of calculation
-can become function `f`.

This is written as the author wrote. Maybe "this method of calculation" should be modified a little. It is probably "this calculation formula" or something.

+same key always produces the same `i`. For example, if we assume that the key
+is limited to positive integers, we can make the function `f` by dividing the
+key by 64. The remainder will always fall between 0 and 63.

This becomes different from the original text.

[markburns]

@ocha- I'm not sure I understand the mistake. It reads like a re-wording to me, but maybe your knowledge of the text is better than mine. Could you possibly explain in Japanese the two meanings you are understanding them to mean? I think we may have crossed-wires.

[ocha-]

I think "we can make the function f by dividing ..." is different from "the calculating expression of dividing ... can be the function f".

Maybe it sounds a little less possible than "can be" in the original text.

[markburns]

No I don't think it sounds any less possible.

In the sentence

"We can X by doing Y"  

The stress is not on the 'can'. The stress is on the X and the Y. Y is a method of doing X.

https://www.google.co.uk/search?q=we+can+make+X+by+Y&oq=we+can+make+X+by+Y&aqs=chrome.0.69i57j69i62l3.4961j0&sourceid=chrome&ie=UTF-8#bav=on.2,or.r_cp.r_qf.&ei=PhYMUprAEI_30gWQ5YCIAg&fp=400f79702f4fb7ab&q=%22we+can+make+*+by+doing+*%22&sa=N&start=10

I'm not an English teacher so I don't know what this pattern is, and I can't explain it well, but it just sounds like it is referring to the way in which the function f is made i.e. by dividing the key by 64. There is no emphasis on the possibility of it happening other than a reference to its occurrence.

More like:

X can happen, so I'm going to talk about X happening, one way in which X can happen is by doing Y

[ocha-]

The original text means "なりうる" of "だからこの計算式は関数 f になりうる".

[ocha-]

It is not "the way in which the function f is made", it says "This calculating formula has a possibility of being f". So f is used to divide the key by 64 in this case.

[ocha-]

I prefer the translation is "linked list" when it is written "リンクリスト", "list" when it is written "リスト". You may think it's too word-to-word, but since the author explains a lot of complicated things, preserving the words can be helpful for readers to understand and safer in order not to lose the original meaning.

[ocha-]

I agree with 80 characters, but as you said, it's better to be a different commit and before the modifications.

Learning what is awkward or seeing rephrases is enjoyable for me, I'll point out when a rephrase lose its original meaning or based on a translating error. We can cooperate to make the accurate translation which is not awkward English.

[johnnymugs]

@ocha- I'm happy to work with you on writing accurate but clear English ;) Maybe you'd like to pair sometime? My Japanese could use some work.

About 80 chars: I didn't realize that I'd introduced these changes with these commits. I thought that 80 chars was already the limit, so I set that as my word wrap limit. I'll be more careful about separating formatting and clarity edits in the future.

[ocha-]

@johnnymugs What is the meaning of 'pair' this case ??

I thought you modified so much but it was not. I'm sorry for that. Now I can understand why you rephrased each part. If you don't mind, I'll update some of them later for accuracy and commit it to this branch, and hope it will be reviewed again.

[markburns]

@ocha- this is great. This is much more useful feedback and it makes your concerns much clearer. I appreciate your conscientiousness in combing through and explaining the issues. This pull request is already getting a little long, perhaps if you edit some more, a new pull request will be easier to follow. Maybe just link to this one at the top?

[johnnymugs]

@ocha- I mean "pair" in the "pair programming" sense. If you'd like, we can do some editing together over Skype sometime. It will help me learn to stay closer to the nuances of the original Japanese, and I can help you write English with a little more clarity. Just get in touch with me privately if you're interested!

[ocha-]

@johnnymugs I'm wondering where is the right place to push my change to. Can I just push it to master so that it can be naturally reviewed? Is it inconvenient for you to continue to work on this branch? Or, are you planning to create a new branch?

[johnnymugs]

I'll create a new branch for new work. Let's consider this branch finished. Either push to master or create your own branch and pull request for review. Whichever you think is best.

On Fri, Aug 16, 2013 at 5:14 PM, ocha- notifications@github.com wrote:

@johnnymugs https://github.com/johnnymugs I'm wondering where is the right place to push my change to. Can I just push it to master so that it can be naturally reviewed? Is it inconvenient for you to continue to work on this branch? Or, are you planning to create a new branch?

— Reply to this email directly or view it on GitHubhttps://github.com/ruby-hacking-guide/ruby-hacking-guide.github.com/pull/12#issuecomment-22794355 .

[ocha-]

OK, I just pushed it to master because the comments of the commit can also be used to discuss. You can edit it again for natural expressions as you like.

My opinion is: Basically, even If a line has a little more than 80 characters, I think we should not edit it just to fit within 80 characters in order to make how much we've edited the file clear for the original translator. And even if a line becomes less than or a little more than 80 characters as a result of editing, not editing the following lines is better as we can easily see where is modified.