DjangoのURL namespacesのところを和訳した

https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces
何回流し読みしてもよく分からないので、和訳した。

---

URL namespaces
URL ネームスペース

Namespaced URLs are specified using the : operator. For example, the main index page of the admin application is referenced using admin:index. This indicates a namespace of admin, and a named URL of index.

ネームスペースに関連付けられたURLは、：演算子を使い表現されます。例えば、adminアプリケーションのメイントップページは admin:index で参照されます。これはadminネームスペースのindexと名付けられたURLを示します。

Namespaces can also be nested. The named URL foo:bar:whiz would look for a pattern named whiz in the namespace bar that is itself defined within the top-level namespace foo.

ネームスペースは入れ子にできます。 foo:bar:whiz というURL名は、それ自身がfooというトップレベルのネームスペース内に定義されているbarというネームスペース内のwhizと名付けられたパターンを指します。

When given a namespaced URL (e.g. myapp:index) to resolve, Django splits the fully qualified name into parts, and then tries the following lookup:

与えられたネームスペースに関連付けられたURL（例…myapp:index）を解読する場合、Djangoは完全記述された名称を要素単位に分割し、以下の検索を試みます。

1. First, Django looks for a matching application namespace (in this example, myapp). This will yield a list of instances of that application.

まず、Djangoは一致するアプリケーションネームスペースを探します（この例の場合myapp）。該当するインスタンスのリストが抽出されます。

2. If there is a current application defined, Django finds and returns the URL resolver for that instance. The current application can be specified as an attribute on the template context - applications that expect to have multiple deployments should set the current_app attribute on any Context or RequestContext that is used to render a template.

もしカレントアプリケーションが定義されていれば、Djangoはそのインスタンスに対するURLリゾルバを探して返します。カレントアプリケーションはテンプレートコンテキストの属性として特定されます。複数デプロイされる事が想定されているアプリケーションは、テンプレートをレンダリングする時に使われるContextおよびRequestContextにcurrent_app属性がセットされるべきです。

3. The current application can also be specified manually as an argument to the reverse() function.

カレントアプリケーションはreverse()関数の引数として明示的に指定も出来ます。

4. If there is no current application. Django looks for a default application instance. The default application instance is the instance that has an instance namespace matching the application namespace (in this example, an instance of the myapp called myapp).

もしカレントアプリケーションが指定されない場合、Djangoはデフォルトアプリケーションインスタンスを探します。デフォルトアプリケーションインスタンスとは、アプリケーションネームスペースと一致するインスタンスネームスペースを持つインスタンスです（この例の場合myapp、と呼ばれているmyappのインスタンス（訳注：namespace="myapp",app_name="myapp"という事ですかね））

5. If there is no default application instance, Django will pick the last deployed instance of the application, whatever its instance name may be.

もしデフォルトアプリケーションインスタンスが無い場合、Djangoは最後にデプロイされたアプリケーションのインスタンスを取り上げます。そのインスタンス名（訳注：インスタンスネームスペース名？）が何であれ。

If the provided namespace doesn't match an application namespace in step 1, Django will attempt a direct lookup of the namespace as an instance namespace.

もし与えられたネームスペースがステップ１のアプリケーションネームスペースにマッチしない場合、Djangoはインスタンスネームスペースであるとして直接検索を試みます。

If there are nested namespaces, these steps are repeated for each part of the namespace until only the view name is unresolved. The view name will then be resolved into a URL in the namespace that has been found.

もしネームスペースが入れ子になっている場合、ビュー名が解決されるまでネームスペースの各要素ごとにこれらのステップが繰り返されます。ビュー名は見つかったネームスペース内のURLとして解決されます（訳注：ここ適当。ここに限らないけど）。

To show this resolution strategy in action, consider an example of two instances of myapp: one called foo, and one called bar. myapp has a main index page with a URL named index. Using this setup, the following lookups are possible:

この解決手順を順を追ってお見せするため、例として２つのmyappのインスタンスを考えます。片方はfoo、もう片方はbarです。myappのトップページのURLにはindexという名前がついています。この設定に基づき、以下の検索が可能です。

・If one of the instances is current - say, if we were rendering a utility page in the instance bar - myapp:index will resolve to the index page of the instance bar.

もしどちらかのインスタンスがカレントならば…すなわち、barインスタンスのユーティリティページをレンダリングしていた場合、myapp:indexはbarインスタンスのトップページとして解決されます。

・If there is no current instance - say, if we were rendering a page somewhere else on the site - myapp:index will resolve to the last registered instance of myapp. Since there is no default instance, the last instance of myapp that is registered will be used. This could be foo or bar, depending on the order they are introduced into the urlpatterns of the project.

もしカレントインスタンスが無い場合…すなわちサイト内の何か別なページをレンダリングしていた場合…myapp:indexはmyappのうち最後に登録されたインスタンスに対して解決されます。デフォルトインスタンスが無いので、登録されたmyappの内最後のインスタンスが使われます。fooでもbarでも、プロジェクトのurlpatternsに登録された順に依存します。

・foo:index will always resolve to the index page of the instance foo.

foo:index は常にfooインスタンスのトップページとして解決されます。

If there was also a default instance - i.e., an instance named myapp - the following would happen:

もしデフォルトインスタンスもあった（インスタンス名がmyappとなっていた）場合、以下のようになります。

・If one of the instances is current - say, if we were rendering a utility page in the instance bar - myapp:index will resolve to the index page of the instance bar.

もしどちらかのインスタンスがカレントならば…すなわち、barインスタンスのユーティリティページをレンダリングしていた場合、myapp:indexはbarインスタンスのトップページとして解決されます。

・If there is no current instance - say, if we were rendering a page somewhere else on the site - myapp:index will resolve to the index page of the default instance.

もしカレントインスタンスが無い場合…すなわちサイト内の何か別なページをレンダリングしていた場合…myapp:indexは、デフォルトインスタンスのトップページとして解決されます。

・foo:index will again resolve to the index page of the instance foo.

foo:index はこの場合もfooインスタンスのトップページとして解決されます。

---

和訳したけど正直なところイマイチピンとこない。
とりあえずインスタンスネームスペースの方がアプリケーションネームスペースより粒度が小さい…という解釈でいいのだろうか。