RED._() behaviour

Is there any particular reason why the definition of RED._() returns a string if i18n returned a string and will return the key sent to i18n in all other cases ? This prevents the use of {returnObjects: true} in options as documented here:

If the key was not found, i18n will return the key anyway so I think maybe RED._() could be simplified from

RED["_"] = function() {
  var v = i18n.t.apply(null,arguments);
  if (typeof v === 'string') {
    return v;
  } else {
    return arguments[0];

(as found here in lines 38-45:


RED["_"] = function() {
  return i18n.t.apply(null,arguments);
1 Like

I can't remember the full details, but yes, this was a choice made.

There are places (such as node status) where we are given a string and we check to see if it is a message catalog id. If it isn't then we return the key. A problem happens when someone sends the status value that matches the first part of a message id, such as debug. This would return the complete object under debug in the catalog - which we don't want. So we only allow look up of absolute messages and don't set returnObjects.

Do you have a particular need to use that feature?

1 Like

In one of my custom nodes, I'm using an object to write text in the cells of a table (text is using locales of course). It was easier to have an object/array rather than a different i18n key for each cell. Hence my use of returnObjects. In the meantime I've used the i18n.t() function directly instead of RED._(). But I suppose this is discouraged as RED._() is the official way ?

We don't expose the i18n internals so I'm not sure how you are using returnObjects in your code.

RED._() is the only official function we provide to get messages from the catalog. The i18n library is an internal implementation detail.

Mmmh ... ì18n is available in my browser's console that's why I'm using it instead of RED._() .. I assumed NR exposed it ... I'm embedding NR in my own app ... maybe I added i18n myself ? I don't remember doing that ... I should check where this comes from ...

i18n exposes itself on the global object, but that isn't intended for general use and nowhere in our docs is it highlighted

1 Like

Thanks for the explanation ! I'm not crazy after all :slight_smile: I can live with i18n for now, even though I'll have to be careful after updates ... any chance RED._() could implement a few features from the original i18n in the future ?

Its possible. But until today no-one has asked about it, so it has never been something on the backlog.

1 Like