Right now, typing a <translate> tag on a script page (as in, a page ending with .js in userspace or Mediawiki-space) makes the translate extension kick in, which means it's impossible to save the page with unbalanced tags.
It'd be good to implement some kind of disabling technique to prevent having to use ugly workarounds like groups and such (e.g., /(<)(translate>)/ or "<tran" + "slate>".
With script pages, do you mean user page subpages ending in .js and MediaWiki namespaces pages ending in .js, or something else?
Change 444549 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/Translate@master] Disable Translate extension on non-wikitext pages
Change 444549 abandoned by Matěj Suchánek:
[mediawiki/extensions/Translate@master] Disable Translate extension on non-wikitext pages
Reason:
Probably not the best way to do it
Change 718014 had a related patch set uploaded (by AntiCompositeNumber; author: AntiCompositeNumber):
[mediawiki/extensions/Translate@master] PageTranslation: Prevent non-wikitext pages from being marked for translation
Can we have a list of non-wikitext pages across Wikimedia that are currently translatable? I recall seeing some smart solution, but I don’t even remember on which wiki, and I can’t query them on Quarry due to T290378.
There isn't an easy way to do that, since there's also no simple API to list translation source pages. However, I did find out in testing that the translation pages keep the same content model as the source page, so we can use the hack of looking for /en subpages to find most translation pages. That will show some false positives of course.
Queries for the content wikis with $wmgUseTranslate: commons meta mediawiki testwiki wikidata wikispecies wikisource betawikiversity incubator frwiktionary
I found the following:
Everything else on commons, meta, mediawiki, testwiki, and incubator were manual translations or Flow talk pages, all other queried wikis had no results.
Actually there is (see the noticeboard I linked in T290378), it’s just not available for those who haven’t signed a non-disclosure agreement with Wikimedia…
However, I did find out in testing that the translation pages keep the same content model as the source page, so we can use the hack of looking for /en subpages to find most translation pages.
And has it been so ever? What I recall was years ago. (Of course, this also makes more probable that I recall it incorrectly, or that the hack was removed since.) If a translatable page hasn’t been changed for years, its /en subpage won’t have correct content model unless it was set correctly years ago.
That will show some false positives of course.
And it may have some false negatives as well (although what I recall is certainly not among them): while the vast majority of translatable pages are English, not all of them, there are a few pages that are translated from another language, and if they haven’t been translated into English, they won’t be found by your queries.
Queries for the content wikis with $wmgUseTranslate: commons meta mediawiki testwiki wikidata wikispecies wikisource betawikiversity incubator frwiktionary
I found the following:
- https://meta.wikimedia.org/wiki/Module:Date/sandbox, a sandbox where @Pols12 was trying to translate 2 error messages
- https://test.wikipedia.org/wiki/User:AntiCompositeNumber/TestTranslationContentModel.js, my test page to make sure the query was working
Everything else on commons, meta, mediawiki, testwiki, and incubator were manual translations or Flow talk pages, all other queried wikis had no results.
Thanks! Even though I have some concerns above, I’m more confident with these queries that nothing will break.
Coming at it another way, I used Global Search to look for \<translate\> in all JS, CSS, and JSON pages and the entire Module namespace on all public Wikimedia wikis.
Generated using Wikimedia Global Search on 2021-09-04 17:37
| Wiki | Page title |
|---|---|
| commons.wikimedia | Help:VisualFileChange.js |
| www.mediawiki | Manual:CommonElements.css |
| meta.wikimedia | User:Kbrown (WMF)/autoTranslationMarkup.js |
| test.wikipedia | User:AntiCompositeNumber/TestTranslationContentModel.js |
| www.wikidata | User:Yangxiansen888/vector.js |
| meta.wikimedia | User:Jeph paul/joinInterfaceMessages.js |
| meta.wikimedia | User:JSutherland (WMF)/autoTranslationMarkupClean.js |
| meta.wikimedia | User:Kbrown (WMF)/autoTranslationMarkup.js/sandbox.js |
| meta.wikimedia | User:Jeph paul/endorseConfig.js |
| meta.wikimedia | User:JSutherland (WMF)/autoTranslationMarkup.js |
| meta.wikimedia | User:Precious.in1derland/vector.css |
| meta.wikimedia | User:Jeph paul/joinconfig.js |
| meta.wikimedia | User:Kbrown (WMF)/autoTranslationMarkup testing.js |
Generated using [https://global-search.toolforge.org/?q=%5C%3Ctranslate%5C%3E®ex=1&namespaces=828%2C486&title= Wikimedia Global Search] on 2021-09-04 17:41
| Wiki | Page title |
|---|---|
| www.mediawiki | Module:Transcluder/doc |
| www.mediawiki | Module:Yesno/doc |
| www.mediawiki | Module:Template translation/doc |
| www.mediawiki | Module:No globals/doc |
| www.mediawiki | Module:Arguments/doc |
| www.mediawiki | Module:String/doc |
| www.mediawiki | Module:Message box/configuration/doc |
| www.mediawiki | Module:Version/doc |
| www.mediawiki | Module:Tmpl/doc |
| www.mediawiki | Module:Message box/doc |
| www.mediawiki | Module:Int/doc |
| pl.wikimedia | Moduł:ModuleMsg |
| meta.wikimedia | Module:Date/sandbox |
Only new-found potential problem is https://meta.wikimedia.org/wiki/Special:PrefixIndex/User:Jeph_paul/ "Luckily" for the purposes of this task all the arbitrary translated javascript is stored as Wikitext, and the two actual JavaScript files are not directly translated. Of course this means there is no protection for the arbitrary javascript loaded and run by the script whatsoever, and is a terrible idea that I'm probably going to have to go find someone to clean up, but this task won't break it. Yay! https://meta.wikimedia.org/wiki/Special:PrefixIndex/Meta:AddMe/ is similar but at least it loads the wikitext as JSON instead of arbitrary javascript. T238386 T156210
Everything else is just doc pages or <translate> used as a string, not as markup to be parsed.
https://meta.wikimedia.org/wiki/Module:Date/sandbox, a sandbox where @Pols12 was trying to translate 2 error messages
I don’t remember the result of this test. However, I have also tried to use Translate in JSON page: meta:Template:Years_or_months_ago/l10n.json. It is parsed as JSON by meta:Module:Years or months ago. However, this does not work when the content model is JSON, so I use wikitext content model.
Solving this task should not create an obstacle for T156210 or T155100: instead of fully disabling Translate extension on non-wikitext pages, we could create a keyword {{DISABLETRANSLATE}} which would do the job, for example.
Magic words work only in wikitext, which is exactly the content model we don’t want to disable Translate for. Also, the current implementation is only about page translation, i.e. <translate> tags, and as far as I see, T156210 is not planned to be resolved with page translation, while T155100 is not even possible (page translation puts translation on subpages, while tabular data / Module:TNT uses one page for all translations).
Tested the patchset #6 - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/718014/6
Should be allowed to save a page with unbalanced translate tag if the page content model is not Wikitext
Did not expect an error, anbd expect the page save operation to work.
Error: Unbalanced <translate> tag.
PageTranslationHook::tpSyntaxError checks for TextContent.
Should not see a "Mark page for translation" header.
As expected
Change 718014 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] PageTranslation: Prevent non-wikitext pages from being marked for translation