Using --keyasareference with duplicate text breaks when converting back to i18next

I have the an i18next JSON source file that contains duplicate text items for different keys. One instance looks something like this:

{
  "role-a": {
    "step": {
      "intro": "Intro",
    },
  },
  "role-b": {
    "step": {
      "intro": "Intro",
    }
  }
}

I convert this to gettext with

i18next-conv --pot -l en -s source.json -b source.json -t target.pot -K

The resulting source.pot file looks like this:

#: role-a##step##intro role-b##step##intro
msgid "Intro"
msgstr ""

Now translators provide a translation in a tool supporting gettext and I convert it back to i18next JSON with

i18next-conv -l ${locale} -s source.pot -t target.json -K

The resulting i18next JSON looks like this:

{
    "role-a": {
        "step": {
            "intro role-b": {
                "step": {
                    "intro": "Intro"
                }
            },
        }
    }
}

It’s wildly different from the original JSON and broken as well.

Now I appreciate that the problem is caused by using the source string as a key which overlaps where the original msgid does not, and in any case, providing one translation for two keys results in ambiguities. However, I was hoping that the conversion would at least allow me to recover the original structure of the JSON. Am I missing something? Or am I asking the impossible?

[oasalonen]

But just to clarify: even if this is somehow fixed, I will not be using this approach going forward because all the instances of the ‘City’ text will get the same translation, which may not always be the case. I will use my original keys as msgids

[jamuhl]

Ah I see…while there is i18next-fluent - there is no real extraction tooling to get that saved as .ftb files…

Hm…guess that is still a good selling point for our locize.com - which works out of the box using the runtime submission of missing keys.