Different JSON structure

[weeco]

I am surprised the output of the translated strings is strucutred as associative array. This causes problems when you want to save it into MongoDB:

Unhandled rejection MongoError: The dotted field 'Zooming out / moving camera, please wait...' in 'uploaded_files..source_strings.Zooming out / moving camera, please wait...' is not valid for storage. at Function.MongoError.create (c:\Users\h9pe\Documents\tms-reworked\node_modules\mongodb-core\lib\error.js:31:11) at toError (c:\Users\h9pe\Documents\tms-reworked\node_modules\mongodb\lib\utils.js:139:22) at c:\Users\h9pe\Documents\tms-reworked\node_modules\mongodb\lib\collection.js:1060:67 at c:\Users\h9pe\Documents\tms-reworked\node_modules\mongodb-core\lib\connection\pool.js:461:18 at _combinedTickCallback (internal/process/next_tick.js:73:7) at process._tickCallback (internal/process/next_tick.js:104:9)

What about an option to store it as object array without a key for each object so that one can save the parsed po object into mongodb?

[smhg]

For future reference: MongoDB doesn't allow dots in field (object key) names. Neither can they start with dollar signs ($).

While I understand your need, changing the format is a big thing. This would require a major release because a reasonable amount of code depends on the current format.

Also, having an array per context instead of the current object structure might make things more difficult in other scenarios. Using the msgids as keys within each context isn't that awkward as they have to be unique. And JavaScript supports any string as object key with proper escaping.

So all in all I think we would just trade one benefit for another, no?

Adding the dollar sign limit, I think it makes little sense to adapt to Mongo's format. Depending on your use case and how you split up your translation data, you might just be better off storing it as a string (with JSON.stringify and JSON.parse).

I'll close this issue, but feel free to add feedback and/or contradict my reasoning.