The Two.

开始翻译这本辞典。会不定期分章节发布。为了有多一点乐趣，每一篇文章都会在开篇放一句常用克林贡常用语。

章节为：

• 绪论
• 1. 克林贡语发音
• 2. 语法大纲 – 简介
• 3. 名词
• 4. 动词
• 5. 其他种类的词汇
• 6. 语法
• 7. 简短克林贡语
• 词典
• 附录
• 补遗

nuqneH

（发音：nook-NEKH）

“你想要什么？”（表示问候）

 

克林贡语（Klingon）是克林贡帝国（Klingon Empire）的官方语言。长期以来，只有一小部分非克林贡人能够掌握足够多的克林贡语知识，与克林贡人进行有意义的交谈。但是最近，联邦科学研究委员会（Federation Scientific Research Council）开始资助一项研究，记录、分析克林贡人的语言和文化。该研究的终极目标是编写一套百科全书和教材。本辞典是这项工作的一项初期成果。

本辞典分为两部分：语法大纲和词典。

语法大纲是克林贡语语法的概要，而非完整介绍。不过，这足以使读者能够将克林贡语单词组织起来了。在语法大纲中给出的许多语法规则，都是由克林贡语语法学家确定的。需要记住的是，即使规则说“通常”和“从不”，当克林贡人说话时，这些规则偶尔也会被打破。这些规则所表示的，换句话说是语法学家们一致同意的“最佳”克林贡语。

由于此项研究尚未完成，本辞典在范围上必然有所局限。确实还有许多克林贡语单词没有在此列举出来。特别是以下三种单词没有收录：科学术语；本地工具、风俗、植物、动物；与食物相关的词汇。与多种科学相关的术语是一项特定研究的课题，最近一份报告正在准备中。克林贡语中的传统工具和长期存在的风俗词语，很难翻译成中文。本地动植物在目前也同样难以理解。这些内容会在即将推出的《克林贡百科全书》中有完整的阐释。食物相关单词的缺失是由于资源受限造成的：我们在招聘对克林贡人饮食习惯感兴趣的员工时，总是遇到问题。在这项研究开展以前，列出含义还不清楚的单词被认为是不合适的。

随着更多信息被收集起来，单词列表毫无疑问地变得越来越长。但是就算在很早的阶段，一些模式就已经显现出来了。比如，没有用作问候的单词，像是中文中的“你好，早安，吃了么”等等。似乎很明显，克林贡语中就是没有这样词和短语。当两个克林贡人碰面的时候（除了军事礼仪要求的举止之外），如果有任何表示介绍性质的话，这种措辞最合适的翻译是“你想要什么？”不像大多数的中文使用者，交谈的时候都要先问候，问问吃没吃、或是彼此的近况，克林贡人倾向于在交谈的时候直奔主题。

虽然克林贡人为自己的语言十分骄傲，经常长篇累牍地论述克林贡语的表现力和美感，但他们还是发现与克林贡帝国国外的沟通时，克林贡语并不实用。于是，像大多数其他政府一样，克林贡政府采用英语作为星系内以及星系间沟通的共通语。通常来说，只有那些上层阶级的克林贡人（包括高级政府官员和军官）才会学习英语。结果，英语在克林贡社会中，增加了两种功用。一，英语被用来作为身份和地位的象征。那些会说英语的克林贡人之间会用英语彼此交谈，以炫耀自己的学识，并且让听者知道他们的地位。二，英语被用在不愿让仆人、士兵、或甚至是普通百姓了解谈话内容的时候。因此，在克林贡飞船上，指挥官会使用克林贡语对船员下达命令，但与其他军官讨论时，会选择使用英语。不过，在非克林贡人面前，一个克林贡军官可能会用说克林贡语来避免其他人了解情况。这种克林贡语的用法非常有效。

克林贡语有许多种方言。在本辞典中只列举了当前克林贡国王使用的一种。从历史上看，无论任何原因，当克林贡国王换位时，新的国王总是说一门不同的方言。结果便是，新的国王使用的方言成为官方方言。那些不使用官方方言的克林贡人，被视为愚蠢或是颠覆分子，并被迫承担那些使用官方方言的克林贡人认为令人讨厌的苦役。大多数克林贡人都能够熟练运用若干种方言。

一些方言与本辞典的方言差别很小。差别都是词汇上的（比如，“前额”一词几乎在各个方言中都不同）或是某些发音上的。不过，也有的方言和目前的官方方言差别很大，以至于这些方言的使用者与现在的克林贡官员沟通起来异常困难。克林贡语的学习者被预先告诫，在试图交谈之前，一定要先弄清克林贡帝国的政治现状。

克林贡语有一种原生态的书写体系（称为 pIqaD ），非常适合各种不同的方言。这种书写系统目前还没有被充分理解，因此，也没有在本辞典中使用。取而代之的，是一套基于克林贡语字母表的转录系统。有一篇文章准备在《克林贡百科全书》中详细介绍 pIqaD 。

在本辞典中的语法大纲部分中，作为标识约定，克林贡语将使用加粗，中文翻译将标以双引号：tlhIngan “克林贡语”

辞典作者希望感谢科学研究委员会为此研究提供资金，还要感谢联邦中介语研究所（Federation Interlanguage Institute）的各位成员对本辞典草稿的批评。辞典作者为错误致歉，并真诚希望这些错误不会造成不幸的误解。

最后，要感谢一位克林贡人提供了所有这些信息，本辞典就是基于这些信息写成的。虽然是联邦的一名囚犯，但他辛苦的工作，使这些知识得以呈现给联邦公民。莫尔茨，我们感谢你。

It’s important to set a right scope and expectation for a plan. So I want to make the new year technical reading plan small and achievable.

“Agile project management with SCRUM”

“Head First Design Patterns”

“Art of computer programming – Volumn 1”

“Agile software development – principles patterns and practices”

“Protect your windows networks”

“Test driven development”

And I’ll start learning a little Japanese to get familiar with JPN IME.

I believe it’s a very common scene that 2 (or unfortunately more) program managers argue in a feature design meeting.

It’s more likely to happen in an early stage of feature design when everyone is not clear about how to implement the functionality. The discussion should be focus on setting the goals, target users, and the scenarios.

According to my experience, the arguements are often initiated by introducing unkown factors of the how: “If we can have Scotty SDK to beam my cup to the tea room… If Scotty SDK is not public to 3rd party, we’ll have to…” But what’s more important is how user’s needs get met in the scenario: “I want to get a cup of tea without going to the tea room in person as I’m on a conf call.” The scenario may go well by asking a Star Trek fan developer to do you a favor.

So the motto can be “No developers in this room” when having a feature discussion on early stage. Focus on how to meet user needs but not how to implement everything.

Of course I mean don’t think like coding the feature on the meeting, but we surely should involve the developers!

Spec is the tool for program managers to communicate with others – developers, test engineers, peer PMs, the remote team located on Mars, etc.

A spec is often started from a “Page-one” stage. On this stage, you’re answering some questions to yourself:

• What’s this feature?
• Why we bother to implement it?
• How to measure that we succefully done it?
• How the users will be using it?

I’m not experienced enough to make it a big topic but I want to share a tip which sometimes makes my spec look better:

When I look at my page-one spec over and over again, I would imagine that the spec is telling a story to a stranger. If the stranger gets the points, the spec is good. If not, the spec fails.

If it doesn’t feel real enough, I would try to explain to some guys not from a same team in the way I spec’ed. If they can understand, the spec works.

So this is my first Spec 101: Page one for strangers.

A very valuable learning from today’s Engineering conference is that when co-designing with your customers, don’t simply ask the stupid question of “what do you want us to design our software?” But observe their footprints of how they’re doing with their current pieces.

The words from the customers may inspire you for further innovation but the footprints are telling the truth where you can address the real issues.

I’d like to start the very first blog post with the mysterious button which bugged me for a while.

I saw this “DHB” button in the elevator of the hotel beside my office.

I was curious and asked my friends around but nobody knows what it means. (We’re in BEIJING and we speak Chinese…)

So I took a picture with my iPhone, and forgot about it later.

1 month ago, I went to the hotel for my wedding again, and the button showed up again. This time I asked the girl behind the reception desk and she told me this button is for emergency.

“OK, so nobody hits it?” I said.

“No.”

I believe nobody hits it but I don’t think it’s for alert.

So I googled it and found out yes it stands for “Door Hold Button”..

Then my points are:

1. In China, people hit the “Open” button to hold the door

2. Chinese people really don’t know what “DHB” means

3. The DHB button is really placed very well among other buttons that it looks neat

4. Nobody hits it

So the lesson learnt is – Don’t put any DHB button in your software.