- User Since
- Jun 20 2017, 9:26 AM (300 w, 9 h)
- LDAP User
- MediaWiki User
- PPetkovic (WMF) [ Global Accounts ]
Dec 9 2019
Dec 4 2019
Making target title read-only is possible. We already do that for source title. Text can be styled to be smaller as well.
Let me write a roundup of current state of changes made for section translation support and ask questions coming out of it. Work is not merged, so this is preliminary.
Dec 3 2019
This change has added visible scrollbar to all pages on Vector, regardless of page needing scrollbar or not. What @matmarex wrote above.
Nov 21 2019
I tried loading this same translation in production, but you still hold onto it. Can you still see the problem if you load the draft?
Nov 20 2019
The warning which can be seen is not expanded, but it still says "Missing reference", whereas no reference is missing.
Nov 13 2019
Does attachedRoot allow to use multiple adjacent <section>s or we need to wrap those which define a range between two <h2> headers?
Nov 12 2019
Are there any articles where this behavior is reproducible? I tried (locally) en:Tensor_product, which is mentioned in the description, but it works fine (using Google and Yandex), without 548956.
Nov 11 2019
lang and dir attributes of source page title are still not updated and wrong when switching source language.
Content Translation treats some API publish errors specifically, like:
Nov 7 2019
Nov 5 2019
We don't necessary need to load full article. There is still no REST API which returns only one section using parsoid and maybe their team had a valid reason not to include such option.
There is a simpler version catered to mobile devices, which I wanted to try out. Loading whole article seems lazy to me. There are some challenges with cross-section content, like named references, but they can be expanded to full definition for that one section.
Nov 1 2019
Oct 27 2019
Can you please try again with your browser console open (by pressing F 12 key on your keyboard) and put the output here?
Oct 25 2019
I don't think this ticket is about creating tutorials. We already have that for Mediawiki core, which seems to be focus of this ticket.
Oct 23 2019
You need to run a script located at core/extensions/ContentTranslation/scripts.
When you are in that directory, run php purge-unpublished-drafts.php. You also need to pass some command line option to your script:
- age-in-days - This option was existing before changes made to the script for the purposes of this task. It determines how old are the drafts which are being removed from DB.
- notify-age-in-days - This option was introduced for this task. It determines how old are drafts that you notify users to "continue their translations before they get deleted"
- really - Unless this option is included, you get log of drafts which users are notified about or which get purged and actions are not performed really. Without this option is what we call "dry run".
You can use something like php purge-unpublished-drafts.php --notify-age-in-days=1 --really to notify users to continue their drafts which are one day old. I'm using one day since you probably don't have older drafts available locally. You can also use other parameters and tweak you calendar date on your OS to test this.
The name of the method is isPotentialTranslator. As name explains, method checks if user is a potential translator, to which we should show invites. @Pginer-WMF we're talking specific invite here. Anyway, the method can confirm that user is potential translator in two ways:
- User has made some translations with CX before
- User has edited more than one Wikipedia
Your Testpitanormal meets the first criteria, that is why you see the invite.
Oct 22 2019
When you have Suggestions view open, adding/removing items using bookmark icon will require refresh. Popup notice with message saying that article is added for later is what we settled for. If you perform same actions when your In progress or Published lists are opened, and then navigate to Suggestions without reload, those new additions will show.
- T194476 happens on this feature as well - if we change the target language on the "new translation" the bookmarked article doesn't show on the bookmarks: example video
The reason is that article you selected exists in Catalan and when you reload, Catalan is selected as target language. Thus, article is considered as existing and removed from the list of favorites. Patch 537781 is meant to deal with this problem.
It was reported by @Jpita that new users on Javanese Wikipedia (on which CX is out of beta) are not seeing invite. I instructed him to edit articles on some non-Javanese Wikipedia and try again. The invite was not showing after that, so we did some investigation. Without a clear cause, I went on to investigate on my own.
I have double checked and Wikidata linking is working automatically after publishing again.
Oct 21 2019
Oct 18 2019
I also did checks using various viewport positions and MT options.
Yes, I tested quite extensively on localhost during development.
Now I checked in production as well, using Serbian Wikipedia. First, while I was on dashboard suggestion view, I opened New translation dialog, found some random article which is missing in Serbian and bookmarked it. Popup message appeared. Page needed to be reloaded to see the changes.
Oct 15 2019
Message "Machine translation failed" was not shown and jump did not happen.
Oct 14 2019
I have looked this up, and there is a protein in human body called GATA4, which is also known as ASD2. We got this suggestion from GATA4 having ASD2 alias on Wikidata.
English Wikipedia page also lists ASD2 as an alias to GATA4. This is valid suggestion.
Oct 11 2019
Oct 10 2019
@Jpita, the fix is not yet deployed to cxserver.
With discarding feature, we have following workflow: 1) Load CX, 2) Open suggestions, 3) Discard unwated, 4) Open CX next time, 5) If nothing changed for seed articles, we get same suggestions, minus discarded one.
Without discard feature, when we get same set of articles, we need to reload all to get rid of some that we don't want to see. Maybe the behavior where we see a lot of the same suggestions is the problem here, but it annoyed me as a user.
What I propose is try to have discard for free or with minimal effort inside new suggestion system. If it requires more effort to modify than to remove (removing also takes some effort, usually minimal), abandon the feature.
Oct 9 2019
I have made required changes. Here are the results:
|Suggestion with image||Suggestion with no image|
I would like to point out that for title "Incumbent", proposed article is a disambiguation page - Titulaire. Description says "We may want to filter out disambiguation pages, not showing them as a suggestion". @Pginer-WMF, you may want to create separate ticket to capture this. API introduced in T227571 offers disambiguation page as suggestion, this ticket is just about presentation.
@Pginer-WMF have you considered allowing users to choose where their published section translations should end up? In your mock ups, there was a way to choose which section to translate from source. Similar to that, we may enable users to choose between which sections in target article to insert newly translated one.
I used to make some efforts personally to determine articles with most languages that are missing in Serbian, regardless of topic. Tried Wikidata first, but without any additional filtering, query would timeout every time. Then, I started querying with instanceof and similar properties, which yielded some results. Some topics with large amount of items would still timeout, like movies, actors, etc. Many others complete successfully, like entrepreneur or bank.
I tried modifying your query slightly, most notably adding ORDER BY DESC(?linkcount) and running it for all categories you defined in topics.json. Some topics returned low quality (and quantity) suggestions, like Q1071 (Geography). Others worked nicely.
I see this approach could be useful. It depends strongly on Wikidata inter-item connections. We will need to make additional efforts to make some topics usable, maybe combining multiple categories.
Also, there is a question of how generic or specific we want our topics to be and how many of them. Do we want them configurable? Those are questions for @Pginer-WMF.
Oct 8 2019
Oct 7 2019
After updating the patch to match @Pginer-WMF's design, I did additional checks to verify all the specs are in place.
@Pginer-WMF, once you verify above screenshots look good and following two items are acceptable, I'm merging the patch:
- The invite does not go away after user starts typing inside the editor
- Blue dot and invite could be shown simultaneously:
Yes, another user linked your new article to Wikidata item.
Patch 539222 to fix this problem for the second time was deployed with 1.34.0-wmf.25 and Wikidata linking is still not working.
Oct 4 2019
I have made some visual adjustments to the patch from @santhosh. Here are some shots:
|Generic invite||Suggestion with no image||Specific suggestion with image|
Oct 2 2019
Sep 30 2019
I was not able to reproduce same errors, but actually got different one reported in T234220. Whether that cxserver error covers TypeError: Cannot read property 'shallowCloneFromRange' of null, when translating first paragraph of en:Vantaa to Spanish, is unclear.
Progress bar is displayed on dashboard. We take number of translated sections and divide that with total number of source sections, which includes those excluded from MT validation. Of that total progress, we mark percentage coming from MT. This calculation excludes sections blacklisted for MT validation.
Sep 27 2019
Not that I know of.
Sep 26 2019
We need to notify users about old drafts in 15 day windows. In order to avoid notifying same user twice or missing some draft, we decided to save timestamp of last notified draft in that run. That avoids saving and updating info per draft as well.
For purpose of saving this timestamp of last notified draft, new database table is introduced. Since this involves schema changes, by following guidelines, I've added Schema-change tag. Separate task will be created after patch is merged.
Patch which introduces this table can be merged before table is created, as new table usage is behind configuration.
Sep 25 2019
The fix has landed with 1.34.0-wmf.24 (deployed on 18 Sep for group 1 wikis like Catalan Wikipedia), but linking to Wikidata is still not working.
Check out some of translations made on 25th of September. Timestamps of when article is created with Content Translation and when that article is linked to Wikidata are not matching. In the two examples, different user has added Wikidata link.
- Talal Derki is created on 01:21, 25 Sep 2019 (UTC+2), but article is linked on 07:11, 25 Sep 2019 (UTC+2) by a different user
- Similar example can be seen with creation of "Of Fathers and Sons" and its linking to Wikidata.
By looking at one of the last articles published before 1.34.0-wmf.20 was deployed, we see that time and author of article creation and Wikidata linking are the same.
Sep 19 2019
Sep 17 2019
Sep 15 2019
I've tried reproducing this. Started translation of en:Vantaa to Spanish and added paragraphs starting with "Vantaa is bordered by Helsinki" and "The largest airport in Finland". Waited for save and reloaded the page. Clicked on only reference to see no error. Reference card was empty.
Sep 13 2019
There were changes in how Abuse Filter sends data when publishing is prevented due to some filter being hit. Due to good communication, the changes were brought to our attention in time, before changes in Abuse Filter ended up in production. The changes are rolling out in 1.34.0-wmf.23.
We reacted and adapted our code to changes. That means, there is no environment (besides local) where you can see what would happen if we didn't adapt to changes.