五千年(敝帚自珍)

主题:【求助】翻译出版一本书,求译者 -- 邓侃

共:💬25 🌺11
全看树展主题 · 分页首页 上页
/ 2
下页 末页
家园 【求助】翻译出版一本书,求译者

人民邮电出版社,想找人翻译一本书,

Next Generation Wireless Application

书比较长,590页,所以最好几个人分工合作。

有意者,请给我发个短信。

谢谢。

关键词(Tags): #翻译#出版
家园 附议

有个小算盘。

这本书的内容或许比较有趣,是否可以这样,谁担当翻译,不妨把翻译的内容先贴到河里来,

1. 让河虾们先过过瘾。

2. 发动河虾检查一下内容是否正确,翻译是否贴切。

大家意见如何?

附议
家园 这么干,人邮出版社能干么?

昨天抱着娃打字,邮打成油了

家园 邮电出版社的提议

邮电出版社自己提议的。

我看大家闲着也是闲着,与其相互掐,不如干点正事儿。

每个人翻译一章,甚至几节,河里交流一下。纠错,并统一翻译的用词什么的。

然后邮电出版社负责出版,在序言里说明,这不仅是几个译者的作品,而且得到了西西河广大河蟹河虾的帮助。

于河,于译者,于出版社,于中国,都是好事儿,共赢的局面。

家园 出版社同意就好

这是个好办法

附议
家园 可以放出占全书1/6的样子前半部分非重点内容

做成可下载版本,就当宣传,吸引一部分潜在读者,全放出来不适合,尤其关键核心几章,这个点子不错,有点西西译言版的感觉,不过人邮怎么总进这么大厚部头

这片偶不熟,嘿嘿,不过友情顶。

家园 内容不是非常技术

我刚刚瞄了一眼,内容不是很技术,而是谈产品定义,市场营销之类。

家园 O'Reilly 和 Manning 就是这么做的

O'Reilly 和 Manning 出书前,会邀请活跃的读者和相关专业人士参与校对。这样讨论几轮以后,质量就很扎实。

早年干过一次,预先得到有关章节看了看。

但是也有义务,想抢先看书可以,但是要有回馈。否则,下次就不好意思了。

我看,我们可以搞个私版。全部章节,在私版里讨论。

公版放几个样章,吊吊大家胃口,随便做点宣传。

家园 【求助】
关键词(Tags): #几点说明
家园 呵呵
关键词(Tags): #翻译
家园 要不先放几小节上来看下难度如何?
家园 请问这是不是这个TOPIC下很好的一本入门书?

正想学习这方面的东西呢。

Paul Golding在业界得到的评价如何呢?

家园 【求助】关于翻译的几点说明

首先非常感谢大家。感谢每一个回复的人。

现在这本书有这样的情况:时间要求比较紧,希望最好能在10月底就翻译完,最晚不要超过11月10号。所以,希望能找到在这段时间里比较空闲的译者。希望多找几个译者,每个译者选取自己最有把握的部分,这样来分配全书。

还有,通常情况下对于还没有译著的译者,我们都是要求试译的。现在由于时间比较紧迫,希望参加翻译的朋友,如果没有译著的话,最好能把自己翻译过的文章发给我们看一下,有那么几段就可以。

另外,我们的封面上上的译者,一般来说不宜超过三个,个别情况下也可以多一些,但如果太多了封面设计上就不好看了,所以封面署名可能就写某某某 某某某 某某某等译,其余的朋友,可能要放在译者序里分别交代一下,都是谁,翻译了哪些内容。总之,每一个参加翻译的朋友,他的劳动一定会在书中得到体现的。

暂时说这么多。谢谢大家!!

关键词(Tags): #翻译#说明
家园 我的翻译在这里

请注意这是发表在网络上面的,而且是翻译论文,所以文字比较随意,还有自己的发挥(没办法,学校里面seminar习惯了,读论文一定要评论的)

翻译:Google大表(BigTable)

大表(Bigtable):结构化数据的分布存储系统

http://labs.google.com/papers/bigtable-osdi06.pdf

{中是译者评论,程序除外}

{本文的翻译可能有不准确的地方,详细资料请参考原文.}

摘要

bigtable是设计来分布存储大规模结构化数据的,从设计上它可以扩展到上2^50字节,分布存储在几千个普通服务器上.Google的很多项目使用BT来存储数据,包括网页查询,google earth和google金融.这些应用程序对BT的要求各不相同:数据大小(从URL到网页到卫星图象)不同,反应速度不同(从后端的大批处理到实时数据服务).对于不同的要求,BT都成功的提供了灵活高效的服务.在本文中,我们将描述BT的数据模型.这个数据模型让用户动态的控制数据的分布和结构.我们还将描述BT的设计和实现.

1.介绍

在过去两年半里,我们设计,实现并部署了BT.BT是用来分布存储和管理结构化数据的.BT的设计使它能够管理2^50 bytes(petabytes)数据,并可以部署到上千台机器上.BT完成了以下目标:应用广泛,可扩展,高性能和高可用性(high availability). 包括google analytics, google finance, orkut, personalized search, writely和google earth在内的60多个项目都使用BT.这些应用对BT的要求各不相同,有的需要高吞吐量的批处理,有的需要快速反应给用户数据.它们使用的BT集群也各不相同,有的只有几台机器,有的有上千台,能够存储2^40字节(terabytes)数据.

BT在很多地方和数据库很类似:它使用了很多数据库的实现策略.并行数据库[14]和内存数据库[13]有可扩展性和高性能,但是BT的界面不同.BT不支持完全的关系数据模型;而是为客户提供了简单的数据模型,让客户来动态控制数据的分布和格式{就是只存储字串,格式由客户来解释},并允许客户推断底层存储数据的局部性{以提高访问速度}.数据下标是行和列的名字,数据本身可以是任何字串.BT的数据是字串,没有解释{类型等}.客户会在把各种结构或者半结构化的数据串行化{比如说日期串}到数据中.通过仔细选择数据表示,客户可以控制数据的局部化.最后,可以使用BT模式来控制数据是放在内存里还是在硬盘上.{就是说用模式,你可以把数据放在离应用最近的地方.毕竟程序在一个时间只用到一块数据.在体系结构里,就是:locality, locality, locality}

第二节描述数据模型细节.第三节关于客户API概述.第四节简介BT依赖的google框架.第五节描述BT的实现关键部分.第6节叙述提高BT性能的一些调整.第7节提供BT性能的数据.在第8节,我们提供BT的几个使用例子,第9节是经验教训.在第10节,我们列出相关研究.最后是我们的结论.

2.数据模型

BT是一个稀疏的,长期存储的{存在硬盘上},多维度的,排序的映射表.这张表的索引是行关键字,列关键字和时间戳.每个值是一个不解释的字符数组.{数据都是字符串,没类型,客户要解释就自力更生吧}.

(row:string, column:string,time:int64)->string {能编程序的都能读懂,不翻译了}

家园 谢谢回复

我现在要去顺义参加一周的国际通信展,22号结束。这段时间恐怕没时间上网。等我回来跟您交流。

我的联系方式:

[email protected] (MSN)

Tel:13671179091

全看树展主题 · 分页首页 上页
/ 2
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河