Hi,
I added a conjugation table to at least two Kott language articles a while ago, and now I'm wondering how to replace my wikitext (a raw table) with one or more conjugation templates for the Kott language. Jackwolfroven (talk) 20:05, 2 July 2015 (UTC)[reply]
Yeah, thanks. If I get more information about the language (for example if I learn of regular conjugation classes), may I edit the template? Jackwolfroven (talk) 20:48, 2 July 2015 (UTC)[reply]
The {{inflection of}} template no longer accepts the pos parameter: "Lua error in Module:parameters at line 85: The parameter "pos" is not used by this template." See azokhoz. How can I find all Hungarian entries with this error? I'd like to correct them. Thanks. --Panda10 (talk) 17:08, 5 July 2015 (UTC)[reply]
Unfortunately, I have no idea where and when they will appear. Which entries? Could you create a category to track it? All Hungarian words that use the {{inflection of}} template and have the pos= parameter. --Panda10 (talk) 17:23, 5 July 2015 (UTC)[reply]
Anyone OK with or objecting to adding gmy (Mycenaean Greek) to the list of languages where we override the manual translit? I encountered this issue when writing code to remove unnecessary translits. In particular, {{grc-alt}} when passed the parameter |dial=muk passes the resulting translit parameter to {{head|gmy}} instead of {{head|grc}}. Now, grc is in the override list but gmy isn't, so I have to special-case this template. I don't see why there would be any exceptional transliterations required for Linear B. Benwing (talk) 08:46, 7 July 2015 (UTC)[reply]
I have added gmy to the list of languages where we override the manual transliteration, but we can wait a little more to see if anyone objects. --Vahag (talk) 10:22, 7 July 2015 (UTC)[reply]
(NB, if the display looks weird of the second string, and it seems the chars from the first string have gotten jumbled in some strange way, it's because your browser doesn't recognize Arabic Extended A as R2L characters yet.) Benwing (talk) 13:02, 7 July 2015 (UTC)[reply]
There is a mistake in your text. U+E8A0 should probably be U+08A0. I also think we should stop maintaining separate scripts, such as fa-Arab, for other Arabic-script languages. --WikiTiki8913:10, 7 July 2015 (UTC)[reply]
There are twelve different sub-varieties of the script code Arab. I understand that not every font that supports Arabic-language Arabic script is optimized for, say, Persian-language Arabic script, but is it really the case that all twelve varieties use such different letters that they need different fonts? (Are there any other issues, like different transliterations?) It would seem like we could combine at least some of the sub-varieties. - -sche(discuss)00:49, 9 July 2015 (UTC)[reply]
Transliterations are irrelevant because they are handled by language, not by script. The difference is that each of these subvarieties has its own special characters that may not be supported by fonts designed for a different Arabic-script language. But nowadays most fonts do support all of these languages. The other thing is that some languages prefer to write certain characters in slightly different ways. But we don't worry about this in Cyrillic, for example, where the б in Serbian is sometimes displayed differently from the б in Russian, but we still use the same script tag for them (in fact, some fonts will handle these differences automatically if the language is properly tagged). If you take the Latin script as an example, there are tons of languages that use vastly different sets of special characters with different capitalization rules (such as for the ı in Turkic languages) and other quirks, yet they all use the same script tag (although we do have Latnx and Cyrs for certain dead Latin- and Cyrillic-script languages because they are less likely to be supported by mainstream fonts). --WikiTiki8915:34, 9 July 2015 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Can we not just write the CSS in a way that it special-cases on the language as well as the script? In MediaWiki:Common.css there are examples like
I can't figure out who is responsible for maintaining the Ancient Greek entries, but I found a number of mistakes in the template calls, where Greek text occurs in the transliteration field that I would otherwise remove. In general these are cases that should go into the sort field that follows the obsoleted translit field, although maybe the sort field is also unnecessary.
Page 8956 αἰώνιος: WARNING: Value 3=αἰωνιος has non-Western chars in it, not removing: {{grc-adj-1&2|αἰώνια|αἰώνιον|tr=aiōnios|αἰωνιος}}
Page 9200 θύννος: WARNING: Value 4=θυννος has non-Western chars in it, not removing: {{grc-noun|θύννου|m|second|θυννος|tr=thunnos}}
Page 9871 χόδανος: WARNING: Value 4=χοδανοσ has non-Western chars in it, not removing: {{grc-noun|head=χόδᾰνος|χοδάνου|m|second|χοδανοσ}}
Page 11618 σταφυλή: WARNING: Value 4=σταφυλη has non-Western chars in it, not removing: {{grc-noun|σταφυλῆς|f|first|σταφυλη|tr=stafulē|cat1=Fruits}}
Page 254 αἰώνιος: WARNING: Value 3=αἰωνιος has non-Western chars in it, not removing: {{grc-adj-1&2|αἰώνια|αἰώνιον|tr=aiōnios|αἰωνιος}}
Page 2089 ζεῦγμα: WARNING: Value 4=ζευγμα has non-Western chars in it, not removing: {{grc-noun|ζεύγματος|n|third|ζευγμα}}
Page 2360 θύννος: WARNING: Value 4=θυννος has non-Western chars in it, not removing: {{grc-noun|θύννου|m|second|θυννος|tr=thunnos}}
Page 3494 μέδος: WARNING: Value 4=μεδος has non-Western chars in it, not removing: {{grc-noun|unknown|m|second|μεδος|cat1=Beverages}}
Page 4277 παρῳδία: WARNING: Value 4=παρωδια has non-Western chars in it, not removing: {{grc-noun|παρῳδίας|f|first|παρωδια}}
Page 4688 πτερωτός: WARNING: Value 3=πτερωτος has non-Western chars in it, not removing: {{grc-adj-1&2|πτερωτή|πτερωτόν|tr=pterōtos|πτερωτος}}
Page 5088 σταφυλή: WARNING: Value 4=σταφυλη has non-Western chars in it, not removing: {{grc-noun|σταφυλῆς|f|first|σταφυλη|tr=stafulē|cat1=Fruits}}
Page 5873 χαραδριός: WARNING: Value 4=χαραδριος has non-Western chars in it, not removing: {{grc-noun|χαραδριοῦ|m|second|χαραδριος|cat1=Birds|tr=kharadrios}}
Page 5906 Χέοψ: WARNING: Value 4=Κheops has non-Western chars in it, not removing: {{grc-proper noun|Χέοπος|m|third|Κheops}}
Page 5935 χόδανος: WARNING: Value 4=χοδανοσ has non-Western chars in it, not removing: {{grc-noun|head=χόδᾰνος|χοδάνου|m|second|χοδανοσ}}
Fixed. All but one of them were mine, mostly dating back to when I was still learning how to use the templates. At μέδος(médos), I wish I could get it to say that the genitive is unknown, rather than indeclinable (It looks like it should be a straightforward second-declension noun, though). My workaround must have worked when I did it, but the template has changed completely since then. As for the sort field: it is unnecessary, though there may be an exception or two I don't know about. Chuck Entz (talk) 06:12, 8 July 2015 (UTC)[reply]
This junky template still makes use of manual translit rather than auto-transliterating the Greek text. If someone (e.g. CodeCat) wants to fix this up, please be my guest. Benwing (talk) 03:10, 8 July 2015 (UTC)[reply]
Not that I have any reason to distrust Benwing in particular, but I think this project has enough admins, actually. — Keφr18:16, 9 July 2015 (UTC)[reply]
I don't need admin privileges but I'd like to be able to edit certain module pages that are currently locked, without having to bug others to do it. CodeCat in particular has not been very responsive recently to requests I've made. Benwing (talk) 07:52, 10 July 2015 (UTC)[reply]
ERROR: editpage: abusefilter-warning-ref-no-references
Hit AbuseFilter: ref no references,
WARNING: Page [[Thule]] not saved
Page 25 Thule: Error
I tried a manual save and I don't hit the abuse filter. The page does have <ref> without <references/> but instead it has {{reflist}}, which seems to do the same thing. This suggests something is wrong with the filter. Benwing (talk) 23:32, 8 July 2015 (UTC)[reply]
I remember deleting that template, back when it did something else. Since it is pointless and causes problems like this, I think it should be speedied and salted. Or replaced with something along the lines of "Just use <references/> directly, you idiot", following {{helpme}}. — Keφr18:18, 9 July 2015 (UTC)[reply]
{{head}} doesn't pay attention to override_translit
Why not? There are a couple of cases, in particular in Ͷ and ͷ where it potentially might make sense to allow overridden translits of Ancient Greek, but in general it seems really hacky to have {{head}} allow overriding langs with override_translit -- it goes against the whole purpose of override_translit and makes it risky to remove manual translits in {{head}}. In these two cases a better idea would be to use |tr=- and manually write the translit afterwards. Benwing (talk) 23:43, 8 July 2015 (UTC)[reply]
Wouldn't this issue affect not just Ͷ and ͷ, but any words spelled with them? I presume such words are attested. Or do we have a policy of "normalizing" the spelling/encoding of words which contain such allographs the way we normalize words from old books that have long s, superscript-e-umlauts, c-t ligatures and some other things? - -sche(discuss)00:58, 9 July 2015 (UTC)[reply]
But, to follow up on this thought, then any links to such words would be affected as much as the entries' {{head}}s, so the solution would be to turn off the overriding of manual transliteration for Greek (iff we don't have a better way of handling entries with Ͷ and ͷ). {{head}} should override manual transliterations to the same extent as other templates. - -sche(discuss)15:45, 9 July 2015 (UTC)[reply]
I don't think there are any words that have Ͷ or ͷ in them. I'm not sure if it makes sense to turn off override_translit for Ancient Greek just to handle these particular cases. Benwing (talk) 07:58, 10 July 2015 (UTC)[reply]
Well override_translit is just a workaround to make sure all transliterations are standardized before we remove all the manual ones. Once we remove all the manual transliterations, we can remove override_translit and then be able to use manual transliterations for exceptional cases. --WikiTiki8917:15, 10 July 2015 (UTC)[reply]
I have a bot to remove the translits but haven't finished, partly because there's an issue with long ā ī ū existing in the translit but not in the Ancient Greek itself, when the underlying vowel is long. My partial run already removed many such cases but I'm thinking of putting them back. There is a list of such cases in my user space; see the comments in my talk page under the entry for Ͷ/ͷ. Ideally the Greek should be canonicalized to include the long marks, based on the translit. There are two ways to do this: Either insert the Greek text with macrons as "alternate display" text or (IMO better and will make a lot of things a lot easier) insert it as the normal text and remove the macrons using a filter, just like we do for Latin. What do you think of implementing such a filter? Benwing (talk) 09:01, 11 July 2015 (UTC)[reply]
There are about 200 Chinese character entries in this category. In many cases (e.g. 匽), the issue seems to be that {{Han etyl}} expects several pictures and not all of them exist. Can someone adapt the template so users can specify that it shouldn't attempt to display certain pictures (because they don't exist)? In other entries, e.g. 血液循環, the issue is that someone has specified ma=y or the like to tell {{zh-pron}} to display an audio file, but no audio file exists. - -sche(discuss)01:23, 9 July 2015 (UTC)[reply]
I thought we made module pages display indentations with a width of four spaces. Now, it seems to have switched back to eight. (See any module page for an example, but for convenience, I will link Module:en-headword.) --WikiTiki8921:19, 9 July 2015 (UTC)[reply]
This should be changed, but I think we should also try to make the syntax highlighting match between the view page and the edit page. —CodeCat21:35, 9 July 2015 (UTC)[reply]
This unpleasant template has display issues, that I've seen a few times:
1. It does not allow a collapsible box header, but simply plops a duplicate "Derived terms" below the "Derived terms" header that is already present.
2. It incorrectly displays some terms. Look at orange#Derived_terms, where "satsuma" orange displays as "atsuma orange",
"sour orange" as "our orange", and "sweet orange" as "weet orange".
How do I make a link appear like normal black text unless it links to a page that exists, then display it normally? Like it is in conjugation boxes? I wanted to do it here. WurdSnatcher (talk) 14:44, 10 July 2015 (UTC)[reply]
Although that will make the CSS class name rather non-indicative... what are you trying to do anyway? — Keφr14:59, 10 July 2015 (UTC)[reply]
I wanted to make a glossary format like this, which has links to citations pages for all of the words. That way the list can be expanded and new citations added to the citations page, and when there are enough to make a page for it, the link will be there automatically. WurdSnatcher (talk) 15:04, 10 July 2015 (UTC)[reply]
Ruby print should be closer to kanji, although this is not a problem in mobile view. This is especially the case with larger fonts and I wish this could be fixed. I would think this would be an easy fix since the spacing between ruby print and kanji is perfect for both large and small font sizes when viewing the mobile version of pages. For a good example of this, please see Appendix:Gikun_Usage_in_Meiji_Version_of_Japanese_Bible and then compare it with the mobile version of the page. This does not appear to be a browser related issue.
馬太阿房 (talk) 21:52, 11 July 2015 (UTC)[reply]
Thanks for the screenshots. I see you are using Firefox with “gothic” font on your laptop and similar font on ipad. It does appear to be a font issues after all. I agree that the spacing between Kanji and ruby print doesn't look bad on your laptop. What is the name of the font your Firefox browser is using? I've tried different fonts with my Chrome browser and even the gothic ones have lots of space between Kanji and ruby. IE seems to have the same issue. 馬太阿房 (talk) 07:59, 15 July 2015 (UTC)[reply]
Keith, your Firefox screenshot convinced me to download Firefox for my personal computer. Happy to say that now the spacing between kanji and ruby print is perfect. Thanks again. By the way, it was definitely an IE and Chrome issue and not a font issue, because I see that with Firefox, even using the exact same fonts as I was using with IE and Chrome, the spacing is perfect.馬太阿房 (talk) 02:51, 16 July 2015 (UTC)[reply]
This template has been altered to read "plural of" instead of "plural form of". I have been using it for the plural form of Norwegian adjectives - there is no template for "plural form of" however. So what's the solution - "form of|plural form|-"? Admittedly a roundabout way of doing it, or can a new template be created? Donnanz (talk) 09:50, 12 July 2015 (UTC)[reply]
Something was accomplished in that thread a year ago. As for being contrary, well, I like accurate descriptions, and the alteration to the template amounts to oversimplification in my opinion. Besides that, I have kept my head below the parapet for some months. I can't be criticised for that, can I? Donnanz (talk) 22:06, 12 July 2015 (UTC)[reply]
All that has happened is that {{plural of}} was made to display the same thing as {{inflection of|...||p}}. I can't think of a reason why they should show different things when they mean the same thing. —CodeCat22:43, 12 July 2015 (UTC)[reply]
Even {{plural form of}} is redirected to {{plural of}}, so I can't win. That template is locked, so nobody can change it even if they want to. So "bad workarounds", even though I don't like them, are the only solution I'm afraid. Donnanz (talk) 13:24, 13 July 2015 (UTC)[reply]
@Donnanz: Please explain why you think "plural of" doesn't make sense for adjectives. You can't expect people to take your side if you don't even explain yourself. --WikiTiki8913:59, 13 July 2015 (UTC)[reply]
As I have already tried to explain above, that is what they are, plural forms of adjectives; {{plural of}} is adequate for simple noun plurals, as in English. This template cannot be used for Norwegian nouns, as there are indefinite and definite forms, so I use {{inflection of}} for those. I used to use that template for definite singular noun forms too, but found that {{definite of}} reading "definite singular of" works well for both those and the definite singular of adjectives (so please don't ever change the wording of that template!). Although thinking about it, definite singular forms and plural forms of adjectives could be merged into one template ("definite singular and plural form of") as they are invariably the same in both Norwegian and Danish, instead of putting them on two lines as at present. No problem with {{neuter singular of}} for the neuter form of adjectives. Adjectives which don't change form are easily catered for by simply adding "indeclinable". Donnanz (talk) 16:37, 13 July 2015 (UTC)[reply]
Our definition of "plural", and that of Chambers, do not say "only applies to nouns". To talk of the plural of an adj is fine. Equinox◑19:39, 13 July 2015 (UTC)[reply]
Yes, to talk of the "plural of" an adjective is fine. (And I fail to see how "plural of" could possibly be problematic without the synonymous but longer "plural form of" being equally problematic.) Merriam-Webster agrees that "plural" can refer to more than just nouns (it has usexes of "plural noun" and "plural verb"), as does Dictionary.com (which makes reference to plural pronouns besides plural nouns), and Oxford Dictionaries (which makes reference to plural nouns, pronouns, and verbs). At Ngrams, "plural of the adjective" was more common than "plural form of the adjective" until about 15 years ago, and it's still about half as common. - -sche(discuss)19:50, 13 July 2015 (UTC)[reply]
No, they show that you are "completely wrong" about "plural of an adjective" being wrong, because if it were wrong, the ratio could not have possibly come even close to 1/2. --WikiTiki8912:49, 14 July 2015 (UTC)[reply]
Hi. Is it better to include the combining characters such as "combining caron" (U+030C) and "combining dieresis" (U+0308) in the actual title of a Svan entry or should I put such characters only in the {{head}} template? Usage of combining characters are necessary because we do not have unicode Georgian letters with circumflex accents, diaereses or carons.
On one hand, putting combining characters in the title of the page causes stuff like this, but on the other — there is no such word as ფაქუ in Svan (i.e., without a circumflex accent on უ) and needless to say უ =/= უ̂. What should I do here? Sorry if this is an extremely nooby question, but I have to ask this. --Simboyd (talk) 18:02, 12 July 2015 (UTC)[reply]
There's nothing wrong with using combining characters in page titles if the precomposed characters don't exist in Unicode (yet). The only time to leave diacritics out of page titles but include them in the headword line is if such diacritics aren't normally found in printed texts but are encountered only (or primarily) in pedagogical texts like dictionaries, grammar books, readers for children and language students. If Svan texts always include these diacritics, then they should be part of the page title. —Aɴɢʀ (talk) 20:38, 12 July 2015 (UTC)[reply]
I completely agree and that is exactly what I tried to do for this word as well, but as you can see combining characters have glitches when applied on Georgian unicode characters. Should I just ignore this then? --Simboyd (talk) 20:58, 12 July 2015 (UTC)[reply]
From what I have seen, Svan uses უ, უ̄, უ̈, უ̄̈(u, ū, ü, ṻ). The problem is not the diacritics, but whether the font was designed to include Svan text. Georgian font designers do not make provisions for these diacritics, since Georgian does not use them, but a font designer can easily adjust the font to display the diacritics correctly over Georgian letters. Therefore, you just need fonts that are intended for Svan, such as TITUS Cyberbit Basic. —Stephen(Talk)23:24, 12 July 2015 (UTC)[reply]
We have the same problem with Armenian dialects. Until today I was stripping diacritics from the links and not including them in the page title, but now I think the diacritics should be included however ugly they look. The only problem is that searching for կյազար does not find կյա̈զա̈ր(kyäzär). Redirects are a solution, when there is no entry with an identical spelling. --Vahag (talk) 08:19, 13 July 2015 (UTC)[reply]
We have lots of nonmainspace pages that would benefit from styling: they can get prettier or even can load faster.
For example, here each line could be 18 characters less and thus load faster.
Also, just above our homey needed exactly this – page-specific css. But instead he ended up using his own template.
Inflection table templates would be easier to style and read. One prominent example is Template:la-decl-adj-table-m+f+n that has three dedicated templates Latincolour1, Latincolour2, Latincolour3.
Also, if we allow this change we would be one step closer to the separation of presentation and markup.
It would make it possible to copy other wikiproject's templates. Notably, moving Wikipedia's Navbox here was a hard-work and, eventually, resulted in an unmaintainable template.--Dixtosa (talk) 13:22, 14 July 2015 (UTC)[reply]
We would be going to be able to use pseudo-classes.
We would be able to reduce the size of MediaWiki:Common.css and leave only truly cross-language styles to it.
concrete example: 20 lines of CSS used by {{zh-hanzi-box}}. Wouldn't it be wiser to put the CSS in the template? Non Chinese entries would load faster
{{Navbox}} should be deleted; we have other conventions for navigation templates. Inflection tables should have inline styles replaced by CSS classes common across languages (harmonising their styles in the process). And if you do that, the whole need for this extension should disappear. I think you will have a hard time convincing the WMF to install this extension here anyway. — Keφr18:47, 18 July 2015 (UTC)[reply]
What conventions? I can image this here. But this was what I got when I copied it. Also, I had to go through a lot of trouble when I copied User_scripts from Wikipedia.
Inflections tables need not be harmonized. Even if they do this does not contradict with the installation of the extension.
What about pseudo-classes? I actually thought maybe {{character info/new}} could enlarge the character (class "character-sample") on :hover. That would make it possible to see every little stroke of a letter.
Yeah, thanks to you and Wikitiki now I stand no chance of being taken seriously on Phabricator.
Anyways, if there's an interest this could be implemented without WMF people. One little addition to Mediawiki:Common.js can make this work. OMG, I can't contain myself - the sexyness of my inflection tables is overwhelming --Dixtosa (talk) 14:06, 19 July 2015 (UTC)[reply]
My bot produced the following errors when trying to match up ("match-canonicalize") Ancient Greek and Latin, transferring macrons and breves from one to the other and then removing the manual transliteration if it's the same as the automatic one. (Note, these are all entries where the Latin translit has a macron over a, i or u.) Can one of the people working on Ancient Greek fix up these entries? Thanks.
Page 8 Amilcare: term.1: NOTE: Unable to match-canon Ἀμίλκας (Hamilkās): Unable to match Greek character Α at index 1, Latin character H at index 0: {{term|Ἀμίλκας|lang=grc|tr=Hamilkās}}
Page 22 Areopagite: term.1: NOTE: Unable to match-canon Ἀρεοπαγίtης (areiopagītēs): Unable to match Greek character ο at index 4, Latin character i at index 3: {{term|Ἀρεοπαγίtης|tr=areiopagītēs|lang=grc}}
Page 29 Dioscuri: term.1: NOTE: Unable to match-canon Διόσκουροι (Dióskūroi): Unable to match Greek character ο at index 6, Latin character u at index 6: {{term|Διόσκουροι||the youths of [[Zeus]]|tr=Dióskūroi|lang=grc}}
Page 60 Promm: m.2: NOTE: Unable to match-canon προῦμνον (prū́mnon): Unable to match Greek character ο at index 2, Latin character u at index 2: {{m|grc|προῦμνον|tr=prū́mnon}}
Page 87 areopagites: term.2: NOTE: Unable to match-canon ἀρειοπαγῑ́tης (areiopagītēs): Encountered non-Greek (?) character t at index 12: {{term|ἀρειοπαγίtης|ἀρειοπαγῑ́tης|tr=areiopagītēs|lang=grc}}
Page 94 beg the question: term.1: NOTE: Unable to match-canon τὸ ἐν ἀρχῇ αἰτεῖσθαι (to en archē aetīsthae): Unable to match Greek character ῃ at index 12, Latin character e at index 10: {{term|τὸ ἐν ἀρχῇ αἰτεῖσθαι|tr=to en archē aetīsthae||to assume from the beginning|lang=grc}}
Page 134 filatelie: term.1: NOTE: Unable to match-canon ἀτέλεια (atelīa): Unable to match Greek character ε at index 6, Latin character i at index 4: {{term|ἀτέλεια|lang=grc|tr=atelīa}}
Page 194 petitio principii: term.1: NOTE: Unable to match-canon τὸ ἐν ἀρχῇ αἰτεῖσθαι (to en archē aetīsthae): Unable to match Greek character ῃ at index 12, Latin character e at index 10: {{term|τὸ ἐν ἀρχῇ αἰτεῖσθαι|tr=to en archē aetīsthae||to assume from the beginning|lang=grc}}
Page 195 philately: term.1: NOTE: Unable to match-canon ἀτέλεια (atelīa): Unable to match Greek character ε at index 6, Latin character i at index 4: {{term|ἀτέλεια|lang=grc|tr=atelīa}}
Page 243 πῶυ: term.1: NOTE: Unable to match-canon पायु (pāyú): Encountered non-Greek (?) character प at index 0: {{term|sc=Deva|पायु|tr=pāyú||guard, protector|lang=grc}}
Page 310 ܡܛܪܐ: term.1: NOTE: Unable to match-canon μήρτα (mḗtrā): Unable to match Greek character ρ at index 3, Latin character t at index 4: {{term|μήρτα|tr=mḗtrā|lang=grc}}
Page 324 Ἀσία: grc-proper noun.page title: NOTE: Unable to match-canon Ἀσία (Asiā/Āsiā): Unable to match trailing Latin character / at index 5: {{grc-proper noun|Ἀσίας|f|first|Asiā/Āsiā}}
Page 411 μάτηρ: grc-noun.head: NOTE: Unable to match-canon μᾱ́τηρ (mātēr): Encountered non-Greek (?) character & at index 3: {{grc-noun|ματρός|f|third|mātēr|head=μᾱ́τηρ}}
Page 590 ἐκπίνω: grc-verb.page title: NOTE: Unable to match-canon ἐκπίνω (pī́nō): Unable to match Greek character ε at index 1, Latin character p at index 0: {{grc-verb|tr=pī́nō}}
Page 665 Κωκυτός: grc-noun.page title: NOTE: Unable to match-canon Κωκυτός (kōkūtos): Unable to match Greek character Κ at index 0, Latin character k at index 0: {{grc-noun|κωκυτοῦ|m|second|kōkūtos}}
Page 725 δράματα: head.head: NOTE: Unable to match-canon δρᾱ́μᾰτᾰ (''drāmata''): Unable to match Greek character δ at index 0, Latin character ' at index 0: {{head|grc|noun form|head=δρᾱ́μᾰτᾰ|tr=''drāmata''|g=n}}
Page 768 Ἀσιανός: grc-noun.page title: NOTE: Unable to match-canon Ἀσιανός (Asiānos/Āsiānos): Unable to match trailing Latin character / at index 8: {{grc-noun|Ἀσιανοῦ|m|second|Asiānos/Āsiānos}}
Page 809 Βρετανία: grc-proper noun.page title: NOTE: Unable to match-canon Βρετανία (Brettaniā): Unable to match Greek character α at index 4, Latin character t at index 4: {{grc-proper noun|Βρεττανίας|f|first|Brettaniā}}
Page 850 Μαικήνας: grc-proper noun.page title: NOTE: Unable to match-canon Μαικήνας (Malakās): Unable to match Greek character ι at index 2, Latin character l at index 2: {{grc-proper noun|Μαικήνα|m|first|Malakās}}
Page 853 Μεσσάλας: grc-proper noun.page title: NOTE: Unable to match-canon Μεσσάλας (Messalā): Unable to match trailing Greek character ς at index 8: {{grc-proper noun|Μεσσάλα|m|first|Messalā}}
Warnings about missing smooth-breathing signs. I've tried to remove all the ones that were bogus.
Page 11 Appendix:Proto-Germanic/anhulǭ: term.1: WARNING: Text αγκύλᾱ may be missing a smooth-breathing sign
Page 19 Appendix:Proto-Indo-European/stéh₂-: l.2: WARNING: Text έστᾱ may be missing a smooth-breathing sign
Page 78 Wiktionary:Requested entries (Ancient Greek): term.1: WARNING: Text Άρβανον may be missing a smooth-breathing sign
Page 78 Wiktionary:Requested entries (Ancient Greek): l.2: WARNING: Text Όσροηνῆ may be missing a smooth-breathing sign
Page 248 Ἠλί: lang.2: WARNING: Text Ηλι may be missing a smooth-breathing sign
Page 249 Ἡλί: lang.2: WARNING: Text Ηλι may be missing a smooth-breathing sign
Page 534 Τίρυνς: lang.2: WARNING: Text Ᾰ Ε Ῐ Ο Ῠ may be missing a smooth-breathing sign
Page 534 Τίρυνς: lang.2: WARNING: Text Ᾱ ΕΙ Ῑ ΟΥ Ῡ may be missing a smooth-breathing sign
Page 669 Λαέρτης: term.1: WARNING: Text ειρειν may be missing a smooth-breathing sign
Page 1188 ἐπιχαιρεκακία: lang.2: WARNING: Text [[w:Aristotle|Αριστοτέλης]], ''[[w:Nicomachean Ethics|Ηθικά Νικομάχεια]]'' may be missing a smooth-breathing sign
Page 1188 ἐπιχαιρεκακία: lang.2: WARNING: Text [[w:Aristotle|Αριστοτέλης]], ''[[w:Nicomachean Ethics|Ηθικά Νικομάχεια]]'' may be missing a smooth-breathing sign
Well, it currently flags every Greek word it processes, regardless of template; that's why I didn't automatically fix up the words. Benwing (talk) 04:17, 16 July 2015 (UTC)[reply]
There's nothing wrong with it looking inside {{lang}} too; the issue at Τίρυνς(Tíruns) is simply that the vowels are being used to refer to their sounds in any position in a word; they're not being used as words. —Aɴɢʀ (talk) 10:06, 16 July 2015 (UTC)[reply]
Greek editors, please check the 09:38 Jul 15 changes for User:WingerBot
Thanks! @ObsequiousNewt I looked at fixing up the genitive but concluded it's too much work to do automatically. I assume there are third-declension nouns where the vowel length actually changes between nom and gen (maybe σῦς?), and even in just the first and second declensions there are bunches of special cases because of the way the accent can move or change its nature between nom and gen, and the inflection templates need to be done as well, etc. What I'm going to do is make a page containing all the nouns fixed up, and maybe eventually someone can go through them manually. Benwing (talk) 04:22, 16 July 2015 (UTC)[reply]
Can someone please make the following change to Module:languages/data3/g? The entry should properly read
m["grc"] = {
canonicalName = "Ancient Greek",
type = "regular",
scripts = {"polytonic", "Cprt"},
family = "grk",
ancestors = {"grk-pro"},
translit_module = "grc-translit",
sort_key = { -- Keep this synchronized with el, cpg, pnt
from = {"[ᾳάᾴὰᾲᾶᾷἀᾀἄᾄἂᾂἆᾆἁᾁἅᾅἃᾃἇᾇᾱ]", "[έὲἐἔἒἑἕἓ]", "[ῃήῄὴῂῆῇἠᾐἤᾔἢᾒἦᾖἡᾑἥᾕἣᾓἧᾗ]", "[ίὶῖἰἴἲἶἱἵἳἷϊΐῒῗῑ]", "[όὸὀὄὂὁὅὃ]", "[ύὺῦὐὔὒὖὑὕὓὗϋΰῢῧῡ]", "[ῳώῴὼῲῶῷὠᾠὤᾤὢᾢὦᾦὡᾡὥᾥὣᾣὧᾧ]", "ῥ", "ς"},
to = {"α" , "ε" , "η" , "ι" , "ο" , "υ" , "ω" , "ρ", "σ"}},
entry_name = {
from = {"[ᾸᾹ]", "[ᾰᾱ]", "[ῘῙ]", "[ῐῑ]", "[ῨῩ]", "[ῠῡ]", "[" .. MACRON .. BREVE .. "]"},
to = {"Α", "α", "Ι", "ι", "Υ", "υ", ""}} ,
}
Basically, the entry-name conversion needs to have raw macrons and breves in it. The main reason is that there are cases like Ᾱ̆̓σῐ́ᾱ (which should link to Ἀσία but doesn't currently) which can have both macrons and breves on the same letter, indicating that the vowel can be long or short. Because of the NFC transformation, the macron over the alpha gets converted to a single-char Ᾱ, but the breve above it remains as a combining character. (A secondary reason is that sometimes people incorrectly write things like Ἀ̄̆σῐ́ᾱ with the macron and breve above the smooth-breathing mark instead of below it, where again the macrons and breves remain as distinct combining chars.)
Wait, hang on, why does the alpha in Ἀσία need a macron/breve? LSJ has it as being short (although long in Ἀσίς, for reasons that are beyond me.) And why does/should Modern Greek have polytonic characters and length marks? —ObsequiousNewt (εἴρηκα|πεποίηκα) 22:48, 19 July 2015 (UTC)[reply]
Well in the pronunciation section of Ἀσία is says "the first vowel is short in prose and long in verse". But my change is for macron/breve combinations in general, irrespective of what's done with this particular entry. As for Modern Greek, I'm not sure why it has the sort key for polytonic characters; I assume it may be to support katharevousa words written in polytonic characters, which Wikipedia says was done until 1981. I assume though that macrons and breves are never needed since Modern Greek doesn't have vowel length, so I've removed my suggested changes for that language. @Atitarev, CodeCat, I'm so meta even this acronym can one of you make the remaining changes? Thanks ... Benwing (talk) 09:48, 20 July 2015 (UTC)[reply]
I'm hoping somebody can fix Template:JAruby to remove the small half-space between kanji and okurigana. Would that be possible to do? Maybe a better option would be to allow the user to specify if a half-space is desired. For example, I think some people might like to use a half-space to separate words, but I can't think of any good reason to have a half-space between kanji and okurigana since both together form one word. For example, take 咽喉が乾く. Notice the half-space between 乾 and く as well as between が and 咽喉. The only thing that makes it not look so bad is the fact that the ruby on 乾 forces a little more space between it and が. However, notice how there is significantly more space between 喉 and が and 乾 and く than there is between が and 乾. If it wasn't for the space created between kanji and okurigana, I wouldn't have so much of a problem with the spacing automatically created, were it not for instances like 諸の草蔬 (an example from a quotation where ruby must be used since it is like that in the original text) where the extra space following the kanji looks even bigger due to more ruby kana above the kanji. It looks even worse when in the context of the complete quoted sentence where spacing appears to be erratic: 神言たまひけるは視よ我全地の面にある實蓏のなる諸の草蔬と核ある木果の結る諸の樹とを汝等に與ふこれは汝らの糧となるべし. I also have found that it makes no difference to the spacing whether you put the okurigana into the template or enter it outside of the template. 馬太阿房 (talk) 02:30, 18 July 2015 (UTC)[reply]
"gender" is often used in WT for noun classes, number, etc. So perhaps "gender" is a misnomer and something like "noun property" would be better, but this is the way it is and I don't think it's so horrible. Arabic templates have "genders" like "m-p", for example. Benwing (talk) 07:52, 19 July 2015 (UTC)[reply]
It's not just in Wiktionary — in linguistics, animacy and inanimacy are classes of gender (see Grammatical gender); they're the only classes some languages have. (Proto-Indo-European, for example, is thought to have only had 'animate' and 'inanimate' classes until 'animate' split to 'masculine' and 'feminine' and left 'inanimate' as 'neuter'.) Other languages, such as Russian, have 'animate' and 'inanimate' classes as well as, overlapping them, 'masculine' and 'feminine' classes. Of course, linguists (and non-linguists) also at other times refer to just the second of those (the division of words into 'masculine'/'feminine'/'neuter'/'common') as "gender" — polysemy strikes again. One could make a case that it would be better to have separate gender and animacy parameters, but it's not incorrect to combine them. If {{cs-noun}} were expanded to accept the plural as a parameter (is that a goal?), it'd arguably easier to combine them: {{cs-noun|m-an|whatever-the-plural-is}} would be easier to type than {{cs-noun|m|whatever-the-plural-is|an=an}} or, with the need to remember to insert an empty parameter or filler ? when the animacy is unknown to the person adding the entry, {{cs-noun|m|whatever-the-plural-is}} (which would be parsed, as in {{ru-noun}}, as indicating unknown animacy) would be easier than {{cs-noun|m||whatever-the-plural-is}}. But as it is, {{cs-noun}} is so basic that the biggest argument I see in favour of combining them is simply that it's good for the same information to be input in the same way across similar languages, and m-an etc is how other Slavic languages, like Russian and Slovene and Ukrainian, input such information. - -sche(discuss)16:51, 19 July 2015 (UTC)[reply]
It's also how language-agnostic templates like {{l}} and {{head}} do it, because it's all handled by the same Module:gender and number. Having Czech templates work differently would just be confusing. If it should be changed, it should be changed globally. —CodeCat17:00, 19 July 2015 (UTC)[reply]
@-sche Re: "animacy and inanimacy are classes of gender": Please point me to a specific sentence in the Wikipedia article (W:Grammatical gender) making that claim. I do not find any such sentence there. Ideally, please present me with a source other than Wikipedia making that claim: if the Wikipedia claim is sourced, it should be easy to point to that source. As far as I know, animacy and gender are two distinct grammatical properties, not one being a subproperty of the other. --Dan Polansky (talk) 17:12, 19 July 2015 (UTC)[reply]
Here are a large number of articles at Google Scholar that discuss animate/inanimate as a form of gender. Rand Valentine, a professor of linguistics at the University of Wisconsin, has a website for the grammar of Ojibwe, where animate and inanimate are described as genders. As for the Wikipedia article on Grammatical gender, it says, "Common gender divisions include masculine and feminine; masculine, feminine and neuter; or animate and inanimate". It also says, "Some authors use the term 'grammatical gender' as a synonym of 'noun class'", but some authors do prefer to use the term "noun class" rather than "grammatical gender" for categories unrelated to sex. —Aɴɢʀ (talk) 17:55, 19 July 2015 (UTC)[reply]
Thank you for that. Some of the hits in your search indeed use such phrases as "animate and inanimate gender", some not so. The search google books:gender and animacy finds many occurrences that suggest agreement with my understanding of gender and animacy as being two distinct features; e.g. "Like gender, animacy is lexically encoded and thus inherent in the noun stem", "Person, Gender, and Animacy", "Consider the basic, inherently lexical qualities of animacy and gender", "including gender, number and animacy", "The specific articles distinguish gender, animacy and number, but in a curiously skewed way.", "There are no gender or animacy distinctions in the third person", and "in addition to agreement properties derived from pronouns, such as person, number, gender, animacy, definiteness and so on.". --Dan Polansky (talk) 19:04, 19 July 2015 (UTC)[reply]
From information design standpoint, to label the m-f-n distinstion and the an-in distinction using one term "gender" is most unfortunate, since these are two attributes that combine. Obviously, there is not single attribute with the domain {m, f, n, an, in}. There is no question that we are dealing with two attributes here. To encode two attributes using one template parameter seems unfortunate. --Dan Polansky (talk) 19:11, 19 July 2015 (UTC)[reply]
@CodeCat: That is not what I recognize as a substantive argument. Am I correct in my impression from the editing history of {{ru-noun}} and Template:ru-noun/documentation that the present use of combined values like m-an or m-in is your making? That is, is it correct that is was your design to create the combinations m-an, m-in, f-an, f-in, m-an, m-in, f, m-an-p, m-in-p, f-an-p, f-in-p, n-p? --Dan Polansky (talk) 20:15, 19 July 2015 (UTC)[reply]
Yes. Before that, we had no way of indicating animacy at all. And plural was indicated as a separate gender, so for example g=m|g2=p for masculine plural. There was no way to say "masculine plural and/or feminine plural". Surely you remember this too. —CodeCat20:18, 19 July 2015 (UTC)[reply]
Ok, great. Now can you please fill in the X in "These combinations are better design than a separate attribute for animacy because X"? --Dan Polansky (talk) 20:36, 19 July 2015 (UTC)[reply]
Because there's no practical reason to separate them, the current setup works well for editors and nobody has expressed a desire to change it. Having separate parameters for gender, number, animacy, noun class etc would just make a mess nobody is asking for. —CodeCat21:04, 19 July 2015 (UTC)[reply]
So there is and was no design reason. Above, there is just a list of things free from substance, like "design is good because nobody has expressed a desire to change it". Impressive. --Dan Polansky (talk) 21:09, 19 July 2015 (UTC)[reply]
So what you're really saying that if everyone is happy with it and thinks your proposal is just a solution looking for a problem, then they're just wrong? Maybe you should actually poll people about this. —CodeCat21:21, 19 July 2015 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
My personal opinion is that there's nothing wrong with including gender, noun class, animacy, number, etc. overloaded in the "gender" slot, given that Module:gender and number already supports it, that most languages (e.g. Arabic, Russian, various other Slavic languages, etc.) do it this way, and that it's easier to have one parameter rather than multiple, esp. as we need multiple gender parameters to support words that can have multiple genders and/or animacies. I also think overloading gender and number (e.g. "m-p") in the gender slot has been around awhile and it's not CodeCat's doing (although I'm not sure about this), and given that we do this, it seems natural to include animacy as well in the mix. I'd rather not have some languages like Czech have the parameters split while other languages (esp. other Slavic languages) have them combined into the "gender" field. Dan, I think if you really object you should open a discussion of splitting gender, number and animacy into different fields on a general basis; whatever we end up doing it should ideally be consistent across languages. Benwing (talk) 09:57, 20 July 2015 (UTC)[reply]
What's my doing is introducing "m-p" as a single gender string. Before it, when genders were still done with templates, there were separate templates for masculine and plural, so to combine them you had to specify them with two separate gender parameters. Like {{head|...|...|g=m|g2=p}}. The gender templates themselves had special code to avoid putting a comma between them. There were no templates for animacy at all, so languages with animacy distinctions were just out of luck. —CodeCat18:10, 20 July 2015 (UTC)[reply]
Is there a way to display form variants separated with a slash, such as variant1/variant2 in a single inflection table generated by Lua? Currently, I have to add two inflection tables to show them. Sometimes it is only a single variant in the accusative case, other times all plural forms are variants. See kapható. --Panda10 (talk) 15:54, 19 July 2015 (UTC)[reply]
@CodeCat Would it make sense to include this functionality in module hu-nominals? I'm not sure how flexible the table structure is to include double forms either next to each other or underneath each other. It might not look as nice as now. I noticed that for long words the table size stays the same on opening and a horizontal scroll bar appears on the bottom to allow viewing the plural column. --Panda10 (talk) 17:24, 19 July 2015 (UTC)[reply]
The module is already "ready" to handle multiple forms. On line 462 multiple forms are joined together with <br/>, a line break. So all that would need to be done is adding additional forms to the list of forms for a particular form (that sentence is confusing, but how else would I say it?). —CodeCat17:29, 19 July 2015 (UTC)[reply]
That would be the next step. At least the underlying code in the module supports multiple forms, so that's a start. I would need to know which parameters are needed though. —CodeCat22:04, 19 July 2015 (UTC)[reply]
I think there is no need to edit pages in any namespace other than the main namespace when there is no difference in the output (one may say there aren't many of those so lets get rid of them once and for all, but we will deal with many similar cases in future, we shouldn't constantly seek to fix irrelevant cases). Regarding the categories, we can restrict the categorization to the main namespace only. Also we can keep these categories as they are and create new categories for terms in the main namespace. We can easily detect the namespace in modules, and add the corresponding category. --Z16:43, 22 July 2015 (UTC)[reply]
A user script to easily manage translations to be checked
I changed the list as to display the "oldest" and "newest" entries in the order they were edited (ordermethod=lastedit according to mw:Extension:DynamicPageList (Wikimedia)); which I believe is better. This way, the "oldest" list contains entries more likely to be in need of being updated in some way. A list of "oldest" in the order they were added to the category would be almost always eternally stationary by definition and thus it wouldn't remain very useful after the first time the list is seen. I edited this parameter a few minutes ago, and apparently the oldest/newest are being updated by the system since the entries look random and automatically changing quickly at the moment. I'm going to see if it stabilizes later. --Daniel Carrero (talk) 15:03, 22 July 2015 (UTC)[reply]
I think for "newest", it would be more useful to have the newest additions to the category than the most recently edited. --WikiTiki8915:38, 22 July 2015 (UTC)[reply]
It should be noted, that lastedit really sorts by the last time the page was touched. In some cases this is not equivalent to the last edit (for example, this includes permission changes, creation or deletion of linked pages, and alteration of contained templates).
lastedit is not what you think. In fact, it is quite useless. But, I ve found some interesting attributes like
offset which enables us to do some paging, but it will be impossible to implement this without js though.
created which is way more attractive than caegoryadd from a statistical standpoint. With categoryadd, all the lemmas' categories start from 2012 (this is when lemma categories were invented). --Dixtosa (talk) 20:22, 22 July 2015 (UTC)[reply]
I am requesting that the functionality of gloss= and g= parameters be added to this module, just like in {{l}} and {{m}}. --Vahag (talk) 16:20, 22 July 2015 (UTC)[reply]
{{alter}} eats unstandardized dialect names and spits out standardized ones, linked to Wikipedia. Just that. If that can be done in a separate template, I will be happy to use it together with regular {{l}}. --Vahag (talk) 17:18, 22 July 2015 (UTC)[reply]
They do it with an awful CSS override. Why do that anyway? It destroys the association between superscripts and items in the list. Not everyone can rely on hyperlinks being there. —Keφr11:15, 23 July 2015 (UTC)[reply]
Ok. Is there a way to make the reference list in բալախ(balax) less ugly? Now the list is a mix of numbered and non-numbered items. We should probably allow a ===Notes=== section in addition to ===References===, and gather the numbered references there. This is what Wikipedia does. --Vahag (talk) 12:03, 23 July 2015 (UTC)[reply]
That is not what Wikipedia's notes sections are for: they're for actual notes. Numbered citations still go in an area of the Reference section. Similarly, the way to make the reference list less ugly is to (a) list the numbered references first and (b) gradually eliminate the non-numbered items. They should point to the information they're being used to cite. — LlywelynII14:16, 18 August 2015 (UTC)[reply]
Links in changelog summaries aren't having diacritics removed
Something I noticed, e.g. in the recent WingerBot changelog summary for 99 percent -- links to foreign words in the summaries don't have diacritics removed, like they normally do. Presumably this can't be fixed without changes in the MediaWiki software? Benwing (talk) 22:47, 23 July 2015 (UTC)[reply]
I don't think so. You could, however, hide the edit summaries, but that is usually done for vandalism and the like. --WikiTiki8913:51, 24 July 2015 (UTC)[reply]
Yeah, and IIRC we do know how to force a two-line display, because we did it for 〳〵 until we just redirected that entry. So, actually, the answer to Pandeist's question is "yes". - -sche(discuss)15:01, 24 July 2015 (UTC)[reply]
You're really asking for the impossible. The check that looks if a page exists or not, #ifexist in Template code or the equivalent in Lua, already creates a link by itself. So it's not possible to simultaneously check for existence while not creating a link. —CodeCat20:25, 24 July 2015 (UTC)[reply]
There's always the option of putting the information in the data modules so such expensive checks don't have to be made every time a page is loaded. Chuck Entz (talk) 21:23, 24 July 2015 (UTC)[reply]
Ok, I've made changes to Module:IPA so that it only includes links to pronunciation pages for languages from a predefined list. That list is defined in the data submodule, Module:IPA/data. It's now up to other editors to fill that list as pages are created. —CodeCat21:32, 24 July 2015 (UTC)[reply]
This text line creates illegal wiki code in hongre, hanche and others:
{{IPA|lang=fr|{{fr-asph}}/ɔ̃ɡʁ/}}
It shows roughly as this:
IPA(key): (aspirated h)/ɔ̃ɡʁ/[[Category:IPA pronunciations with invalid IPA characters|<>A:G#</>Cg:F//]]
The IPA template or module checks if the template argument contains illegal IPA delimiters (other than // or []) and does not expect other templates. No idea if it should.
--MaEr (talk) 15:58, 25 July 2015 (UTC)[reply]
Hey all. Annoyingly, entries using Template:es-adv by default class adverbs as being comparable. I'd prefer to have them by default not showing comparability, because at the moment there are plenty of errors. Can someone either unprotect the Template so I can fiddle with it? Or better still, to remove this default themselves? --A230rjfowe (talk) 20:24, 26 July 2015 (UTC)[reply]
I editedUser:Conrad.Irwin/editor.js so that it would not add the unnecessary sc=Hebr to Hebrew and Yiddish translations. However, this had the side-effect of disabling the transliteration field by default. Is there any way to make the transliteration field enabled by default but not add the unnecessary script code? --WikiTiki8914:48, 27 July 2015 (UTC)[reply]
The script determined if transliteration was necessary by first guessing its script. If it was guessable and different from Latn it displayed the transliteration box.
No I was wrong, we need a new attribute in metadata for specifying if the transliteration can be automated for each language, or revert all script-related edits and let peace be upon them... .--Dixtosa (talk) 19:15, 27 July 2015 (UTC)[reply]
Special:Contributions/Glory of Space has highlighted that we should probably block users from moving pages to titles with multiple consecutive punctuation characters. If possible, a filter preventing un-auto-confirmed users from making more than e.g. 6 moves in an hour would also seem useful, as would a filter preventing un-auto-confirmed users from moving pages to titles longer than e.g. 30 characters. - -sche(discuss)20:21, 28 July 2015 (UTC)[reply]
Per a request, I've copied en.wp's edit filter 68 "Pagemove throttle for new users" to Wiktionary's filter 44. It is currently set to tag only as I have not copied over the (warning message) and want to leave the design of that and filter settings choices to active admins here. Note that to limit users to 6 moves, the abuse filter limit needs to be 12 actions as moving a page and it's associated talk page count as 2 move actions. Thryduulf (talk) 22:59, 2 August 2015 (UTC)[reply]
Can we please reject the new changes to the Watchlist UI?
Indeed. I have to scroll through a screen and a third of other mess before I reach my actual watchlist. The buttons should be made normal-size, step 1. Step 2, perhaps the entire section could be trimmed and/or collapsed. Step 3, if we could remove the line "Pages that have been changed since you last visited them are shown in bold." for people like me who have suppressed the bolding, that'd be nice, too. I would suggest shortening MediaWiki:Rcnote and MediaWiki:Rclinks so that they could fit onto one line, if there were a way to put them on the same line rather than on separate lines one after the other. - -sche(discuss)02:51, 30 July 2015 (UTC)[reply]
All the top content has some value when one is learning the system, but it is just screen-space-devouring meaninglessness thereafter. Perhaps it could all be collapsed by an active selection in preferences. DCDuringTALK03:53, 30 July 2015 (UTC)[reply]
If the only script specified in Module:languages is Latn can the transliteration field be disabled? People apparently like to use it for all kinds of crap that isn't transliteration- see User:DTLHS/cleanup/bad_translit (partial- generating a full report now). Further, could the translation templates generate a cleanup cat in these cases? DTLHS (talk) 23:48, 30 July 2015 (UTC)[reply]
I doubt that most of those were entered through the editor. After all, the transliteration field clearly says what it is. The tr= parameter, on the other hand, has a very ambiguous and misleading name. I pointed this out before, and proposed renaming it to xlit=. —CodeCat23:54, 30 July 2015 (UTC)[reply]
Fine. I still think adding a category would be a good idea, since it would also let us find languages that need more scripts specified. DTLHS (talk) 00:31, 31 July 2015 (UTC)[reply]
The first case is fixable with an appropriately placed L2R code (U+200E) directly before the left paren. The second case has the translit listed next to the wrong word and is also fixable with an L2R code:
It's in the right place, but what I'd like is an LRM at the end of the output if there's no transliteration (i.e. directly after the linked word); that will fix the second example above. Benwing (talk) 03:54, 1 August 2015 (UTC)[reply]
Done. Keep up the good work. --Anatoli T. (обсудить/вклад) 11:17, 8 July 2015 (UTC)
