Template talk:Dir

Shouldn't kk-arab and ku-arab be added to his template too? Or is there a reason not to add variants? --Slomox (talk) 22:23, 6 April 2009 (UTC)

When I made this I added only the languages that had at least one local Wikimedia project (to keep the size down), but we should definitely add any that are used here. Rocket000 (talk) 23:05, 6 April 2009 (UTC)

I added everything that is selectable in the preferences and obviously is rtl (perhaps I missed something, the script direction cannot be recognized from the list in preferences, but I at least added anything in Arabic script). --Slomox (talk) 00:11, 7 April 2009 (UTC)

Add oc

Can you add Occitan link (oc)? Thanks a lot! --Cedric31 (talk) 12:24, 3 July 2009 (UTC)

To what do you want 'oc' to be added? This template indicates the direction of a language's script. Left to right is default and only right to left languages need to be added to this template. So no modification is necessary for 'oc'. --Slomox (talk) 22:14, 5 July 2009 (UTC)

Hold on, I want to see his translation first. Rocket000 (talk) 08:24, 6 July 2009 (UTC)

Not needed. Occitan is unambiguously written in the Latin script. There's absolutely no demonstrated transcription or orthography of Occitan written in the Arabic script (even in the Medieval age, where in fact it would still be another language code)

Note that the "oc" language code is post-1500 and it spans several countries all using languages written also with the Latin script: Spain, France, and possibly some Romance valleys in Switzerland and Italy; elsewhere it was only a minority language of emigrants, spread in isolated familes or small quarters of some cities notably in America; or it was litterature found in various royal or monastic libraries in Western Europe, and following the moves of armies, from the Middle-Age Kingdoms to the time of European Empires governed by others). verdy_p (talk) 05:42, 1 March 2010 (UTC)

Heh, I think he was talking about some template he translated and wanted us to link to it (mistaking this for something else). I was joking with my comment. Rocket000 (talk) 10:55, 1 March 2010 (UTC)

However, there's a missing language code ug (for Uyghur, which is written in the Arabic script, including officially in China, where the attempts to introduce the Han ideophonographic script failed for this language).

verdy_p (talk) 05:46, 1 March 2010 (UTC)

 Done for ug but  Not done for oc --Dferg (talk) 11:00, 27 March 2011 (UTC)

ug and pnb

please add this languages.−ebraminio^talk 10:06, 5 March 2011 (UTC)

 Done --Dferg (talk) 10:59, 27 March 2011 (UTC)

ku

{{editprotected}} Please remove ku, Kurdish/Kurdî. Usually, the standard variety of Kurdish uses Latin as at the Wikipedia, the template reads "Kurdî", and there is a ku-arab language option on Commons. Brought up at Commons:Village pump#Kurdish. —innotata 01:40, 17 March 2011 (UTC)

 Done --Dferg (talk) 10:59, 27 March 2011 (UTC)

Change beahaviour a little

{{Editprotected}}

rtl|ltr -> {{{2|rtl}}}|{{{3|ltr}}}

While direction is mainly used for rtl/ltr parameter, this would expand usage to left/right decisions in tables. So for example I would be able to use some code like {{Dir|{{{lang}}}|right|left}}. -- とある白い猫 ^ちぃ？ 02:43, 22 April 2012 (UTC)

 Done -- とある白い猫 ^ちぃ？ 03:41, 22 April 2012 (UTC)

Convert to Module:Dir

{{Editprotected}}

I've created Module:Dir, which gets the language code direction from the MediaWiki software instead of storing it in the template. This should make maintenance of this template easier, and catch any RTL codes that hadn't been included already. Some language codes that are considered RTL in the old template are considered as LTR by MediaWiki - these codes have been overridden using Module:Dir/RTL overrides. There are test cases at Template:Dir/testcases.

Please copy the contents of Template:Dir/sandbox to Template:Dir, so that the template can use the new module. Also, please protect Module:Dir and Module:Dir/RTL overrides, as they will become high-risk after the edit is made. — Mr. Stradivarius ^{♪ talk ♪} 04:37, 21 February 2015 (UTC)

That module was actually not using the overrides (there's currently a bug in mw.loadData('Module:...'), which does not load anything

Also I completed the map to cover the whole set of languages known to MediaWiki

Now that module will no longer need to use mw.language.new(code):isRTL() which generates errors as soon as you've tested 20 languages : all known languages are now in the data of the module, which also includes a complete test for checking that its data is correct, offers full coverage, has its data correctly ordered and formated and uses only valid languageCodes.

The data part is simpler to update, thanks to the quickTest module integrated

It is also MUCH faster (because it no longer needs to load external linguistic data resources in MediaWiki files or in the database. Now it can be a TRUE replacement of the template.

It also correctly maps a few other legacy codes (not known to MediaWiki) but used in Commons (they are in the data Module:Dir/RTL overrides)

You may enter data as you want in the "overrides" : duplicate or misordered items do not really matter. QuickTests (whose status is shown at top of Module:Dir page when viewing it directly) asserts that everything is OK, in case of problem, open the editor and run: =getmetatable(p).quickTests() to see the details in the Lua console.

If MediaWiki adds other languages still not known in our data, the QuickTests will detect it, but the status will remain OK: the module will query MediaWiki for any valid language code that it does not know.

verdy_p (talk) 21:09, 20 April 2015 (UTC)

 Not done Not needed anymore. --Hedwig in Washington ^(mail?) 04:38, 2 August 2015 (UTC)

That's wrong, it is needed even more today ! The template version has a higher cost than the module version in various pages where "dir" is used several thousands times (notably because of the expansion cost of the #switch, even if it seems very small, but in fact has incomplete coverage). verdy_p (talk) 16:25, 2 May 2020 (UTC)

trim the list

I would like to propose to trim this list and remove:

• fa-af - Persian (Afghanistan) is very rare and not not a known language to MediaWiki software
• prd - Parsi-Dari language is very rare and not not a known language to MediaWiki software and supposedly a spurious languages according to Glottolog
• ha - Hausa language is LTR

Template:Dir is most transcluded template on commons and it it good to clean it from time to time. --Jarekt (talk) 18:34, 9 July 2015 (UTC)

 Done --Hedwig in Washington ^(mail?) 04:42, 2 August 2015 (UTC)

 Thank you. I would have done it (after others had time to review it) but I forgot about it. --Jarekt (talk) 00:52, 3 August 2015 (UTC)

Note: Haussa may be RTL: it has a known variant written in the Arabic script instead of Latin (this is one of various languages that have attested litterature with an important corpus in multiple scripts); the Arabic-written variant is not at all extinct (and in fact it is in rapid expansion; so that it could even override the Latin script). When you use the language code "ha" you don't specify at all which script will be used. For this reason, Wikimedia supports the variant "ha-arab" when we need to specify this variant, but still does not support "ha-latn". Both variants can default to "ha", but actually defaults should be reversed: "ha" should just take for now the default from "ha-latn", and "en" otherwise, without any translation provided for "ha" itself (all translations should be explicitly in "ha-arab" or "ha-latn")

This would be a bit similar to the situation of "zh" that takes its default from "zh-hans", but accepts the fallback to "zh-hant" before "en". However the only fallback from "ha-arab" would be "ar" before "en", the only fallback from "ha" (empty data, just an alias) would be to "ha-latn" (then "en"), and the only fallback of "ha-latn" would be "en" (fallback via "ha" is not needed at all even if BCP47 indicates it, simply because "ha" should be a redirecting alias for "ha-latn", and the fallback to "ha-arab" should be removed).

In such case, both "ha" and "ha-latn" are LTR; but "ha-arab" is RTL and it should be supported (it is supported in Mediawiki). verdy_p (talk) 16:21, 2 May 2020 (UTC)

lrc

{{Editprotected}}

Please add lrc (Northern Luri) to the list. Its main page (سرآسونٱ) is currently broken because MediaWiki knows it’s RTL (so the margins are set appropriately for RTL), but this template doesn’t (so the page has dir="ltr", which forces the texts and table column order to be LTR). Thanks in advance, —Tacsipacsi (talk) 00:19, 2 March 2020 (UTC)

 Done 4nn1l2 (talk) 11:33, 2 March 2020 (UTC)

lki and others

{{Editprotected}} Those are missing in the list of RTL languages (note that the current code is not longer sorting codes alphabetically, you could introduce duplicates); all of them are written in the Arabic script:

"aeb-arab|ary|fa-af|khw|ks-arab|ku-arab|lki|luz|prd|sdh|skr-arab|ug|ug-arab"

These languages are already supported in these wikis: Commons, Meta, Mediawiki, and translatewiki.net.

Those codes with "-arab" variants (for codes: "aeb, ks, ku, skr, ug") are needed because the same languages also are written in some LTR script and the only safe way to indicate the script and infer the direction is to tag the script used explicitly (even if there's no Wiki edition or variant support with transliterators, we need to distinguish the scripts in multilingual pages; including in pages that exhibit both scripts simultaneously, like "ks" for Kashmiri).

Thanks. verdy_p (talk) 05:28, 2 July 2020 (UTC)

need update to the list of RTL languages (aeb, and others)

{{Editprotected}} @Dferg, 4nn1l2, and Hedwig in Washington: The updated list of RTL languages should be:

aeb|aeb-arab|ar|arc|arq|ary|arz|azb|bcc|bgn|bqi|ckb|dv|fa|fa-af|glk|ha-arab|he|khw|kk-arab|kk-cn|ks|ks-arab|ku-arab|lki|lrc|luz|mzn|nqo|ota|pnb|prd|ps|sd|sdh|skr|skr-arab|ug|ug-arab|ur|uz-arab|ydd|yi

instead of just:

ar|arc|arz|azb|bcc|bgn|bqi|ckb|dv|fa|glk|ha|he|kk-arab|kk-cn|ks|ku-arab|lrc|mzn|pnb|prd|ps|sd|ug|ur|ydd|yi

In other words, the following are missing:

aeb|aeb-arab|arq|ary|fa-af|ha-arab|khw|ks-arab|ku-arab|lki|luz|nqo|ota|sdh|skr|skr-arab|ug-arab|ur|uz-arab

And the following should be removed:

ha (Latin script by default, not Arabic)

My previous request more in last July (almost 7 months ago) ago was still not replied and completed, this new request reincludes it.

See also Module:Dir/RTL_overrides which already has this update (and links to a test page), however it is used only from other Lua modules. This module has a complete map of all Wikimedia-supported languages, including those in LTR direction.

Thanks. verdy_p (talk) 20:06, 1 February 2021 (UTC)

 Done Thank you! Jarekt (talk) 20:22, 1 February 2021 (UTC)

Thanks. For info, this template and the Module:Dir/RTL_overrides should be in sync. They are short enough to avoid one calling the other one (with extra performance cost when transitionning between the MediaWiki parser and the Lua engine, via Scribunto, as it is known that the transition costs about 1-5 microseconds per transition; these transitions can cumulate very fast on some pages for such heavily used function (whose usage is constantly growing as internationalization progresses): we have limitations of total time for the Mediawiki parser per page, and one way to avoid such transitions is to use caches (in MediaWiki itself for cachable templates, or in Lua by usingthe engine memory, but the memory has also to be saved.

So it is best to limit the number of needed transitions, and it is clearly possible with this tiny function which is why it is still implemented *separately* in a Mediawiki template and in Lua. For this reason, I have added the link in the doc page of this template. Both are optimized as much as possible (with the existing working technologies).

I've been very careful to use profiling info returned by Mediawiki and by Lua to minimize the bottlenecks (also beause MEdiawiki runs in a farm of servers, not all of them having the same performances, even if they have the same memory/time contraints: some server can server a page within 8 seconds, another within 16 seconds, and we have no control about which server will be selected, and we need to keep all pages below 8 seconds in all cases, otherwise pages will be broken and their rendering will be cached in their broken state. This is challending for some complex pages (e.g. infoboxes, statistics, multilingual pages using lot of langages, wikidata integration, integration of Commons, and soon we'll have the additional performance constraints of Wikifunctions itself).

For now the schedulers and ressource management for servers used in Wikimedia are still not correctly balanced, and performances vary a lot, even without significant difference of traffic by visitors: the constraints given however are very "hard" and can cause troubles on pages that were still correctly designed (but that work only 80% of the time). We have to live with it, even if I'm sure that the WikiTech team is working on improving that for better scalability and resilience to spikes of traffic (this is a very tricky work, I know it is very complex to measure and predict the effect of optimizations and still keep the systems evolutive and maintanable). verdy_p (talk) 00:24, 2 February 2021 (UTC)

And I note that there's still some costs we can avoid:

<noinclude>
{{documentation}}

[[Category:Internationalization templates|{{PAGENAME}}]]
[[Category:Function templates|{{PAGENAME}}]]
</noinclude>

should be reduced to just {{Documentation}} by moving the categories only in the doc subpage.

And the <noinclude>{{heavily used template}}</noinclude> protection banner at top should better be at top of the doc subpage and removed from the template itself, keeping only the switch and the "noinclude" documentation template call, nothing else.

Every single byte matters for heavily used templates (even if it saves a few microseconds or a dozen of bytes in processing memory, this has a cost; notably the memory which can causes lengthy garbage collection in the middle of processing when we are nearly reaching the ressource limits; there's no need of garbage collection at end of processing, as rpocessing engines are simply reset directly in a much faster and more efficient way without browsing and marking complex data structures). verdy_p (talk) 00:34, 2 February 2021 (UTC)

Also there's the need to update the list of RTL languages in the similar template on MediaWiki-wiki (it has a few other optional parameters, but here also the list should match (at least the version in the Lua module on Commons contains an extensive test of what is really supported in Wikimedia, as it also has a more complete access to the Mediawiki API, allowing the extensive test to see the remaining quirks, and detect new languages added with a full or limited support; Commons is highly multilingual, it is the most multilingual of all wikis). — Preceding unsigned comment added by verdy_p (talk • contribs)

{{Editprotected}}

Out of the above discussion about performance, the actionable is the following:

• Remove

  <noinclude>{{heavily used template}}</noinclude>
  

• Replace

  <noinclude>
  {{documentation}}
  
  [[Category:Internationalization templates|{{PAGENAME}}]]
  [[Category:Function templates|{{PAGENAME}}]]
  </noinclude>
  

  with

  <noinclude>{{doc}}</noinclude>
  

  (this is even shorter and thus even more efficient than what verdy_p proposed above).

Both are now included in the documentation, so they don’t need to be processed when this template is used, only when someone views this very page. Maybe @Jarekt? Thanks in advance, —Tacsipacsi (talk) 22:13, 3 February 2021 (UTC)

 Done Thank you Jarekt (talk) 00:59, 4 February 2021 (UTC)

@Verdy p and Tacsipacsi: , I totally agree with your desire to keep this template as simple and streamlined as possible. I am curious about "profiling info returned by Mediawiki and by Lua" you mentioned. Where can I learn more about it? --Jarekt (talk) 01:03, 4 February 2021 (UTC)

No what I proposed was more accurate: We don't need any category in the base template itself, only in the documentation subpage (within its "includeonly" section). As well we don't need the banner (which can be in the documentation subpage as well. So @Tacsipacsi: , reread my request, all was correct, your suggestion was actually worsening things. Note using {{doc}}} instead of {{Documentation}}} will not save bytes, actually it causes the parser to analyse it and see it as a redirec, and asdds a trackign category. This template alias is not even recommended (reserve 3-letter to language codes; especially in a template that will be locked and heavily used, we should not use any redirection). As well, remove newlines: we don't need any empty line, and not even any newline here in the noinclude section, as the doc template already encapsulates an HTML formatting block. These empty lines are incirations to other editors to insert something else in the noinclude section and nothing else should ever be here! verdy_p (talk) 15:41, 6 February 2021 (UTC)

Profiling info is rendered in HTML comments by Mediawiki and Scribunto. They are also exposed using the Mediawiki API. You have the name of each template or module, timing, number of calls, total time and average time, you have also the name of the server in the wiki farm doing the parsing running the processing of Lua code; you have other metrics about memory, locks, database queries, timestamps, cache info, costly calls... If you've never seen that, open your brower's settings menu in "Developer options" and look at the HTML code with it: at end of the div element with "content", you find this generated HTML comment. With the Mediawiki you have even more info, but the HTML comment is already cxontaining the most important things that help diagnose what you want when you have performance issues, or when some resource usage limits are exhausted (note that processing time varies a lot even without modifying the page, as it depends on the actual server on the Wikimedia from that will process your page when it is "modified" or "purged", as this server is unpredictable, and servers are herogeneous and don't all have the same capabilities/performances and theuy are incorrectly balanced: the pertormance can vary by factor of 2 or 3 depending only on which server is used, and totally independantly of their workload at the same time, you easily see that some of them are ALWAYS much slower than all others and are ALWAYS the cause of some pages not being rendered and showing errors for timeout on limits and this if independant of time of day, activity of "recent edits" (even if you test it at hours with lowest usage): this is clearly a problem of incorrect configuration of the load balancer of servers in Wikimedia, or lack of accurate metrics to make the balancer work (my opinion is that it only uses a "flat" randomizer, without taking into account the capacilities and connectivity iof each server: this only work for modest pages, but some pages use complex templates with Wikidata, or other connected sites; the absence of a correct load balancer will becvore even more critical with Wikifunctions and it is already critical for many infoboxes using Wikidata). verdy_p (talk) 16:01, 6 February 2021 (UTC)

@Verdy p: I’ve reread your request. While I’m sure you meant to ask removing all whitespace within the <noinclude> block, I think you wasn’t entirely explicit on this. (I was, yet Jarekt kept them…) You haven’t mentioned redirects before, but I’d be very surprised and someone got the parser incredibly wrong if anything was parsed at any level in the <noinclude> block—the sum of <includeonly> and <noinclude> may not even make any sense! (For example how would it parse {{#if<includeonly>expr:{{{1}}}>0</includeonly><noinclude>eq:1|1</noinclude>|…}}?) So why do redirects matter in the <noinclude> block? (Of course they matter when MW parses this very page, but the cost of that one parsing is negligable, only the cost of parsing pages that transclude this counts.) Also, I don’t know what tracking category you’re speaking about—no extra categories appear at the bottom of the page just because it uses a redirect. It may add some tracking information—I don’t know—, but it’s unfortunate to call them tracking categories, since that term has a very specific meaning in MediaWiki. By the way, {{Doc}} is used on more than 200 pages and it’s a pretty established shortcut for this template, so deleting/repurposing it would be highly controversial; I think we can freely use it for the time being (which may be infinitely long). It’s “not even recommended”—not, but neither discouraged, at least not in its documentation. (P.S. Please be very careful if you decide to type other users’ user names instead of copy-pasting them; I’ve got no notification about your ping, as you clearly mistyped my name—it’s a red link, not blue like the one in my signature.) —Tacsipacsi (talk) 20:57, 6 February 2021 (UTC)

The typo in your user name is fixed above. It was copy-pasted, but edited involuntarily. verdy_p (talk) 21:18, 6 February 2021 (UTC)

@Verdy p: Thanks for correcting my name! What about the subject matter, i.e. whether redirected templates in <noinclude> affect the performance when included? —Tacsipacsi (talk) 02:18, 8 February 2021 (UTC)

Add "ms-arab" into RTL languages

{{Edit request}} "ms-arab" has been recently added into Wikimedia projects. Please add ms-arab" into the RTL language list. Thank you. --Tofeiku (talk) 08:20, 21 May 2021 (UTC)

 Done Awesome! Thank you! Hedwig in Washington ^(mail?) 02:56, 24 June 2021 (UTC)

Languages not recognized by Mediawiki

According to mw:Manual:Language#Names.php "Names.php is the master registry of languages supported by MediaWiki", and comparing this list to {{Dir}} shows that latest edit by User:Magog the Ogre added about 145 new languages which are not supporterd by MediaWiki, expanding the list from original 44 to the current 186. This is unnecessary overcomplication of a template used on 112M pages. I do not know much about Module:Dir/RTL overrides but the the official lua version of this function is mw.language:getDir and this template should be in synch with that list. I updated Template:Dir/sandbox to include only 41 languages currently supported by MediaWiki. Are there any reasons not to use it? Jarekt (talk) 19:57, 8 August 2023 (UTC)

It literally says in the edit summary that I was making the change for someone else and who that person is. Magog the Ogre (talk) (contribs) 23:33, 8 August 2023 (UTC)

Merge the better template Dir2 into this template

{{Edit request}}Template:Dir2 uses Module:Dir that is much better than this. I suggest to replace Template:Dir's code into {{#invoke:Dir|main}} to get better efficiency. 阿南之人 (talk) 14:32, 7 October 2023 (UTC)

It’s exactly efficiency that’s likely worse in case of Dir2 – running a Lua module is expensive (the Lua interpreter needs to be loaded and the Lua code needs to be interpreted and run, in addition to the parse of wikitext, which is necessary either way, as the {{#invoke:}} is also wikitext). Module:Dir wasn’t even designed with efficiency in mind, for example it uses require() to load the data rather than mw.loadData(). The code of Module:Dir is also much more complex than I’d expect from a module to be used on over a hundred million pages. —Tacsipacsi (talk) 08:49, 8 October 2023 (UTC)

 Not done This would be a potentially controversial change and should be decided on a community forum. The Squirrel Conspiracy (talk) 23:34, 14 November 2023 (UTC)