Page MenuHomePhabricator

Translate extension finds translation markup on JsonConfig pages
Closed, DuplicatePublicBUG REPORT


List of steps to reproduce (step by step, including full links if applicable):

  • Create a JsonConfig page (Data namespace on Commons)
  • Add "<translate></translate" to the page

What happens?:
The Translate extension adds the page to the list of pages proposed for translation. No other wikimarkup is evaluated in JsonConfig data, so the markup can't be escaped with <nowiki></nowiki> or HTML entities. JSON hex escaping is replaced prior to page save.

image.png (892×1 px, 185 KB)

What should have happened instead?:
The translate extension should ignore the markup.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

Event Timeline

I would need some help figuring out how to implement this. I could think of multiple different ways:

  • Exclude by namespace
  • Exclude by page content type
  • Hard-coded inclusions/exclusions
  • Configurable inclusions/exclusions
  • Extension-configurable inclusions/exclusions

The example page ( has the following properties:

  • Namespace: Data
  • Content type: Tabular.JsonConfig

I think whether page translation makes sense depends on the content type. In this case this coincides with the namespace, but it’s not necessarily the case: for example, page translation could be turned off on other JSON pages and CSS/JS pages as well. There are JSON and JavaScript pages in the MediaWiki and user namespaces (gadgets, user scripts, Common.js etc.), CSS pages in MediaWiki, user, template and module namespaces (gadgets, user styles, Common.css, TemplateStyles). The user and template namespace particularly often contains translatable pages, but I’ve seen translatable pages in the MediaWiki and module namespaces as well. It could be turned off on Lua modules, but not their documentation subpages, on which you worked hard to get page translation working (T258756).

Completely hard-coding the exemptions doesn’t seem a good idea: it could work well on WMF wikis and, but third-party wikis using extensions that aren’t used on WMF/TWN would need to constantly patch the extension. Extension-configurable inclusions/exclusions work best when the other extension’s maintainers care for Translate, LocalSettings.php configuration works better when they don’t. I’m not sure which of the latter two is the best solution.

Page content model would make the most sense to me. It would be easiest to just disable the Translate extension on non-wikitext content models. A configuration variable could be provided if an extension created a wikitext-like content model that would work with the Translate extension, but I don't see any on where Translate might be useful & would work without modification.

[…] page translation could be turned off on […] JS pages as well […]

I just found T163254, which asks exactly this.