Node.js i18n开发疑问：使用__方法还是直接导入JSON文件？

Great question—consistency is key when working with i18n, so you’re absolutely right to push for a single, standardized approach. Let’s break down the two methods you’re seeing and why one is clearly better suited for your setup:

The Problem with Directly Requiring Locale JSON Files #

Your controller’s current approach:

var responses = require('../../locales/en.json');
let message = responses.authorisation.flashes['welcome'];

has several critical drawbacks:

• Hardcoded language: You’re explicitly loading en.json, so this code will never serve translations for other locales (like nl) without manual, error-prone changes to load the right file.
• No i18n library benefits: You’re bypassing all the features your configured i18n library provides—like automatic locale detection, fallback to the default locale, and dynamic language switching based on user preferences or request headers.
• Redundant, messy code: Every time you need a translation, you’ll have to import the correct JSON file, which leads to repeated boilerplate and increases the chance of path errors.

Why Using req.__() is the Superior Approach #

The middleware’s use of req.__('organisation.not-found') aligns perfectly with how your i18n library is designed to work, and it solves all the issues above:

• Automatic locale handling: Since you’ve configured i18n with locales: ['en', 'nl'] and objectNotation: true, the req.__() method will automatically pull the correct translation based on the current request’s locale (e.g., if req.locale is set to nl, it will use nl.json instead of en.json).
• Seamless integration with existing tools: It works naturally with connect-flash (as shown in your middleware), keeping your flash message logic consistent across the codebase.
• Clean, maintainable code: No more manual file imports—just call req.__('path.to.your.translation') (using dot notation for nested keys, thanks to objectNotation: true) and the library handles the rest.
• Scalable: Adding new locales later only requires creating a new JSON file in your locales directory—no changes to business logic needed.

How to Standardize Your Codebase #

To bring everything into alignment:

1. Replace all direct JSON imports with req.__(). For your controller example, rewrite it to:

   let message = req.__('authorisation.flashes.welcome');
   return res.status(200).json({ success: true, message, token, user: userData });
   

   The dot notation matches the nested structure of your JSON files exactly, so this will work the same way as your original code—but with all the benefits of the i18n library.
2. Ensure req.__() is available everywhere: Your i18n configuration already registers the library globally, but in Express, the method is automatically attached to req and res objects for request-specific locale handling. Using req.__() is the safest way to ensure translations respect the current user’s language preference.
3. Enforce the standard: Update your project’s style guide or documentation to specify that all translations must use req.__() (or res.__() if rendering templates) to keep the codebase consistent.

Final Verdict #

Stick exclusively with the req.__() syntax. It’s the idiomatic way to use your i18n library, integrates seamlessly with your existing middleware stack, and makes your codebase more maintainable and scalable long-term.

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