Module talk:Fallback

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Good idea[edit]

Zolo, I like the idea of redesigning those templates and I an glad you have tacked it. --Jarekt (talk) 14:10, 20 November 2013 (UTC)

Thanks, that was not super-easy for me, but I think it finally works ! I have left a message at template talk:Fallback. --Zolo (talk) 16:50, 20 November 2013 (UTC)

Very nice, indeed. Just if you feel bored: Niklas made a nice graphic: File:MediaWiki fallback chains.svg. I would welcome if we could put the data into a separate module and load it with fallbacks = require('Module:Fallbacks') or similar so we can re-use this in Module:Languages, for example. -- Rillke(q?) 18:26, 21 November 2013 (UTC)

Thanks, that seems reasonable. Actually, it seems that the current list is incomplete and I am wondering if there is a way to make use of some mediawiki built-in feature. It seems that there is a working fallback mechanism independent from getFallback for messages in the mediaWiki namespace or translate through Translatewiki (note that it seems incomplete too: [artwork in Corse] shows the message in English instead of French even though the fallback to French works for [Tahitian]). --Zolo (talk) 07:45, 22 November 2013 (UTC)
gerrit:96981 -- Rillke(q?) 11:54, 22 November 2013 (UTC)
Thanks, but I am not sure Italian is the right choice. The language seems to be closer from Italian than French, just about everyone who can speak Corsu speaks French fluently, and I do not think most of them can speak Italian (we already have Tahitian -> French because Tahitian people can speak French, even though the languages are completely different). --Zolo (talk) 12:14, 22 November 2013 (UTC)
Interesting, after a quick glance, I had the feeling, the language is a lot closer to Italian than to French but this is maybe not the only criterion for a fallback, as you say, one has to consider what people are actually also speaking. Feel invited to comment over there! -- Rillke(q?) 12:19, 22 November 2013 (UTC)
I have left a message at their main talk page, but it seems that there is at most one registered native-speaker active at the moment ([1], [2]).
Looking at File:MediaWiki fallback chains.svg we have may be half of the fallback connections mentioned there. Shall we add the rest? Also it looks to me that a lot of connections are between "xx-yyyyyy" languages and "xx" base languages may be such connection should be a default. I would also propose that Module:Fallbacklist would not be just a list but also a short bare bones function to create list of fallbacks for each input language. --Jarekt (talk) 19:19, 22 November 2013 (UTC)
Hmm. I like if data is completely separated from functionality. This allows you, for example creating bots regulary updating this list or such. -- Rillke(q?) 19:53, 22 November 2013 (UTC)
OK, although I can not think of need for updates since languages should not be changing much, unless we are synching it with some other list, but than may be we can just use the original. How about synching with File:MediaWiki fallback chains.svg connections? --Jarekt (talk) 20:54, 22 November 2013 (UTC)
This seems to be the easiest way, unless someone wants to write a parser for all files in that directory. The $fallback variable defines MediaWiki's behaviour. Should we also file a bug/feature request for Lua/Scribunto for an API that we do not have to maintain? -- Rillke(q?) 00:15, 23 November 2013 (UTC)


What's the issue with'Module:Fallback').exists

except that it is expensive, but #ifexist is also… -- Rillke(q?) 08:54, 25 November 2013 (UTC)

Defintely better. It's just that I had seen somewhere that "ifexist" was not supported in Lua and did not investigate further... --Zolo (talk) 09:35, 25 November 2013 (UTC)

Customized fallbacks[edit]

I have no knowledge of Javascript, but I am wondering if it would be possible to have a tool that would allow user to create their own fallback list instead of retrieving in from Module:Fallbacklist. --10:28, 25 November 2013 (UTC) That said, it would have to work for message from the mediawiki namespace as well otherwise, that may look a bit strange. --Zolo (talk) 10:31, 25 November 2013 (UTC)

JavaScript is processed 100% client side in your browser while LUA-processing is done 100% server-side. I cannot imagine how this should work, especially in regard of how MediaWiki with its parser-cache works: Each page is cached for every language but not per user. JavaScript would have to switch the language at the client side, if required, which in turn means either outputting all languages through the LUA-module or having to make an extra XHR with JS, resulting in a notable delay until the translation appears. -- Rillke(q?) 10:36, 25 November 2013 (UTC)


See Commons talk:Lua --Jarekt (talk) 19:46, 25 November 2013 (UTC)

User:MIT Harvard Observatory/Treemap-index "no fallback page found for autotranslate"[edit]

User:1Veertje made a very useful color index for graphics in Category:Treemaps on Export, but it shows only "no fallback page found for autotranslate". I have no idea how to fix this. Can you help? --Atlasowa (talk) 11:29, 6 December 2013 (UTC)

Same for {{/Header}} at COM:UH. -- Rillke(q?) 11:30, 6 December 2013 (UTC)

I wonder whether it was ever supposed to work with something not being in the template namespace. -- Rillke(q?) 11:39, 6 December 2013 (UTC)

The former version of {{Autotranslate}} used "{{base}}"rather than {{Template:base}}. It means that, even though "Template:" was added when the base name did not contain any namespace, it also supported other namespaces. I do not think that was intended and I am not convinced allowing that would be a great idea, but if needed the Lua function can be adapted to make it work. --Zolo (talk) 12:52, 6 December 2013 (UTC)

I just hit the exact same problem by chance. I was trying to create a autotranslated template in my userspace only to find out that Module:Fallback assumes the pages to reside in template namespace. I think it should be checked if base contains a namespace. If yes, use it without change; if no, prefix base with "Template:". --Patrick87 (talk) 16:06, 7 December 2013 (UTC)

I think the simplest solution would be to check first if Template:base exists (as it is by far the most common case), and if not check it base exists. But if a page sues autotranslate, that is presumably because it is supposed to be seen by a variety of users, and then wouldn't it be better to move it to the Template namespace ? --Zolo (talk) 16:45, 7 December 2013 (UTC)
The use case I have in mind is developing testing and debugging templates in userspace before moving them to template namespace. I think your proposed solution would work, although checking if Template:base exists is probably more expensive than doing a quick reg-ex to check if the given base contains a valid namespace? --Patrick87 (talk) 16:55, 7 December 2013 (UTC)
The template has to check if the page exists for fallback anyway. My solution would indeed be more expensive, as it has to check two namespaces, but it would be a bit less expensive in the template namespace that is the foreseen usecase of this template. Actually I would think it is better to debug templates through sandbox templates rather than through user pages, so that other users can benefit from previous test pages and also becausee it is more reliable because some parts of the templates may turn out to be namespace-dependent. --Zolo (talk) 17:15, 7 December 2013 (UTC)
Will you implement this at some point? I just hit another scenario where it would be useful: Headers of project pages are often transcluded from "/header" subpages, e.g. Commons:Translators' noticeboard/header. When translating those using ext.translate you can't transclude those directly anymore but have to use an autotranslate-like system. I managed to use {{SuperFallback}} now for this purpose here, but I feel like a "one-for-all" template that can be used in all cases would be more appropriate. --Patrick87 (talk) 14:53, 12 December 2013 (UTC)
Ok done, I am wondering if it is a good idea to use autotranslate to transclude a page using the translate extension. I would imagine there should be more direct ways to translude it correctly. --Zolo (talk) 15:58, 12 December 2013 (UTC)
Thanks! What would you use/propose instead? I'm just getting used to ext.translate and it seems to me that this is the "default way" currently. --Patrick87 (talk) 16:07, 12 December 2013 (UTC)
Actually I cannot find any other solution. Do you know if that is intentional that transcluding pages using the translate extension show the translate tags even though they do not appear on the original page ? --Zolo (talk) 09:55, 15 December 2013 (UTC)
Yes, this is a current limitation of the Translate extension. It might change in future but currently one needs to transclude the subpages with the correct language code. --Patrick87 (talk) 15:08, 15 December 2013 (UTC)
But this is not that difficult using {{TNT}} on translatable pages and the awesome new {{autotranslate}}. -- Rillke(q?) 11:30, 20 December 2013 (UTC)
Actually the version of thr TNT template on Commons does not solve issues that I have fully solved on Meta. It can support all namespaces (also Meta uses a legacy check for the main namespace, if the base template is not found in the "Template:" namespace.
Soon I will had proper fallbacks on Meta too.
But the current list of fallbacks here is clearly insufficient (e.g. "sc" for Sardinian should fallback to Italian), and the current lack of support here for regional source variants (in user settings) means that fallbacks don't work correctly for them. It would be useful for example if users could set "co-it" as their user language (for the Southern Corsican dialect spoken in Sardinia) so that it will default to generic Corsican (co), then to Italian (it) instead of French, so the fallback list for "co-it" would be "co", "it"; then after that, the fallbacks of generic corsican will be used (so French will occur after Italian), and the fallbacks for Italian (none); then after that the "default" and "en" fallbacks.
As well, English can be a primary fallback with another secondary language to test before going to the "default" (such case is needed in India or South Africa). We should not assume that an English translation will always be present (the Translate tool should not assume that, we should be able to create a source in another language, such as Chinese, and then translate it to Cantonese and Gan (Chinese will be accurate, but English may be extremely fuzzy and should not be the reference, so Englihs should be considered as a derived translation created in the Translate tool and modifiable there). In summary, the translate tool should be able to track the language used in the base version. If later another translation becomes better than the source, we could swith the reference, and make this translation the new reference. The Trnalsate tool should allow switching the base language by marking a new language as the source (it will then rewrite the base page with the content of the translation (inserting there the translate tags automatically, instead of inserting only the translated items).
  • My version of Fallback supports that: another base language than English, BCP47 default fallbacks, cached list of resolved fallbacks, accelerated with no recursion. My version of TNT supports alternate namespaces.
  • My version of TNT also can work on page that have still not been marked for translation (the current version here on Commons fails with "Script error" becaus it attempts to transclude a "/en" subpage that still does not exist). The interest is that you don't have to worry if you have to use TNT or not when transcluding a template. You can add TNT immediately, then prepare the target for translation by adding "translate" tags. These translate tags won't appear on the page, they have no effect until that page is effectively marked for translation and subpages start being created (including the subpage for "/en").
  • Finally the current version of LangSwitch lacks several improvements I made also on Meta, notably tagging properly the possible changes of directions, using "bdi" tags every time a fallback is used that does not match the content language for the current page. The bdi tag should indicate also with lang="" and dir="" attributes the language used, including for fallbacks. This is important for correct rendering of these languages as pages may become multilingual (otherwise, punctuations are mixed up, and fonts are not setup correctly to render some scripts like Burmese/Myanmarese, Tibetan, Yi, or Gotic, or the wrong font is used for the script style needed in Urdu, Farsi and Dari). In a multilingual page as well, we could have BOTH simplified Chinese AND traditional Chinese and mixing them without tagging will not allow correct reading in one of the other (where the variants are not interchangeable like in monolingual pages using ULS).
  • Also I really don't like that "/en" is locked, this is absolutely not needed: the TNT template can work to render the text modified in the "/en" version via the Translate tool. The base page (used to mark the source of translations) has its own separate life. My opinion id that this source base page should be treated like an unspecified language (und) or as a variant of English (such as "en-x-source"), and the Translate admin should be allowed to specified in which language the source is really ("en-x-source" or "zh-x-source"). Here again the support of BCP47 fallbacks from a variant of a language (like "zh-x-source") to shorter codes with less subtags (such as "zh" here), means that the other transcluded templates will still render correctly (they may not find "zh-x-source" for these separate templates, but will still find "zh").
In summary, the Translate tool should not lock down any page. Translations should be available to any editor (just like any editor can work on templates based on LangSwitch), even if only a tranlate admin can mark which page to use as the source for translation or for updating the source. But even in this case, as all languages will be unlocked, the Translate tool should not just display the internally marked source, but should also display the unlocked "English" translations in "/en" remaining modifiable via this tool. The reference language for translators should not be only English, they should be able to display and use any other translations and the tool will display if this other translation is fuzzy according to the current referene language (not the one in the fully editable base page). verdy_p (talk) 10:45, 19 January 2014 (UTC)

LangSwitch fallback broken @{{Self-photographed}}[edit]

de-ch should fallback to de. -- Rillke(q?) 11:30, 20 December 2013 (UTC)

The issue is at l.17 where new is  de-ch and ' ' .. l evals to  de. -- Rillke(q?) 12:12, 20 December 2013 (UTC)
If you don't mind, I convert the logic to make use of a table. -- Rillke(q?) 12:14, 20 December 2013 (UTC)
In the sandbox, an accelerated version supports not only the preferred fallbacks kisted, but also just after them the BCP47 fallbacks
This sandbox is optimized and also use cached results if the module is invoked many times with the same language when viewing the same rendered page.
I have passed time to also reduce all unneeded recursions, all is performed in the same function. verdy_p (talk) 10:04, 19 January 2014 (UTC)


It would be nice if Module:Fallback/doc described what's the input and what's the output of this template. --Federico Leva (BEIC) (talk) 14:52, 29 September 2014 (UTC)

Lua error in Module:Fallback at line 73: attempt to index a nil value.[edit]

See User talk:Prada16. I don't understand why this error comes on this page (only?). Regards, Yann (talk) 15:10, 9 December 2014 (UTC)

I cannot see any error. Where is it, and using what language ? --Zolo (talk) 07:01, 12 December 2014 (UTC)
The error disappeared. I still wonder what happened... Yann (talk) 09:39, 12 December 2014 (UTC)

Lua error: too many expensive function calls[edit]

I thought last month this problem will maybe soon solved, but I do still see on COM:T many templates not visible through this error-msg (Module:Fallback: in function "fallbackpage"; Module:Fallback: in function "chunk" User: Perhelion (Commons: = crap?)  19:07, 2 February 2015 (UTC)

I suggest you trace the issue down and fix it, then. It's a wiki. -- Rillke(q?) 19:33, 2 February 2015 (UTC)
User: Perhelion, What page shows that error? --Jarekt (talk) 20:47, 2 February 2015 (UTC)
@Rillke: Ok, that's a point, but I'm not so experienced with Lua and this is one of the most used modules on Commons
@Jarekt: Ok, not the first templates, after Commons:Templates#Related files the most inclusions shows this error (I mean I saw this the first time at end of December last year)!?
User: Perhelion (Commons: = crap?)  22:39, 2 February 2015 (UTC)
Ah, I see. I do not see a way to fix it. Old template code had as many tests for existence of a page and it worked. Lua does not, that is a problem with Lua. --Jarekt (talk) 13:02, 3 February 2015 (UTC)
PS: But I know from JavaScript, IF in a LOOP is bad for performance, and here are two IF in a loop. Maybe this can solved in other way. User: Perhelion (Commons: = crap?)  23:00, 2 February 2015 (UTC)
The "expensive function" is I do not think there is any way to get around that without rewriting all templates using {{Autotranslate}}. If you ask me I would very much like to stop using autotranslate and showing clutterish list of langs inside boxes. --Zolo (talk) 06:50, 3 February 2015 (UTC)
Maybe the config of commons can be changed to fix this (changing a limit?) --Steinsplitter (talk) 13:35, 3 February 2015 (UTC)
This issue is new. I think we need to find a forum where problems with Lua are discussed and report it. May be people that know more about it will have some suggestions. --Jarekt (talk) 14:22, 3 February 2015 (UTC)
Maybe wmf can change memoryLimit and/or cpuLimit in $wgScribuntoEngineConf (mw:Extension:Scribunto), but not sure if this fix the problem. Maybe reporting the problem in phabricator:? --Steinsplitter (talk) 14:54, 3 February 2015 (UTC)
This is neither specific to Commons nor specific to Lua. There has always been a limit of 500 hundred expensive function calls in all Wikis. If you preview Commons:Templates, you see that Lua-related statistics are fine (Lua memory usage: 2Mo out of 50, Lua time uage < 1 s out of 10). The issue is that title.exists counts as an expensive function, just like the #ifexist wikiparser, and here we have 642 calls to expensive functions (for the English version, can be more in other languages). --Zolo (talk) 15:24, 3 February 2015 (UTC)
The thing is that COM:T displayed all templates with calls to #ifexist and I think I have seen it working with Lua calls, but now it is not working. Another approach is to either split or retire COM:T. We do have many thousands of templates and it is hard to show even representative sample on a single page. Also many templates did not show correctly on that page, since they might require some parameters which are hard to pass. --Jarekt (talk) 16:12, 3 February 2015 (UTC)
I did not know [Commons:Template]] but it seems relatively useful in getting a bird's eye view on important template. In any case, it requires some cleanup at the very least, and there does not seem to be any harm in splitting it. --Zolo (talk) 06:58, 4 February 2015 (UTC)
Hey guys, I've now two solutions (I've traced the issue down by myself as requested)
  1. Remove only the Template: tlrow seems to work, as you can see on the last version without.
  2. Include only the /en subpage for all autotranslate templates, this will exclude all this Lua-Fallback.
But first I ask here for reviews, the remove of tlrow will swell a bit the source text. But IMHO in fact for this page this is ok. User: Perhelion (Commons: = crap?)  16:21, 24 February 2015 (UTC)
✓ Done I choosed the 2nd solution, however the template "tlrow" does seems not to have been guilty in that manner. User: Perhelion (Commons: = crap?)  19:57, 24 February 2015 (UTC)
PS: All translations of COM:T transclusion need the same fix (fr, ... @Zolo it was your hint which give me the fix. I guess it is only table copy to each headline.) User: Perhelion (Commons: = crap?)  11:38, 19 March 2015 (UTC)
@Rillke, Jarekt, Steinsplitter, Zolo: Maybe it is good to install the ext.translation i18n here ? To end this problem here... I would do the /i18n thing (but I'm not very experienced here) !? User: Perhelion (Commons: = crap?)  11:52, 19 March 2015 (UTC)

mediawiki fallbacks[edit]

{{edit request}} Make this change to this module.

I noticed that one of the authors of this template requested an function in scribunto to get fallbacks, but never added it to this module. I hope that asking that it will be added now to the module will fix that. This edit will also fix the errors under the "test_fallbacks" section on Module talk:Fallback/testcases.--Snaevar (talk) 22:09, 20 February 2015 (UTC)

One specificity of the Commons-made fallbacklist is that unlike MediaWiki's built-in function, it can be bidirection, like zh-cn -> zh and zh-> zh-cn.
{{#invoke:Fallback|langSwitch|zh-cn=zh-cn|lang=zh|default=default}} -> zh-cn
{{#invoke:Fallback/sandbox|langSwitch|zh-cn=zh-cn|lang=zh|default=default}} -> default.--Zolo (talk) 22:03, 25 February 2015 (UTC)
What to do with this editrquest? Fulfilling or not? --Steinsplitter (talk) 14:28, 7 March 2015 (UTC)
I am clueless. For new code, I would use the MediaWiki supplied ones; if we change this code people may start to wonder why we "broke" the fallback chain for their language. On the other hand we would have consistency with what MediaWiki does and if someone requests a change, we could point them to MediaWiki's code base/ Phabricator, thus having less maintenance efforts but less control, too - so we can't simply quickly fixing some fallback chains if we see a need for. -- Rillke(q?) 14:53, 7 March 2015 (UTC)
Can we do both? Use MediaWiki list for most and add exceptions? we do something similar with Template:And. --Jarekt (talk) 19:54, 7 March 2015 (UTC)
 Not done No consensus to change the module. --Hedwig in Washington (mail?) 04:44, 2 August 2015 (UTC)

Lua Errors[edit]

{{PD-scan|PD-signature}} gives

This image is in the public domain because it is a mere mechanical scan or photocopy of a public domain original, or – from the available evidence – is so similar to such a scan or photocopy that no copyright protection can be expected to arise. The original itself is in public domain for the following reason:
Public domain This signature is believed to be ineligible for copyright and therefore in the public domain because it falls below the required level of originality for copyright protection both in the United States and in the source country (if different). In this case, the source country (e.g. the country of nationality of the signatory) is believed to be ***Tag invalid. You must provide the source country as a parameter.***.
Note that this tag cannot be used on all signatures, as not all signatures are copyright-free.
See Commons:When to use the PD-signature tag for an explanation of when the tag may be used.

This tag is designed for use where there may be a need to assert that any enhancements (eg brightness, contrast, colour-matching, sharpening) are in themselves insufficiently creative to generate a new copyright. It can be used where it is unknown whether any enhancements have been made, as well as when the enhancements are clear but insufficient. For known raw unenhanced scans you can use an appropriate {{PD-old}} tag instead. For usage, see Commons:When to use the PD-scan tag.

Note: This tag applies to scans and photocopies only. For photographs of public domain originals taken from afar, {{PD-Art}} may be applicable. See Commons:When to use the PD-Art tag.

. Anybody knows how to fix it? --Jarekt (talk) 13:12, 10 May 2016 (UTC)