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.

Patch 1 merged. The next step is to make top-viewed wikis correctly arranged according to users' locale.

@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!

Test environment: Chrome 101.0.4951.54 (Windows 10)

Patch is merged. The bot will build the portal next Monday, let's see whether everything works by the time.

In T305319#7828348, @Dbrant wrote:

these two variants doesn't have full conversion

Can you clarify what you mean by this? What specifically is not converted?
The different Chinese variants are absolutely intended for end users, so if something is not converted properly, we would like to know.

The problem was reported to be resolved a few days ago, hence closing this task.

In T284625#7559210, @dom_walden wrote:

In T284625#7559208, @Tranve wrote:

@dom_walden The patch has been merged and deployed to that site. To reproduce this bug, you should try at https://zh.wikipedia.org, which still uses an old version of MediaWiki yet.

Thanks. When I said

I can no longer reproduce the bug in the description.

I meant that as a good thing :) I was testing that I could no longer reproduce that bug.

In T284625#7559056, @dom_walden wrote:

I can no longer reproduce the bug in the description.

Closing this task due to the fact that Wikipedia has been blocked in all languages since Mar 2019, which leaves this task meaningless.

ESNI has been superseded by the ECH, hence updating the task.

In T244635#7505826, @Urbanecm wrote:

In T244635#7505821, @Shizhao wrote:

在T244635#7504225中，@Urbanecm写道：

Apart from the potential solutions you offered, simply copying RefToolbar's code to zhwiki space should workaround the issue. A simple IA-privileged bot should be able to maintain the page if so desired. Not ideal, but better than status quo I think?

Now only the cross-domain request for RefToolbar gadget has been found to cause this problem, but there are multiple scripts in zhwiki that have cross-domain requests. I’m not sure if there are other scripts that can cause this problem?

Yes, very likely requesting the same gadget from ie. cswiki would have the same implication (your computer making a request to cs.wikipedia, which doesn't let you to autocreate an acc., which logs you out).

In T171647#3679370, @Jdrewniak wrote:

@mxn good point on lang="nan" I'll revert that back in the patch here.
Also, to your point on yue.json and zh-yue.json, it looks like in this specific instance the translation strings don't collide, so these two files can be merged without much conflict, but in the future, if such a conflict did arise, like with lzh, I suppose the newer file could take precedence?

As for the language codes, I apologize for my unfamiliarity with what the correct mappings are. In chrome for example, zh-tw is described as "Chinese (traditional)" which I assumed could be mapped to the zh-classical wiki. As is stands though, I'm still not sure for what browser language codes we should be showing zh-classical wiki in the top ten.

For the rest of the Chinese language codes, would the following mapping be correct?

browser code	translation file
zh zh-hant	zh-hant.json
zh-hans zh-cn zh-sg	zh-hans.json
zh-hk	zh-yue.json + yue.json

Currently, we're only serving the zh.json file for anyone who has a zh-* browser language. The zh-hant.json file seems to be a more complete translation than the zh.json file, would it be preferable to serve that in place of the zh.json? or should we combine the two?

I'm commenting here due to no replies in this task.

In T153367#7139776, @BrandonXLF wrote:

In T153367#7137447, @Tranve wrote:

More styles should be added to improve the appearance, and wikipage.content hook should be fired.

What's wrong with the appearance that needs improvement?

@Aklapper Sorry for inconvenience, I've updated the description to provide more details.

More styles should be added to improve the appearance, and wikipage.content hook should be fired.

As a discusser of this problem on zhwiki, I'd like to provide more information:
First, the problem is not only related to ActionFieldLayout, ButtonGroupWidget (with a non-label icon-only button and a button with label inside) is also affected.
Second, the problems always exist on zhwiki (without changing browser's font size). There's a default gadget enlarging the article area's font size in zhwiki (link here), which is considered the cause of the problem.
Third, here're two photos describing the problem before and after disabling the gadget.

After disabling the gadget, the widget aligns as expected.

With the gadget enabled (large font), the widget doesn't align properly.