Use generated message as a default one in sourceLocale catalog

[sladek-jan]

Hi,

In an attempt to add metadata ("context" for linguists) to translations, I used this new feature as follows:
i18n('Word // some context here')`Word`

The docs say Generated message is used as a default one. If I understand it correctly, in this case a key Word // some context here should be created in the catalog, with a default English translation Word (as long as sourceLang="en").

This is not what happens. The entry created in the catalog for en is:

"Word // some context here": {
    "translation": "Word // some context here",
    "origin": [
     ...
    ]
  },

This is logical, because of this commit which copies translation IDs over as default translations into source locale. But isn't this in conflict with what the docs say?

I am currently using version 2.0.1 until another issue is resolved.
Thank you for the great lib btw.

[vsnig]

Yeah, using messages as IDs can be tough :) I believe this can be fixed changing this line to

translation: config.sourceLocale === locale ? message.defaults : "",

as I proposed here

[tricoder42]

@sladek-jan I've just created a PR and it should be merged soon.

Just curious: if there were a better way to add metadata to translations, would you still use custom IDs?

For example adding metadata to comments:

// i18n: some context here
i18n.t`Word`

Generated message catalog might look like this:

"Word": {
    "translation": "",
    "context": "some context here",
    "origin": [
     ...
    ]
  },

Just an idea I had in the past.

[sladek-jan]

@tricoder42 Ok, thank you!

I guess it depends on what such a way would look like exactly.
Comments sound reasonable, and it would certainly look cleaner than placing the context after two slashes.
What I like most about i18n is the conciseness of use though, so if there was a way to place such context directly into code (similarly as it works with custom IDs), I would find it even better. Also, it might spare some code crawling, I imagine.

But I find comments just fine too.

[tricoder42]

Adding context directly to code might be even better. We just have to remember to remove it from production bundle as context is just for documentation purposes (for translators).

I'll think about it, what solution is easier.

[tricoder42]

Fixed and released in v2.2.0. Thanks to all involved!