Parsing translation with returnObjects: true replaces the object with a string

[salockhart]

• Is this a bug or a feature request?
  Bug

• What version are you running (0.x or 1.x)?
  1.0.6

• Which runner (cli, gulp...)?
  cli

What I'm trying to do?

I have a namespace for translating country names. I want to request this as an object, so that I can simply iterate through the countries.

t('country:countries', { returnObjects: true })

{
  "countries": {
    "AFGHANISTAN": "Afghanistan",
    "ALAND_ISLANDS": "Aland Islands",
    "ALBANIA": "Albania",
    "ALGERIA": "Algeria",
    ...

How am I doing it?

Here is my config file:

module.exports = {
  input: ['src/**/*.{ts,tsx,js}'],
  output: 'i18n/$LOCALE/$NAMESPACE.json',

  // only write to english, since it is the fallback for other languages
  // which would be translated externally
  locales: ['en'],
};

The command I'm running:

i18next

What was the result?

After parsing, the countries object is replaced with a blank string

{
  "countries": ""
}

What was I expecting?

Translations that are marked as returning objects should not be parsed as having a string result. I would expect this to have been ignored.

[karellm]

It's not per say a bug but a missing feature. The parser doesn't support the returnObjects option, I didn't even know it existed. You are welcome to submit a PR with the change, I don't have lots of time to work on this project atm.

[salockhart]

Okay, good to know! I will see about submitting a fix

[stophecom]

Any update on this? 😅

[wjramos]

This would be extremely helpful

[karellm]

Feel free to submit a PR

[ytytsophia]

Same Problem

[steodor]

Is this project maintained any more? We're looking for a parsing module for i18n but if issues like this are getting ignored for 3+ years then maybe this one is not a good idea to adopt. Thank you.

[karellm]

@steodor The eternal question of open-source and its entitled users. Instead of expecting things to be fixed, I invite you to contribute either with code or financially to ensure things that are important to you get fixed.

On a personal note, I've been clear for years that I don't use this project and have very limited bandwidth to write code for it. I review PRs and publish new versions regularly though. If you need custom work on the parser for your company needs, you can hire me.

[igorsantos07]

The problem is not only with the open source users, but with the fact that i18next officially endorses many subprojects, but don't provide any development time for them either. I totally understand the motto "don't wait, submit a PR", but you must also understand that, for an outsider (which just came in from the i18next docs), it's Very Odd™ to see a feature in the JS side but noticing it's absent from the parser which "accompanies" the main library.

Not blaming on you, but again (because this is not the first time I explain this confusion) on the i18next (creators?) maintainers, who decided to put stuff they don't control, and don't even bother helping, under the same umbrella.

It's been years I've been using i18next, and only now I found some use for "that objects feature they have". Checked the docs, included on my code, then a day later or so I ran the parser and poof, the objects are now gone. I mean, who would expect that i18next/i18next-parser would have limited features in comparison with i18next/i18next? And then I find a feature request covering my problem which dates from before the time I started using i18next.

I hope you can see what I mean :)
And again, I'm not putting pressure on you, Karel. I'm trying to explain it's more than just "open source users are entitled", it is confusing when some parts of the official organization are well maintained and others depend on the free time of other people.

---

I took a quick look at the source code, but got lost on what I could be looking for, given "passing objects through" doesn't seem like a complex PR. Would you have any pointers as to what files / parts of them would need fixing, @karellm?

At the very least, it would be helpful for future users if the parser could emit an error when it finds the returnObjects option, so users don't get baffled as to what's going on.

[jamuhl]

@igorsantos07 Currently, also the work on i18next, react-18next and some other modules is done either by @adrai or by developers contributing PRs to them. Time is limited, and as long as i18next and all its modules, whether maintained by core members or not, are free to use - do not expect any commercial level of support on it... we owe nothing to anyone... i18next is not a product, has no commercial licence, no real commercial backing.

https://npmtrends.com/i18next-vs-intl-messageformat-vs-messageformat-vs-vue-i18n If every company that used open source shared some of their success with the maintainer, the situation would be different. But I have yet to see a solution that has been proven to work...getting stuff for free is just too easy.

If you have an idea on how to make i18next a self-sustaining business, we're open to discussion. If not - please understand - our lives, our families come first and take precedence over working for free on things we don't even need. If companies urgently need something, either contribute or hire someone who can contribute.

[karellm]

@igorsantos07 As much as I would love to, I don't currently have the time to review the feature and give pointers. As to your other points, I understand the confusion and that it is less than ideal for an "outsider". Yet, I still stand with everything @jamuhl responded. I have other priorities than coding for free on something I don't currently need.

[igorsantos07]

Yeah, I totally get the "contribute to things we don't even use anymore".

Sadly, this is not what gets seen from the outside. Only after picking the library and implementing it, and maybe even after several years of use, that more and more issues become apparent, specially the fact there might be no fix for many of them, only self-written workarounds. Then it might be too late to switch.
As I've mentioned time and time again, i18next pages gives a somewhat twisted view (I don't say this in a bad way), passing on the impression of being a big community, a big project backed by a company funded by its own services, well maintained and all. But it turns out most developers got other things to do nowadays, and moved away from the project. Also, much of the "big community" is actually a patchwork of plugins that the main company/developers don't care much about. I'm sure I've mentioned most of those factors in previous issues, specially the surprise that projects under the i18next organization are not cared at all by the organization.

I don't say this to despise all your work or to disagree with all you said before - but exactly because I agree with your points, and that FOSS is, indeed, a sad place to be. After being bitten by this a couple of times, I hope issues like this reach more people and make them think twice, and maybe look around, when baking i18next onto their projects and build pipelines.

P.S.: any hope that the movement Sentry wants to start will be of any benefit? I'm not sure, but I hope so lol

Best wishes for you two!