translation updates.

whosaysni · whosaysni · commit 278820628ae5 · 2008-09-17T12:31:12.000Z
diff --git a/howto/custom-template-tags.txt b/howto/custom-template-tags.txt
@@ -6,35 +6,33 @@
 
 :revision-up-to: 8961 (1.0)
 
-.. TBD
-
-
-Introduction
+はじめに
 ============
 
-Django's template system comes a wide variety of :ref:`built-in tags and filters
-<ref-templates-builtins>` designed to address the presentation logic needs of
-your application. Nevertheless, you may find yourself needing functionality that
-is not covered by the core set of template primitives. You can extend the
-template engine by defining custom tags and filters using Python, and then make
-them available to your templates using the ``{% load %}`` tag.
-
-Code layout
------------
-
-Custom template tags and filters must live inside a Django app. If they relate
-to an existing app it makes sense to bundle them there; otherwise, you should
-create a new app to hold them.
-
-The app should contain a ``templatetags`` directory, at the same level as
-``models.py``, ``views.py``, etc. If this doesn't already exist, create it -
-don't forget the ``__init__.py`` file to ensure the directory is treated as a
-Python package.
-
-Your custom tags and filters will live in a module inside the ``templatetags``
-directory. The name of the module file is the name you'll use to load the tags
-later, so be careful to pick a name that won't clash with custom tags and
-filters in another app.
+Django テンプレートシステムには、広範な :ref:`組み込みタグとフィルタ
+<ref-templates-builtins>` が付属していて、アプリケーションのプレゼンテーショ
+ンロジックに纏わる問題を解決できます。とはいえ、コアのテンプレートタグ
+プリミティブだけでは、要求を満たせない場合もあります。そういう場合のために、
+テンプレートエンジンを拡張できます。Python で自作のタグやフィルタを書き、
+テンプレート上で ``{% load %}`` タグを使って使えるのです。
+
+コードの配置
+-------------
+
+カスタムのテンプレートタグやフィルタは Django のアプリケーション内に置きま
+す。既存のアプリケーションに関連があるのなら、そのアプリケーションにバンド
+ルすればよいでしょう。そうでなければ、コードを入れておくための新たなアプリ
+ケーションを作成します。
+
+アプリケーション内には、 ``templatetags`` ディレクトリを置かねばなりません。
+このディレクトリは、 ``models.py`` や ``views.py`` などと同じ階層に置きます。
+``templatetags`` がなければ、作成してください。ディレクトリ内に
+``__init__.py`` を置いて、パッケージ化するのを忘れないでください。
+
+カスタムのタグやフィルタは、 ``templatetags`` ディレクトリの下に置きます。
+モジュールファイルの名前は、あとでタグをロードするときに使う名前にします。
+ですから、他のアプリケーションのカスタムタグやフィルタと名前が衝突しないよ
+う、よく注意して名前を決めましょう。
 
 ``poll_extras.py`` という名前のファイルに自作のタグ／フィルタを入れているの
 なら、アプリケーションのレイアウトは以下のようになるでしょう::
diff --git a/howto/deployment/fastcgi.txt b/howto/deployment/fastcgi.txt
@@ -243,11 +243,8 @@ URL を ``mysite.fcgi`` (または ``FastCGIExternalServer`` ディレクティ
 
 .. _mod_rewrite: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
 
-.. TBD
-
-Django will automatically use the pre-rewrite version of the URL when
-constructing URLs with the ``{% url %}`` template tag (and similar methods).
-
+Django は、 ``{% url %}`` テンプレートタグ (や、同様のメソッド) で URL を構
+築する際、自動的にリライト前の URL を使います。
 
 .. _lighttpd setup:
 
diff --git a/howto/error-reporting.txt b/howto/error-reporting.txt
@@ -5,17 +5,14 @@
 
 :revision-up-to: 8961 (1.0)
 
-.. TBD
+サイトを公開しているときには、 :setting:`DEBUG` を常に切りましょう。
+:setting:`DEBUG` を切ると、サーバの動作は軽くなり、エラーページを介して悪意
+あるユーザにアプリケーションの詳細が漏れてしまうのを防げます。
 
-When you're running a public site you should always turn off the
-:setting:`DEBUG` setting. That will make your server run much faster, and will
-also prevent malicious users from seeing details of your application that can be
-revealed by the error pages.
-
-However, running with :setting:`DEBUG` set to ``False`` means you'll never see
-errors generated by your site -- everyone will just see your public error pages.
-You need to keep track of errors that occur in deployed sites, so Django can be
-configured to email you details of those errors.
+その代わり、 :setting:`DEBUG` を ``False`` にすると、サイト上で発生したエラー
+を一切表示できません。ユーザはみな、公開用に作られたエラーページを見るだけ
+です。実運用のサイトで発生したエラーを追跡したい場合のために、 Django はエ
+ラーの詳細をメールで送信するように設定できます。
 
 .. _Server errors:
 
@@ -64,11 +61,9 @@ Django は、サイトのリンクが切れている (404 "page not found") 時
 この機能を無効にしたければ、 :setting:`SEND_BROKEN_LINK_EMAILS` を
 ``False`` に設定してください。
 
-.. TBD
-
 .. seealso::
 
-    You can also set up custom error reporting by writing a custom piece of
-    :ref:`exception middleware <exception-middleware>`. If you do write custom
-    error handling, it's a good idea to emulate Django's built-in error handling
-    and only report/log errors if :setting:`DEBUG` is ``False``.
+    自作の :ref:`例外ミドルウェア <exception-middleware>` を書けば、エラー
+    レポートを自作できます。エラー処理をカスタマイズしたければ、 Django 組
+    み込みのエラー処理をエミュレートして、 :setting:`DEBUG` が ``False`` の
+    ときだけ、レポートやログ記録を行うとよいでしょう。
diff --git a/ref/index.txt b/ref/index.txt
@@ -1,12 +1,10 @@
 .. _ref-index:
 
-API Reference
-=============
+API リファレンス
+===================
 
 :revision-up-to: 8961 (1.0)
 
-.. TBD
-
 .. toctree::
    :maxdepth: 1
    
diff --git a/ref/models/querysets.txt b/ref/models/querysets.txt
@@ -9,6 +9,8 @@ QuerySet API リファレンス
 
 .. currentmodule:: django.db.models
 
+.. TBD
+
 This document describes the details of the ``QuerySet`` API. It builds on the
 material presented in the :ref:`model <topics-db-models>` and `database query
 <topics-db-queries>` guides, so you'll probably want to read and understand
diff --git a/ref/settings.txt b/ref/settings.txt
@@ -161,13 +161,13 @@ DATABASE_ENGINE
 クエンドは、 ``'postgresql_psycopg2'``, ``'postgresql'``, ``'mysql'``,
 ``'sqlite3'``, ``'oracle'`` です。
 
-.. TBD
+.. versionchanged:: 1.0
 
-In the Django development version, you can use a database backend that doesn't
-ship with Django by setting ``DATABASE_ENGINE`` to a fully-qualified path (i.e.
-``mypackage.backends.whatever``). Writing a whole new database backend from
-scratch is left as an exercise to the reader; see the other backends for
-examples.
+    Django 1.0 から、 Django に組み込まれていないデータベースバックエンドを
+    組み込むために、 ``DATABASE_ENGINE`` にバックエンドモジュールの完全指定
+    パス (例えば ``mypackage.backends.whatever``) を指定できます。全く新し
+    いデータベースバックエンドの作成は、読者の皆さんに委ねます。他のバック
+    エンドの例を参照してください。
 
 .. setting:: DATABASE_HOST
 
@@ -331,12 +331,11 @@ DEFAULT_CONTENT_TYPE
 DEFAULT_FILE_STORAGE
 --------------------
 
-.. TBD
+デフォルト値: ``django.core.files.storage.FileSystemStorage``
 
-Default: ``django.core.files.storage.FileSystemStorage``
-
-Default file storage class to be used for any file-related operations that don't
-specify a particular storage system. See :ref:`topics-files`.
+特定のストレージシステムに依存せずにファイル関連の操作を行うときに使う、
+デフォルトのファイルストレージクラスです。 :ref:`topics-files` を参照してく
+ださい。
 
 DEFAULT_FROM_EMAIL
 ------------------
@@ -550,12 +549,9 @@ FORCE_SCRIPT_NAME
 
 デフォルト値: ``None``
 
-.. TBD
-
-If not ``None``, this will be used as the value of the ``SCRIPT_NAME``
-environment variable in any HTTP request. This setting can be used to override
-the server-provided value of ``SCRIPT_NAME``, which may be a rewritten version
-of the preferred value or not supplied at all.
+``None`` に指定すると、 HTTMP リクエストの ``SCRIPT_NAME`` 環境変数の代わり
+に指定値を使います。この設定は、サーバが指定する ``SCRIPT_NAME`` の内容を上
+書きしたり、 ``SCRIPT_NAME`` を空にしたりするために使えます。
 
 .. setting:: IGNORABLE_404_ENDS
 
@@ -864,14 +860,6 @@ Django で作られたページに空でないリファラつきで訪問した
 ``IGNORABLE_404_STARTS``, ``IGNORABLE_404_ENDS`` および
 :ref:`howto-error-reporting` も参照してください。
 
-.. TBD
-
-Whether to send an e-mail to the ``MANAGERS`` each time somebody visits a
-Django-powered page that is 404ed with a non-empty referer (i.e., a broken
-link). This is only used if ``CommonMiddleware`` is installed (see
-. See also ``IGNORABLE_404_STARTS``,
-``IGNORABLE_404_ENDS`` and .
-
 .. setting:: SERIALIZATION_MODULES
 
 SERIALIZATION_MODULES
diff --git a/releases/index.txt b/releases/index.txt
@@ -1,7 +1,7 @@
 .. _releases-index:
 
-Release notes
-=============
+リリースノート
+===============
 
 :revision-up-to: 8961 (1.0)
 
diff --git a/topics/cache.txt b/topics/cache.txt
@@ -183,12 +183,10 @@ memcached インスタンスでキャッシュを共有しています::
 
     CACHE_BACKEND = 'locmem:///'
 
-.. TBD
-
-Note that each process will have its own private cache instance, which means no
-cross-process caching is possible. This obviously also means the local memory
-cache isn't particularly memory-efficient, so it's probably not a good choice
-for production environments.
+各サーバプロセスは、個別にキャッシュインスタンスを保持するので、プロセス間
+でキャッシュは共有されません。このことから、明らかに、ローカルメモリキャッ
+シュのメモリ効率は非常に悪いといえます。おそらく実運用環境向きとではないで
+しょう。
 
 .. _Dummy caching (for development):
 
@@ -207,26 +205,26 @@ for production environments.
  
     CACHE_BACKEND = 'dummy:///'
 
-Using a custom cache backend
-----------------------------
+カスタムのキャッシュバックエンドを使う
+-----------------------------------------
 
 .. versionadded:: 1.0
 
-While Django includes support for a number of cache backends out-of-the-box,
-sometimes you will want to use a customised version or your own backend.  To
-use an external cache backend with Django, use a Python import path as the
-scheme portion (the part before the initial colon) of the 
-:setting:`CACHE_BACKEND` URI, like so::
+Django には、すぐに使えるキャッシュバックエンドがいくつもありますが、カスタ
+マイズしたバックエンドや自作のバックエンドを使いたい場合もあるでしょう。
+外部のキャッシュバックエンドを Django と組み合わせたいなら、以下のように、
+Python の import パスを :setting:`CACHE_BACKEND` の URI のスキーム部分 (最
+初のコロンより前の部分) に指定します::
 
     CACHE_BACKEND = 'path.to.backend://'
 
-If you're building your own backend, you can use the standard cache backends
-as reference implementations. You'll find the code in the
-:file:`django/core/cache/backends/` directory of the Django source.
+自作のバックエンドを作成しているなら、リファレンス実装として標準のキャッシュ
+バックエンドを使うとよいでしょう。キャッシュバックエンドは Django のソース
+中の :file:`django/core/cache/backends/` ディレクトリ下にあります。
 
-Note: Without a really compelling reason, like a host that doesn't support the
-them, you should stick to the cache backends included with Django. They've
-been really well-tested and are quite easy to use.
+注意: 運用ホスト上でサポートされていないなど、本当に特別な理由がないかぎり、
+Django 組み込みのキャッシュバックエンドを使った方がよいでしょう。組み込みの
+バックエンドは良くテストされており、とても簡単に扱えます。
 
 .. _CACHE_BACKEND arguments:
 
@@ -287,12 +285,12 @@ In this example, ``timeout`` is ``30`` and ``max_entries`` is ``400``::
         'django.middleware.cache.FetchFromCacheMiddleware',
     )
 
-.. TBD
 .. note::
 
-    No, that's not a typo: the "update" middleware must be first in the list,
-    and the "fetch" middleware must be last. The details are a bit obscure, but
-    see `Order of MIDDLEWARE_CLASSES`_ below if you'd like the full story.
+    そう、ミドルウェアの順番は、これで間違っていません。 "Update" ミドルウェ
+    アがリストの先頭で、 "Fetch" ミドルウェアが末尾です。詳しいからくりは
+    ちょっとややこしいのですが、後述の `MIDDLEWARE_CLASSES の順番`_ で説明
+    しています。
 
 次に，以下の必須の設定を Django 設定ファイルに追加します:
 
@@ -463,11 +461,9 @@ get() には ``default`` 引数を指定できます::
     >>> cache.get('add_key')
     'Initial value'
 
-.. TBD
-
-If you need to know whether ``add()`` stored a value in the cache, you can
-check the return value. It will return ``True`` if the value was stored,
-``False`` otherwise.
+``add()`` によってキャッシュにデータが保存されたどうかを知りたければ、戻り
+値をチェックしてください。戻り値が ``True`` なら、保存されています。そうで
+ないときは ``False`` を返します。
 
 キャッシュを一度しかアクセスしない ``get_many()`` インタフェースもあります．
 ``get_many()`` は指定した全てのキーのうち，キャッシュ内に実在する (そして期
@@ -719,28 +715,26 @@ Django には，アプリケーションのパフォーマンスを最適化す
 MIDDLEWARE_CLASSES の順番
 =========================
 
-.. TBD
+キャッシュ関連のミドルウェアを使う場合、 ``MIDDLEWARE_CLASSES`` 設定中の
+正しい場所に配置することが重要です。というのも、キャッシュミドルウェアは
+キャッシュストレージ上のコンテンツとの差異を検出するために、どのヘッダが変
+更されたかを調べる必要があるからです。ミドルウェアは通常、必要に応じて
+``Vary`` レスポンスヘッダに情報を付加します。
 
-If you use caching middleware, it's important to put each half in the right
-place within the ``MIDDLEWARE_CLASSES`` setting. That's because the cache
-middleware needs to know which headers by which to vary the cache storage.
-Middleware always adds something to the ``Vary`` response header when it can.
-
-``UpdateCacheMiddleware`` runs during the response phase, where middleware is
-run in reverse order, so an item at the top of the list runs *last* during the
-response phase. Thus, you need to make sure that ``UpdateCacheMiddleware``
-appears *before* any other middleware that might add something to the ``Vary``
-header. The following middleware modules do so:
+``UpdateCacheMiddleware`` はレスポンスフェイズに動作します。レスポンスフェ
+イズのミドルウェアは逆順に処理されるので、リストの先頭のミドルウェアは
+*最後* に呼び出されます。従って、 ``UpdateCacheMiddleware`` は、 ``Vary``
+ヘッダに何らかの情報を付加するミドルウェアよりも *手前* に追加せねばなりま
+せん。以下のミドルウェアが、 ``Vary`` ヘッダを操作します:
 
     * ``SessionMiddleware`` は ``Cookie`` を追加します．
     * ``GZipMiddleware`` は ``Accept-Encoding`` を追加します．
     * ``LocaleMiddleware`` は ``Accept-Language`` を追加します．
 
-.. TBD
-
-``FetchFromCacheMiddleware``, on the other hand, runs during the request phase,
-where middleware is applied first-to-last, so an item at the top of the list
-runs *first* during the request phase. The ``FetchFromCacheMiddleware`` also
-needs to run after other middleware updates the ``Vary`` header, so
-``FetchFromCacheMiddleware`` must be *after* any item that does so.
+一方、 ``FetchFromCacheMiddleware`` はリクエストフェイズに動作します。リク
+エストフェイズでは、ミドルウェアは先頭から末尾に向けて処理されるので、
+リストの先頭にあるミドルウェアが *最初* に呼び出されます。
+``FetchFromCacheMiddleware`` もまた、 ``Vary`` ヘッダを操作するミドルウェア
+よりも後に呼び出さねばならないので、 ``FetchFromCacheMiddleware`` は
+*後ろ* に置かねばなりません。
 
diff --git a/topics/db/models.txt b/topics/db/models.txt
diff --git a/topics/forms/formsets.txt b/topics/forms/formsets.txt
diff --git a/topics/forms/index.txt b/topics/forms/index.txt
diff --git a/topics/forms/modelforms.txt b/topics/forms/modelforms.txt
