@sbassett, yes I was part of those dicussions. We discussed this specific topic too. Alternatives to webpack is discussed and I think everybody is on same page that we need a bundler with relatively less risk profile(Rollup was one candidate). Language team will definitely switch to such bundlers once we decide it. Our code does not use any webpack plugins other than the ones coming with default configurations, so it should be trivial to change to bundler to something else. As per the vue task force discussions, it was observed that the current plan with section translation need not be blocked for this, but definitely an item to explore and fix without much delay(see vue task force meeting minutes, that I believe you have access).

In case it helps, https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/tree/master/app/src/plugins/ve is the source code of Section translation's VE integration using Vue

https://sx.wmflabs.org lists some examples of direct access

I will keep this in in-progress till we do end-to-end tesitng this api

Yes, that is expected, but can be controlled using configurations as per https://www.mediawiki.org/wiki/Content_translation/CX3

@ssastry, When VE updates the code, our frontend will function as expected, but we need to do some code changes and test updates in CX-cxserver , espcially when we do image adaptation and sanitization of machine translation. Do you have any timeline for deployment?

The current version of Content translationis not designed for mobile. This is a known issue. The three column layout that require for translating content demands wider screenspace. We donot recommend using it in small devices.

Yes, we are almost getting ready, fixing couple of major bugs. After that we will make sure you have correct version of code to test and make it available in deployed state at test server too. We will update it here.

In T237028#6615328, @ssastry wrote:

In T237028#6614148, @ssastry wrote:

But, apart from that, one option for parsoid is to add a synthetic tag as the first node that holds the transclusion information. We are evaluating the specific choice of node. @Arlolra proposed meta tag as a potentially safe candidate. Separately, we are evaluating if we should do that always (vs. only in special circumstances such as this). So, that is one possible solution.

Note that if we do this, the style tag will still have a typeof for TemplateStyles. But, other than that, if we pursue this solution, would it help your use cases?

After https://gerrit.wikimedia.org/r/640124, When you click that blinking cursor card, you go back to sentence selector and there is no Edit translation button.

Another example where this causing issue in translating quotes:

The javascript error is same as T262703: Uncaught TypeError: e.on/off is not a function (and Object doesn't support property or method 'on' error) in Minerva

Uncaught TypeError: e.on is not a function
    jQuery 4
    OoRouter https://en.m.wikipedia.org/w/resources/lib/oojs-router/oojs-router.js?541b6:46
    emit jQuery
    OoRouter https://en.m.wikipedia.org/w/resources/lib/oojs-router/oojs-router.js?541b6:35
    jQuery 9
    OoRouter https://en.m.wikipedia.org/w/resources/lib/oojs-router/oojs-router.js?541b6:34
    <anonymous> https://en.m.wikipedia.org/w/resources/src/mediawiki.router/index.js?3b125:3
    <anonymous> https://en.m.wikipedia.org/w/resources/src/mediawiki.router/index.js?3b125:4

I did some debugging, thanks to the screenshot given above for "OxiClean" article from en->es. I used the translation debugger available at https://cxdebugger.toolforge.org/
Enter 1059523 as translation Id and press fetch translation button. Then go to Translation tab

This stacktrace is same as T262563: TypeError: parentDomElement is null / TypeError: data[i] is undefined at ve.dm.Converter.prototype.getDomSubtreeFromData

Created follow up tickets T267102: Migrate Special:CXStats to contenttranslation skin and T267103: Migrate Special:CX to contenttranslation skin for remaining items in this ticket.

The proposed approach looks ok to me and appreciate your offer to help implementing it. Ideally, an API as @Tgr mentioned would help us more to trigger these validations at client side and make abusefilter decoupled completely from CX. As the existing code shows, we need to do title validation and section content validation.

In T263093#6593534, @Jpita wrote:

@santhosh any hints on how I can test this?

@ngkountas I think we need to do some cleanup operation before we exit from browser to avoid this issues. Terminating the editing surface cleanly may fix this.

The rendering issue can be solved by just using a good quality font and latest version. There are many.

MediaWiki's code for minimumGroupingDigits in numeric formats has an off-by-one error: MediaWiki uses (for example) 2 for polish to indicate that 1000 shouldn't have a grouping separator, but the Unicode CLDR defines this as 1.

I observed that the recommendation api is quite unstable these days. https://es.wikipedia.org/api/rest_v1/data/recommendation/article/creation/translation/en?count=24 This is giving expected results today, but was failing yesterday.

In T259496#6500856, @ngkountas wrote:

In T259496#6498253, @santhosh wrote:

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@santhosh I think that there are three important differences between our current tab UI component and the desired one (at least for this case):

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@Pginer-WMF About the style for this tabs, do you see this as a tab UI component pattern or a new UI pattern? In dashboard, we have similar tabs(suggestions, published, in draft). Do you think those tabs and this should use different styling and UX? Asking this because, the Vue component need to be designed for that pattern. The way @ngkountas attempted to solve this is by reimplementing the tab component just for this screen. Is there a logic behind using #222 for highlighting pattern deviating from OOUI style

I propose adding the following too:

Error while reading config file: Error: ENOENT: no such file or directory, open '/opt/cxserver/config.yaml'

Thanks @Jdlrobson!. I will try to take it forward.

In T243495#6455216, @Jdlrobson wrote:

Definitely can help with that. When do you need to know by?

@Jdlrobson Can you please guide us with this approach? I am not familiar with skins system. If we create a new skin, wouldn't it be globally available? Can it be used for just a special page? Can you give some pointers on where to start?

In T260236#6380074, @sbassett wrote:

^ to follow up: I think we'd be looking for something a bit beyond the basic installation instructions, whether that's a docker or similar that works out of the box with minimal effort and no missing pieces (elevated rights, credentials, dependencies, etc). If the installation instructions can accommodate this (have not tried them yet), that's fine.

Screencast of cypress integration:

In my opinion, this is mostly about design vocabulary we want to follow. If we want a consistent design pattern where icons(in its purpose defined by design style guide) are always at the beginning of a component, there is no question of icons appearing elsewhere in the component. So icon not only get its position, but its meaning and purpose. Same for indicators.

In T241589#6402210, @Jpita wrote:

I cannot start a translation in https://sx.wmflabs.org/

After considering the complications, I changed my mind. Rather than developing a small hack router, it would be better to use vue-router itself. https://gerrit.wikimedia.org/r/621679 illustrates this.

In T254780#6395844, @kostajh wrote:

Thanks @santhosh!

nodejs and npm - if possible latest LTS versions.

Personally I lean towards providing instructions and tooling to use wikimedia/fresh. Consistency with CI would be a major advantage of going that route. I'm interested to hear what others think.

I created this page: https://www.mediawiki.org/wiki/MediaWiki-Docker/Configuration_recipes/Customize_base_image

One way to do this is modifying the mediawiki service in docker-compose.override.yaml as follows:

I am working on this. With https://www.mediawiki.org/wiki/Docker it is not much difficult to get Content Translation up and runnig with its database, cxserver instance. I will document it in detail at https://www.mediawiki.org/wiki/MediaWiki-Docker/Extension/ContentTranslation

Changed related to this ticket caused a bug in the Wikidata linking in ContentTranslation - T249458: ContentTranslation is not adding pages sitelinks to wikidata

Content translations, wikidata linking code depends the RL module mw.config.values.wbRepo. So please let us know the migration strategy too.