Subscribing shizhao as he participated in a related discussion on Telegram.

The new one works much better in that it also knows how to split words. (search ”中国大陆电台干扰“, expect ”中国无线电干扰“) Great work!

The entire w:zh:H:AC page is worth translating into an independent page for LanguageConverter. mw:Writing systems/Syntax should probably be moved to a page under the new LC page after its created. "User friendly" or "cheatsheet" info in w:zh:Help:手工字詞轉換 should be merged into the Syntax page. Some big good TODOs.

To be fair, the syntax page mainly talks about user usage and behavior (well that's not thoroughly documented either), not the actual internal classes used for implementators working on actual classes. Dev docs should probably just go into the source as comments so they are available in doxygen. Patchy-patchy time for T21044.

I believe this is intentional given the unidirectional setting. The original programmers intended to mainly provide variants instead of scripts for Chinese, since:

This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

No longer reproducible on zhwiki. Test procedure:

In T160830#3112268, @Izno wrote:

An alternative fix on the CSS level would be doing clear: both to transfer the blame away from reference wrappers.

I don't see how that fixes the possible objection

@zhuyifei1999, the new revision (6) should have fixed the problem. Would you like to give it a try? I wrote a somehow nobody-wants-to-reuse function, but got rid of the XXX: note in the process.

In T160498#3101303, @TheDJ wrote:

mw-columns-narrow

Confirmed fixed: result contains section markers and many sentences.

Patch for testing submitted. Use it as a proof of concept, and don't expect it to pass human review. (Ugh, PHP bites harder than snakespeak!)

Since the 2 thing is nevertheless weird (UTF-8 won't let ASCII characters appear from nowhere), I modified my second mini-repro to use an h3 heading. Very curiously, it now says ��3 near the end.

With a longer extract length (256) set, and using &utf8 for readability, \n\n\n1 历史 appeared in place of the \n\n��2� markers. Using &exintro kills the FFFD as expected as that's where the lead section ends. Using a length of 129 gives `\n\n\n1. A length of 127 or 126 takes the last FFFD into the ellipses but keeps the 2, and 125 takes away �2, leaving a single FFFD.

It might be possible to mention the possibility of customizing the column-width for individual wikis via site-level CSS (rationale being they may have different averages for citation line lengths) while also mentioning mobile page width as a caveat in the documentation. This way MediaWiki itself may avoid changing the 35em value, which may have been determined as, say, a good enough value for most wikis.

Ah, a more careful look at https://m.mediawiki.org/wiki/User:Artoria2e5/t1 shows the references is actually present. It's just the .content element being fixed to a max-width too small for the effects to show up. Should I still consider it an interoperability problem?

@TheDJ You and I may want to hijack this issue to make it target the entire ol.references though. Targeting the conditionally-appearing div is problematic...

of div.mw-references-wrap

In T33597#3100752, @Cwek wrote:

Hi, on zhwp there seems to be still some good amount of confusion among almost-techy (bot-capable) users (including sysops, sadly), so I added a paragraph in the document to clarify the process up. Please find some time to review these changes, possibly perform some copyedit, and ideally mark these text for translation. Pretty sad to see people opposing stuff with questions in mind.

In T148693#3090260, @Shoichi wrote:

No matter how many sites connect to the server, they share the same cache.

The current "bad words" list contains a mix of simp/trad versions for these "steal QQ account" stuff. Are these duplicates necessary, or can the module figure out as mentioned in T110841?

It appears that the common word stats is quasi-incorrectly segmenting chinese words into single characters. Have you looked into anything like https://github.com/fxsjy/jieba for proper, pre-trained Chinese word segmentation?

In T117945#3046773, @Liuxinyu970226 wrote:

At least this isn't happened on eowiki, happy now?

Liuxinyu970226, this problem seems to affect all sites independent of language settings. Are you sure you are going to tag all languages that often use titles with non-ASCII characters?

Because that's the wikipedia site name assignment, and human may or may not
know to actually check the option values…

@West.andrew.g's FFFD count seems to match up with UTF-8 byte count (verified with '\u2013' in [[Obsessive���compulsive disorder]] and 'é' in Milowent's "Murder of JonBenét Ramsey" example; matches up with others). Therefore accidental, file-level truncation is likely not the cause for him. (UTF-8 is pretty resilient and self-synchronizing anyway. Per-byte truncation when decoding may still be the cause (Failed UTF-8/ASCII out-of-range). "Forced ASCII" locales like C (aka POSIX) in glibc can cause issues somewhere too.) There are also some ??? sequences in west.andrew's page that appear analogous to � in terms of byte count behavior.

In T135575#2939664, @TTO wrote:

I've written a patch that does this, and I'll upload it in a moment.

Apologies for my habit of doing post hoc additions, but I happened to address what you have been talking about before seeing your comment. Artoria has decided to abstain from further discussions on this topic for a nice nap in her box. (Noisy human.)

In T135575#2939526, @Liuxinyu970226 wrote:

That conflicts System messages style

Regarding re-titling, I guess my initial "multi-column" title summarizes it better. Not all possibly messed-up wikis use fullwidth indicators; hakwiki, for instance, uses more than one latin character for each indicator.

Just noting here, I'm opposed to ditching language neutrality unless there is absolutely no other way to fix this.

Then I refuse to submit a very trivial patch without sufficient expressed support.

Converging on a resolution is required for a technical solution. I have not seen any non-zh user speaking, let alone the fact that nobody has expressed their thoughts on ditching language neutrality for a quick workaround. Other WMF wikis that potentially suffer from this bug include kowiki, jawiki, hakwiki, etc., but nobody from these wikis has yet spoken.

2017-01-14, too lazy to add a comment:

Ugh, OK. What a mess.

Regarding marking translated comments, consider using something like /*e to
replace /**, and //e to replace ///. This would allow easy English javadoc
generation with some quick sed-work.

but even identifiers are in Chinese in some places

Adding zhwiki tracking per VPT (check VPT archives if you can't find the anchor).

In T135575#2622771, @Liuxinyu970226 wrote:

There's no multicol-indicator-charrange-friendly existing, let's err... get rid of such confusing context-context-...-context in the next time please?!

Good, break it down, break it down.

Such a request seems fundamentally unsound as LC kicks in some very final step currently:

When will this patch get merged?

Looking for sectionId does not give anything special on the JS side, but it could be something wrong in the backend too. Is the query in includes/TranslationStorageManager.php case-sensitive or insensitive?

In T33791#2315571, @Liuxinyu970226 wrote:

Could you please give me another demo about this method? http://fonttailor.wmflabs.org/ no longer possible to visit.

The large size might be avoidable by slicing the webfont into smaller units of e.g. 256 glyphs and merging the slices back into one font in css using unicode ranges. This may have some advantages over 'tailored' subsets as it provides some possibility of reusing among pages, and this reduces the need of having dynamic magic too.

Regarding zhwiki, a space is needed if $group[-1] is alphanumeric (otherwise [foo_999 1] -> [foo_9991]). Some simple "change-the-blank-string" config will not be enough for this.