For everyone's info, F-droid has been blocked in China now.

@Quiddity I think it's unrelated. Looking at Pygments I cannot find lexers for html5 and html4strict, and looking up in the release notes I cannot find relevant information either.

I hope WMF can participate in this project with the community since such a portal is hard to maintain solely by the community itself.

We could probably migrate to Vite and Vue and use SSG to generate a static site.

As the author of this task, I'll close this issue as declined in favor of T327286

Okay, let's keep the discussion on topic. Which gadgets are the blockers? Who should be responsible, and how to fix them?

Some thoughts:

1. It's not promising to rely on censorable but not yet censored platform (like Toolforge). We should use censorship-resistant platforms, typically to rely on large entities which government cannot easily block. (See also T327286)
2. We should find a balance between security/privacy/anonymity and convenience. Use as less custom software as possible. The more complex the procedure is, the less a user will be willing to join. Anything involves money transfer should be avoided.
3. Such portal may collect sensitive personal information. Does WMF privacy policy apply here? Which platform will it run on? I think this needs wider discussion.

In T335886#8926426, @Hamishcn wrote:

However I do think the deployment date shall take the local consensus into consideration. If this is Foundation's official plan, I sincerely invite your team to notify our community at zhwiki Village Pump, as the new skin is really incompatible for many gadgets/tools. Thank you.

In T338743#8921397, @TheresNoTime wrote:

Could you link to your user account please?

In T338743#8921376, @RhinosF1 wrote:

Is this request for a specific site like zhwikipedia or all zh language wikis?

A bunch of gadget compatibility issues should be resolved before the deployment.

jquery.tipsy is used by a default gadget on Chinese Wikipedia providing cross-language link support, which has wide usage in the wiki.

I can completely understand your team's eagerness to put Vector 2022 into wider usage, but I also hope that community consensus is respected in such case.

It looks like we can just mark lexers in "non-HTML markup languages" category (https://pygments.org/docs/lexers/#lexers-for-non-html-markup-languages) to generate RTL content by default in a RTL wiki. @bd808 Is it technically feasible?

Hmmm, from my intuition, we should set up a config file telling which Pygments lexer is "ltr-only" (e.g. JavaScript) or not. (e.g. Wikitext)

In T335930#8825488, @stjn wrote:

Could be done by adding a style direction: inherit for .mw-highlight-lang-wikitext class, which would override dir="ltr" definition.

@bd808 From my testing single quotes also work as lang='xxx'. I think those cases need to be searched too.

Use {{#tag:syntaxhighlight}} mentioned here.

In T334137#8783024, @Iniquity wrote:

Draft for Tech/News
Later the SyntaxHighlight extension will start supporting wikitext markup as the corresponding Pygments library has been updated. You will be able to use the new highlight by selecting the language wikitext or mediawiki. Old highlights used to replace wikitext highlights, such as html5, moin, html+handlebars, could be replaced.

Check this text plz :)

Tracked in T298399.

Upstream PR is merged, now waiting for a Pygments release so we can bundle it in MediaWiki.

That list is just for everyone's reference. They may not work in China currently, but we can possibly leverage their technique.

@Tgr This ticket is for evaluating Turnstile's use at Wikimedia websites, not just implementing it in MediaWiki.

In T305319#7832921, @cooltey wrote:

Moreover, after removing them, we should decide what to do with existing options where users have chosen zh-hans and zh-hant as their preferred languages.

Before we have provided the full Chinese language variants options in the app for over one year, the zh-hant and zh-hans were the original ones that were the available Chinese language variants options in the app.

Not sure what would be the default region-wise language variants for Traditional Chinese and Simplified Chinese, and I think it is not appropriate to change them automatically without notifying the users.

I suggest keeping the current setting which shows the entire list of language variants but also introducing a toolbar or some other messages interfaces that can inform the user about language variants options.

cc @JTannerWMF

Another potential risk is that integrating censorship evading measures may cause the iOS app to be removed from China App Store. I'm not saying we should not add this -- censorship poses a risk to us all and we should resist, but I'd rather be cautious and think about wise and lasting solutions, so it won't be a waste of money.

...but the word 'domain fronting' is usually connected with the use of clouds and CDNs.

Domain fronting takes the advantage of collateral freedom, but unfortunately I cannot see much damage for the government to block Wikimedia IPs. Yes, for a medium term this is a feasible approach, but it costs nearly nothing for the government to block an IP, but changing one costs a considerable amount of resource. What should we do if all IPs are blocked in the future?

Upstream PR: https://github.com/pygments/pygments/pull/2373

I have been working on this for quite a while. Now I am going though a bunch of tests, hopefully a PR would be filed soon.

I have created https://zh.wikipedia.org/wiki/User:Diskdance/public/T306862_test for testing, and found this inconsistency (same in Vector 2022):

Just curious, can this task be closed without a proper QA? We can confirm it works as expected on Chinese Wikipedia.

@Edtadros As a Chinese speaker I can confirm it is correctly converted.

FYI, TypeScript definitions of OOjs and OOUI are published at DefinitelyTyped and available on npm:
https://www.npmjs.com/package/@types/oojs
https://www.npmjs.com/package/@types/oojs-ui

Apologies for my ambiguous wording in my last reply.

@bd808 In my use case the only objective is to check whether you can successfully receive a response from w.wiki regardless of what it is. This helps users figure out, for example, if it is DNS poisoned or interfered by state censor in any manners. Thank you for your clarification anyway.

In T319155#8280970, @bd808 wrote:

The Toolforge CSP header is in report-only mode, so nothing is actually blocked by it. I do hope to one day put the policy into enforcement mode however, so this is a reasonable request.

@Diskdance could you provide a little more detail of what sorts of interactions you would hope to have with the w.wiki domain from a Toolforge hosted tool that a Content-Security-Policy header would be able to block? I ask because my current general understanding is that w.wiki is the domain used for Extension:UrlShortener generated links in the Wikimedia movement related deployment on metawiki. This does not seem to be a domain that is actively used for API calls or static asset delivery which are largely the actions intended to be restricted by a CSP header.

In T316465#8198466, @Jdlrobson wrote:

I don't completely understand this. On https://fr.wikipedia.org/wiki/Conf%C3%A9rence_de_Kreuznach_(19_d%C3%A9cembre_1917) if I click "hide" on table of contents and collapse the sidebar doesn't the same behaviour happen?

Yes! Apologies for that and I have added that scenario in the task description.

@Ladsgroup Hi, do you have any idea on this?

Hi @abi_, thank you for your response! I have added message documentations. Then how can I give twn bot push access to my repo? By giving then collaborator rights?

By the way, I want to emphasize that QUIC encrypts initial packets of a connection. Even though its key is known, as a result of it, QUIC is more censorship resistant in many ways.

In T312212#8066295, @alexhollender_WMF wrote:

@Diskdance thank you for reporting this issue.

@Jdlrobson looking at the screenshots it seems like we lost ~25px of spacing.

In T273179#8048062, @Ladsgroup wrote:

In T273179#7960028, @Diskdance wrote:

@Ladsgroup Hello! I'm sorry but I think the deployment process of wikibooks.org should be delayed because it doesn't serve Chinese translation correctly, and its top 10 wikis are not rearranged by users' locale. Wiktionary.org has the same issue. Please see T308009 for more details. Thank you!

Thanks to your patch, those seems to be fixed now. I do see zhwiktionary in wiktionary.org now. Shall I move on with the work?

I am interested in porting {{NoteTA}} and CGroup module from Chinese Wikipedia to translatewiki.net to better support Chinese variant conversion. Both of them are written in Lua because of their size.

Most of translation problems have been fixed now, but it is still problematic when Chinese is not in the top10 area. To fix this some abstraction and cleaning up is needed. See T311361.

@Jdlrobson Does the new ToC use Parsoid? IIRC Parsoid is not able to handle Chinese variant conversion properly now.

For everyone's information, CodeMirror 6 has been stable now:

If we find out it's somewhat complex to implement this completely in the future, can we sync the search keywords only, at least?

@Jdrewniak Sorry to interrupt, but can I use ES6 features like arrow functions, Promise and fetch() in portals' code?
I have encountered a problem that, there is an asynchronous XHR in topten-localized.js and we must ensure that its execution is completed before that of PerformChineseConversion(), but it is not easy to achieve the effect.
I think the best approach is to convert code in topten-localized.js and page-localized.js to use Promise chains, which are not supported in IE11. Since IE11 has got its special treatment, can we just break support of it and use those modern stuffs? Thanks.