Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception when performing edits on Wikidata: "Multiple terms provided for the same language" #1917

Closed
davidabian opened this issue Dec 29, 2018 · 2 comments
Assignees
Labels
pull request pending For issues that will be fixed by an open PR Type: Bug Issues related to software defects or unexpected behavior, which require resolution. wikibase Related to wikidata/wikibase integration
Milestone

Comments

@davidabian
Copy link

Describe the bug
After some successfully performed edits on Wikidata, the following exception raises and breaks the editing process.

Exception in thread "Thread-11" java.lang.IllegalArgumentException: Multiple terms provided for the same language.
	at org.wikidata.wdtk.datamodel.implementation.TermedStatementDocumentImpl.constructTermMap(TermedStatementDocumentImpl.java:389)
	at org.wikidata.wdtk.datamodel.implementation.TermedStatementDocumentImpl.<init>(TermedStatementDocumentImpl.java:157)
	at org.wikidata.wdtk.datamodel.implementation.ItemDocumentImpl.<init>(ItemDocumentImpl.java:96)
	at org.wikidata.wdtk.datamodel.implementation.DataObjectFactoryImpl.getItemDocument(DataObjectFactoryImpl.java:277)
	at org.wikidata.wdtk.datamodel.helpers.Datamodel.makeItemDocument(Datamodel.java:629)
	at org.wikidata.wdtk.datamodel.helpers.Datamodel.makeItemDocument(Datamodel.java:595)
	at org.openrefine.wikidata.editing.EditBatchProcessor.performEdit(EditBatchProcessor.java:134)
	at org.openrefine.wikidata.operations.PerformWikibaseEditsOperation$PerformEditsProcess.run(PerformWikibaseEditsOperation.java:211)
	at java.lang.Thread.run(Thread.java:748)

To Reproduce
Steps to reproduce the behavior:
1.

Current Results
On the web interface the message "Peform [sic] edits on Wikidata // 51% complete" remains, as if the process continued, but the process has actually stopped and no more changes are uploaded to Wikidata.

Expected behavior
The problem ("Multiple terms provided for the same language") should be detected and handled before the editing process starts.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS, Windows 10, Linux, Ubuntu 18.04]
  • Browser Version: [e.g. Chrome 19, Firefox 61, Safari, NOTE: OpenRefine does not support IE but works OK in most cases]
  • JRE or JDK Version:[output of "java -version" e.g. JRE 1.8.0_181]

OpenRefine (please complete the following information):

  • OpenRefine 3.1

Datasets
If you are allowed and are OK with making your data public, it would be awesome if you can include or attach the data causing the issue or a URL pointing to where the data is.
If you are concerned about keeping your data private, ping us on our mailing list

Additional context
Add any other context about the problem here.

@wetneb wetneb added Type: Bug Issues related to software defects or unexpected behavior, which require resolution. wikibase Related to wikidata/wikibase integration labels Dec 30, 2018
@wetneb wetneb added this to Todo in Wikidata integration via automation Dec 30, 2018
@wetneb wetneb self-assigned this Dec 30, 2018
@wetneb
Copy link
Sponsor Member

wetneb commented Dec 30, 2018

Oops! That is annoying. Thanks a lot for the report, I will investigate.

@davidabian
Copy link
Author

Thanks! :D

@wetneb wetneb added the pull request pending For issues that will be fixed by an open PR label Dec 30, 2018
Wikidata integration automation moved this from Todo to Done Jan 6, 2019
@wetneb wetneb added this to the 3.2 milestone Feb 7, 2019
tfmorris added a commit to tfmorris/OpenRefine that referenced this issue Jun 12, 2020
Fixes OpenRefine#1917. Previously we were using a funky ContentType to attempt
to force a file download rather than display in browser, but this
conflicted with attempts to save UTF-8 which was outside the Basic
Multilingual Plane (BMP).

By switching to ContentDisposition: attachment, which has been
the preferred method for a number of years, we can avoid this conflict.
tfmorris added a commit to tfmorris/OpenRefine that referenced this issue Jun 13, 2020
Fixes OpenRefine#1917. Previously we were using a funky ContentType to attempt
to force a file download rather than display in browser, but this
conflicted with attempts to save UTF-8 which was outside the Basic
Multilingual Plane (BMP).

By switching to ContentDisposition: attachment, which has been
the preferred method for a number of years, we can avoid this conflict.
tfmorris added a commit to tfmorris/OpenRefine that referenced this issue Jun 14, 2020
Fixes OpenRefine#1917. Previously we were using a funky ContentType to attempt
to force a file download rather than display in browser, but this
conflicted with attempts to save UTF-8 which was outside the Basic
Multilingual Plane (BMP).

By switching to ContentDisposition: attachment, which has been
the preferred method for a number of years, we can avoid this conflict.

As part of this, switch to using the "preview" param consistently
to control preview vs download rather than the content type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pull request pending For issues that will be fixed by an open PR Type: Bug Issues related to software defects or unexpected behavior, which require resolution. wikibase Related to wikidata/wikibase integration
Projects
No open projects
Development

No branches or pull requests

2 participants