Multi-language Responses & Localized Food Names

More info on personalization options in the APIUsers Profile Management section.

Plan & Token Requirements

Feature available in the following LogMeal Plans:

Accessible by the following User Types:

Who does what?

• 🔴 APIUser: has a language attached to their user profile; most endpoints use this language by default when providing user-facing information.
• ⚫ APICompany and 🔵 APIUserManager: can set or override language on behalf of their assigned users.

What It Does

LogMeal's multi-language support lets you return localized names for:

• Detected dishes and food items
• Ingredients (including reference ingredients such as salt, sugar, oil)
• Food groups and food types
• Occasions (breakfast, lunch, etc.)
• Nutritional indicators and custom nutritional indicators
• Measurement units both at dish and ingredient level.
• Custom entities such as custom occasions and custom recipes (via their translation endpoints)

Instead of building your own translation layer, you simply choose a language once (per user or per request) and all supported endpoints will respond in that language.

Currently supported languages (via ISO 639-2/T codes) are:

• spa → Spanish
• eng → English
• fre → French
• ita → Italian
• nld → Dutch
• ger → German
• gre → Greek
• tur → Turkish
• heb → Hebrew
• cat → Catalan

You can always retrieve the up-to-date list programmatically using
GET /info/languages.

When to Use It / Outcomes

Use multi-language responses when:

• Your app UI is not in English (e.g. Spanish, French, German…) and you need dish names such as piña instead of pineapple, pollo instead of chicken, etc.
• You operate in multiple countries and want one backend that returns localized labels based on each user’s profile.
• You want to avoid maintaining your own translation table for thousands of dishes, ingredients and nutrients.

Expected outcomes:

• JSON responses where:

  • food_name, dish_name, ingredient names, food group names, occasions names, nutritional indicator names, etc. are returned in the requested language.
  • Internal IDs (dish IDs, ingredient IDs, indicator codes…) remain stable and language-independent, so you can safely store and query them in your own database.

• No additional
  ©
  monthly credits,
  (D) daily request limits or
  (S) per-second request limits are consumed beyond the underlying endpoint calls.

Feature-Specific Details

Supported Languages & Codes

The canonical list of languages and their codes is returned by
GET /info/languages.

Each key in the JSON corresponds to a three-letter ISO 639-2/T code used across the API, for example:

{
  "spa": "spanish",
  "eng": "english",
  "fre": "french",
  "ita": "italian",
  "nld": "dutch",
  "ger": "german",
  "gre": "greek",
  "tur": "turkish",
  "heb": "hebrew",
  "cat": "catalan"
}

Two Integration Modes

You can integrate multi-language support in two complementary ways:

1. User-Level Default Language (Recommended)

Store a default language (and country) in each 🔴 APIUser user profile.

• Set or update the user’s language via
  POST /profile/modifyUserProfileInfo.
• Use the language field (e.g. "spa") and optionally country (e.g. "ES") in the profile payload.
• Once set, this language will be used as the default for most endpoints, so you don’t need to pass ?language= on every call.

This is the best option when your own users can choose their preferred language in your app settings.

2. Per-Request Language Override

On endpoints that support it, you can dynamically override the language for a single request with the language query parameter:

POST /image/segmentation/complete?language=spa

• language must be one of the three-letter ISO 639-2/T codes returned by
  GET /info/languages.
• If omitted, the endpoint falls back to the APIUser’s user profile language or English.

Use this option when language depends on runtime context, such as:

• A shared device where end-users change language frequently.
• A multi-tenant backend that needs to forward the language of another system.

Behavior on Invalid or Unsupported Languages

• Passing an unsupported language code (e.g. xxx) may result in a 400 Bad Request with a validation error message.

• To avoid this:

  • Always use the values returned by
    GET /info/languages.
  • Validate user input on your side before calling the API.

Related Endpoints

Core language information

• GET /info/languages → ⚫ 🔴 🔵 Returns the list of available languages and their ISO 639-2/T codes.

Set the user’s default language & country

• POST /profile/modifyUserProfileInfo → 🔴 Modify an APIUser user profile, including language (default response language) and country (used for country-aware recognition and nutrition).

Recognition & nutrition endpoints with language support

• POST /image/segmentation/complete → 🔴 Multiple dishes segmentation & recognition. Accepts language to localize dish and ingredient names in the response.
• POST /nutrition/recipe/ingredients → 🔴 Returns localized ingredients for detected dishes.
• POST /nutrition/recipe/nutritionalInfo → 🔴 Returns localized nutritional indicators and values for detected dishes.

Dataset endpoints with language support

• GET /dataset/dishes → ⚫ 🔴 🔵 Returns the dish catalog; names are localized using language (query) or the APIUser’s default user profile language.
• GET /dataset/ingredients → ⚫ 🔴 🔵 Returns the ingredient catalog; names are localized using language (query) or the APIUser’s default user profile language.
• GET /dataset/referenceIngredients → ⚫ 🔴 🔵 Returns modulator ingredients (salt, sugar, oil…) with localized names.
• GET /dataset/foodGroups → ⚫ 🔴 🔵 Returns the food groups catalog; names are localized by the APIUser’s default user profile language.
• GET /info/nutrients → ⚫ 🔴 🔵 Returns the nutrients catalog; names are localized by the APIUser’s default user profile language.
• GET /dataset/weightMeasures/dishes → ⚫ 🔴 🔵 Returns dish weight measures and conversion rates; names are localized using language (query) or the APIUser’s default user profile language.
• GET /dataset/weightMeasures/ingredients → ⚫ 🔴 🔵 Returns ingredient weight measures and conversion rates; names are localized using language (query) or the APIUser’s default user profile language.

Custom translations (advanced)

Use these endpoints if you need to localize your own company-specific labels:

• POST /custom_nutritional_indicator_translation → ⚫ 🔵 Create a custom nutritional indicator translation (e.g. for a proprietary score) in a specific language.
• PATCH /custom_nutritional_indicator_translation → ⚫ 🔵 Edit an existing custom nutritional indicator translation.
• DELETE /custom_nutritional_indicator_translation → ⚫ 🔵 Delete a custom nutritional indicator translation.
• POST /intake/createOccasionTranslation → ⚫ 🔵 Create or update translations for Custom Occasions (e.g. Desayuno, Comida, Cena).

Typical Workflow

A common integration flow for multi-language food recognition looks like this:

1. Create an APIUser (see User Management docs) and obtain a 🔴 APIUser token.

2. Let the end-user choose their language and country in your app settings.

3. Update the APIUser user profile with language and country:

   • Call POST /profile/modifyUserProfileInfo with language: "spa" and country: "ES".

4. During day-to-day usage, call your usual recognition endpoints (e.g.
   POST /image/segmentation/complete)
   without specifying language:

   • Responses will automatically come back in Spanish for that APIUser.

5. (Optional) For special cases, override the language per request:

   • Append ?language=eng or another valid code to temporarily change the response language.

6. Store IDs (dish IDs, ingredient IDs, indicator codes) in your own database, and only display localized names in your UI.

Related Use Cases

• Personalized food diaries where each user sees their intakes in their own language.
• Multi-country apps that share a backend but offer localized dish and ingredient names.
• Clinical platforms where 🔵 APIUserManagers review intakes from users in different countries and languages.
• White-labeled apps where you want to change branding and language without re-training models.

Implementation Examples (Recipes)

Follow these recipes to implement the previously mentioned flow:

Set user profile data once to improve label language and regional dishes: