43,749
edits
Talk:Wiki: Difference between revisions
Jump to navigation
Jump to search
m
→Map features too huge
|
: The only compelling reason for the existing all-inclusive one-page solution that comes to my mind is that one can easily get an archive or offline documentation / booklet by saving or printing the page to PDF file. I for myself don't like or use that slow an long page either. --[[User:Chris2map|Chris2map]] ([[User talk:Chris2map|talk]]) 07:42, 30 March 2024 (UTC)
:: Then we can create such a PDF and link to it. [[User:Maro21|maro21]] 14:18, 30 March 2024 (UTC)
----▼
I don't know whether, in the case of the English [[Map features]] page, the loading is prolonged by the number of Commons images or the number of templates. I suppose the images, because there are long loading pages with a large number of images and a small number of templates. Does anyone know which has more impact? It's not likely to be local images, because pages like [[LinesTab]] load quickly. [[User:Maro21|maro21]] 14:36, 30 March 2024 (UTC)▼
----▼
In the template [https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:shop&action=history Template:Map Features:shop], I removed unnecessary parameterization of parameters that are not translated, and removed 165 same links to Key:shop, on top of that called by the template, which uses data items. The whole thing reduced page loading by about 2.3 seconds, from 6.8 s to 4.5 s. This is just one of the templates nested in [Map feautures], but one of the bigger ones. Maybe I can slim down the templates and reduce the loading time of Map features. I will continue. [[User:Maro21|maro21]] 15:28, 30 March 2024 (UTC)▼
: And isn't the faster loading of English pages caused by the fact that they use a different display system in the Template? See the difference https://wiki.openstreetmap.org/wiki/Template:Map_Features:craft which is faster and loads things sequentially from the Taglist and https://wiki.openstreetmap.org/wiki/Template:Generic:Map_Features:craft where the table is programmed directly in the source of the page (more complicated/slower). I would see a disadvantage of the faster version, that not everything for different languages will be translated as in the slower version. -- [[User:Lenochod|Lenochod]] ([[User talk:Lenochod|talk]]) 21:36, 4. April 2023 (UTC)
: As possible solution, we can replace {{t|LL}}, {{t|Keylink}} and {{t|Valuelink}} transclusions by links to data items, which are independent from languages, provides basic info, and contains links to actual documentation. [[User:Something B|Something B]] ([[User talk:Something B|talk]]) 09:29, 11 April 2024 (UTC)
::Removing link completely would be more helpful. Data item pages have only what is infobox and this is not very useful info. And unexpectedly linking it would be confusing at best. Maybe manual direct linking to specific wiki page without using resource-hungry templates would work? [[User:Mateusz Konieczny|Mateusz Konieczny]] ([[User talk:Mateusz Konieczny|talk]]) 12:12, 11 April 2024 (UTC)
<p>The page currently uses {{tl|Keylink}} and {{tl|Valuelink}} in order to link to each key and value, but I think we should replace this usage with old-fashioned {{tl|TagKey}} and {{tl|TagValue}}, which I'm [[Template talk:TagValue#Lua rewrite|rewriting for better performance]]. {{tl|Keylink}} and {{tl|Valuelink}} rely on data items to discover translations in other languages. While data items are a good tool for discovering translations of ordinary wiki pages like "[[Bicycle]]" and "[[Tags]]", I think it's overkill for key or value description pages, which have predictable titles. From MediaWiki's perspective, fetching a data item is equally expensive as checking whether a page exists at a particular title, but there's also a cap on the number of data items that can be fetched per page.</p><p>The only current benefit of {{tl|Keylink}} and {{tl|Valuelink}} is that it can fall back to a more closely related language than English without having to check ''that'' page's existence. But currently it can only perform language fallbacks based on {{tl|langcode}} – that is, the language implied by the page name. The page might as well specify a fallback language explicitly, saving everyone effort. [[MediaWiki talk:Lang#Still To-Do]] would make it possible for the fallback to be based on the user's preferred interface language, but this doesn't really require data items.</p><p> – [[User:Minh Nguyen|Minh <span style="font-variant: small-caps;">Nguyễn</span>]] <sup>[[User talk:Minh Nguyen|<span style="display: inline-block;">💬</span>]]</sup> 22:15, 14 April 2024 (UTC)<p>
▲----
▲I don't know whether, in the case of the English [[Map features]] page, the loading is prolonged by the number of Commons images or the number of templates. I suppose the images, because there are long loading pages with a large number of images and a small number of templates. Does anyone know which has more impact? It's not likely to be local images, because pages like [[LinesTab]] load quickly. [[User:Maro21|maro21]] 14:36, 30 March 2024 (UTC)
▲----
▲In the template [https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:shop&action=history Template:Map Features:shop], I removed unnecessary parameterization of parameters that are not translated, and removed 165 same links to Key:shop, on top of that called by the template, which uses data items. The whole thing reduced page loading by about 2.3 seconds, from 6.8 s to 4.5 s. This is just one of the templates nested in [Map feautures], but one of the bigger ones. Maybe I can slim down the templates and reduce the loading time of Map features. I will continue. [[User:Maro21|maro21]] 15:28, 30 March 2024 (UTC)
== Whitelist forms.gle ==
| |||