當本地化Django應用程序makemessages命令簡單地解析所有的TXT，HTML和PY文件併爲它們生成PO文件時，但是在本地化JS文件時，您需要運行djangojs命令。我還沒有深入研究Django源代碼來弄清楚爲什麼這樣做的方式不同。有人可以解釋嗎？爲什麼JavaScript文件應該在Django中進行不同的本地化？
我讀過，在生產環境中，Apache用於提供應用程序文件，而像Nginx這樣的簡單代理用於提供靜態文件，因爲這大大減少了應用程序服務器的負載。在這種情況下，我猜想它是這樣工作的：在呈現模板時，Django檢查請求的語言環境，加載適當的本地化文件並提供模板，但另一方面，作爲靜態媒體的JS不會被Django解析。是這個嗎？
（在與Django的本地化的世界和我的第一次嘗試，我裝得滿滿的問題，很多是誰的答案，我似乎無法找到，因此這個職位。）
感謝
處理不同的原因是docs。
添加翻譯成JavaScript帶來了一些問題：
- JavaScript代碼沒有訪問gettext的實現。
- JavaScript代碼無權訪問.po或.mo文件;他們需要由服務器交付。
- JavaScript的翻譯目錄應儘可能小。
所以基本上，內部的Python翻譯是在服務器上完成的。但是對於JS，服務器提供另一個文件，其中包含用戶語言所需的所有翻譯。翻譯是在用戶身上完成的。正如你所看到的，這是一種完全不同的策略。 Django通過爲JS文件添加類似的接口來幫助，即使它們以完全不同的方式處理。
我想它的工作原理是這樣的：渲染模板時，Django的檢查 請求的區域設置，加載相應的本地化文件和 提供的模板，但JS，另一方面被服務的靜態 媒體不由Django解析。是這個嗎？
在第一部分中，關於處理模板是正確的。處理JS的工作正如我上面解釋的。
請注意，Django JS翻譯機制，不會將JS翻譯視爲靜態文件。它使用Django視圖每次生成JS文件（在第一行中鏈接的文檔中提到的javascript_catalog）。 這是我遇到的問題之一。這些文件不需要在每個請求上生成。有些項目實際上允許您將這些JS翻譯作爲靜態文件進行打包，並使您能夠正確緩存它們（如django-mediagenerator）。
感謝您的優秀和翔實的答覆。關於你提到的三點 - 我曾在文檔中閱讀過關於它們的內容，但它沒有解釋爲什麼以類似的方式將JS本地化爲模板是一個問題。我覺得這有點奇怪，我想這就是爲什麼django-mediagenerator是方便的。例如：如果你有一個帶有簡單行alert（'Hello'）的JS文件，並且這是從http：// www.example.com/en/static/example.js提供的，那麼你可以德文版本來自'http：// www.example.com/de/static/example.js'。你甚至可以緩存這個。我希望我一直冗長。 –
是的，這就是爲什麼我喜歡django-mediagenerator;）你可以對靜態文件做很高級的事情，比如捆綁它們，壓縮，讓他們意識到i18n ......其中一個重要特性是能夠對它們進行版本化，你使用沉重的緩存瀏覽器端。如果你改變你的靜態文件，mediagenerator只會做_cache busting_並使瀏覽器的緩存失效。 –