Template talk:Lang/Archive 6

1564:

to the script). These methods are shared across all objects of the same type using a metatable. This is convenient, because you can use a single variable for the language or the script and retrieve the code or the name from it when needed, and cleaner, because the code that handles the retrieval of the code and name is removed from the functions that use the code and name. But an object is probably overkill at this point if just the code and name are used. Another possibility would be table containing the code and first name (for instance,

31: 1255:. Each language code corresponds to a single language name that we call a "canonical name". The canonical name appears in level-2 headers in entries. There are two subtypes of languages: what could be called "full" language codes are allowed in regular linking or tagging templates, and etymology languages (codes for subtypes of full languages) are allowed in etymology templates: for instance, 8383:

So, if I understand correctly, the practical rationale behind the promotion to ISO 639-1 is that these codes are more likely to be understood by browsers? If this is so then it makes sense. But do we really want to have the maintenance burden of having to clean up every time someone uses an ISO 639-3

3757:

Like the current version of the data modules, the data created by the extraction tool does not have codes that are deprecated, codes that have preferred alternatives, nor codes that are marked as private use. I do not believe that there is a need for these particular codes but I could be wrong. I'm

1660:

The live templates do not categorize pages that are not in article space. For the time being, I have disabled that discrimination in the module for the purposes of debugging so you will see red-linked categories produced by the module at the bottom of this page (all hidden categories if 'Show hidden

8947:

I have seen instances of these codes used when the derivation of a word is unclear, but where it does appear to be traceable to a root word in a collective set of languages. I agree that there should be a recommendation to use them only in that situation or similar situations. I support the proposal

2709:

had some module code that would automatically transliterate the input text to the other script. That apparently didn't ever become live because there are/were problems transliterating Cyrillic to Latin in the presence (or lack – I'm not quite sure) of certain Unicode characters. I don't think that

1563:

Another thing I could mention is that we use language and script objects that have several methods (for basic things like retrieving the code and canonical name, or more complex things like retrieving the scripts used by a language, transliterating, or counting the characters in a string that belong

1485:

templates, but I don't have the motivation to sort out the crazy IETF tags (crazy from my perspective because I don't have to deal with them on Wiktionary), non-Wiktionary language codes, language names, colons, italicization, and the lack of any CSS classes for scripts. But if the distinct purposes

1420:

As you can see, Wiktionary is much more restrictive than Knowledge (XXG). Many of the features are probably not applicable, but at least you have an overview. One feature that would be nice is script recognition, at least if Knowledge (XXG) starts adding CSS classes for scripts. (Or the module could

1084:

The fallback idea sounds good to me. I have to note that many 639-2 codes do not work, even with the current non-Lua templates (including some of the other Frisian languages/dialects). I think we have a big win if end up with a system in which none of the lang-family templates will redlink (or break

3970:

giving a new index and value from the array each time it's called.) So functions would in many cases make unexpected things happen if they were saved in memory and accessed by multiple invocations. Other types (number, string, boolean, nil) don't behave in this way, so they can safely be saved in a

8462:

I might have said this somewhere in one of these threads, but it bears repeating: not all the three-letter codes are a 1:1 correspondence with two-letter ones. I have no issue with synonymous longer ones being made more concise (though yes, the longer ones are often more intuitive) as long as the

3932:

That works. Thanks. Failure on my part to grasp this in the documentation: "The value returned from the loaded module must be a table ... booleans, numbers, strings, and other tables" For a long time I somehow misunderstood that (perhaps not necessarily from the documentation; could have been

2512:; we don't need the language name, the "translit.", or the "lit." labels after the first occurrence in the same block of material, or sometimes we need the language one only, e.g. when comparing cognates. What we're doing now is using the template once, then abandoning it for manual markup with a 7235:

defined by sil.org as a collective with the name 'Germanic languages' but used by this template as an individual language named 'Proto German'; we should not be redefining international standards so if there is not international standard code for Proto German, we should not make one up except to

8431:(you reverted an edit made by that script). Yesterday there were about 550 pages in that category. Most of what remains is there because I didn't let the script make the edit so that I have the opportunity to fix the italic markup that will cause errors when the italic error checking code for 7819:

According to the ISO 639-2 custodian, "Multiple codes for the same language are to be considered synonyms." This would explain why the IANA data set has both ISO 639-1 and 639-3 language codes but does not have both -1 and -3 codes for the same language. This issue was brought to my attention

878:

will be easier to deal with. I spent a while creating (hundreds?) of ISO 639 templates and matching categories for obscure languages; the error category should more properly be used to track actual errors. I would be happy to help create a list of language codes and their matching full language

669:

code with 900+ of these already worked up can be dumped and munged in a way that makes it easy to adapt to the new Lua code. If there's a convenient way to extrapolate the language code to WP article correspondences in an array that is included that would probably make maintenance and expansion

8502:

The relationship between codes and language names is a frustrating one. ISO 639 establishes the base code-to-name mapping. When a code has more than one possible name, ISO 639 lists them in some sort of an order. IANA, sometimes chooses to use a different order for the same code and names.

1547:

Another feature I forgot to mention is that Wiktionary uses a data module to determine whether a script is RTL. It's probably a bad idea to set text direction for a given language, because languages are written in multiple scripts, and direction is a characteristic of the script, and as script

1520:

Thanks for that; it'll take a bit to digest but my initial reaction is that there is a basic lack of compatibility between Wiktionary and en.wiki in that en.wiki attempts, for the most part, to adhere to IETF/IANA language coding and attempts to minimize custom language coding. I do like the

8565:

I have written elsewhere in these discussions that we should not be making up our own primary language tags; should not be redefining tags that have already been defined by international standards. Instead we should be operating within the permitted uses of the standard.

8489:

There is no 1:1 mapping of all three-character codes to two-character codes. There is a 1:1 mapping of all two-character codes (ISO 639-1) to three-character codes (ISO 639-2/3). Three-character codes that have an associated two-character code are omitted from the IANA

5494:

script code, while the previous template didn't. Because the previous template didn't automatically do it, the correct way to format these words was to italicize them using wiki markup, which means that the module now appears to render them with two sets of encapsulating

4083:, some languages use three scripts (at least) – kk.wp is available in Latin, Cyrillic and Farsi script, for example. It would be convenient if all could be accommodated within a single template, but the sort of workaround you illustrate above could work too. 5526:

Latin scripts, I'd also be fine with the relatively small amount of redundant HTML generated by the current formatting in order to remove the need for doing it manually in the future. That might be doable by checking a language's suppressed script codes for

8871:(of which only a handful are in current use at en.wiki) where the language name ends with the word 'languages' (plural). This, according to the LOC faq, is how ISO 639-2 distinguishes individual and macro-language names from collective-language names. 2558:

switch and perhaps unlinking the translation and transliteration static text so that I can think about making the templates function correctly given a variety of inputs. That I think is mostly done so I'm about to take the module live on a handful of

4117:

In the example above, both alphabets are contained in a single template. That is still wrong and this change does nothing to permit that. But, it does start us on the way to supporting multiple alphabets in a single template as I have suggested at

3364:

depends on aren't necessarily current so at the moment I'm working on code that will extract language, script, and region information from the language-subtag-registry file. Currently there is no 'variant' data file but that could be extracted as

2787:

I suppose one could poke through the hundreds of templates to look for parameters, but another way to do it would be to convert the templates one by one to the new module, and have module code that detects unsupported parameters. Like the proposed

3954:

Exactly. The rationale is that functions can "trap" values from one module invocation that could then be transferred to another, or can otherwise change their behavior each time they are called. (For instance, the iterator function returned by

1785:. I created a bunch of them, but it gets tedious, especially because three other categories are also requested by the documentation for each ISO 639 name xxx template. A bot might be helpful in creating all of these red-linked categories. – 1746:

Yeah, I wasn't going to get into those yet. Getting all the ISO stuff to work would be first priority, but it would be nice to support codes introduced by others like Glottolog, at least for languages and dialects with no ISO code.

856:

Yep, am aware of that. I haven't given it a close line by line reading but to me it looks to be more tailored to Wiktionary's needs than to Knowledge (XXG)'s needs. I'm not opposed to merging this with that if it makes sense to do

7827:

It is common practice to promote three-character language codes to equivalent two-character codes. We should adhere to this practice. To that end I have created a tool that creates a Lua table from the data in the table at the

5986:; the template labels this text 'Greek' but the documentation implies that this template is to be used with Ancient Greek text so perhaps the labeling is incorrect; this is another case where private use tags may be useful: 2792:, such parameters could be evaluated for their utility and potentially incorporated into the module. Parameters that are determined to be unneeded or non-standard could be removed or converted to standard parameters. – 1290:

for the Unicode characters included in the script. Each language may have an array of script codes indicating which scripts it is written with, either in real life, in linguistic works, or on Wiktionary (for instance,

2900:, because that template receives its language code directly from the template in wikitext, editors will be creative in how they set that parameter. The module now supports the most commonly used (I think) IETF tags: 2814:

because to do the latter you are in effect doing the former? These templates are basically similar enough that we will see the oddball parameters straight away; no need for the module to detect anything. Compare

1548:

direction can be determined automatically, editors should not have to deal with it at all. (On Wiktionary, this item in the data module is almost never used, because text direction is set for many RTL scripts in

8494:

so browsers and other html readers are not obligated to know about those synonymous three-character codes. We do not reject three-character codes as input but where there is a two-character synonym, we use the

8704:

because there is an existing redirect. Categorization isn't quite noodled out yet. Simplest and best, I think, it to create three individual categories for the three languages and make them subcategories of

3340:%% Type: variant Subtag: petr1708 Description: Petrine orthography Added: 2010-10-10 Prefix: ru Comments: Russian orthography from the Petrine orthographic reforms of 1708 to the 1917 orthographic reform 1250:

But I guess I can explain something about Wiktionary's treatment of languages and scripts, which is very different. Language codes that are allowed in language-tagging and linking templates are listed in

9149:, all that should be required to implement the collective naming convention is to move the categories associated with these code to the appropriate names and tweak the data set to correctly support them. 8514:

So, we have a table of alternate names; of alternate spellings; of names we choose because of ISO 639/IANA of list order differences; of codes that improperly redefine the standard's definition:

3579:

BCP47 says that IETF language tags are case insensitive so I have relaxed the checking to allow any mixture of case. The code does, however, prettify its output (not that anyone will see it):

3289:

and so on. While there will always be variant subtags that won't get recognised by something all-encompassing (though you could just truncate off the last section, especially if it matches the

970:

which has, as its accompanying 'documentation', this: "Wikimedia wikis uses some non-standard codes and a subset of IANA codes, plus composite codes". Why? Why 'spoil' the standard that way?

4659:

That all looks better to me. If we have both translation and transliteration, we should not have any parameters that are abbreviated "trans" or "transl". That's just begging for confusion. –

5414:

statements. Were this code running on a micro-controller, such optimization might be required. It is not so we can afford to spend some processor cycles and use up memory space evaluating

7533: 8196:

I'm not quite sure I see the benefit of running this task. On occasions, the 3-letter code is more intuitive than the 2-letter one: if anything we should encourage the use of for example

5072:

Sounds good, though it may not be idea for lang-xx to be transcluding lang this way; better that it does this in Lua with a call to the same function, to reduce the transclusion count.

7647: 6872: 6818: 6801: 6734: 6717: 1725: 8301:

templates use codes and names from IANA (which gets them from ISO 639, but does sometimes reorder names when there is more than one spelling). IANA and ISO 639 do not distinguish

6839: 6822: 6768: 6751: 5022:

to use the module. I don't anticipate that this will cause problems. But, with 625,000-ish transclusions, problems may arise. The number is so large because a majority of the

2671:

Serbo-Croatian. This language uses both Latin characters and Cyrillic characters (not at the same time, I think) so the issue of italics arises. Rendering is controllable with

8463:

longer ones aren't rejected as input, and most especially as long as three-letter codes for dialects, historical stages, etc., are never collapsed to the generic language name.

8428: 7841: 2191:

Well, you were definitely right about this being more complicated than it seemed! Definitely appreciate the effort you're putting into this. We've needed to Lua-ize this for

1868:

to track those templates that are using the module during the transition period. Once all templates that can be have been changed to use the module, this category can go away.

8886:

templates use language names obtained from the data set for categorization and for language labels. For the occasions when collective-language codes are used, I propose that

8785:

templates should not use collective-language codes. Such use should be discouraged because these codes don't properly identify the language of the text held by the template:

804:; etc. We can keep a table specifically for fall back codes and another table to hold language names for 639-2 and -3 codes that don't fall back to 639-1 (Hopi, for example) 1781:

has existed since 2011, but it looks like the non-existence of the category causes the generic categorization. You can see a couple hundred other such templates with gaps at

5982:– appears to be a sort of catch-all for 'hard to define' Greek text or for Greek text that doesn't have a specific IANA/ISO 639 language code; internally the template uses 3937:. Clearly it means that it doesn't matter how the table is built, just that when the module returns, it can only return a table containing a limited subset of data types. 3017: 2504:

I would certainly think so. Another issue I was just thinking of again today (and grinding my teeth) is that we need a way to suppress these things entirely e.g. with a

7512:

is used to label Montenegrin which, apparently does not have a language code; a search of sil.org finds little mention of Montenegrin – no article transclusions; delete?

7902:

If that is correct, it would help to have an error message of some sort, perhaps shown in preview mode only, to give the editor a hint about how to fix the error(s). –

8427:

The maintenance message is only visible to those who turn on the display with the css code above. I have an AWB script that will help to clear the hidden maintenance

3197:

That is an excellent explanation. I look forward to getting rid of the current morass of hundreds of templates, redirects, and other madness. Keep up the good work. –

1456:, but didn't go anywhere with it, because it would only be for my own use until Knowledge (XXG) has a coordinated approach to script tagging and the associated CSS. 3816: 1694: 5736:

with the template as it was before the switch to the module (old). I right-clicked view source and to see the html the en.wiki serves, copy/pasted the markup for

1820:

templates to a module has been started before but never been completed. On the face of it, conversion to a module is simple but then you look under the bonnet ...

615:

Schweet. I'm not sure what the "for languages supported by MediaWiki" means; we'd want it, surely, to try to do the right thing for any arbitrary value given for

661:, etc. would also work after the Lua adaptation, since we have specific articles on various dialects of English. I guess that's a lot of work, but hopefully the 5805:

I should note that I'm looking at the publicly available page, because I'm unable to use the template edit or preview functionality due to it being protected. –

2947:

The module emits an error message when IETF tags don't match these forms or do look right but have invalid content. These tests should probably be added to the

937:

which also has 639-1 codes. That file may be dated since a comment at the top of it reads 2014-04-10 and I haven't wrapped my brain around the documentation in

3739: 7840:

uses that table to promote ISO 639-3 codes to ISO 639-1 codes. When this happens, a maintenance category is added so that the template call can be tweaked.

3528:

The variant data records in the iana language-subtag-registry file include a Prefix item that specifies the language code used with the variant. For variant

6438:

as 'Songhai languages', a collective of individual languages; special handling in Module:lang is required for collections – no article transclusions; delete?

6339:

as 'Romance languages', a collective of individual languages; special handling in Module:lang is required for collections – no article transclusions; delete?

2565:

templates to see what happens – to see if anyone outside of this conversation notices. You should probably start a new wish-list topic for the label thing.

4031:. I don't know how to tell the difference. My gut would say that switching alphabets 'midstream' is inappropriate. The same applies to transliterations; 2769:. Without a standard list, editors can (and will) write whatever suits them but what they concoct may not be understandable by readers and other editors. 1287: 9219:

under the German current lyrics heading is written using characters belonging to the Unicode Latin character set so should have been rendered in italics.

9116:→ 'Norman' – not defined as a collective but has the appearance of a collective – IANA names: Jèrriais, Guernésiais; proper handling of this may require 8706: 5341:

I work very closely with articles containing Ethiopic script. I agree with discontinuing support. Most modern browsers support rendering Ethiopic script.

6473:– provides labeling for simultaneous rendering of Cyrillic, Latin, and Arabic scripts; this functionality apparently never documented – 402 transclusions 1728:. I think that philosophy is misguided. I think that red-linked categories are more likely to get 'fixed' than a blue-linked dumping-ground category. 3933:

from other reading or conversation) because modules always return tables (even if they are tables of functions – something that is used quite a bit in

5689:

That is how it 'used' to look. Compare it against the rendering made by the live template. How are they different? They don't seem different to me.

4829: 4340: 4238: 3588: 3545: 3519: 3506: 3493: 3480: 3440: 3427: 3414: 3176: 3114: 3101: 1861: 1015: 312: 6621:

template that directly calls the module, we would be lumping all of these various old Greek languages into the same category used for modern Greek (

1642: 1027: 875: 6526:

as 'Sorbian languages', a collective of individual languages; special handling in Module:lang is required for collections – 8 article transclusions

6363:

as 'Salishan languages', a collective of individual languages; special handling in Module:lang is required for collections – 1 article transclusion

6325:

as 'Prakrit languages', a collective of individual languages; special handling in Module:lang is required for collections – 2 article transclusions

5418:. There is the added benefit that editors who come after us can know specifically what it is that is needed at that particular point in the code. 7418:

which don't appear to be necessary; if really for Latn script, should be italicized (for pinyin, presumably) – 0 transclusions; should be deleted?

6424:

as 'Slavic languages', a collective of individual languages; special handling in Module:lang is required for collections – 4 article transclusions

1857: 1782: 1654: 9298: 6349:– has support for IPA rendering plus transliteration none of which is documented and may only be used in a very few articles – 2073 transclusions 5269:

All of these are Ethiopic languages. If this is all that use this markup, then, for standardization, it would seem best to discontinue support.

6311:– has support for IPA rendering plus transliteration none of which is documented and may only be used in a very few articles – 197 transclusions 3246: 3777: 8540:

The provenance for the codes/names listed in that module is wholly unknown so is suspect. Cleaning that up is just one more task to be done.

7302:– template name uses a code that is not a legitimate IANA / ISO 639 code ostensibly to refer to Medieval Greek (internally the template uses 3919:, and the data will not be recompiled each time one of these templates is transcluded. That is the way we load data modules on Wiktionary. — 3880:. These tables don't need to recompiled for every use because they will only change when the standards from which they were created change. 5718:

tags instead of one; one set from the wiki markup, which was previously required for formatting, and one from the new lang module output. –

7045:

set to the appropriate value; the names 'Serbian Cyrillic' and 'Serbian Latin' not preserved because that usage is inconsistent with other

5342: 5214: 1865: 8948:

to match the language codes with the "collective" name; if editors want a more specific label, they can use a more specific language code.

3747: 3383: 5930:

when I preview the relevant section too. There is no caching involved because I previewed the page before looking at the source code. —

5522:

If, however, anyone wants to go the opposite direction and make the module output for Latin scripts more consistent by auto-italicizing

3751: 2621:

lists several templates that have sandboxen. Of those, where the template also has a /testcases page, I have edited the sandbox to use

1682: 1649:

template that matches the language code. The module doesn't use these templates so it uses a different category when the code isn't in

6871:– similar to Lang-de-AT, IETF language tags like this will require special handling bu Module:lang – 4 transclusions in article space ( 5971:. Most were relatively trivial to switch, the remaining templates less so. These remain to be switched, redirected, deleted, or not: 3819:

times out before it can be fully rendered. I guess I'm not all that surprised because the data set (all of those modules mentioned in

2224:

I got to wondering about the html/css markup around transliteration renderings when it occurred to me that the module doesn't (because

1897:

templates have support for translation rendering and some support transliteration rendering. I have attempted to add that support to

8953:

All of that said, I expect that this change will have some unexpected side effects, and we should be open to refining it as we go. –

6985: 6964: 5436:

Because we managed to break the module and because there are currently some 41k transclusions of it, I have protected it and created

4538: 3975:, accessed through the metatable of a dummy table, and shared between modules. In any case, you can always try loading a module with 2110: 1331:

to automatically detect the script of text that is being tagged. Thus, script codes are generally not required in tagging templates.

8700:

I use Walapai instead of Hualapai for standardization and because it matches the existing category. The label will link Walapai to

8474: 5298: 5083: 4688: 3686: 3266: 3252: 2579: 2539: 2206: 1758: 1096: 681: 344: 236: 3658:

I have not thought about that. Can you make a separate wish-list topic to hold this and other idea so that it/they don't get lost?

6179:); may require article naming of the creation of suitable redirects to make this template work with Module:lang – 26 transclusions 2894:

showed how it is necessary for the module to support IETF language tags so I've modified the module accordingly. When processing

7916:

Hadn't got there yet. Because it isn't really broken, I had thought to do something akin to the maintenance messages emitted by

8701: 6595:

code where the defined name associated with that code is 'Greek'. The module uses the defined name for the rendered label (the

3746:. I believe that we should update our data files to be inline with the current registry file. To that end I have cobbled-up a 5386: 4088: 1646: 1186: 1030:

and find what appear to be legitimate language codes that aren't part of 639-anything and create a table for use by the module.

902: 437: 3226: 424:(I was surprised to see that name still available). Not complete but in this first iteration it appears to correctly render 7171:

Converted to use the module; created three new templates that use private use codes, one each for the three language names:

3845:). The Lua processing time limit is 10 seconds. As an experiment, I forced the module to use only one of the data modules 157:{{Language with name|es|Spanish|{{#if:{{{italic|}}}|{{{1}}}|''{{{1}}}''}}|links={{{links|{{{link|yes}}}}}}|lit={{{lit|}}}}} 8366:

attribute. This is a prime argument for Module:Lang to discontinue support of the two linguist list codes it now supports.

3258: 923: 97: 5499:

tags (presumably one from the mark-up and one from the module). This also means the module auto-italicizes Latin scripts

3846: 3727: 2986:

might provide some useful examples of scripts that are in use. Some of the redirects appear to be for invalid scripts. –

934: 8134: 7895: 7833: 7316: 3387: 1276: 1252: 89: 84: 72: 67: 59: 8991: 8527: 3790: 3735: 3731: 1689: 1386:

to select different fonts for a variant of the script, either for their looks or their character set. (The script code

1247:

I saw that my name was mentioned above. It's a wide-ranging discussion, and I'm not sure exactly what I'm being asked.

1056: 967: 788:

I think that the rule we can apply to 639-2 and -3 language codes is to fall back on 639-1 when there is a 639-1: code

448:

is set. The module doesn't deal well with erroneous input and does not yet support categorization; basic rendering of

303:, but we should not have to do this, and it's so brittle and ugly that later editors are likely to break or revert it: 9294: 9173: 8937: 8750: 8548: 8447: 8374: 8183: 8166: 8122: 8101: 8047: 7996: 7874: 7800: 7658: 7636: 7383: 7344: 7282: 7211: 7144: 7031: 6941: 6851: 6780: 6643: 6535: 6170: 6166: 6087: 6066:

finds 83 instances of the template that use this functionality; not sure what to do with this one – 3819 transclusions

5779: 5697: 5591: 5519:). I think this should be reverted to the previous behaviour to both avoid this inconsistency and the duplicate HTML. 5473: 5448: 5426: 5321: 5277: 5181: 5161: 5062: 4999: 4943: 4902: 4853: 4785: 4650: 4394: 4278: 4070: 3945: 3888: 3801: 3766: 3666: 3626: 3568: 3373: 3188: 2973: 2851: 2777: 2654: 2634: 2601: 2494: 2401: 2384: 2322: 2179: 1876: 1828: 1736: 1538: 1231: 1067: 1038: 978: 949: 865: 834: 605: 401: 279: 167: 8868: 8491: 8222: 7941:

gets categorization functionality, the usual fix will be a fix to the template itself – though it is possible to set

3743: 3325: 5706:

The look hasn't changed, only the HTML markup and the circumstances around when the text will be auto-italicized by

3781: 3758:

going to update the data files. If anyone knows of a reason to include the codes that the tool skips, let us know.

3058: 2683:

when rendering the transliteration tool tip – though I don't know how useful that actually is). In this scheme, if

2459:, shouldn't that unlink the primary language (Hebrew) and the transliteration and literal translation static texts? 898: 7051:

templates for languages that use multiple scripts and because it is easy to distinguish one script from the other.

5788:

Curious. I've cleared my caches, and purged the page, but on the current version of that article I see this markup:

5462: 4084: 3076: 2659: 2649: 2644: 2639: 2629: 1215: 299:

Yeah, the presence of the language name necessitates a template-internal fix. There is a grotesque hack one can do

38: 7240:; any private use IETF tags will require special handling by Module:lang or by rewriting the templates to use the 3637:

Fantastic work. Should we also be warning against or disallowing language tags with suppressed script codes, e.g.

1557: 1445: 9040: 9021: 7254: 7111: 5733: 5635: 5601: 4823:{{#invoke:Lang|lang_xx_inherit|code=ru|text=какой-то кириллический текст|script=Cyrl|region=ru|variant=luna1918}} 2618: 1153:

so that we can override the BDP47 language names if needs be. The initial values assigned produce these results

252:

I was hoping you could just put italics around the template when you use it in an article, but that doesn't work:

9254:

to do its work, the text has these strip markers and it has the original newline characters (U+000A, LF, '\n').

6866: 6396: 6269: 6202: 6114: 4273:

Another reason to do this? So we don't have to fork a bunch of templates to properly support script subtags. —

2824: 2741:, to replace the langauge name with an unlinked abbreviation of the name. I am sure that we really don't need 1945:{{#invoke:lang|lang_xx_italic|code=de|text=Im Westen nichts Neues|italic=|translation=In the West Nothing New}} 1776: 1706: 1650: 1527: 1111: 963: 938: 897:

If there should be an array matching ISO 639-3 codes to language names, then it should ideally be in sync with

7898:

to see if there is an equivalent two-letter code. Then I change the three-letter code to the two-letter code.

3042: 2665:

Doing this found a handful of coding errors that have been fixed. The interesting case in these templates is

198:{{Language with name|es|Spanish|{{{1}}}|italic={{{italic|}}}|links={{{links|{{{link|yes}}}}}}|lit={{{lit|}}}}} 8351:

is deprecated, uses an invalid language code in its name, has no article transclusions, so should be deleted.

2528:

and driving readers nuts by repeating the same crap over and over at them as if they have dain bramage. ;-/

1441: 1051:

One answer to my 'why spoil the standard' question might be because the 'official' name associated with code

775: 9290: 9169: 8933: 8746: 8544: 8443: 8370: 8179: 8162: 8118: 8097: 8043: 7992: 7870: 7796: 7760: 7751: 7715: 7706: 7654: 7632: 7596: 7587: 7551: 7542: 7517: 7497: 7409: 7395: 7379: 7340: 7278: 7207: 7194: 7185: 7176: 7140: 7027: 6937: 6847: 6776: 6639: 6531: 5775: 5693: 5587: 5565:

This is a work in progress. It is not possible (for this human, at least) to, in one go, switch all of the

5469: 5444: 5422: 5336: 5317: 5273: 5177: 5157: 5058: 4995: 4939: 4898: 4849: 4781: 4646: 4390: 4274: 4080: 4066: 3941: 3884: 3797: 3762: 3662: 3622: 3564: 3369: 3184: 3145: 2969: 2847: 2773: 2597: 2490: 2397: 2380: 2318: 2175: 1872: 1824: 1732: 1534: 1227: 1063: 1034: 974: 945: 861: 830: 706: 653:

in most contexts (how often do we really need a wikilink explaining what the Spanish language is)? Ideally,

601: 397: 8384:

code instead of the 639-1 one? Won't it be possible for the template to do these conversions internally? –

8359: 8215:

According to the ISO 639-2 custodian, "Multiple codes for the same language are to be considered synonyms."

1467:

eventually if possible. It's unfortunate to have two modules that do similar things. I did attempt to make

911: 444:

and appears to correctly render when that parameter is used. It also appears to handle rtl languages when

7733: 7569: 7445: 6488: 6443: 6141: 6031: 4759: 2761:

as well. Is there a standardized list of language abbreviations? If yes, then perhaps we should support

2435: 2038:{{#invoke:lang|lang_xx_inherit|code=el|text=Θεοτόκος|italic=no|translation=God-bearer|translit=Theotokos}} 1173: 7742: 7578: 7471: 4045:(also incorrectly finds bold markup – I'll fix that) because the correct way to control italicization of 440:) so the module will need a table of the language names not supported by MediaWiki. The module supports 8471: 8232: 7437: 7105: 7059: 6548: 6133: 6015: 5977: 5458: 5295: 5080: 4685: 3683: 3309: 3300:

project. Anything that makes it easier for editors to add language tags to content gets my support :) —

2885: 2838: 2576: 2536: 2203: 2135: 2051: 1999: 1755: 1199: 1160: 1093: 1085:

entirely) unless a) we have no article or the language/dialect, or b) the code given is simply invalid.

1002: 761: 746: 700: 678: 341: 233: 8967:

I have tweaked the sandbox to use the category naming convention described above. In mainspace, this:

8009: 6368: 3840: 8331:

all produce the same html markup and the latter two would produce the same visible display and links (

8019: 5646:

text looks the same (to me) as it does when that page is rendered with the module. See for yourself:

7130: 5550:

Examples of what you mean are always appropriate. Which template are we talking about? Many of the

5771:

These look the same to me. Is it possible that you are looking at a cached version of an older page?

1549: 1383: 134:, etc.), so that the style is not applied to proper names (e.g. placenames, titles of songs, etc.). 8958: 8571: 8030: 7917: 7907: 7306:, Ancient Greek); the correct solution may be to rename the template to use a private use variant: 6833: 6812: 6795: 6762: 6745: 6728: 6711: 6698: 6673: 5437: 4771: 4664: 4424: 4199:{{#invoke:Lang|lang_xx_inherit|code=abq|text=Къарча-Черкес автоном область|script=Cyrl|italic=yes}} 3934: 3290: 3202: 2991: 2869: 2797: 2447: 2147: 2063: 2011: 1958: 1924: 1842: 1790: 1662: 962:(IETF language tags) should be used when choosing the code for the template. That being the case, 884: 656: 290: 219:{{Language with name|ru|Russian|{{{1}}}|italic=no|links={{{links|{{{link|yes}}}}}}|lit={{{lit|}}}}} 7164:– IANA/ISO 639-3 name is 'Havasupai-Walapai-Yavapai'; this template requires the use of a code in 3784:. I have used this tool to update that module and the other tool to update the IANA data modules. 2368:

So then, does that not mean that the html/css markup around transliteration renderings should be:

1453: 1283: 9193: 9165:

can be used to locally override the template-provided label (category name will remain the same).

8625: 8274:

By promoting synonymous ISO 639-2/-3 codes to ISO 639-1, Module:Lang aligns with this convention.

7982:(not sure why one would want to do that – perhaps that is something that should be prevented for 6457:

tag that applies special fonts and sizing; does not provide labeling in the manner of most other

5810: 5723: 5625: 5540: 5369: 5352: 3820: 3649: 1490: 47: 17: 8503:

Sometimes the ISO 639/IANA names are not suitable for direct use as a label by Knowledge (XXG):

7114:; does nothing special except label the text as 'Serbian Latin' – 50 transclusions; redirect to 4060:{{lang-abq|Къарча-Черкес автоном область}} {{lang|abq|Q̇arća-Ćerkes avtonom oblast’|italic=yes}} 3876:

The obvious solution is to create some sort of static version of the table of tables created by

1686:

because 'West Frisian' (the current category name) does not match the code/name defined by BCP47

5634:

I'm having a difficult time understanding what the problem is. If I take a step back and view

8912: 8385: 8362:

so that browsers and other html readers understand what is meant by the value assigned to the

8346: 8326: 8205: 8150: 7775: 7724: 7692: 7683: 7674: 7623: 7614: 7605: 7560: 7423: 7356: 7297: 7226: 7159: 6998: 6977: 6956: 6905: 6883: 6566: 6517: 6429: 6415: 6388: 6354: 6344: 6330: 6316: 6288: 6261: 6249: 6243: 6221: 6194: 6184: 6160: 6106: 6071: 5935: 5261: 4987: 4979: 4971: 4955: 4931: 4923: 4889: 3992: 3924: 3238: 2720: 1599: 1511: 1431:

and its subtemplates. But inline CSS is best avoided because, to overrule it, you have to add

991: 919: 848: 843:

I haven't been following the discussion, so apologies if this is irrelevant, but there exists

640: 148:{{Language with name|es|Spanish|''{{{1}}}''|links={{{links|{{{link|yes}}}}}}|lit={{{lit|}}}}} 9237:

The '?' characters in the strip marker are used here as visual replacements of the invisible

8864:

I am not suggesting that such codes should never be used, but they should be used with care.

8218: 7829: 7440:

but named as 'early German' (sic – a redirect) – no article transclusions; should be deleted?

4334:{{#invoke:Lang|lang_xx_inherit|code=abq-latn|text=Къарча-Черкес автоном область|script=Cyrl}} 9238: 9131: 9101: 9069: 8681: 8653: 8466: 8318: 7492:; no documentation so not clear indication of the purpose – 2 article transclusions; delete? 7092: 6923: 6478: 6468: 6306: 6049: 6023: 5402: 5345:

that should be archived. It is no longer necessary. The is not needed or helpful any more.

5290: 5252: 5225: 5198: 5075: 4963: 4915: 4881: 4873: 4680: 3678: 3303: 3136: 3082: 2571: 2531: 2523: 2198: 2102: 1750: 1150: 1088: 673: 648: 632: 491: 476: 379: 336: 324: 265: 255: 228: 207: 186: 140: 129: 7466:; no documentation so not clear indication of the purpose – 1 article transclusion; delete? 5740:. I repeated the procedure with the current template/module (new). Here are the results: 4098:

As a solution to this languages-with-multiple-scripts problem, I have renamed the existing

4023:

apparently has both Cyrillic and Latin scripts so the italicized part could be the correct

3245:, so not the more common types you're covering here. German has the same kind of tags with 1530:

so I guess that the mentioning editor presumed that by doing so, you had become the expert.

874:

I support the module-ization of this template, especially if it means that categories like

8221:). Promotion to ISO 639-1 is the generally accepted convention. If you look in the IANA 7824:

was causing a mis-categorization to Letzeburgesch when it should have been Luxembourgish.

7487: 7461: 7433: 7067: 6553:

is to label Classical Attic, Koine, or Byzantine Greek text as "Greek", I'd suggest using

6496: 6298: 6294: 6253: 6231: 6079: 5045:

because such checking will detect the hardcoded italic markup added by many (most) of the

4750: 4677:

to continue working; lots of use that, since it's short and mnemonic for what it outputs.

4444: 3278: 3230: 2426: 2227: 2118: 1949: 1915: 1468: 1464: 1425: 844: 779: 575: 560: 521: 506: 4232:{{#invoke:Lang|lang_xx_inherit|code=abq|text=Къарча-Черкес автоном область|script=Cyril}} 2911:

primary language code is the two- or three-character ISO 639 language code lowercase (ll)

8801: 5660:

https://en.wikipedia.org/search/?title=Template:Lang&action=edit&oldid=775049579

4150:{{#invoke:Lang|lang_xx_inherit|code=abq|text=Q̇arća-Ćerkes avtonom oblast’|script=Latn}} 4126:{{#invoke:Lang|lang_xx_inherit|code=abq|text=Къарча-Черкес автоном область|script=Cyrl}} 2860:

Modifying the templates will tell us whether or not the unusual parameters are actually

1449: 1328: 8954: 8026: 7903: 6990:

without the annotation; could be easily converted to use Module:lang – 14 transclusions

6969:

without the annotation; could be easily converted to use Module:lang – 32 transclusions

4743:

is too onerous, don't use any of them; positional parameters aren't going away either:

4660: 4420: 4203: 4154: 4130: 4020: 3793:? Anyone know where the data in that module came from? Is there an 'official source'? 3198: 2987: 2953:

so that we can, if appropriate create new templates that might make use of it (perhaps

2865: 2793: 2305: 2295: 2126: 2042: 1990: 1838: 1786: 880: 286: 8025:. I did a lot of that when cleaning up those template calls in the pre-module days. – 6483:– provides for simultaneous rendering of multiple transliterations – 235 transclusions 3750:

that creates the tables held in the data files from the IANA source. You can see the

2107:

doesn't allow editors to specify the transliteration standard nor does the underlying

1114:

has flaws. For example, that data would return these language names for these codes:

9249: 9199: 8774: 8765: 8434: 8290: 7930: 7888: 7847: 7479: 7453: 6604: 5806: 5719: 5709: 5652: 5621: 5615: 5568: 5536: 5407:

so that all Arabic script was rendered in italics font when it should not have been.

5365: 5348: 5017: 4552:– transliteration standard (only templates rendered by the module); module parameter 4295: 4253: 3861:. The page rendered properly in about 2 seconds. The differences are significant. 3826: 3645: 3215: 2864:, not just whether they exist in the template. Unused parameters can be discarded. – 2515: 1809: 1624: 1500: 1475: 1264: 816: 807: 664: 457: 360: 154:

The brute-force way around this is to go template-by-template and do something like:

6165:– one of two Ligurian languages officially 'Ligurian' but the en.wiki article is at 3865:

allows the included modules to hold executable code but must be reloaded with every

430:

for languages supported by MediaWiki (not the whole 900+ languages supported by the

9177: 8962: 8941: 8754: 8552: 8484: 8451: 8388: 8378: 8208: 8187: 8170: 8153: 8146: 8126: 8105: 8051: 8034: 8000: 7911: 7878: 7804: 7662: 7640: 7387: 7286: 7215: 7148: 7035: 6945: 6908: 6855: 6784: 6647: 6569: 6562: 6557:. None of the other special subtags have been abbreviated to three characters, and 6539: 5938: 5931: 5814: 5783: 5727: 5701: 5629: 5595: 5544: 5477: 5452: 5430: 5374: 5357: 5325: 5308: 5281: 5185: 5165: 5093: 5066: 5003: 4947: 4906: 4857: 4789: 4698: 4668: 4654: 4455:

templates that support transliteration? Of course, none of these are good reasons.

4428: 4398: 4282: 4092: 4074: 3995: 3988: 3949: 3927: 3920: 3892: 3805: 3770: 3696: 3670: 3653: 3630: 3572: 3377: 3315: 3206: 3192: 2995: 2977: 2873: 2855: 2801: 2781: 2605: 2589: 2549: 2498: 2405: 2388: 2326: 2216: 2183: 1880: 1846: 1832: 1794: 1768: 1740: 1602: 1595: 1542: 1514: 1507: 1235: 1106: 1071: 1042: 994: 987: 982: 953: 927: 915: 888: 869: 851: 838: 691: 609: 405: 354: 294: 246: 4462:

For the most part, there are four different groups, if you will, of parameters in

6580:

templates is desired, editors can, after the next update to the live module, use

2272: 9216: 8887: 8254: 7837: 6679: 6189:– has support for two simultaneous transliteration renderings – 47 transclusions 6003: 5995: 5968: 5639: 5580: 4038: 3850: 3723: 3391: 3361: 3029: 2891: 2711: 2622: 1898: 1460: 1260: 421: 46:

If you wish to start a new discussion or revive an old one, please do so on the

5362:

In fact, it has become a page for software developers to add promotional spam.

1526:

I think that you were mentioned here because you were the last editor to touch

8060:

Hidden messaging added. To see the messages, add this to your preferred css:

7856:. Without any issues or problems, this functionality will be extended to the 6584:. It isn't clear to me how the reader benefits from that kind of obfuscation. 4186:

is set, the module will apply italic markup only when the specified script is

3021: 3001: 1677:

templates ever call Module:Lang, namespace discrimination will be reinstated.

999:

And there is more ... There are lang-xx templates that don't use BCP47 codes:

373:'"`UNIQ--templatestyles-0000000B-QINU`"' 9257:

I have tweaked the sandbox to account for the delete and newline characters:

8597:

is the BCP47-required singleton that marks the beginning of a private use tag

8309:; they provide the same names in the same order: Panjabi and then Punjabi so 5503:

of the time, but not most of the time (such as in the common cases where the

4838:

Error: {{Lang-xx}}: script: cyrl not supported for code: ru (])</span: -->

4351:

This error message should be rare because it should not be necessary to have

1394:, but having a distinct script code for Persian allows it to be displayed in 6929: 4498:– language script (only templates rendered by the module); module parameter 4270:. If they are not the same, the module will emit a mismatch error message. 4015:{{lang-abq|Къарча-Черкес автоном область ''Q̇arća-Ćerkes avtonom oblast’''}} 1375: 725: 5490:

The module currently seems to auto-italicize language tags which include a

966:

would seem to be the best choice ... except that it includes a file called

743:

Of those languages that are supported, there are likely to be differences:

8393:

The module does do the promotion so that it produces correct html markup:

3597:

Error: {{Lang}}: script: cyrl not supported for code: ru (])</span: -->

2717:

The other one that I have found, though I've done nothing with it yet, is

1657:– that name could certainly be less wordy and more concise. Suggestions? 1440:

to every rule in your personal stylesheet that contradicts it.) I started

4416: 3360:

yes, but the others that you mentioned, no. The data files that the new

2982:

I don't know how the ISO 639 name xx templates fit into all of this, but

2753:

and because to someone unfamiliar with the internals of these templates,

2286:

are the defaults. If they are used here then that suggests that the css

1837:

Keep going! If anyone can do it, you can. Let us know how we can help. –

1405:

We don't allow any modifiers to be appended onto language codes: placing

1395: 990:

might have an opinion here, as he was the last to work on this module. –

6932:

handles the complexities and nuances of Chinese text; nothing to do here

1986:{{Lang-el|Θεοτόκος|links=yes|translation=God-bearer|translit=Theotokos}} 3016:

which returns 'Russian' so that the article is properly categorized in

2092: 774:

in this case 'Western Frisian' agrees with the ISO 639 custodians; see

6044:

diacritical marks; not sure what to with this one – 3521 transclusions

3675:

I set up a section for that, and put both my and Quoth's items in it.

2140: 7086: 6678:– this and similar templates will require special handling either in 6574:

For the cases where a label different from the label provided by the

6039: 8707:

Category:Articles containing Havasupai-Walapai-Yavapai-language text

8570:(IETF language tags) provides for private use tags. I have tweaked 6169:(the other officially is 'Ligurian (Ancient)' and its article is at 5465:. The sandbox produces different (correct) results for these tests. 4055:

All of this suggests that the correct way of writing this would be:

2159: 1486:

of generating a Wiktionary-compatible tagging and linking template (

8535:→ Medieval Latin (there is no ISO 639/IANA code for Medieval Latin) 3869:(every 'template' in the wikisource). The modules 'included' with 2393:

Changed. Results can be seen in the transliteration example above.

2267:

For this example, shouldn't the module output something like this:

9000:→ 'Bihari' – Bihari languages ; only two-character collective code 8567: 4248:

The module does not now, but will, compare the IETF script subtag

3609:{{lang/sandbox|es-419|Spanish in Latin America and the Caribbean}} 959: 901:

as well as – whenever possible – with the comprehensive series of

8926:

Category:Articles with text from the Romance languages collective

8853:

Spanish, Old (to 1500) (not in IANA list by that name – possibly

5714:. If you inspect the HTML you should see two sets of surrounding 5604:

under the Chinese Mandarin entry with its pinyin transliteration

3873:

must not hold executable code but are loaded only once per page.

3233:. Text written in that specific form of Russian should be tagged 7168:

to choose one for the language label and link; 29 transclusions

3324:

variant listed. There is this, extracted from the current IANA

2914:

script is the four-character IANA script code; title case (Ssss)

5638:

with the previous version of the template (the last one before

4607:

Can't do much about existing template parameters here and now (

3460:

but rejects improperly formed tags and emits an error message:

3067:. I have no idea where ru-1708 came from. Its only use is in 4237:

Error: {{Lang-xx}}: unrecognized script: cyril for code: abq (

3544:

Error: {{Lang}}: unrecognized variant: petr1708 for code: de (

3536:

so using that variant with another language code is rejected:

1911:{{lang-de|Im Westen nichts Neues|lit=In the West Nothing New}} 1643:

Category:Articles containing unknown ISO 639 language template

1417:

into a linking or tagging template results in a module error.

1028:

Category:Articles containing unknown ISO 639 language template

876:

Category:Articles containing unknown ISO 639 language template

172:, to do italics automatically by default, but exclude it when 25: 5410:

The purpose of the module edits was to simplify a handful of

4828:

Error: {{Lang-xx}}: script: cyrl not supported for code: ru (

4304:, editors can simply add the appropriate IETF script subtag: 4300:. Because the template gets the language code directly from 2554:

For the time being, I'm going to limit 'new features' to the

8603:

is the private use tag; one to eight alphanumeric characters

5649:

this link opens the edit window for the previous version of

5531:

when no script tag has been supplied, and italicizing it if

2917:

region is the two-character IANA region code; uppercase (RR)

1858:

Category:Articles containing unknown language template codes

1783:

Category:ISO 639 name from code templates without a category

1655:

Category:Articles containing unknown language template codes

1271:). Some of the codes are Wiktionary-specific: for instance, 7884:

So to fix these codes: I look for a three-letter code in a

4223:

The module emits an error message if the value assigned to

2675:

but it might be better to create another script parameter (

2372: 1421:

add the very verbose inline CSS that is currently found in

8158:

Copy/pasta from another of the tools, otherwise no reason.

5039:

around the text. I have disabled the italic checking for

4597:(only templates rendered by the module); module parameter 3587: