Could happen if some code tries to parse undefined converted to a string as a JSON.

On the thread the relevant method seems to be: Object.ve.dm.CXReferenceNode.static.toDataElement

It may be good to investigate in conjunction with the work on T220790 which is also related to making more solid the recovery of saved translations.

Another user reported the issue. @santhosh, any idea about which can be the cause? It seems that the reports started appearing around the time T204308 was deployed. Any details we should ask users that can help debug this?

Change 516574 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Don't store undefined as data for ve.dm.CXReferenceNode

https://gerrit.wikimedia.org/r/516574

This error happens when user adds completely new reference (not with editing adapted reference).

CX data is stored in reference node, and since reference isn't going to cxserver for adaptation, we have undefined as data. That is stored in CX corpora when saving translation. When draft is loaded again, "undefined" (string) is passed to JSON.parse, which fails with SyntaxError: Unexpected token u in JSON at position 0.
That is what @Nikerabbit is talking about in T224715#5225548.

With 516574, I'm preventing "undefined" to be stored as data, which solves the problem for new translations, but existing ones are still affected.
To allow users affected by this bug to load their translation, we may need to check explicitly for "undefined" as reference data when loading drafts. Other approaches and ideas are welcome.

In T224715#5251941, @Petar.petkovic wrote:

This error happens when user adds completely new reference (not with editing adapted reference).

Thanks for the analysis, @Petar.petkovic. I think it makes sense to do both, (a) make sure that undefined data is not stored and (b) make the loading approach more tolerant to undefined data in a way that does not block the load of the whole document.

Change 517934 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Be more tolerant when extracting data for references

https://gerrit.wikimedia.org/r/517934

Same problem! My translate doesn't load so I can't publish it. Please fix it as soon as possible!

In T224715#5251941, @Petar.petkovic wrote:

This error happens when user adds completely new reference (not with editing adapted reference).

CX data is stored in reference node, and since reference isn't going to cxserver for adaptation, we have undefined as data. That is stored in CX corpora when saving translation. When draft is loaded again, "undefined" (string) is passed to JSON.parse, which fails with SyntaxError: Unexpected token u in JSON at position 0.
That is what @Nikerabbit is talking about in T224715#5225548.

With 516574, I'm preventing "undefined" to be stored as data, which solves the problem for new translations, but existing ones are still affected.
To allow users affected by this bug to load their translation, we may need to check explicitly for "undefined" as reference data when loading drafts. Other approaches and ideas are welcome.

Yesterday I started a new translation (see picture above) and added new references. After that the load error appeared although this was a new translation after fixing the loading bug.

In T224715#5276654, @Voltmetro wrote:

Yesterday I started a new translation (see picture above) and added new references. After that the load error appeared although this was a new translation after fixing the loading bug.

The fix that I'm talking about has not reached production yet. Given the current status, earliest time the fix will reach production is late next week.

Change 516574 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Don't store undefined as data for ve.dm.CXReferenceNode

https://gerrit.wikimedia.org/r/516574

Change 517934 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Be more tolerant when extracting data for references

https://gerrit.wikimedia.org/r/517934

@Voltmetro, now I can give you exact times when fixes will reach production.
For new translations, fix will be effective this Thursday (time of day depending on your time zone) and existing translation will be fixed next Thursday.

@Petar.petkovic thank you. I will wait it to continue my translation.

@Petar.petkovic Thank you!

For translations started after last Thursday (June 27), restoring should not be a problem anymore. For already affected translations, which are started before, the fix should land in production not this Thursday (July 4) as I said in my last comment, but next Thursday (July 11).

When I was writing last comment, I was not aware there will be no deployment this week, due to 4th of July US national holiday.

I tried to reload my translation in progress, but it still doesn't work. The translation is Sopra Steria (FR->ZH)

In T224715#5324473, @Lzcjames wrote:

I tried to reload my translation in progress, but it still doesn't work. The translation is Sopra Steria (FR->ZH)

Same problem

@Lzcjames and @Voltmetro can you try now? The fix was not in production by the time you checked and reported.

In T224715#5326551, @Petar.petkovic wrote:

@Lzcjames and @Voltmetro can you try now? The fix was not in production by the time you checked and reported.

It works! Thank you!

It works! thank you so much @Voltmetro

Hi everybody. The issue has now been solved for me! Thank you so much for your efforts!!

Kind regards,
Álvaro