Hey there, let's tackle your AngularJS 1.5 translation scenario—multi-domain deployment per language, no language switch UI, and avoiding browser-side JIT translation makes total sense here. Browser-side translation can add unnecessary load time and isn't ideal when each domain is locked to one language. Here's a robust, pre-compiled approach tailored to your needs:

Core Strategy: Pre-Compile Translations at Build Time #

Instead of loading translation files and replacing text in the browser, we'll bake translations directly into your templates and app bundle during the build process. This means each language domain gets a fully translated, ready-to-run app with zero client-side translation overhead.

Step 1: Pick the Right Tool for AngularJS 1.5 #

Go with angular-gettext—it’s designed specifically for AngularJS and supports offline pre-compilation (not just the browser-side compile you saw in docs). It lets you extract translation keys from your templates, manage translations in standard PO files, and compile those translations directly into your templates during build.

Step 2: Implement Pre-Compiled Workflow #

Break this down into build and deployment steps:

• Mark Translatable Content: Use the translate directive or translate filter in your templates to tag text that needs translation:

  <!-- Using directive -->
  <h1 translate>Welcome to Our Platform</h1>
  
  <!-- Using filter for dynamic text -->
  <p>{{ 'SERVICE_DESCRIPTION' | translate }}</p>
  

• Extract Translation Keys: Use angular-gettext’s CLI tools (like grunt-angular-gettext or gulp-angular-gettext) to scan your templates and JS files, generating a master .pot template file. This file lists all translation keys to be localized.
• Create Language-Specific PO Files: For each language (e.g., en.po, fr.po, de.po), copy the .pot file and fill in the translated text for each key.
• Compile Translations into Templates: Configure your build tool to compile templates against each PO file. This replaces all translation keys in your templates with the actual translated text. For example, with Grunt:

  grunt.initConfig({
    nggettext_extract: {
      pot: {
        files: {
          'po/template.pot': ['app/**/*.html', 'app/**/*.js']
        }
      }
    },
    nggettext_compile: {
      english: {
        files: {
          'dist/en/templates.js': ['po/en.po']
        }
      },
      french: {
        files: {
          'dist/fr/templates.js': ['po/fr.po']
        }
      }
    }
  });
  

• Deploy Per-Language Bundles: Deploy each compiled bundle to its corresponding domain. For example:
  • dist/en/ goes to en.yourdomain.com
  • dist/fr/ goes to fr.yourdomain.com

Step 3: App Code Adaptations #

• Remove Client-Side Translation Logic: Since translations are pre-compiled, you don’t need to load translation JSON files or initialize angular-gettext’s runtime translation service. Your app will render translated text immediately.
• Handle Dynamic Content: For text coming from APIs, have your backend return language-specific content based on the request domain. Alternatively, if it’s static dynamic text, add it to your PO files and compile it into your app.
• Strip Language Switch UI: Since there’s no need for users to switch languages, remove all flags, dropdowns, or other switch controls from your templates.

Pro Tips for Smooth Deployment #

• Optimize Per-Language Bundles: Each language bundle only needs resources relevant to that language (e.g., localized images, if any), reducing load times.
• Leverage CDN Caching: Cache each domain’s static assets separately to speed up repeat visits.
• Test Early & Often: Since translations are baked into the bundle, any errors require a rebuild and redeploy. Test each language bundle thoroughly before going live.

内容的提问来源于stack exchange，提问作者Mirek