Change Details

In the Europeana Art History Challenge (https://www.wikidata.org/wiki/Wikidata:Europeana_Art_History_Challenge) we're using content translation. Users find an article to translate and do so. Turns out that content translation isn't adding the sitelink to the Wikidata item so the translation goes unnoticed. We already had a case where two users translated the same article without knowing because the sitelink wasn't added. Especially for new users it's almost impossible to explain that after the translation you have to manually add the link again. What should happen: * User goes through the content translation interface * User translates an article from source language to destination language * User saves the page * Process starts to add the new item to the existing wikidata item (or a new one) Probably the process that adds the missing link in the background could be similar to the move implementation we currently have //Edit by @Amire80, 2017-01-23:// I discussed this with @daniel and @Lydia_Pintscher at Dev Summit 2017, and we more or less agree that the addition of the sitelink should be moved from the frontend to the backend, although it has a few challenges. The current process is that the article is published [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/api/ApiContentTranslationPublish.php | using the cxpublish API ]]. It's a simple process that uses the usual edit API to save a wiki page with a bit of extra processing—edit summary, change tag, Echo notification, etc. Then the [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/modules/publish/ext.cx.wikibase.link.js | Wikibase JavaScript Library is invoked ]] to add the sitelink. This advantage of using the Wikibase JavaScript Library is that it is simple—it just takes source and target titles and does everything else. The disadvantage is that is may fail silently if the user closes the window too quickly, and possibly because of other reasons. It would be better to stop using JavaScript for this and make the sitelink adding part of the publishing API. Wikibase's LinkTitles class can be used for the actual linking in a job similar to UpdateRepoOnMoveJob. However, doing this is more complicated than using the Wikibase JavaScript Library. In particular, the linking should be done with the same username as the one that was used for publishing the translated article, but since the repo is on another site, it's non-trivial to reuse the log-in session in a backend job.

In the Europeana Art History Challenge (https://www.wikidata.org/wiki/Wikidata:Europeana_Art_History_Challenge) we're using content translation. Users find an article to translate and do so. Turns out that content translation isn't adding the sitelink to the Wikidata item so the translation goes unnoticed. We already had a case where two users translated the same article without knowing because the sitelink wasn't added. Especially for new users it's almost impossible to explain that after the translation you have to manually add the link again. What should happen: * User goes through the content translation interface * User translates an article from source language to destination language * User saves the page * Process starts to add the new item to the existing wikidata item (or a new one) Probably the process that adds the missing link in the background could be similar to the move implementation we currently have //Edit by @Amire80, 2017-01-23:// I discussed this with @daniel and @Lydia_Pintscher at Dev Summit 2017, and we more or less agree that the addition of the sitelink should be moved from the frontend to the backend, although it has a few challenges. The current process is that the article is published [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/api/ApiContentTranslationPublish.php | using the cxpublish API ]]. It's a simple process that uses the usual edit API to save a wiki page with a bit of extra processing—edit summary, change tag, Echo notification, etc. Then the [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/modules/publish/ext.cx.wikibase.link.js | Wikibase JavaScript Library is invoked ]] to add the sitelink. The advantage of using the Wikibase JavaScript Library is that it is simple—it just takes source and target titles and does everything else automatically. The disadvantage is that is may fail silently if the user closes the window too quickly, and possibly because of other reasons. It would be better to stop using JavaScript for this and make the sitelink adding part of the publishing API. Wikibase's LinkTitles class can be used for the actual linking and executed in a job similar to UpdateRepoOnMoveJob. However, doing this is more complicated than using the Wikibase JavaScript Library. In particular, the linking should be done with the same username as the one that was used for publishing the translated article, but since the repo is on another site, it's non-trivial to reuse the log-in session in a backend job.

In the Europeana Art History Challenge (https://www.wikidata.org/wiki/Wikidata:Europeana_Art_History_Challenge) we're using content translation. Users find an article to translate and do so. Turns out that content translation isn't adding the sitelink to the Wikidata item so the translation goes unnoticed. We already had a case where two users translated the same article without knowing because the sitelink wasn't added. Especially for new users it's almost impossible to explain that after the translation you have to manually add the link again. What should happen: * User goes through the content translation interface * User translates an article from source language to destination language * User saves the page * Process starts to add the new item to the existing wikidata item (or a new one) Probably the process that adds the missing link in the background could be similar to the move implementation we currently have //Edit by @Amire80, 2017-01-23:// I discussed this with @daniel and @Lydia_Pintscher at Dev Summit 2017, and we more or less agree that the addition of the sitelink should be moved from the frontend to the backend, although it has a few challenges. The current process is that the article is published [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/api/ApiContentTranslationPublish.php | using the cxpublish API ]]. It's a simple process that uses the usual edit API to save a wiki page with a bit of extra processing—edit summary, change tag, Echo notification, etc. Then the [[ https://phabricator.wikimedia.org/diffusion/ECTX/browse/master/modules/publish/ext.cx.wikibase.link.js | Wikibase JavaScript Library is invoked ]] to add the sitelink. ThisThe advantage of using the Wikibase JavaScript Library is that it is simple—it just takes source and target titles and does everything else automatically. The disadvantage is that is may fail silently if the user closes the window too quickly, and possibly because of other reasons. It would be better to stop using JavaScript for this and make the sitelink adding part of the publishing API. Wikibase's LinkTitles class can be used for the actual linking and executed in a job similar to UpdateRepoOnMoveJob. However, doing this is more complicated than using the Wikibase JavaScript Library. In particular, the linking should be done with the same username as the one that was used for publishing the translated article, but since the repo is on another site, it's non-trivial to reuse the log-in session in a backend job.