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)

Ifexist[edit]

What's the issue with

mw.title.new('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)

Standards[edit]

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)