1 files changed, 147 insertions, 0 deletions
diff --git a/tde-i18n-zh_TW/docs/kdebase/faq/questions.docbook b/tde-i18n-zh_TW/docs/kdebase/faq/questions.docbook
new file mode 100644
index 00000000000..8c3af4e46a6
--- /dev/null
+++ b/tde-i18n-zh_TW/docs/kdebase/faq/questions.docbook
@@ -0,0 +1,147 @@
+
+<chapter id="questions">
+
+<title
+>詢問問題</title>
+
+<para
+>您是否問了個問題，然後有人告訴您，您必須講清楚一點，然後有人叫您來看這份文件？為了要得到清楚而適當的答案，您的問題也必須清楚而適當，這樣其他人才能夠瞭解您的問題，進而提供您解答。如果您詢問問題的方法不當，被認為是粗魯的，不禮貌的，懶惰的或是講得不清不楚，則您的問題可能就會被刻意忽略。</para>
+
+<qandaset>
+<qandaentry>
+
+<question
+><para
+>我在詢問之前應該先做什麼？</para
+></question>
+
+<answer
+><para
+>先閱讀應用程式的文件與 &FAQ;。&kde; 有很多的文件，包括在輔助中心，還有在網路上。這些文件是由很多人花了很多的功夫建立起來的，而且通常都能涵蓋到您的問題。要開啟一般的 &kde; 使用者指南，您可以在 &konqueror; 的位址列中輸入 <userinput
+><command
+>help:/userguide</command
+></userinput
+>。</para>
+
+<para
+>搜尋網頁：通常用特定的錯誤訊息到 Google 上或是郵件論壇的檔案中搜尋，都可以找得到解答。</para>
+
+<para
+>試試看吧！對您不確定的項目，看看所有應用程式的選項，讀一讀「這是什麼？」的說明，還有工具提示。如果您真的不確定某個選項是在做什麼的，先把資料存起來，然後試試看！只要您有點概念，通常不會因為按個按鈕就把一切都毀了。</para>
+
+<para
+>除此之外，不要太偷懶。如果您在詢問時可以先提出您對此問題所做的研究與搜尋的資料，那麼其他人會認為您是值得幫忙的人。盡量先找相關問題的資料，這樣能節省其他協助者的時間。</para
+> </answer>
+</qandaentry>
+
+<qandaentry>
+<question
+><para
+>我應該到哪裡去問問題？</para
+></question>
+
+<answer
+><para
+>通常最好的地方是在 <acronym
+>IRC</acronym
+> 的頻道上，還有郵件論壇中。不要在開發者的頻道跟郵件論壇中詢問一些關於使用 &kde; 的簡單問題。那些地方是在討論技術方面的問題的。您可以到 irc.freenode.net 中的 #kde 頻道，或是 &kde; 郵件論壇中詢問。</para
+></answer
+> </qandaentry>
+
+<qandaentry>
+<question
+><para
+>我該怎麼詢問？</para
+></question>
+
+<answer
+><para
+>盡可能提供足夠的資訊來描述您的問題，還有保持客氣與禮貌。</para>
+
+<para
+>問題：&kde; 真是糟糕，跑得有夠慢</para>
+
+<para
+>這樣問問題您是得不到任何有用的答案的。因為它沒有任何有用的資訊來找出問題，而且以攻擊該軟體的方式來詢問。</para>
+
+<para
+>問題：我在 Slackware &Linux; 上，用編譯源碼的方式把 &kde; 3.2.3 更新到 3.3.2，不過好像變得很慢─有些應用程式得花廿秒才會跑起來。我用的是前一版本的使用者設定，也試過用新的使用者登入。我在郵件論壇或 Google 上找不到任何跟我的問題有關的資訊。有人能給我一點指引與方向，告訴我要怎麼辦嗎？</para>
+
+<para
+>這樣問問題就很有禮貌，盡可能包含了足夠的資訊，同時也告訴其他人您有試著去找過答案。</para>
+
+<para
+>還有一點很重要：遇到問題時，不要自動假設都是 &kde; 的錯誤。不然若是最後發現是您自己的問題而非 &kde; 的錯誤，可能會讓別人很不爽。</para>
+
+<para
+>拼字盡量正確，避免用不明確的字眼。在寫下問題前後要再確認是否已將自己的問題想清楚了。&kde; 是個很大的專案，很多使用者與開發者都不是說英文的。如果您使用了不是很標準的英語，有時會造成誤解。在 IRC 頻道或郵件論壇上要使用正確的語言─否則其它人可能也看不懂您在說什麼。</para>
+
+<para
+>盡量包含所有相關的資訊，即使您不確定是否跟問題有關。您是否更新其它的軟體或硬體？是否換過系統函式庫或新的核心？這些問題都有可能影響到 &kde; 的運作。即使您看不出其中關聯，不過也許有人會知道其中的關聯所在。</para>
+
+<para
+>不要改寫錯誤訊息，盡量完整地貼上去。如果不只一兩行，不要直接貼到 <acronym
+>IRC</acronym
+> 上面去。您可以用貼上服務如 <ulink url="http://www.rafb.net/paste/"
+> http://www.rafb.net/paste</ulink
+>。如果要用手打字，要確定您輸入的跟原來的錯誤訊息 100% 一樣。如果您提供了錯誤的訊息，其它人就不容易協助您了。 </para>
+
+<para
+>將您解決方法貢獻出來。若是其他人提供您解決問題的方向，或是您自己找出了解決方法，請回報給大家，讓提供給您意見的人知道這個問題的解決方法是對的，同時讓以後的人可以搜尋郵件論壇並找到解決方法。</para
+> </answer>
+</qandaentry>
+
+<qandaentry>
+<question
+><para
+>如果別人告訴我去別的地方看看，我該怎麼辦？</para
+></question>
+
+<answer
+><para
+>如果有人告訴您<quote
+>Google 大神知道！</quote
+>或是<quote
+>上 Google 去找找</quote
+>，則有可能表示您沒有依照上面的提示來詢問。您沒有好好先做功課，問題的解答可能其實是很容易找到的。如果別人告訴您去找 <acronym
+>FAQ</acronym
+> 或使用者手冊，不要回答<quote
+>我不想去讀那些，我要你告訴我！</quote
+>這是很糟糕的態度。如果您自己不想去閱讀文件，其它人又為什麼要花時間去幫您的忙呢？如果其他人告訴您去 Google 查一查，那麼就去查查吧。</para
+> </answer>
+</qandaentry
+> </qandaset>
+
+<para
+>最重要的就是保持禮貌。&kde; 使用者與開發者通常都是志願性的，而且行程都很滿。保持禮貌，經常說請與謝謝，並讓協助您的人知道您的感謝。 </para>
+
+<para
+>講了這麼多，問個問題看起來好麻煩是嗎？如果您認為其他人欠您一個答案或是支援，您大可以付費給提供您 &UNIX; 上的 &kde; 支援的商業公司。如果您不想付費，那麼，就付出您的禮貌與感謝給那些免費協助您的人吧。</para>
+
+
+<para
+>如果您覺得您提出的問題應該被列入 &kde; &FAQ;，您可以提交給 &kde; &FAQ; 維護者，電子郵件地址是 <email
+>faq@kde.org</email
+>。</para>
+
+
+
+</chapter>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: xml
+sgml-omittag:nil
+sgml-shorttag:nil
+sgml-namecase-general:nil
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:0
+sgml-indent-data:true
+sgml-parent-document:("index.docbook" "book" "chapter")
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->