Wiktionary:Grease pit/2014/November

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← October 2014 · November 2014 · December 2014 → · (current)

---

American Sign Language Letter Images Showing at Full Size

As an IP noted at Talk:C, the "100px" parameter in Image wikilinks wrapped in {{head|head=}} seems to be ignored, so the image of the finger-spelled "C" fills the page. Chuck Entz (talk) 17:13, 1 November 2014 (UTC)

Fixed; the section-linking code was parsing the link wrongly and corrupting the size specifier. I fixed the parsing code; though we should probably suppress section linking altogether for File-namespace links (and probably some others). — Keφr 20:08, 1 November 2014 (UTC)

Cyrillic Uyghur

Can someone please suppress Cyrillic in Module:ug-translit? Or write another function for it? See Khorgas. قورعاس and Қорғас (Qorghas). --Anatoli T. ^{(обсудить}/^вклад) 00:08, 10 November 2014 (UTC)

I changed the transliteration module so that it returns nothing if the script is not Arabic. It needs an extra function for Cyrillic still, but someone else will need to do that. —CodeCat 00:29, 10 November 2014 (UTC)

Thanks. If someone adds a framework for it (the logic), I can fill the table with transliteration symbols. w:Uyghur_Cyrillic_alphabet. --Anatoli T. ^{(обсудить}/^вклад) 00:38, 10 November 2014 (UTC)

Is the transliteration just by each letter individually? As in, there are no pairs of letters (or similar) that must be transliterated separately? —CodeCat 00:48, 10 November 2014 (UTC)

I've set it up now. —CodeCat 00:52, 10 November 2014 (UTC)

Thanks. They are very straightforward, one-to-one and there are most likely no rules to change transliterations depending on the position of letters, like Russian "е" (e, je, etc.). I'll have a go at it later, if no-one does, just need to map Uyghur Arabic transliterations (which is fully fully phonetic and doesn't use any diacritics unlike Arabic) to Cyrillic, so we have some consistency, e.g. "چ" = "ch" = "ч". --Anatoli T. ^{(обсудить}/^вклад) 00:58, 10 November 2014 (UTC)

@CodeCat. I've added the Cyrillic letters, not sure why there is no Arabic equivalent of Ә. I've asked User:Hahahaha哈, a Uyghur speaker (not sure if they know the mapping between Cyrillic and Arabic). --Anatoli T. ^{(обсудить}/^вклад) 21:46, 10 November 2014 (UTC)

Calling @ZxxZxxZ as well, please check if you can. --Anatoli T. ^{(обсудить}/^вклад) 21:49, 10 November 2014 (UTC)

Ә = ه —Stephen ^(Talk) 03:39, 11 November 2014 (UTC)

Thanks, Stephen, I have added ه. --Anatoli T. ^{(обсудить}/^вклад) 04:57, 11 November 2014 (UTC)

Fixed a mismatch. Cyrillic "е" is apparently Roman "ë" (="ې"), e.g. يېزىق (yëziq) and йезиқ (yëziq) "script", "alphabet" (from Russian "язык"?) and Cyrillic "ə" is Roman "e" (="ه"), can't find an example word with "ه". --Anatoli T. ^{(обсудить}/^вклад) 05:10, 11 November 2014 (UTC)

Found a Cyrillic letter, which was missing in Wikipedia. Added "э" as "é". I'm not sure what it should be. --Anatoli T. ^{(обсудить}/^вклад) 05:22, 11 November 2014 (UTC)

Sorry for the late reply. I can't read Cyrillic script. I checked the Arabic part, and found this ["ع"] = "ğ", They don't have this letter in Uyghur Arabic form, the letter "ğ" is the letter "gh" in ULY. The letter "é" is no longer in use, it is "ë" now. --Hahahaha哈 (talk) 04:57, 7 December 2014 (UTC)

Searching for green ACCEL links

Is there any way to search for, or generate a list of, entries with green ACCEL links in them? --Type56op9 (talk) 15:03, 11 November 2014 (UTC)

Scan Wiktionary for redlinks wrapped in spans with appropriate CSS classes (plural-of or whatever). Using a dump may make it easier. — Keφr 17:57, 11 November 2014 (UTC)

I have no idea how to use dumps. Perhaps a help page Help:Taking a Wiktionary dump and being creative with it is needed. --Type56op9 (talk) 09:17, 12 November 2014 (UTC)

"pagelinks" is a (compressed) text file containing a series of SQL statements which can be imported verbatim into a MySQL database (and maybe others, after some modifications). Then you can use the "all-titles" dump to remove all bluelinks (and links to non-content namespaces) from your database. Then you do select unique pl_from from pagelinks;, giving you a list of pageids of pages containing redlinks. If you expand templates in each (with e.g. mw:API:Revisions) and look for <span class="form-of, it means you got something which WT:ACCEL can turn into a greenlink. Probably.

Hmm. Quite a lot of work, it seems. If I were to do it, I would probably (ab)use my Admin Powers™ by editing Module:headword to add a tracking template for each accelerated link, and then just pull the list from mw:API:Embeddedin… — Keφr 20:35, 12 November 2014 (UTC)

But then you'd have to wait a long time for the changes to show up. A dump is a much better solution. --WikiTiki89 22:06, 12 November 2014 (UTC)

With 3M jobs in the queue right now, you might have a point. — Keφr 15:31, 13 November 2014 (UTC)

Ref no references warning banner

It has a mistakes in it, it says to used <references> which is incorrect, it's <references/>. I suppose it's somewhere in the MediaWiki namespace. Renard Migrant (talk) 16:35, 11 November 2014 (UTC)

MediaWiki:Abusefilter-warning-ref-no-references. I have edited it like you suggested; although I do not consider this an error myself, I agree it might be misleading for newbies (which are the primary target of this message in the first place). — Keφr 17:54, 11 November 2014 (UTC)

I get this message all the time, and I'm not a newbie. I get it because I add <ref> tags in one section (usually the Etymology section), save that section, and then go to the bottom of the language to add a new ===References=== section with the <references/> tag in it. —Aɴɢʀ (talk) 18:51, 11 November 2014 (UTC)

Well, okay. But you know what to do already: this message merely reminds you to do it, so its actual content is of lesser importance to you. — Keφr 19:08, 11 November 2014 (UTC)

I think it's hard to remember where the forward slash goes, I'm always happy to be reminded, better than than get it wrong! Renard Migrant (talk) 00:06, 14 November 2014 (UTC)

@Renard Migrant To explain the slash placement: "<references>" is an opening tag, "</references>" is a closing tag. Every opening tag must have a corresponding closing tag. However, when no text needs to be placed between the opening and closing tags, it is redundant to write the tag twice. Thus, "<references/>" is a shorthand for "<references></references>". --WikiTiki89 05:22, 14 November 2014 (UTC)

Removing diacritics for all regional versions of Arabic, not just Standard Arabic

A number of regional Arabic dialects (aka languages) have entries for words in those languages. E.g. there are quite a number of words in Category:Egyptian Arabic nouns and Category:Libyan Arabic nouns, and they're written in Arabic script. Personally I think the lemmas should be written in transcription since the Arabic script can never be phonologically very accurate for the dialects, and indeed most pedagogical literature uses transcription more or less exclusively. But since we have stuff written in Arabic, we should at least provide diacritic-removal services like we do for Standard Arabic. As it is, you can't e.g. put diacritics in an Egyptian Arabic link without manually specifying the non-diacritic version as another param. I'm proposing that the automatic diacritic removal we do for Standard Arabic should be done for all the Arabic varieties. The full list is here:

[1]

This would simply involve copying the entry_name = entry in the language table for code ar to all the codes given in the list above, possibly with a check that "Arab" is actually one of the allowed scripts. Could someone do this? Thanks.

Benwing (talk) 07:29, 15 November 2014 (UTC)

The change is straightforward but a few data modules needs to change. I have just updated Module:languages/data3/a, which happens to have a bunch of Arabic dialects, including Egyptian, Moroccan, for which we have a lot of entries - diff and diff. I only changed those with sc=Arab but this may need to change. I also changed User:Conrad.Irwin/editor.js for translations - diff. Pls check if there are other data modules, like Module:languages/data3/a with Arabic dialects. --Anatoli T. ^{(обсудить}/^вклад) 11:29, 15 November 2014 (UTC)

There is also Shihhi Arabic (ssh) and Chadian Arabic (shu) in Module:languages/data3/s, and Hassaniyya (mey) in Module:languages/data3/m, all with sc=Arab. Juba Arabic in Module:languages/data3/p (a pidgin or creole) has sc=Arab but I think this is a mistake and should be changed to Latin -- Ethnologue says script is Latin, and the one entry we have in the dictionary is in Latin script.

According to Ethnologue:

• Tajiki Arabic (abh), Baharna Arabic (abv), Saidi Arabic (aec), Eastern Egyptian Bedawi Arabic (avl) are listed in Ethnologue as using Arabic script but we have them as sc=None, which should be changed to sc=Arab and the diacritic-removal stuff put in.
• Ta'izzi-Adeni Arabic (acq), Hijazi Arabic (acw), Najdi Arabic (ars), Sanaani Arabic (ayn) have no writing system listed in Ethnologue and we have sc=None but all are vigorously-spoken languages that serve as regional or national standards, so I suspect they do use Arabic script and I think we should change them to sc=Arab and put in the diacritic-removal stuff.
• Hadrami Arabic (ayh) has no writing system listed in Ethnologue and we have sc=None. It is vigorously-spoken by a smaller community (300,000 people) than the other two dialects in Yemen. Based on the example of things like Tajiki Arabic and Eastern Egyptian Bedawi Arabic I'd tentatively set it to sc=Arab and put in the diacritic-removal stuff.
• Uzbeki Arabic (auz) has no writing system listed in Ethnologue and is given as moribund, so I think it should remain as sc=None.
• For Cypriot Arabic (acy) we have sc=None and Ethnologue has "Arabic script [Arab], no longer in use. Greek script [Grek], no longer in use. Latin script [Latn], revitalization efforts in one town". I would set sc=Latn here.

Benwing (talk) 15:33, 15 November 2014 (UTC)

@Benwing You can follow the changes I made to other dialects and update the appropriate scripts and handling of diacritics for them. The translation adding tool should also follow. If you don't have access to the modules, pls make a list of required changes. Provided there are no objections, I'll make the changes. --Anatoli T. ^{(обсудить}/^вклад) 22:22, 18 November 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Atitarev I can't change the modules myself.

• Please include diacritic-removal stuff for Shihhi Arabic (ssh) and Chadian Arabic (shu) in Module:languages/data3/s, and Hassaniyya (mey) in Module:languages/data3/m.
• Please change Juba Arabic in Module:languages/data3/p to have sc=Latn.
• For Tajiki Arabic (abh), Baharna Arabic (abv), Saidi Arabic (aec), Eastern Egyptian Bedawi Arabic (avl), Ta'izzi-Adeni Arabic (acq), Hijazi Arabic (acw), Najdi Arabic (ars), Sanaani Arabic (ayn), Hadrami Arabic (ayh) please change to have sc=Arab and add the diacritic-removal stuff in. (This is all the remaining Arabic dialects in Module:languages/data3/a other than Uzbeki Arabic and Cypriot Arabic.)
• For Cypriot Arabic (acy) please change to have sc=Latn.

Thanks.

Benwing (talk) 23:54, 18 November 2014 (UTC)

OK, if no-one else does, I'll do it in the near future (there's no urgency as there are not much content in these languages/dialects). --Anatoli T. ^{(обсудить}/^вклад) 01:43, 19 November 2014 (UTC)

Orangelinks gadget not working for me

At spur#Etymology {{m|ang|spora}} (spora) and {{term|spora|lang=ang}} (spora) showed blue, not orange, though there is no Old English section at [[spora]]. Here they look tan in color, which must be the current 'visited-link' color. DCDuring TALK 15:54, 19 November 2014 (UTC)

I see orange links above. —CodeCat 15:56, 19 November 2014 (UTC)

@CodeCat So you must not have visited [[spora]]. What about spora at spur#Etymology? DCDuring TALK 16:10, 19 November 2014 (UTC)

I don't see an orange link there, no. —CodeCat 16:12, 19 November 2014 (UTC)

I think this is caused by a JavaScript error at [[spur]]. I don't know enough to investigate it. --WikiTiki89 16:15, 19 November 2014 (UTC)

OK. The page seems to have mostly garden-variety templates and other formatting, so it might recur elsewhere. DCDuring TALK 16:27, 19 November 2014 (UTC)

Ugh. I broke it. I have restored it to a working version. Ironically, I was trying to debug a defect which seemingly only I keep hitting… (I have some idea why, but I am yet to discover the specifics.) — Keφr 18:23, 19 November 2014 (UTC)

Thanks, it works for me now. Hope you can solve your problem. DCDuring TALK 19:11, 19 November 2014 (UTC)

Duplicate TLFi

Kennybot (talk • contribs) has 'helpfully' added {{R:TLFi}} to all French lemmas. The problem: this include French lemmas that already had it! For example this edit to pionnier. Could anyone rectify this?

The second problem, where the TLFi link links to a nonexistent page is harder to fix and that's definitely beyond me. The first one I could fix just not yet. Renard Migrant (talk) 15:09, 20 November 2014 (UTC)

Can I just check that no-one's done this? I was going to do it tomorrow. Renard Migrant (talk) 18:07, 24 November 2014 (UTC)

Text editors

I've used Textpad as an editor for some 20 years, it does almost everything I need: sorting, multiple files (openable in one operation as a "workspace"), macros, find/replace (which handles /n, /t etc), and syntax highlighting, (there may be others). BUT it won't handle more than one "character set" - ie if I'm using Greek characters (η, ή etc) it handles Roman letters in the same file - but not if they're accented (é, etc).

I've been looking for another editor, can anyone recommend one (simple off the shelf (free!), not requiring "plugins" ? I've been trying Notepad++, but syntax highlighting for wiki files is difficult to sort out (Textpad makes it easy) Np++ uses XML files - with syntax and terminology I don't understand (I do html but don't wish to to master XML). Thanks — Saltmarsh^{απάντηση} 16:00, 20 November 2014 (UTC)

The problem is not so much the text editor, but the font and encoding. You need to make sure the encoding is some form of Unicode. Also, most simple text editors only use one font at a time and unless it supports everything you need, you will have display issues. --WikiTiki89 17:02, 20 November 2014 (UTC)

Where I work, we're on Windows, and we routinely apply the Arial Unicode MS font to text to ensure that 1) all characters are displayed properly, and 2) that we don't have unnecessary internal markup where fonts change because the language changed. FWIW. ‑‑ Eiríkr Útlendi │ Tala við mig 18:32, 20 November 2014 (UTC)

Thanks, but I'm afraid its not that simple, displaying in Athena Unicode doesn't make the problem go away. I think it's to do with the number of bits used to store each character. Textpad lets you choose which font you want displayed, but you have to opt for a script (Western|Greek|Baltic|central European|...) Western-script will give abcdef and áä éë (but not Greek alphabet) Greek-script will give abcdef and αβγδεέ (but not accented western chars) — Saltmarsh^{απάντηση} 19:40, 20 November 2014 (UTC)

• I'm not familiar with Textpad, but what you describe as "script" sounds an awful lot like the character encoding. Specific character encodings like Western, Greek, Baltic, or Central European only display those specific characters. Try using Unicode instead. Unicode has been developed precisely to overcome the problem you describe -- it's a single character encoding that defines characters for (ideally) all languages. ‑‑ Eiríkr Útlendi │ Tala við mig 20:21, 20 November 2014 (UTC)
  • Technically Unicode is a character set, not an encoding. The encoding is UTF-8 (or UTF-16, UTF-32, UCS-2 but those are less popular as file formats). —CodeCat 20:59, 20 November 2014 (UTC)

    UTF-16 is still more common on Windows. No one ever uses UTF-32 except as an intermediate encoding. --WikiTiki89 15:32, 21 November 2014 (UTC)

    • @CodeCat, thank you, yes, my sentence got things confused.
    • @Wikitiki89, I thought UTF-8 was more common? Then again, I work mostly with the combination of English and Japanese, so that might have something to do with it. Also, at work, we have some older tools that can only properly handle UTF-16LE (little-endian). ‑‑ Eiríkr Útlendi │ Tala við mig 19:17, 21 November 2014 (UTC)

      UTF-8 is more common in general, especially on the web, but specifically not on Windows, which uses UTF-16 as the native and default encoding for many things such as the command prompt. I don't think the combination of English and Japanese has anything to do with it, since that would work perfectly fine in encoding.

I sometimes use SC UniPad [2]. Not as great as TextPad or Np++ but it supports a lot of scripts and you can enter them with a big variety of keyboards and character maps or make your own. It's very useful if you want to break up complex characters, separate diacritics. It can decompose Korean hangeul into individual jamo. Great for deciphering scripts you don't know too - it gives you the names of characters and you can see diacritics separately and edit them. It has its limitations - doesn't support ligatures and doesn't have the advanced features of text editors. --Anatoli T. ^{(обсудить}/^вклад) 21:19, 20 November 2014 (UTC)

• Thanks folks - I'll continue using Textpad — Saltmarsh^{απάντηση} 06:19, 22 November 2014 (UTC)

2 exceptions for клеветать and жаждать in Module:ru-verb

Module:ru-verb needs some changes, please. I feel less confident now with Lua after not coding for a long time.

клеветать is type "6c" needs a "щ" parameter, like "4a" function, жаждать is "6a" type, it needs to suppress iotation, some functions use "no_iotation" parameter, e.g. "present_je_a" function.

Alternatively, I'll make full conjugation paradigms as for completely irregular verbs but I prefer not to do that. --Anatoli T. ^{(обсудить}/^вклад) 23:36, 20 November 2014 (UTC)

Good try, thanks for helping :). I guess, I'll have to try it myself when I have more time. :/ --Anatoli T. ^{(обсудить}/^вклад) 12:47, 22 November 2014 (UTC)

Better Handling of Language-Code Errors

Currently, if someone uses a language code we don't recognize, such as sp for Spanish, they get an error message that says: "", with a hyperlink to the module where the error was executed.

This doesn't do much for the casual contributor who doesn't know the correct language code or where to find it- telling you that the language code is invalid is better than nothing, but it doesn't tell you how to fix it.

I would suggest that we should at least refer them to WT:LOL, with extra credit for a clickable link to it. Can we do this? Chuck Entz (talk) 00:23, 22 November 2014 (UTC)

I don't think you can put links in module errors. They interfere with the link that shows the error details. —CodeCat 00:43, 22 November 2014 (UTC)

"Interference" seems to be exactly what Chuck wants, if I understand him correctly. I'm not sure what the nature of the 'interference' you invoke actually is: does it cause the servers to crash? blank users screens? break the internet? defund the Bank of International Settlements? Can't errors be trapped? DCDuring TALK 01:00, 22 November 2014 (UTC)

Try it and see. And errors can be trapped but I don't see much point in doing that in this case. —CodeCat 01:27, 22 November 2014 (UTC)

The reason I said "extra credit" was because I suspected that was the case. I still think we should at least figure out a good way to tell contributors where they can get correct language codes. Chuck Entz (talk) 22:03, 22 November 2014 (UTC)

It's possible to catch errors, and show a more informative message for certain errors. But we can't pick and choose which errors to catch and which to let through; either we catch them all, or none. Catching all errors would not necessarily be desirable, because there are many cases where the actual module error message is more helpful than anything we could come up with. —CodeCat 00:16, 25 November 2014 (UTC)

We could mention WT:LOL in the error message, but I suspect that sending lots of casual users to that very resource-intense page would be bad for the site's servers. - -sche (discuss) 01:03, 25 November 2014 (UTC)

A Little Module Oddity

{{pt-conj}} and {{pt-verb}} showed up for the first time in Category:Pages with module errors in the past day or so: It looks like the huge number of transclusions in the documentation page are pushing the Lua execution time past its limit.

What I don't understand is why this only happens when the documentation is transcluded into the template page, but not when you view the documentation page itself. Previewing both the {{pt-conj}} template and documentation pages in edit mode shows the documentation using 2.353 seconds, but the template using 29.579 seconds (commenting out {{documentation}} drops Lua usage to zero, so there's nothing in the template itself that could account for it). Even stranger, all the items in the Lua Profile for the template don't add up to 10 seconds- let alone 29.579. That leaves two-thirds of the Lua time usage unaccounted for. The memory usage is 2.87 MB and 3.66 MB, with highest expansion depths of 22 and 24, so it doesn't look like those would explain it. Null edits on both haven't changed anything.

What's going on here? Chuck Entz (talk) 05:24, 22 November 2014 (UTC)

This happened ever since Kephir converted {{documentation}} to use Lua. —CodeCat 14:03, 22 November 2014 (UTC)

Is it because the non-Lua part of the template expansion is now part of the Lua execution time? Would it be possible for the module to just export wikitext and let the expansion happen afterwards? Or have separate invocations for the part before the documentation-page transclusion and the part after, so the documentation-page expansion doesn't have to be done by Lua?

I realize this is mostly due to the complexity of Daniel Carrero's template code, and to the abnormally-large number of template calls in the documentation pages, but it does show that there's added overhead here. Chuck Entz (talk) 21:56, 22 November 2014 (UTC)

I wonder why Lua even has its own execution time limit. They should really get rid of that and just use a page-wide limit. —CodeCat 22:04, 22 November 2014 (UTC)

I guess converting the pt-verb/pt-conj templates to Lua would help with the overhead and make it more maintainable in general ? It looks like it would be a bigger job, but hard for me to estimate, I'm new here. Jberkel (talk) 15:21, 30 November 2014 (UTC)

Absolutely. And the key to peace in the Middle East is getting Muslims and Jews to get along with each other... ;)

The problem is that Daniel Carrero's code is notoriously impenetrable- I've described it before as a cross between spaghetti and an Escher engraving. Names like "do work" for major components of the code are a sure sign of poorly-thought-out structure and disregard for maintainability. It would be easier to have someone who knows Portuguese verbs well to just look at the output and create something new from scratch. Chuck Entz (talk) 16:05, 30 November 2014 (UTC)

Ungoliant? — Keφr 18:34, 30 November 2014 (UTC)

I was working on a Lua module for Portuguese conjugation, but gave up when CodeCat and you started complaining about the amount of data modules (even though the amount of data module would be fewer than the current amount of data templates necessary...) — Ungoliant ^(falai) 21:01, 30 November 2014 (UTC)

That? I posted it on 21st of September, while your last edit to a subpage of Module:pt-verb (still nonexistent as of yet) was on 14th of September. I would guess you had stopped working on it for a while before.

Though I remember my thought back then was that given that these data modules are quite small, and we could not see any actual logic behind them (i.e. no code which would actually get input from a user and assemble conjugation tables), I figured that these should probably be consolidated into a single data module. — Keφr 23:32, 30 November 2014 (UTC)

My approach would be the following: parse the existing templates with conjugation data into a data structure (with the help of an external script) then serialise the conjugation data back to a Lua table (could just be one file, but will be large, see Module:User:Jberkel/pt-verb-table), then write the module logic which reads the data and generates the HTML tables. Jberkel (talk) 01:18, 1 December 2014 (UTC)

I had a look at the templates, you're right, it probably needs a complete rewrite. Are there any examples of well-written inflection/conjugation modules out there? Jberkel (talk) 20:36, 30 November 2014 (UTC)

I wrote most of Module:ar-verb (Arabic) and Module:fro-verb (Old French), and I think they're fairly well written, although they may be daunting because of size; both languages have quite complex verb conjugations, and there's a lot of stuff in there to handle them. Easier for you might be Module:it-conj, which is fairly well written and close in language as well. Benwing (talk) 08:09, 1 December 2014 (UTC)

Thanks for the pointers, I think I've got a handle on it, almost there. Famous last words. Jberkel (talk) 14:24, 1 December 2014 (UTC)

OK, here is a first version: pt-conj-test. Let me know if anything is broken. Jberkel (talk) 15:30, 3 December 2014 (UTC)

Module:tagged but not listed

I made a module which scans RFX categories for pages which are not listed on their corresponding RFX pages. Outrageously ugly hack, but it seems to work well enough. Discuss. — Keφr 15:56, 24 November 2014 (UTC)

It sounds quite useful. - -sche (discuss) 01:04, 25 November 2014 (UTC)

@Kephir The unstrip() hack is going to break on December 10th. The Vietnamese Wiktionary is using this same trick for its main page at the moment, so I filed T76844 to request that DynamicPageListEngine be installed there as a cleaner way to process DPL output. Perhaps the same should be done for this wiki. – Minh Nguyễn ^💬 09:49, 5 December 2014 (UTC)

Yes, please. (Mxn: making a 乒 (pīng) after you already signed your post does not work. See mw:Help:Echo.) — Keφr 11:23, 5 December 2014 (UTC)

Editing an Appendix

I would like to correct the transliteration of one of the Bulgarian numerals in Appendix:Cardinal numbers 0 to 9. Unfortunately one can't edit it by clicking on "edit". How is this done? --Kreuzkümmel (talk) 17:09, 24 November 2014 (UTC)

Words are automatically transliterated based on the language given. One of the words was tagged as Belarusian by mistake, so it was transliterated as if it were Belarusian. I fixed that now. —CodeCat 17:16, 24 November 2014 (UTC)

Manual translit is being ignored

On page Appendix:Proto-Indo-European/ph₂tḗr, the manual translit param tr=pitrulu for Telugu is getting ignored in favor of the auto translit pitṛlu. (I have no idea if the manual translit is even correct -- I suspect it may not be -- but it's what was present before in parens after the entry.) Benwing (talk) 06:21, 25 November 2014 (UTC)

That's an expected behaviour. Manual translit is suppressed. Telugu is 100% phonetic, at least in terms of transliteration. --Anatoli T. ^{(обсудить}/^вклад) 07:38, 25 November 2014 (UTC)

"D" button in Recent Changes not working

The red "D" accelerator button (to delete an entry directly from Recent Changes) doesn't seem to work any more. It says "notoken: the token parameter must be set". Equinox ◑ 14:39, 28 November 2014 (UTC)

Categorization of lb-adj

Somebody ought to place the template {{lb-adj}} into Category:Luxembourgish headword-line templates, but I'm not sure how that works. --Lo Ximiendo (talk) 09:43, 28 November 2014 (UTC)

Done. —CodeCat 13:15, 28 November 2014 (UTC)