Localization of documents is a crucial aspect when developing applications that cater to various regions or languages. The localizeDocument method provided is a powerful tool to handle document localization in an efficient and straightforward manner. Here’s an overview of the method usage and its advantage:

Usage

Invoke the localizeDocument method, passing the document object and the desired language code as arguments. The method traverses the document, identifies the localized fields, and returns a new document where the values are replaced with the specified language translations.
const localizedDocument = localizeDocument(object, lang);

Data Structure

Your document should have a specific structure to work with this method. Localized fields should be nested under a localized property, with language codes as keys.
{
  "title": {
    "localized": {
      "en": "Hello",
      "de": "Hallo"
    }
  },
  "otherproperty": ""
}

Advantages:

  • Simplicity: You don’t need to know the location of the translations within the document. The method takes care of finding and applying the translations for you.
  • Backward Compatibility: The method is designed to be backward compatible. If the document structure evolves over time, the method should still work as expected without requiring modifications.

Background:

The localizeDocument method traverses the document and looks for properties with a localized object. It then replaces the main properties with the translated values from the localized object based on the specified language. If a translation for the specified language isn’t available, it falls back to English or another available language.

Alternatives:

While the localizeDocument method is handy, an alternative approach is using projection for localization. However, projection requires you to know the path to the localized fields, which might not always be convenient or feasible.
// Example of a projection
YourModel.find({}, { 'title.en': 1 });
The choice between using localizeDocument method and projection would depend on your project’s requirements and the complexity of your document structures. In the given example:
private static getLanguageProtection(languageCode = 'de') {
  return {
    title: `$title.${languageCode}`,
  };
}

static DEFAULT(languageCode: LanguageCode): any {
  return {
    ...this.getLanguageProtection(languageCode),
    ...this.getDefaultProtection(),
  };
}

Usage

SchemaProtection.DEFAULT(args.languageCode)
Here, a static method DEFAULT is defined which takes a languageCode argument. This method calls another method getLanguageProtection, passing the languageCode to it. The getLanguageProtection method returns an object with a projection for a specific language, which is then used in DEFAULT method to return a combined projection object. This approach of defining a projection is more structured and allows for dynamically determining the language-specific projection based on the languageCode argument. However, it still requires a predefined understanding of the document structure and the path to the localized fields, unlike the localizeDocument method which abstracts the localization logic regardless of the document structure.