Extract named parameters for some complex identifiers in t-macro

[tmcheung]

Problem

Simple identifier works great

When using string interpolation for message arguments like:

t(`${price} for ${numberOfDays} days`)

the parameter extracted is named:

i18n._(
  /*i18n*/
  {
    id: "+nhkwg",
    message: "{price} for {numberOfDays} days",
    values: {
      price: price,
      numberOfDays: numberOfDays,
    },
  }
);

// en/messages.po

msgid "{price} for {numberOfDays} days"

this is great as it provides context for translators about the available parameters.

All non-simple identifiers; not so great

However, it is only supported with simple identifiers, and anything else is replaced with positional parameters. The result is that identifiers/paths of nested references also get thrown out the window:

t(`${product.price} for ${product.numberOfDays} days`)

i18n._(
  /*i18n*/
  {
    id: "+nhkwgs",
    message: "{0} for {1} days",
    values: {
      0: product.price,
      1: product.numberOfDays,
    },
  }
);

// en/messages.po

msgid "{0} for {1} days"

Proposed solution

This behavior is defined here, but I would like it to not include nested paths as they are named. For nested paths it would be great if the leaf node or full path could be included so that it works like:

t(`${product.price} for ${product.numberOfDays} days`)

i18n._(
  /*i18n*/
  {
    id: "+nhkwgs",
    message: "{price} for {numberOfDays} days",
    values: {
      price: product.price,
      numberOfDays: product.numberOfDays,
    },
  }
);

// en/messages.po

msgid "{price} for {numberOfDays} days"

[andrii-bodnar]

Thanks for the suggestion!

Actually, there is a new feature in the v5 pre-release that aims to provide additional context about placeholders in exactly the same case as you describe.

[timofei-iatsenko]

Here is a PR implementing this for more context:

#1965

BTW i still considering to implement optional full identifier as proposed in #1874