Template talk:ISO 639 name/Archive 1
This is an archive of past discussions about Template:ISO 639 name. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Ready to implement?
I've made a few changes today to ensure that ISO 639 name|XXX is producing exactly the same as ISO 639 name XXX. See User talk:MSGJ/Sandbox3 for a comparison.
- Are we sure that all templates of the form {{tl|ISO 639 name XXX}} are not incorporated into this one?
- Which templates use these? I know about {{lang}}; are there any others?
- What should we do with the {{tl|ISO 639 name XXX}} templates?
- Ignore them
- Point them to this template
- Tag them as depreciated and eventually delete them
— Martin (MSGJ · talk) 12:38, 29 April 2009 (UTC)
- You could do what I did with the interwiki translation templates: replace the code with the appropriate code of this template to output the data, and then I could have my bot subst the new code onto the articles after a little while when we ensure it works properly, assuming no objections. –xeno talk 12:44, 29 April 2009 (UTC)
- I believe the situation is that not many articles call those templates directly. Most calls come via {{lang}} and so the switchover could be quite easy. About substitution, I would advise against it. Okay, the name of a language might not be about to change, but as soon as you do that you've lost the ability to add extra functionality. And the benefits of substituting are, I think, tiny. — Martin (MSGJ · talk) 13:19, 29 April 2009 (UTC)
- It's a bit difficult to see what's going to be left until {{lang}} has been changed, so why not get that part done, wait a little while, and then check the "What links here" on all the templates to see what is left to do then. If there's not much then it could be worth deleting the old templates. -- WOSlinker (talk) 22:26, 29 April 2009 (UTC)
- What I meant by subst, is that since you've replaced "ISO 639 pl" with "{{ISO 639 name|pl}}", when I subst ISO 639 pl, it ends up putting the ISO 639 name template in. Not substing the ISO 630 name template itself. Erm, I guess I should've just said replace, it's just easier this way =) –xeno talk 23:28, 29 April 2009 (UTC)
- I believe the situation is that not many articles call those templates directly. Most calls come via {{lang}} and so the switchover could be quite easy. About substitution, I would advise against it. Okay, the name of a language might not be about to change, but as soon as you do that you've lost the ability to add extra functionality. And the benefits of substituting are, I think, tiny. — Martin (MSGJ · talk) 13:19, 29 April 2009 (UTC)
Duplicate of Template:Language
This templage has the same functionality as {{Language}} and should be redirected and deprecated. This would ensure that only one list of ISO 639 codes is used within English Wikipedia. Please give your comments before I ask for {{editprotected}}. Andreas (T) 20:13, 13 July 2009 (UTC)
- Hmm. This template seems to cover all of ISO 639-1, -2, and -3, while {{language}} seems to only understand IDO 639-1, e.g. it only knows "de" for German, not "ger" or "deu".
However, they could still be merged, and should probably. I wonder why Martin created this one, let's wait what he says.
Cheers, Amalthea 20:36, 13 July 2009 (UTC)- I created this to replace the hundreds of template of the form {{tl|ISO 639 name de}}, {{tl|ISO 639 name ja}}, etc. etc. In fact, this template is not in use anymore as it was found that such a large switch was detrimental to performance. See Template talk:Lang#Template simplification for the discussion. So unfortunately, the neat solution was not the best solution in this case, although I hope that someday this will change and we can use this template and deprecate all the separate ones. I would definitely support merging this functionality, if it is indeed duplicated. I believe there may be several other templates out there which do something similar to this as well. — Martin (MSGJ · talk) 14:18, 14 July 2009 (UTC)
- Oh, I didn't even notice. –xenotalk 14:25, 14 July 2009 (UTC)
- I created this to replace the hundreds of template of the form {{tl|ISO 639 name de}}, {{tl|ISO 639 name ja}}, etc. etc. In fact, this template is not in use anymore as it was found that such a large switch was detrimental to performance. See Template talk:Lang#Template simplification for the discussion. So unfortunately, the neat solution was not the best solution in this case, although I hope that someday this will change and we can use this template and deprecate all the separate ones. I would definitely support merging this functionality, if it is indeed duplicated. I believe there may be several other templates out there which do something similar to this as well. — Martin (MSGJ · talk) 14:18, 14 July 2009 (UTC)
This template and [[Template:Language/en]] are being used. If the performance is better with sub-templates rather than a switch, should we change this template to be "{{ISO 639 name {{{code}}}}}" with some checking to ensure that "ISO 639 name <x>" exists? John Vandenberg (chat) 10:31, 11 November 2011 (UTC)
- Yes we should, this template also does not support anything like as many codes as the systemic solution, although I aded a bunch in some time ago, and the systemic solution has the advantage that anyone can add a new code, while the high use templates remain protected. I will make it so. Rich Farmbrough, 01:58, 22 March 2012 (UTC).
Another option is to start using {{#language:..|..}} (documented at mw:Help:Magic words), however there are still some differences between the language names supported by enwp templates, commons templates and mediawiki software. See commons:Template_talk:Language#Make_use_of_MediaWiki_1.18_capabilities. John Vandenberg (chat) 04:54, 26 November 2011 (UTC)
Edit request on 6 May 2012
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I have nominated this template for deletion, so please add {{tfd|inline=yes}}
to it.
Liam987 16:11, 6 May 2012 (UTC)
- Done, though I used
type=tiny
. Chris Cunningham (user:thumperward) (talk) 09:47, 9 May 2012 (UTC)
Switch to module
I've converted this tpl to Lua; there are two obvious benefits to this:
- the list of languages is much more easily manageable (see [[Module:ISO 639 name/data]]; I've imported all the codes from live except a few that were improper, and added a few more)
- we can fuzzy string match, i.e. as long as the base ISO code is defined, compounded codes will find a match, e.g.:
- {{ISO 639 name|ar-x-nastaliq}} → {{ISO 639 name|ar-x-nastaliq}}
- {{ISO 639 name/sandbox|ar-x-nastaliq}} → {{ISO 639 name/sandbox|ar-x-nastaliq}}
- etc.
It otherwise behaves the same it does now on live.
I suppose I'll make a protected edit request in a few days if no one's against this change and if I've not goofed something up. Templates that circumvent the parent tpl will have to be edited (to change the space to a vertical bar). — Lfdder (talk) 18:31, 8 September 2013 (UTC)
- Which existing codes did you find "improper"?
- I hope you don't mind that I've edited the data template to remove all the redundancies and nil lines. I don't think this will make it harder to maintain, the data page is 90% smaller, and a (single) invocation is now significantly faster.
- It'll always be slower than the dependent template transclusion but maintainability clearly trumps the current hack. :)
- At the moment an undefined code shows an {{error}} that can be caught -- I think this behavior should be retained.
- What's the intention of the obfuscated
code
parameter name in Template:ISO 639 name/sandbox? Only to handle an empty parameter and control display on the template page? - Once this is deployed, all those old helper templates needs to be deleted. I can do that semi-automatically while verifying that there are no remaining transclusions, if you want.
- A somewhat broader question, independent from a move to a module: I'm wondering whether it wouldn't be better to have specialized templates for the ISO-639 lists. In a meta template you usually want more narrowly defined input and throw an error if the input is incorrect. For example, {{Infobox language}} has explicitly defined inputs for the various ISO 639 codes and uses one/some of them as parameters for this template, but the fuzziness of this template will hide input errors instead of point them out to the editor.
This template doesn't have /that/ many transclusions with 5000 (and its odd cousin {{language}} has less) so it would certainly be doable to take this opportunity and split it into more specialized templates.
- Amalthea 21:11, 8 September 2013 (UTC)
- Some nonexistent ones like cz for Czech or lowercase country codes like in zh-cn (should be zh-CN). See the test cases here.
- Well, I think we should keep the "redundancies" and nil entries. There weren't redundancies in the output 'cos the tables were combined at the bottom and the same key would overwrite the previous one; nil entries are discarded. Also, we'll probably want to define many of the nils.
- Not noticeably slower anyway.
- I'll add that back, thanks. Done — Lfdder (talk) 22:18, 8 September 2013 (UTC)
- Yeah, that's what it's for. It'll only pass
|code=
on to the script if it's set or blank, but not if it's left out altogether. - That'd be good, thanks.
- The module has two modes: simple (strict) or fuzzy. Infobox lang could invoke the module directly with simple. Other templates like {{lang}} will definitely want fuzzy. What would the more specialised templates be for? These two things? Or do you have something else in mind?
- Thanks for the feedback! — Lfdder (talk) 21:40, 8 September 2013 (UTC)
Improved the fuzzy logic, it'll now try to match derivative compounded codes before falling back to the base code. — Lfdder (talk) 11:07, 9 September 2013 (UTC)
- {{ISO 639 name/sandbox|zh-Hant-CN}} → {{ISO 639 name/sandbox|zh-Hant-CN}}
- {{ISO 639 name/sandbox|zh-Hant}} → {{ISO 639 name/sandbox|zh-Hant}}
- {{ISO 639 name/sandbox|zh}} → {{ISO 639 name/sandbox|zh}}
All {{#ifexist:{{ISO 639 name {{{1}}}}}| ... }} tests will need to be changed to use #if and a vertical bar. They'll still work after importing sandbox 'cos they don't interact with this template, so this can be done after deploying the module -- but before deleting all the ISO 639 name templates. — Lfdder (talk) 08:16, 12 September 2013 (UTC)
Import the sandbox to go live with the module. — Lfdder (talk) 11:26, 13 September 2013 (UTC)
- Thanks for taking the time to write this! I was just thinking that the language name templates were overly complex as I was fulfilling your edit requests - and now I see that's what you had in mind from the start. By the way, I've made some tweaks to the whitespace and to the comma placement. There are a few different styles out there that I've seen in use, but indentation in the module namespace is always done with four spaces, as far as I've seen. The same goes for the comma placement - in the module namespace, I've only ever seen them at the end of the relevant line, not at the start of the next one.
Also, I agree with Amalthea about the nil values, and I've removed them all again. It seems like getting Lua to process a lot of table entries for not much reason. I know Lua is very fast when compared to templates, but why make it do the work when it doesn't have to? If you want to include the keys for maintenance purposes, probably commenting them out would be a better idea. Or, my preferred solution, you could make a subpage somewhere listing all of them that wouldn't actually be used in the live template.
And finally, is there any chance you could create Module:ISO 639 name/doc and [[Module:ISO 639 name/data/doc]]? It would be useful to have some documentation specific to the modules, even if only to say that all it does is implement the old ISO 639 name template. Best — Mr. Stradivarius ♪ talk ♪ 12:31, 13 September 2013 (UTC)
- Re. the nils, they're only processed once (and discarded) when the data is imported. It should have no impact on performance. (I think.)
- I've added documentation for Module:ISO 639 name, will do the same for data in a bit. Thanks, — Lfdder (talk) 13:42, 13 September 2013 (UTC)
I've replaced all the language names with their ISO names (used to be a mix of Wikipedia page titles and the names that were in all the ISO 639 name tpl's), which means that if this goes live now, it'll break category sorting for {{lang}} and others, so I've pulled the edit request. I've also added another mode to the script (explained in module doc). Would appreciate feedback. — Lfdder (talk) 17:00, 14 September 2013 (UTC)
Loop error with blank parameter
{{ISO 639 name|}} (with a blank parameter) creates a template loop error. This is only affecting 2 pages, that I know of, {{User x}} and {{User x/doc}}. —PC-XT+ 06:45, 31 March 2014 (UTC)
- I put a fix in the sandbox, but I also fixed the User x templates, so I'm not sure it really needs to be applied. —PC-XT+ 06:33, 5 April 2014 (UTC)
Add Hopi language
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Could someone add the Hopi language code, "hop"? I noticed it's not showing up on the {{rd from language}}
template with that language code given. --Xiaphias (talk) 07:57, 15 November 2014 (UTC)
- This can't be changed within this template; all it does is transcluding different language-specific templates.
{{ISO 639 name|hop}}
results in a transclusion of {{ISO 639 name hop}}, which contains the language name. This works as intended: Hopi. - Looking at the source code of {{r from alternative language}}, it displays the language only if a category for the language exists. Therefore all that is needed for the redirect template to work for Hopi redirects is creating Category:Redirects from Hopi-language terms and/or Category:Redirects to Hopi-language terms. SiBr4 (talk) 12:59, 15 November 2014 (UTC)
- Just noting for future changes (once Hopi is active): test adding Hopi to the main documentation led to the aforementioned "loop error" (see previous section). We'll probably need to implement the sandbox fix, when Hopi should get included in the documentation. GermanJoe (talk) 13:28, 15 November 2014 (UTC)
Help with Tuvan/Tyvan?
For {{ISO 639 name tyv}} gives {{ISO 639 name|tyv}}. However Tyvan is actually a redirect to Tuvan. Some of the pages that use it seem to be set to see it as Tyvan, others, like Category:Redirects from Tuvan-language terms use Tuvan. I don't want to change the value of the template from Tyvan to Tuvan without being sure that it won't screw something up.Naraht (talk) 21:45, 18 January 2015 (UTC)
Template-protected edit request on 11 February 2015
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
~ait″ Brayn not ait″
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. —
{{U|Technical 13}} (e • t • c)
15:06, 11 February 2015 (UTC)
Describing the template
Can a description be added to explain the criteria for being in the table? I could not find Filipino language, though its page says that it has ISO 639-2 and ISO 639-3 codes. Also, a description of "Code1" through "Code4" should also be included, or the column headings should be made more descriptive in the table; the current description mentions that the template resolves three standards, but there are four codes and the relationship to the standards is not stated. —Ost (talk) 20:47, 2 June 2015 (UTC)
Where is Old French??
Was Old French this deliberately left out of this list for some reason? We have Old English, Old Irish, and Old Church Slavonic (for crissake!) but no Old French? If I had more confidence with modifying the relevant code/ template I would take a stab at inserting it myself, mais zut alors, je ne l'ai pas! (bien que je puisse essayer!). Is there a story? If so, lay it on me. KDS4444Talk 05:43, 14 March 2016 (UTC)
- The list in the documentation does not cover all the possibilities, but the template does accept Old French as an argument:
{{Language|fro}}
. Cordialement, —capmo (talk) 07:15, 14 March 2016 (UTC)- Sweet! Thank you! KDS4444Talk 08:42, 14 March 2016 (UTC)
Template-protected edit request on 1 February 2017
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please change Sami language (which doesn't exist, it's a redirect to the language family) to Northern Sami. Florian Blaschke (talk) 05:13, 1 February 2017 (UTC)
- See Sami languages for more information. I think this editor may be looking for "sme" to represent "Northern Sami", but I'm not sure. The code "se" should probably not be used to code written language, since it is a language family. Someone with some domain expertise may be able to help more. – Jonesey95 (talk) 05:38, 1 February 2017 (UTC)
- It looks like "Northern Sami" is correct based on the SIL page, so I've changed it with this edit to Template:ISO 639 name sme. There are also some related categories which need to be moved - I'll do that now. — Mr. Stradivarius ♪ talk ♪ 06:42, 1 February 2017 (UTC)
- Actually, it turns out that "se" refers specifically to Northern Sami as well. "se" is the ISO 639-1 code for Northern Sami, and "sme" is the ISO 639-3 code for Northern Sami. The other Sami variants don't have an ISO 639-1 code. — Mr. Stradivarius ♪ talk ♪ 07:03, 1 February 2017 (UTC)
- Thank you, Mr. Stradivarius! --Florian Blaschke (talk) 11:20, 1 February 2017 (UTC)
- Actually, it turns out that "se" refers specifically to Northern Sami as well. "se" is the ISO 639-1 code for Northern Sami, and "sme" is the ISO 639-3 code for Northern Sami. The other Sami variants don't have an ISO 639-1 code. — Mr. Stradivarius ♪ talk ♪ 07:03, 1 February 2017 (UTC)
- It looks like "Northern Sami" is correct based on the SIL page, so I've changed it with this edit to Template:ISO 639 name sme. There are also some related categories which need to be moved - I'll do that now. — Mr. Stradivarius ♪ talk ♪ 06:42, 1 February 2017 (UTC)
Return empty string for codes not on the list
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
When provided with a language code that is not on the list, the template should ideally return an error message, or better yet, an empty string. However, it returns a link(?) to a nonexistent page! Can this be fixed, please? For example {{Language|xyzzy}}
returns a link to [[Template:ISO 639 name xyzzy]], but it should instead verify for the existence of that page and, if not found, return something else (error message, empty string... anything that can be tested with an #if). Thanks, —capmo (talk) 15:16, 20 June 2015 (UTC)
- That would require a test to see if the corresponding template exists or not. This parser function (ifexist) is considered "expensive" in terms of server resources, so I'm not sure if there would be any performance concerns for putting this in. Suggest we leave this for a few days to see if anyone else comments. Regards — Martin (MSGJ · talk) 19:56, 20 June 2015 (UTC)
- Just one or even half a dozen ifexist tests on a page shouldn't be a problem. Issues would arise if you tried to create a "meta page" that made ifexist checks for dozens of languages. I think this is a good idea. We have Category:Articles containing unknown ISO 639 language template, with over 500 pages, and it's difficult to find these without a bold red error message pointing to the offending template. I investigated León, Spain, which is in that category, and found the problem was caused by {{Leonese|Llión}}, which I found redirects to Template:Lang-ast-leo, which is in Category:Lang-x templates with other than ISO 639. Well, doh. We need to sort this out so that nobody wastes time chasing spurious errors. – wbm1058 (talk) 18:22, 4 April 2017 (UTC)
- Leonese dialect is in Category:Dialects of languages with ISO 639-3 code:
dialects and other varieties of languages which do have ISO 639-3 codes; unless the variety is reclassified as a separate language, it cannot be expected to ever have an ISO code, so there is no point in listing it in the main ISO maintenance category, which is intended to capture articles where the ISO code was overlooked.
– wbm1058 (talk) 23:02, 4 April 2017 (UTC)- That is why I left León, Spain for later as I was working through the alphabet. You'll notice that with the exception of the (pain in the neck) linguistics articles and a few sorted under "0-9", everything from A to E has been fixed. I have been fixing errors in that category for the last month or so by creating missing templates and fixing typos, but it is a real pain with the current template. A call to {lang|foo|text in language foo} does not generate a visible error message, does not generate a call to a nonexistent template in the list of transcluded templates, and does not generate a red category.
- If you can manage to figure out which invocation of the lang template is causing the error, then you have to create a new template and a new category for that language. In short, the errors are hard to fix, and the whole system is mostly opaque. It would be wonderful if someone could fix at least one of these shortcomings, either by showing an error message or showing a red template transclusion in the "Templates used in this page". It would be even better if a bot or bored AWB user could be permitted to create "ISO 639 name xxx" templates and matching categories for every ISO 639 language code. I have created 290 of the templates and their matching categories by hand, and it's tedious.
- It has occurred to me that some Lua magic might be in order here, but I don't know the first thing about how it works. I will award bonus points for a template or module that automatically redirects all calls to "Template:ISO 639 name xxx-YYYY", where YYYY is a valid ISO 15924 script, to "Template:ISO 639 name xxx". That would be amazing. – Jonesey95 (talk) 23:26, 4 April 2017 (UTC)
- This whole setup is looking a little crazy to me. Template:Lang-ast-leo is transcluded in just two articles: León, Spain and Province of León. What is the template really accomplishing for the encyclopedia? This is a near-extinct language dialect. My inclination is to just substitute the template, clean up any junk left behind, and put it up for deletion. It was a mistake to create a template for something that doesn't have an ISO code in the first place. wbm1058 (talk) 23:37, 4 April 2017 (UTC)
- Substituting templates one-by-one will be too tedious. Plan B. See if there can be a centralized fix to accommodate "dialect languages" without needing to create a boatload of new files with "fake-ISO" support. wbm1058 (talk) 00:46, 5 April 2017 (UTC)
- Speaking of Lua magic, there is a Module:ISO 639 name – it's actually a pseudo-redirect to Module:Language/name, which is used by Module:Language/text, a module meant for replacing
{{lang}}
and all lang-x templates. The modules are rated as alpha. Module:Language/name is invoked by Template:Wikipedia rank by size/WP to draw the pie chart shown in List of Wikipedias and Wikipedia § Language editions. Those are the only two articles currently transcluding the module. As I said, the efficiency of modules is most leveraged in "meta pages" like that which link to a lot of different languages. – wbm1058 (talk) 16:44, 5 April 2017 (UTC)
- It has occurred to me that some Lua magic might be in order here, but I don't know the first thing about how it works. I will award bonus points for a template or module that automatically redirects all calls to "Template:ISO 639 name xxx-YYYY", where YYYY is a valid ISO 15924 script, to "Template:ISO 639 name xxx". That would be amazing. – Jonesey95 (talk) 23:26, 4 April 2017 (UTC)
- I have a fix in the sandbox that returns an empty string as requested. – wbm1058 (talk) 16:44, 5 April 2017 (UTC)
- I also patched Template:Lang to check for {{{1}}} to prevent false-positive {{error}}s. Sorry it took 5 tries to get it right. In the process of that, I discovered that it is standard practice for Template:Language with name/for to call {{lang}} without passing a parameter {{{1}}}. See Template talk:Language with name/for; I'm wondering about that too. So as {{lang}} transcludes
{{ ISO 639 name {{{1}}} }}
we need to accomodate {{Language with name/for}}'s unconventional usage (maybe). My current fix has created Template:ISO 639 name non-English transclusions. That's better than having template loops or transcluding Template:ISO 639 name undefined, as the ISO 639 code has intentionally not been supplied by {{Language with name/for}}. So I think if we continue to tolerate and accommodate this time-consuming convoluted logic, then implementing the sandbox patch will make the undesirable Template:ISO 639 name non-English transclusions go away. I still need to look into how to ensure that the errors Jonesey95 wants to make easier to find are actually reported so they can get fixed more promptly. – wbm1058 (talk) 17:21, 5 April 2017 (UTC)
- I also patched Template:Lang to check for {{{1}}} to prevent false-positive {{error}}s. Sorry it took 5 tries to get it right. In the process of that, I discovered that it is standard practice for Template:Language with name/for to call {{lang}} without passing a parameter {{{1}}}. See Template talk:Language with name/for; I'm wondering about that too. So as {{lang}} transcludes
- Thanks for doing this. I am seeing the red-linked categories, which help track down the problem transclusions.
- I wonder if it would be acceptable to use something like
<span style="display:none;font-size:100%" class="error">unknown ISO 639 language code</span>
to display an error message. Editors who want to see the error message can choose to put custom css in their .css file that displays class=error. I think there is a more elegant way to do it, though: Template:ISBN calls a module that shows an error only in Preview mode, which is user-friendly, because it doesn't put red text in front of casual readers, but it shows an error to the tiny percentage of en.WP visitors who edit pages to improve them. That said, I don't know how to make an error message appear in preview mode as this ISBN Template/Module does. – Jonesey95 (talk) 05:16, 6 April 2017 (UTC)
- I wonder if it would be acceptable to use something like
As a result of the categorization changes, I am seeing redirects as categories, for example in Voiceless bilabial fricative. Is this showing up for others? I don't know why this would happen; I would expect the "ifexist" test to pass, since there is a page at Template:ISO 639 name {1}, even if it's a redirect. – Jonesey95 (talk) 14:31, 8 April 2017 (UTC)
- I see those redirects too. This isn't the easiest template to work on, but per that and this note left on my talk page, we need to come up with a better solution. wbm1058 (talk) 20:43, 9 April 2017 (UTC)
Template-protected edit request on 28 September 2017
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Could someone please make this template substitute cleanly by wrapping the three template calls in {{{|safesubst:}}}
, because it is substituted in {{internetquelle}}. Pppery 23:37, 28 September 2017 (UTC)
- Done — JJMC89 (T·C) 00:13, 29 September 2017 (UTC)
Hawaiian
Could someone please add Hawaiian to the list (Code: haw). I tried to do the edit myself but was quickly bogged down with vermicelli. Thank you in advance. nagualdesign 04:46, 24 November 2017 (UTC)
- Hawaiian has already been supported by this template since 2010. {{3x|p}}ery (talk) 21:15, 5 June 2018 (UTC)
Template-protected edit request on 20 September 2018
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Replace with {{#invoke:ISO 639|name|{{{1}}}}}<noinclude>{{doc|content={{ISO 639 templates|lua=yes}}}}</noinclude> as ISO 639 has been luafied. Using Module:ISO 639 allows for
1) More types of inputs (different types of codes and names)
2) The output of ISO 639-5 names (which should be supported as the name implies)
3) The output of all names officially in ISO 639 (as the names are directly from sil.org)
4) Better organization
– BrandonXLF (t@lk) 03:05, 20 September 2018 (UTC)
- Where are the test cases that show that this change won't break anything?
- As it stands right now,
{{lang}}
has a similar database. I had intended to modify this template to use{{lang}}
's data but hadn't yet got round to it. I don't think that en.wiki should have two (or more) databases that hold more-or-less the same thing. - —Trappist the monk (talk) 08:18, 20 September 2018 (UTC)
- @Trappist the monk: Module:ISO 639 allows for more inputs then lang. I'll make a test case. I feel as if ISO 639's database and Module:Script databases combined are more complete then lang's. – BrandonXLF (t@lk) 12:28, 20 September 2018 (UTC)
- Test-cases at Template:ISO 639 name/testcases – BrandonXLF (t@lk) 12:34, 20 September 2018 (UTC)
{{lang}}
has a specific purpose which is to correctly label text using thelang=
html attribute. The value assigned to that attribute must be listed in the IANA language-subtag-registry file so that browsers and screen readers understand the meaning of the attribute value. The IANA registry derives from the various ISO 639, 15924, 3166 standards so for the purposes of{{ISO 639 name}}
, the{{lang}}
data is sufficient. For the enhancements that you propose,{{ISO 639 name}}
can get 639-1 names from Module:Language/data/iana languages; can get 639-3 names from Module:Language/data/ISO 639-3.{{lang}}
has no use for explicit 639-2 and 639-5 nor for the non-IANA codes from 15924. I would advocate for the creation of separate Module:Language/data/ISO 639-2 and Module:Language/data/ISO 639-5 in the same format as Module:Language/data/ISO 639-3. This lends some amount of efficiency because for the typical case of{{ISO 639 name|<code>}}
you search the tables by indexing into them rather than by the cumbersome, time-consuming, brute-force search as is done in Module:ISO_639. For the name-to-code reverse lookup, a separate table could be created by automation that would combine the separate 639-1 data from Module:Language/data/iana languages, and the 639-2, -3, -5 tables to make a table of tables:['name'] = {639_1code, 639_2code, 639_3code, 639_5code},
.
-
- There is a bug:
{{ISO 639 name/sandbox|ang}}
→ Old English - —Trappist the monk (talk) 13:56, 20 September 2018 (UTC)
- @Trappist the monk: Bug fixed, If you want I can move Module:ISO 639/data, Module:ISO 639/data/altnames, Module:ISO_639/data/ISO_639-5 and Module:Script/data to module language replacing the current ones as they have more data, let me know waht you wan, all I really want is a tempalte that does what the name implies (that includes returning ISO 639-5 names. The current sub template is a mess and is very confusing, so it needs to converted to lua one way of another. Also, how is ISO 3166 related to language? – BrandonXLF (t@lk) 19:51, 20 September 2018 (UTC)
- Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. BrandonXLF, given that one bug has been uncovered so far the testcases need to show that all the existing uses work, which means all 1678 of the languages used by the existing template in Special:PrefixIndex/Template:ISO 639 name, not the languages in the module's code.
- @Trappist the monk: Bug fixed, If you want I can move Module:ISO 639/data, Module:ISO 639/data/altnames, Module:ISO_639/data/ISO_639-5 and Module:Script/data to module language replacing the current ones as they have more data, let me know waht you wan, all I really want is a tempalte that does what the name implies (that includes returning ISO 639-5 names. The current sub template is a mess and is very confusing, so it needs to converted to lua one way of another. Also, how is ISO 3166 related to language? – BrandonXLF (t@lk) 19:51, 20 September 2018 (UTC)
- There is a bug:
1678 languages in Special:PrefixIndex/Template:ISO 639 name, stripped to the bare language
|
---|
1bd |
- As an aside, (and please, don't take this the wrong way) when you're trying to show that you've been attentive to detail, leaving 3 spelling mistakes & unclosed brackets in your final comment doesn't help your case. Cabayi (talk) 08:57, 21 September 2018 (UTC)
- A very large part of the problem with the
{{ISO 639 name}}
suite of templates is that too many of the 'codes' that they support, aren't ISO 639 codes:{{ISO 639 name 1bd}}
→ {{ISO 639 name|1bd}} :1bd
is a Linguist list identifier so doesn't belong in an ISO template{{ISO 639 name Arab}}
→ Arabic :Arab
is four characters so is not an ISO 639 code; is an ISO 15924 script code{{ISO 639 name Cherokee}}
→ Cherokee :Cherokee
is a language name; why call a template with a language name to render that same name? (chr
→ Cherokee){{ISO 639 name Hluw}}
→ {{ISO 639 name|Hluw}} :Hluw
is an ISO 15924 script code{{ISO 639 name Ja-Latn}}
→ Japanese : an ISO 639 code with an ISO 15924 script suffix is no longer an ISO code but is an IETF language tag{{ISO 639 name ar-DZ}}
→ Arabic : an ISO 639 code with an ISO 3166 region suffix is no longer an ISO code but is an IETF language tag{{ISO 639 name be-tarask}}
→ {{ISO 639 name|be-tarask}} : an ISO 639 code with an IANA variant suffix is no longer an ISO code but is an IETF language tag{{ISO 639 name be-x-old}}
→ {{ISO 639 name|be-tarask}} : an ISO 639 code with an IANA private-use suffix is no longer an ISO code but is an IETF language tag{{ISO 639 name cbk-zam}}
→ {{ISO 639 name|cbk-zam}} : presumablycbk
= Chavacano andzam
= Zamboangueño; ISO 639-3zam
is Miahuatlán Zapotec;zam
is not an IANA-registered extlang;cbk-zam
is used as a sub-domain name for cbk-zam.wikipedia.org
- no doubt there are other non-ISO 639 'codes'. The
{{ISO 639 name}}
templates that use 15924 script codes should use the{{ISO 15924 name}}
template suite; those templates might be upgraded to use Module:Script/data (which should be harmonized with Module:Language/data/iana scripts if possible). For those 'codes' that are in the form of IETF tags, perhaps an{{IETF name}}
template that takes its data from the IANA data used by{{lang}}
. - —Trappist the monk (talk) 11:25, 21 September 2018 (UTC)
- A very large part of the problem with the
- As an aside, (and please, don't take this the wrong way) when you're trying to show that you've been attentive to detail, leaving 3 spelling mistakes & unclosed brackets in your final comment doesn't help your case. Cabayi (talk) 08:57, 21 September 2018 (UTC)
- Pretty sure that I did say what it is that I thought should be done.
-
- 3166 is the basis for the region part of an IETF language tag: pt-BR → Portuguese as used in Brasil.
- —Trappist the monk (talk) 09:03, 21 September 2018 (UTC)
- @Trappist the monk: Ok, So how you you want them moved over? I think instead of having ISO 639 name we should just call it language name and have it include IETF/IANA data. So in then end we would have a Script suite and a Language suite with other templates do special formatting to their outputs. Does that sound good? – BrandonXLF (t@lk) 12:24, 21 September 2018 (UTC)
- It is not an issue of movement as much as it is an issue of data sourcing and then, once we have decided on sourcing, we must take a decision about how we structure and define that data. Because the data come from multiple sources (infoterm (-1), Library of Congress (-2, -5), sil (-3)), we should attempt to use data directly from the appropriate source. Alas, infoterm apparently doesn't publish the official list of 639-1 codes so we must look elsewhere for them; the likely best place being IANA which prefers -1 over -3 codes when both exist. For -2 and -5, Library of congress publishes lists of codes – the -2 list contains both -2/T and -2/B codes. For -3, sil.org publishes multiple lists that appear to sometimes contain different data for the same code depending on which file you're looking at – for example the current iso-639-3_Name_Index_20180914.tab lists two spellings of
aee
while iso-639-3_20180914.tab from the same zip file lists only one spelling.
- It is not an issue of movement as much as it is an issue of data sourcing and then, once we have decided on sourcing, we must take a decision about how we structure and define that data. Because the data come from multiple sources (infoterm (-1), Library of Congress (-2, -5), sil (-3)), we should attempt to use data directly from the appropriate source. Alas, infoterm apparently doesn't publish the official list of 639-1 codes so we must look elsewhere for them; the likely best place being IANA which prefers -1 over -3 codes when both exist. For -2 and -5, Library of congress publishes lists of codes – the -2 list contains both -2/T and -2/B codes. For -3, sil.org publishes multiple lists that appear to sometimes contain different data for the same code depending on which file you're looking at – for example the current iso-639-3_Name_Index_20180914.tab lists two spellings of
-
- Because
{{lang}}
already uses 639-1 codes from the IANA language-subtag-registry file and 639-3 codes from sil.org's iso-639-3_Name_Index_YYYYMMDD.tab file, those two are I think, taken care of. For 639-2, it would seem a simple matter to create Module:Language/data/ISO 639-2 from the LOC data in the same format as Module:Language/data/ISO 639-3. For 639-5, Module:ISO_639/data/ISO_639-5 (what is the source for these data?) there are the issues of format conversion and ofaltnames
which do not appear in the LOC listing. - —Trappist the monk (talk) 15:17, 21 September 2018 (UTC)
- Because
- @Trappist the monk: Ok, So how you you want them moved over? I think instead of having ISO 639 name we should just call it language name and have it include IETF/IANA data. So in then end we would have a Script suite and a Language suite with other templates do special formatting to their outputs. Does that sound good? – BrandonXLF (t@lk) 12:24, 21 September 2018 (UTC)
- I've created testcases 1 2 3 & 4 (it's too much for 1 page). There's more that will need work beyond the dialect & script suffixes - bh, eml, & gkm caught my attention. Hope that helps, Cabayi (talk) 15:29, 21 September 2018 (UTC)
- That was a bit of work, thanks.
-
bh
is a valid 639-1 code; it is the only two-character collective:{{#invoke:lang|name_from_tag|bh}}
→ Bihari languages;eml
is not a valid ISO 639 code (deprecated 2009);gkm
is not currently a valid 639-3 code; see here.- —Trappist the monk (talk) 16:14, 21 September 2018 (UTC)
-
- testcases4 revealed a bug in Module:lang, now fixed. thanks
- —Trappist the monk (talk) 18:43, 21 September 2018 (UTC)
-
- The reason that the testcases had to be spread across four pages is revealed here (these parser profiling data captures from testcases2):
CPU time usage 6.248 seconds Real time usage 6.754 seconds Preprocessor visited node count 8,038/1,000,000 Preprocessor generated node count 0/1,500,000 Post-expand include size 19,120/2,097,152 bytes Template argument size 6,948/2,097,152 bytes Highest expansion depth 5/40 Expensive parser function count 420/500 Unstrip recursion depth 0/20 Unstrip post-expand size 0/5,000,000 bytes Number of Wikibase entities loaded 0/400 Lua time usage 5.521/10.000 seconds Lua memory usage 16.14 MB/50 MB
- this one from after I added calls into Module:lang (the IETF comments):
CPU time usage 6.048 seconds Real time usage 6.672 seconds Preprocessor visited node count 8,430/1,000,000 Preprocessor generated node count 0/1,500,000 Post-expand include size 22,894/2,097,152 bytes Template argument size 6,948/2,097,152 bytes Highest expansion depth 5/40 Expensive parser function count 420/500 Unstrip recursion depth 0/20 Unstrip post-expand size 0/5,000,000 bytes Number of Wikibase entities loaded 0/400 Lua time usage 5.249/10.000 seconds Lua memory usage 27.76 MB/50 MB
- in both cases the expensive parser function count is approaching the limit; once converted to Lua, the count will be zero. The lua time usage metric shows that the brute-force search currently employed by Module:ISO 639 is taking a lot of time; it shouldn't. The lua time measurement is not precise but giving scributo more work to do will not reduce the time it takes to accomplish the original work plus the new work
- —Trappist the monk (talk) 18:43, 21 September 2018 (UTC)
- @Trappist the monk: I got the ISO 639-5 list form the Wikipedia article, I couldn't find any sources. I'll try to find sources for the rest and post them here. – BrandonXLF (t@lk) 19:50, 21 September 2018 (UTC)
- Library of Congress is the custodian for -2 and -5. Their lists are:
- —Trappist the monk (talk) 20:40, 21 September 2018 (UTC)
- The more I look at the sub pages the more I'm confused. The naming system is a mess and there's so many sub-pages without documentation it's crazy. I think using Module:ISO 639 for now is a good idea, and then we can merge it with Module:Language. For now we should merge Module:Lang with Module:Language. – BrandonXLF (t@lk) 15:51, 23 September 2018 (UTC)
- Yes, the existing
{{ISO 639 name}}
template suite is confusing; that is why we are having this conversation I think using Module:ISO 639 for now is a good idea
– not in its current implementation for reasons stated aboveand then we can merge it with Module:Language
– no; the two modules have distinctly separate purposes and functionalityFor now we should merge Module:Lang with Module:Language.
– no; the two modules have distinctly separate purposes and functionality- —Trappist the monk (talk) 17:25, 23 September 2018 (UTC)
- @Trappist the monk: I'm saying Module:Language sub pages are confusing (
{{ISO 639 name}}
sub pages are confusing as well). I've made changes to Module:ISO 639, how does it run now?– BrandonXLF (t@lk) 20:11, 23 September 2018 (UTC)- BrandonXLF, Have you looked at the testcases 1 2 3 & 4 ?? I think the appearance of Lua error: not enough memory. early in each page answers your question. Cabayi (talk) 20:45, 23 September 2018 (UTC)
- ... and the testpages have ended up in Category:Pages with script errors. Cabayi (talk) 20:50, 23 September 2018 (UTC)
- BrandonXLF, Have you looked at the testcases 1 2 3 & 4 ?? I think the appearance of Lua error: not enough memory. early in each page answers your question. Cabayi (talk) 20:45, 23 September 2018 (UTC)
- @Trappist the monk: I'm saying Module:Language sub pages are confusing (
- Yes, the existing
- The more I look at the sub pages the more I'm confused. The naming system is a mess and there's so many sub-pages without documentation it's crazy. I think using Module:ISO 639 for now is a good idea, and then we can merge it with Module:Language. For now we should merge Module:Lang with Module:Language. – BrandonXLF (t@lk) 15:51, 23 September 2018 (UTC)
- @Trappist the monk: I got the ISO 639-5 list form the Wikipedia article, I couldn't find any sources. I'll try to find sources for the rest and post them here. – BrandonXLF (t@lk) 19:50, 21 September 2018 (UTC)
- I have hacked Module:Sandbox/trappist_the_monk/ISO_639_name. Used in Template:ISO 639 name/sandbox is doesn't run out of memory nor time when used in testcases 1 2 3 & 4 and renders error messages for those 'codes' that aren't ISO 639 codes.
-
- I'll add similar code for the
{{ISO 639 code-1}}
,{{ISO 639 code-2}}
, and{{ISO 639 code-3}}
templates. - —Trappist the monk (talk) 22:53, 23 September 2018 (UTC)
- @Trappist the monk: Your sandbox looks good, but it needs to be able to accept names, it needs to turn AA into aa and it needs to accept ISO 639-5. Also, how's Module:Time/sandbox? – BrandonXLF (t@lk) 04:59, 24 September 2018 (UTC)
- The purpose of this template is stated in the first line of its documentation:
- The
{{ISO 639 name}}
template is used to resolve ISO 639-1, ISO 639-2 and ISO 639-3 codes to language names.
- The
- A language name is not an ISO 639 code so the template should not accept input that is not a valid 639 code. Alas, because the current template does accept such input, any template replacement must deal with that misuse. I used an error message to show which of the testcases were not valid 639 codes so that something other than the simple error message might be done for them. At the moment I'm thinking that 'codes' that look like ietf tags will be stripped of their subtags and the result used to index into the appropriate 639 table. For non-code input, return the non-code input (perhaps decorated, perhaps not). In both of these cases, the code will add an error category so that these non-codes can be found and fixed.
- The purpose of this template is stated in the first line of its documentation:
-
- 639-5 will come in its turn; first we must get -1, -2, and -3 to work correctly because those are the codes most in use and supported by the template suite as it exists today.
-
- Can you show a case where my code did not properly handle a valid 639 code regardless of case? The code that you complained about appears to work correctly:
{{ISO 639 name/sandbox|AA}}
→ Afar
- —Trappist the monk (talk) 09:12, 24 September 2018 (UTC)
- @Trappist the monk: Are we not trying to make a template that supports
{{ISO 639 code-1}}
,{{ISO 639 code-2}}
, and{{ISO 639 code-3}}
? To stay organized it should be the same module. And I don't see why it's and for this to accept names. I can make the lua table for name to code using the find and replace function in Wikipedia, should this discussion be moved? – BrandonXLF (t@lk) 22:17, 24 September 2018 (UTC)- Yes, I think that we are trying to make a template that supports
{{ISO 639 code-1}}
,{{ISO 639 code-2}}
, and{{ISO 639 code-3}}
as well as the generic{{ISO 639 name}}
. And the code that I've written does that:{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_1|AA}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_1|AA}}{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_2|afa}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_2|afa}}{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_3|chr}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_code_3|chr}}
- I agree that all of this should be in the same module (data excepted).
- Yes, I think that we are trying to make a template that supports
-
- Some words have escaped from your sentence so it no longer makes sense:
And I don't see why it's and for this to accept names.
- What did you mean that sentence to say?
- Some words have escaped from your sentence so it no longer makes sense:
-
- Surely there's a better way of constructing a name-to-code table than by search and replace. Why should we consider moving this discussion?
- —Trappist the monk (talk) 22:40, 24 September 2018 (UTC)
- @Trappist the monk: I meant to say: I don't see why it bad (not and) for this to accept names. And to do the find and replace you find the regex (["[A-Z]+"]) = (.+"}) and replace it with the regex $2 = $1,, all you need to do it is AWB. – BrandonXLF (t@lk) 22:44, 24 September 2018 (UTC)
- It is pointless for the template to accept a language name that is not an ISO 639 code and return that same language name except as an error condition. Accepting a language name is contrary to the purpose of the template as stated on its documentation page.
- —Trappist the monk (talk) 23:05, 24 September 2018 (UTC)
- @Trappist the monk: Let's say you're making a template that has a output of a language name at some point. Some people might put the language name as the input for the parameter. Rather the having editors fix these issues, why not let Template:ISO 639 name accept the names of languages? Of course it should be more of a backup. – BrandonXLF (t@lk) 23:11, 24 September 2018 (UTC)
- Editors might also give the template the name of the Andalusian ambassador:
{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name|Pedro Jiménez de Góngora}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name|Pedro Jiménez de Góngora}}
- which is returned with an error message. For this template, language names as input are wrong just as the ambassador's name is wrong.
- —Trappist the monk (talk) 14:15, 25 September 2018 (UTC)
- Editors might also give the template the name of the Andalusian ambassador:
- @Trappist the monk: Let's say you're making a template that has a output of a language name at some point. Some people might put the language name as the input for the parameter. Rather the having editors fix these issues, why not let Template:ISO 639 name accept the names of languages? Of course it should be more of a backup. – BrandonXLF (t@lk) 23:11, 24 September 2018 (UTC)
- Module:Sandbox/trappist_the_monk/ISO_639_name_to_code built by Module:Sandbox/trappist_the_monk/ISO_639_name_to_code/make supports name-to-code:
{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Afar|1}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Afar|1}} – 639-1{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Cherokee|2}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Cherokee|2}} – 639-2{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Chazumba Mixtec|3}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Chazumba Mixtec|3}} – 639-3{{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Chazumba Mixtec}}
→ {{#invoke:Sandbox/trappist the monk/ISO 639 name|iso_639_name_to_code|Chazumba Mixtec}} – 639 part unspecified
- —Trappist the monk (talk) 14:15, 25 September 2018 (UTC)
- @Trappist the monk: I meant to say: I don't see why it bad (not and) for this to accept names. And to do the find and replace you find the regex (["[A-Z]+"]) = (.+"}) and replace it with the regex $2 = $1,, all you need to do it is AWB. – BrandonXLF (t@lk) 22:44, 24 September 2018 (UTC)
- @Trappist the monk: Are we not trying to make a template that supports
- Can you show a case where my code did not properly handle a valid 639 code regardless of case? The code that you complained about appears to work correctly:
- @Trappist the monk: Your sandbox looks good, but it needs to be able to accept names, it needs to turn AA into aa and it needs to accept ISO 639-5. Also, how's Module:Time/sandbox? – BrandonXLF (t@lk) 04:59, 24 September 2018 (UTC)
- I'll add similar code for the
@Trappist the monk:But it can't change ISO 639-2 to ISO 639-3 for example, But Module:ISO 639/sandbox can.
Output | Input | Output type |
---|---|---|
{{#invoke:ISO 639/sandbox|code1|French}} | French | code1 |
{{#invoke:ISO 639/sandbox|code2|french}} | french | code2 |
{{#invoke:ISO 639/sandbox|code3|French}} | French | code3 |
{{#invoke:ISO 639/sandbox|code3|fra}} | fra (code 2/3) | code3 |
{{#invoke:ISO 639/sandbox|code2|fra}} | fra (code 2/3) | code2 |
{{#invoke:ISO 639/sandbox|code2|fr}} | fr (code 1) | code2 |
– BrandonXLF (t@lk) 03:52, 27 September 2018 (UTC)
- I don't think that what you are attempting to do is working correctly:
{{#invoke:ISO 639/sandbox|code1|Cherokee}}
→ {{#invoke:ISO 639/sandbox|code1|Cherokee}}{{#invoke:ISO 639/sandbox|code2|Cherokee}}
→ {{#invoke:ISO 639/sandbox|code2|Cherokee}}{{#invoke:ISO 639/sandbox|code3|Cherokee}}
→ {{#invoke:ISO 639/sandbox|code3|Cherokee}}
- —Trappist the monk (talk) 11:34, 27 September 2018 (UTC)
- @Trappist the monk:, my bad. It's fixed now. How does it look? – BrandonXLF (t@lk) 19:44, 27 September 2018 (UTC)
- @Trappist the monk: Fixed all other issues too. – BrandonXLF (t@lk) 04:00, 28 September 2018 (UTC)
- @Trappist the monk: Can we move the data pages to Module:Language? – BrandonXLF (t@lk) 01:02, 5 October 2018 (UTC)
moving on
... before this discussion becomes moribund and is flushed into an archive
I have usurped Module:ISO 639 name (it was a pseudo redirect to Module:Language/name) and its associated /doc page (a true redirect to Module:Language/name/doc).
This module is currently in use in {{ISO 639 name/sandbox}}
. The four testcases pages created by Editor Cabayi are here:
The module has:
- Module:Language/data/ISO 639 override to allow us to return an alternate of the standard ISO 639 name when appropriate
- support for ISO 639-1, -2, -3, -5; codes and names all taken from custodial or other official sources
- support for individual code-part lookup
- the ability to link language name to a Wikipedia article; to be used by
{{ISO 639 name link}}
- code-from-name lookup
- code to replace expensive
{{#ifexists:}}
parser function - error messaging (can be hidden by user css) and categorization (Category:ISO 639 name template errors
Given the extensive coverage provided by Editor Cabayi's testcases, I expect little in the way of trouble implementing this module in the wider world. However, now is not the time for feature-creep so no edits should be made to the module except those that repair deficiencies or outright errors.
—Trappist the monk (talk) 14:34, 17 October 2018 (UTC)
- I've implemented the module in
{{ISO 639 name link}}
and in{{User x/doc}}
. - —Trappist the monk (talk) 16:06, 17 October 2018 (UTC)
Implemented the module in{{Native_name}}
.- —Trappist the monk (talk) 13:19, 19 October 2018 (UTC)
- Module:Lang is a better fit for
{{native name}}
. - —Trappist the monk (talk) 10:29, 22 October 2018 (UTC)
- Module:Lang is a better fit for
- Implemented the module in
{{Wikisourcelang}}
. - —Trappist the monk (talk) 11:00, 23 October 2018 (UTC)
- Implemented the module in
{{Infobox name module}}
. - —Trappist the monk (talk) 13:13, 24 October 2018 (UTC)
- Implemented the module in
{{Proofreader needed}}
,{{User Translator}}
- —Trappist the monk (talk) 13:03, 25 October 2018 (UTC)
Template-protected edit request on 18 December 2018
This edit request to Template:ISO 639 name has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
We received the folloing rewuest at the help desk:
- please fix {{iso2language|lij}} with link to Ligurian (Romance language). thanks!!! --2001:B07:6442:8903:8D3C:C5DA:57A1:9F2F (talk) 14:53, 18 December 2018 (UTC)
I checked at the ISO639 site: this is the correct mapping. please add:
- Already done Already done. Test:
{{iso2language|lij}}
- See rest of the discussion at Wikipedia:Village_pump_(technical)#template_fix_request. Dreamy Jazz 🎷 talk to me | my contributions 22:45, 19 December 2018 (UTC)
- Already done Already done. Test:
Mbo langues lead to the disambiguation page
Noticed that the mbo langues lead to the disambiguation page:
{{ISO 639 name|mbo|link=yes}}
→ Mbo - this is for Mbo language (Cameroon){{ISO 639 name|zmw|link=yes}}
→ Mbo - this is for Mbo language (Congo)