Page MenuHomePhabricator

FuzzyBot overwrites translations (issue related to page language different from $wgLanguageCode)
Closed, ResolvedPublic

Description

Hi,

on my German Wiki I enabled $wgPageLanguageUseDB because I want the source translation page often to be in another language than set from $wgLanguageCode="de". But in the end, after translating, the maintenance runJobs overwrites my translations (English -> German) from English source. The versions I use MW 1.26.2 (special:version shows 1.26.2 but it is mediawiki package 1.26.3-1.1 from http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_13.2/) and Extension:Translate MLEB 2016.04.

I did the following steps:

  1. in LocalSettigns.php: $wgLanguageCode="de"; $wgPageLanguageUseDB=True;
  2. Create an English page "Testpage" in the German Wiki, set page language to be English
  3. from this point on maintenance/runJobs.php invokes TranslateRenderJob summarizing via "tpt-render-summary" and writes the English source each time into the German page ("Testpage/de" whether I did a translation or have a new translation setup with only the source language)
  4. the translation system ignores the changed page language of English and interprets the English page as being German, hence selecting German as translation target results in the message that this is the source language and cannot be translated. However when I switch translation target to be English and back to German it loads all German message groups (which became English from the runJobs maintenance)
  5. I can translate to German but the translated German display title does not show up on the German Testpage/de
  6. if I modify the English source page "Testpage" and update it into the translation system, FuzzyBot (via runJobs) overwrites all German translations again.

I asked already here:

I'd like to have one or two solutions

  1. if possible solve this issue that the changed page language is taken into account by the translation system ($wgPageLanguageUseDB=true;)
  2. a way to deactivate or manage FuzzyBot

Thank you

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 30 2016, 9:27 AM
infinite-dao triaged this task as High priority.May 30 2016, 10:43 AM

I tested this again and I could not reproduce what you said with master version of MediaWiki and Translate.

From your steps to reproduce, it is unclear whether you mark the page for translation before or after changing the source language. Currently changing the source language of a page already marked for translation is not handled.

Please test with 1.27 release candidate or this patch applied: https://github.com/wikimedia/mediawiki/commit/d23738002136761e34f11d72e7dd7eea65e3b655

unclear ... that's right in 2nd step I described only loosely, I meant: set page language from German to English, then mark the page for translation, then step 3

How can I get a single patch file to test it from https://github.com/wikimedia/mediawiki/commit/d23738002136761e34f11d72e7dd7eea65e3b655? I would like to try to apply the patch first before trying the 1.27 release candidate.

Try https://phabricator.wikimedia.org/rMWd23738002136761e34f11d72e7dd7eea65e3b655?diff=1
or Download Raw Diff in rMWd23738002136761e34f11d72e7dd7eea65e3b655

But I have no idea whether this patch will apply clean to 1.26, so you will have to try and see.

Nikerabbit changed the task status from Open to Stalled.Jun 7 2016, 11:08 AM

Have you tried either approach yet?

Honestly, my problem is that I don't know how to apply the https://phabricator.wikimedia.org/rMWd23738002136761e34f11d72e7dd7eea65e3b655?diff=1 directly. The wiki I have is not in git but managed by openSUSE software manager.

Alternatively I could wait until the MW 1.27 stable is out, and upgrade MW using the software management, which would be this June-something.

I'm not familiar with patching and applying diff. So far I tried:

wget https://phabricator.wikimedia.org/rMWd23738002136761e34f11d72e7dd7eea65e3b655?diff=1 --output-document="rMWd23738002136761e34f11d72e7dd7eea65e3b655.diff"
# dry run first
patch --follow-symlinks --strip=1 --input=rMWd23738002136761e34f11d72e7dd7eea65e3b655.diff --dry-run

but it reports

can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/includes/OutputPage.php b/includes/OutputPage.php
|index e527001..459fb4d 100644
|--- a/includes/OutputPage.php
|+++ b/includes/OutputPage.php
--------------------------
File to patch: 
Skip this patch? [y] y

Is there any smart way to apply the diff without git (patchutils perhaps)?
Do I have to split patches with splitpatch from patchutils and somehow manually apply patch file by file?

patch -p1 < rMWd23738002136761e34f11d72e7dd7eea65e3b655.diff works[1] for me in the MediaWiki root directory.

[1] fails to though apply since I am in master

When I issue the patch command from the mediawiki root folder, I get

cd /usr/share/mediawiki
patch --strip=1 --input=rMWd23738002136761e34f11d72e7dd7eea65e3b655.diff --dry-run --backup
# checking file includes/OutputPage.php
# Hunk #1 FAILED at 1.
# 1 out of 1 hunk FAILED
# ...

so I guess the diff-patch is not really compatible and I would test it downloading individual files ... I'm uncertain if I invest this time now.

Anyway, I report back by the MW stable 1.27 at the last

infinite-dao closed this task as Resolved.Jul 6 2016, 1:10 PM
infinite-dao claimed this task.

Yes, with MW 1.27 the language page issue is resolved

  • page title is displayed properly
  • translation links (for /de, /en) work as expected

But somehow it did not update translations on the page right away, only after I tried several things:

  • purge the page (no effect)
  • run maintenance/runJobs.php (had effect)

Does translation status also influence on how translations are published, transcluded through or is just the maintenance/runJobs the key?

Thanks for confirming.

Translation status does not have any functional effect. It is there to only support other processes. runJobs is what makes the background tasks to actually execute.