Angular localize用法疑问：硬编码兜底字符串是否为不良实践？

硬编码兜底是否属于不良实践 #

分场景判断：

• 小型项目、兜底文本复用率极低的情况下，硬编码是Angular官方设计的标准用法，不算不良实践。这种写法的优势是代码可读性高，不需要额外查变量映射关系，ng extract-i18n提取翻译时可以直接识别到源字符串。
• 中大型项目、同一兜底文本需要在多处复用的情况下，硬编码确实属于不良实践，你提到的修改遗漏问题会真实发生，建议做统一封装。

你提出的动态兜底写法不可行 #

$localize是编译时处理的工具，所有翻译ID、兜底文本必须是静态字符串才能被Angular的AOT编译器和i18n提取工具识别。你写的${someFallbackLanguage[text-to-translate]}属于动态变量，编译阶段无法被解析，会直接导致翻译提取结果缺失源文本，运行时也可能出现兜底不生效的问题，因此不建议使用该写法。

更优的实现方案 #

推荐以下两种落地性强的方案，完全兼容Angular localize的设计规则：

• 方案1：统一封装全局翻译服务
  将所有翻译项统一收敛到全局服务中维护，所有业务代码直接调用服务获取翻译内容，修改兜底时只需要改服务里的一处即可：

  // i18n.service.ts
  @Injectable({ providedIn: 'root' })
  export class I18nService {
    // 所有翻译项统一在此处维护
    get textToTranslate(): string {
      return $localize`:@@text-to-translate:IAmText`;
    }
  
    get otherText(): string {
      return $localize`:@@other-text:OtherContent`;
    }
  }
  

  业务代码中使用：

  constructor(private i18n: I18nService) {
    console.log(this.i18n.textToTranslate);
  }
  

• 方案2：配置全局兜底语言+统一ID常量
  在angular.json中配置i18n的sourceLocale为你的兜底语言（比如en-US），同时将所有翻译ID收敛到常量文件统一管理，避免ID写错的问题：

  // translation-ids.ts
  export const TRANSLATION_IDS = {
    TEXT_TO_TRANSLATE: '@@text-to-translate',
    OTHER_TEXT: '@@other-text'
  } as const;
  

  代码中使用：

  $localize`${TRANSLATION_IDS.TEXT_TO_TRANSLATE}:IAmText`
  

  同时Angular会自动在当前语言翻译缺失时，回退到你配置的sourceLocale对应的翻译文件内容，不需要在代码层面做额外处理。

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