In T268872#7012318, @Jpita wrote:

Can be tried by pasting { "html": "<span typeof=\"mw:Transclusion\" data-mw=\"{}\" id=\"mwCH0\">" } as the request content at https://en.wikipedia.org/api/rest_v1/#/Transforms/post_transform_html_to_wikitext.

trying this method I get an error

{
  "type": "https://mediawiki.org/wiki/HyperSwitch/errors/unknown_error",
  "method": "post",
  "uri": "/en.wikipedia.org/v1/transform/html/to/wikitext"
}

is this expected?

REST endpoints for alt.wikipedia.org is not functional - https://alt.wikipedia.org/api/rest_v1/?doc. That is unusual. I expect this is taken care as port of wiki creation automation.

A rough outline of MT integration:

I see that https://github.com/hfst/hfst/issues/494 is closed now. Does that unblock update?

@Pginer-WMF A nuance I noticed while working on this is, while publishing, we cannot give options for chosing target under Username. Should we hide the publish options altogether or remove that particular option alone? I prefer hiding publishing options(the cog icon) since there is nothing else to chose in this case.

In T278141#6957098, @colewhite wrote:

In T278141#6949288, @colewhite wrote:

@santhosh I could not replicate the problem. Please advise on how to replicate?

Oh right, it's still in the branch in the template. You can use this code https://github.com/wikimedia/service-template-node/pull/148 to see what needs to be done.

@Pchelolo We just updated the service-runner library to 2.8 and then followed the migration guide to update the metrics reporting interface(https://gerrit.wikimedia.org/r/c/mediawiki/services/cxserver/+/670441/). cxserver is an existing project(since 2014), so the template project cannot be used as such, but can be referenced for these changes.

cxserver_robots_txt_GET_200 Metric autogenerated by statsd_exporter.
cxserver_robots_txt_GET_2xx Metric autogenerated by statsd_exporter.
cxserver_robots_txt_GET_ALL Metric autogenerated by statsd_exporter.

@Pginer-WMF, in the current implementation these warning or error is shown when the user click on publish button. Is that the expected behaviour? Should we display the error or warning along with the publish preview? That is, when user press "Done" button in previous screen?

One possible way to do this is to rewrite all asset paths to vite development server(example: localhost:3000/path/to/assets/module.js) in debug or development mode. A simple example of such PHP+Vite example is given at https://github.com/andrefelipe/vite-php-setup/blob/master/public/helpers.php

You are right. Async is not a keyword supported by minifier. It just came into bundle because of our browserslistrc configuration lists browsers supporting them.

I created a minimal testcase which can reproduce the issue.

(function () {
    async function f() {
        return Promise.resolve([]);
    }
    var a = function () { }
    var b = []
})

Running this through wikimedia/minify/bin/minify produce the following output

Unassigning from me since I am not actively working on this part at this point of time

Also see T272879: Migrate WVUI library to Rollup or Vite

Explicitly exlcuded IE11 from supported browsers and there is a gain in bundle size now since some polyfills are removed. . New report:

Very minimal content that cause this error <span typeof="mw:Transclusion" data-mw="{}" data-cx="[{&quot;adapted&quot;:false}]" id="mwCH0">

I did an analysis using webpack bundle analyser.
Here is the html report

Here is a screenshot based on the patch from my development environment. The cx specific skin is based on the SX design and hence the small visual changes. Since the SX's modern codebase will be eventually used for replacing CX's old codebase, @Pginer-WMF can confirm if this is ok.

I chose this ticket before T267103: Migrate Special:CX to contenttranslation skin so that we can test this low traffic page thoroughly before going to high traffic Special:CX

The error is coming from VE code, so I assume the user at this point was editing the section.

Closing this as we have first iteration of section translation and enabled in one wiki after reviews. We can create follow up tickets as needed for further iterations

After fix

Perhaps we need to work on frontend build system first and then apply that to WVUI? or generalize the requirements before we pick one for WVUI? Or do you think the bundler for WVUI can be independent of MW frontend build tooling? I think it is possible technically, but might not be wise choice for a coherant frontend architecture.

@egardner, While rollup is a better choice here, one major drawback to resolve here is lack of Hot Module Replacement that has negative impact on developer experience and speed. There is no good solution of HMR in rollup since it is just bundler. There were some attempts like Nollup, but recently Vite solved this issue. Vite internally uses rollup for bundling, but does extra magic for fast HMR.

Hi @sbasset, We are ready for the security review.

The issues seems quite random. Publishing usually works fine - So it is not like the error is always happening.

@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