Page MenuHomePhabricator

Scribunto: Logic works in Preview but fails on Save, creating ghost category links at ko.wiktionary
Closed, DuplicatePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Create or edit any new page on the Korean Wiktionary. (e.g. https://ko.wiktionary.org/wiki/가로수)
  • Add content that invokes a headword template, which in turn uses Module:headword. For instance, add ==한국어==\n{{ko-noun}}.
  • Click the "Show preview" button. Scroll to the bottom and observe that no incorrect maintenance category appears. The result is correct.
  • Now, click the "Publish" button to save the page.
  • Observe the newly created page. A maintenance category link, 분류:잘못된 언어 헤더가 있는 한국어 항목(Category:Korean entries with incorrect language headers), has now appeared at the bottom.
  • Click on that category link. Observe that the category page itself states it is empty ("This category currently contains no pages or media.").

What happens?: A "phantom" category link appears on the saved page, even though the preview for the exact same wikitext showed no such category. This happens on 100% of pages that use the module. Although the articles link to the category, the category page itself reports that it contains no members. This creates a fundamental contradiction between the rendered article and the wiki's database state.

What should have happened instead?: The saved page should look identical to the preview. No incorrect maintenance category should appear, as the underlying logic for adding it is demonstrably false.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia): WMF-hosted wiki(ko.wiktionary)

Other information (browser name/version, screenshots, etc.): I am a non-technical user with no programming background. I am reporting this issue because I encountered it while trying to import the Module:headword from the English Wiktionary to the Korean Wiktionary. I have been using an AI to help me debug, as I cannot read or write the code myself.

The whole situation is extremely confusing to me for a few reasons that just don't seem to make sense:

  1. The "Preview" button shows everything is fine. When I edit a page and click "Show preview," the error category at the bottom disappears, just like it should. But the moment I click "Publish," the error category comes right back on the saved page. It feels like the preview and the final result are showing two different things for the exact same text.
  2. The category is a "ghost." All the articles have a link to the error category, making it look like they are part of it. But when I actually click the category link, the page says "This category contains 0 pages." It's a contradiction—the articles claim to be in a category that claims to be empty.
  3. The module's own report says it's working. The AI helped me add a "debugger" that prints a report right onto the page. I've attached that report below. I'm told this report shows that the module is correctly identifying the texts as identical and that the final line, IF condition...: false, means it decided not to add the error category. But it adds the category anyway, right after showing this report.

This is the part I truly don't understand. The module's own output proves it shouldn't be adding the category, yet it does so immediately after I save the page. As a non-programmer, I'm completely at a loss and believe this must be some kind of deeper system bug.

Here is the debug report that the module is generating:

  • Debug Output for page 가로수 (Korean entry):

[Final Root Cause Analysis]

  1. get_current_L2() (From page header)
    • Type: string
    • Content: "한국어" (Korean)
    • Bytes (HEX): ED 95 9C EA B5 AD EC 96 B4
  1. data.lang:getCanonicalName() (From language module)
    • Type: string
    • Content: "한국어" (Korean)
    • Bytes (HEX): ED 95 9C EA B5 AD EC 96 B4
  1. Comparison Analysis
    • Simple comparison (A == B): true
    • Comparison after NFC normalization (toNFC(A) == toNFC(B)): true
    • The actual IF condition (toNFC(A) ~= toNFC(B)): false
  • browser name/version : Chrome/Version 141.0.7390.76 (64bit)

Event Timeline

You should ask these questions on the module's home wiki's talk page. They may be able to assist better than the audience usually-unfamiliar with modules on Phabricator, but beyond that this module appears to be quite complicated.

Following the advice given here, I opened a discussion on the English Wiktionary's Grease Pit.

The cause has been identified: the issue is triggered by the Parsoid. The module uses a hack to determine its page context, which fails under Parsoid. I can confirm that disabling the Parsoid and switching back to the legacy parser makes the problem disappear completely.

While a local workaround (commenting out the feature) exists, the underlying incompatibility between Scribunto's capabilities and Parsoid remains.

Related Discussions: https://w.wiki/Fgt6

T384060: enwiktionary: Parsoid's output includes self-links for fragment links unlike legacy output is the issue on enwiktionary that fails because of using this same hack. We haven't yet figured out how to solve this issue.