Wiktionary:Grease pit/2014/September

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

---

Where is the documentation on Javascript in Wiktionary/MediaWiki?

For Lua there's WT:LUA aka WT:Scribunto, which gives a nice introduction to Lua and has links to explain the MediaWiki-specific things. Is there an the equivalent for JavaScript? I don't have that much experience with this language and it's a bit confusing trying to make sense of e.g. the stuff going on in MediaWiki:Common.js or User:Ruakh/Tbot.js. I've found some documentation on www.mediawiki.org but it seems rather disjointed. Benwing (talk) 02:52, 1 September 2014 (UTC)

You won't find much in MediaWiki because those were written by people here at Wiktionary. I suppose there might be documentation somewhere of the Wikimedia infrastructure that the JavaScript code is manipulating, but it wouldn't explain what we're doing with it. Chuck Entz (talk) 03:47, 1 September 2014 (UTC)

Right, I get that those were written here but I assume the documentation should be common to both projects. Is there any JavaScript documentation here on Wiktionary? Benwing (talk) 05:53, 2 September 2014 (UTC)

Template:character info adding bogus script cats

Discussion moved from Wiktionary:Grease pit/2014/August.

There are at least four redlinked "script" categories in Special:WantedPages that bear the names of Unicode blocks that aren't actually scripts:

1. Category:CJK Compatibility Forms script
2. Category:Enclosed CJK Letters and Months script
3. Category:Miscellaneous Symbols And Pictographs script
4. Category:Supplemental Punctuation script

With my limited template skills, I'm not sure if it's the parameters passed to {{character info}}, or something about these Unicode blocks themselves that the template code can't handle, but {{character info}} is where the cats are generated.

Can anyone figure out why this is happening, and make it stop? Thanks! Chuck Entz (talk) 00:10, 1 September 2014 (UTC)

@Kephir —CodeCat 23:59, 15 September 2014 (UTC)

The problem is simple: the various {{Unicode block character info}} templates pass the Unicode block to {{character info}} in a |script= parameter, which is then used to form a category name. It may be suppressed by adding an empty |category= parameter to {{character info}}, or removing the |script=. And the category name is wrong anyway. (I am sure you could have figured that one easily.) The replacement I have been working on, {{character info/new}} does not add any categories, but I am not sure if this is right (probably not). Additionally, the code for it (Module:character info) is relatively messy, and uses a rather crude hack for script detection (although using Module:scripts for that would make it even worse, if it be possible at all). So it is not really ready for deployment. — Keφr 04:46, 16 September 2014 (UTC)

@Kephir, Chuck Entz I have made some changes to these templates and I think it has solved the problems. The parameters of {{character info}} are more straightforward now. {{{block}}} specifies the Unicode block name to display and the appendix to link to; {{{sc cat}}} specifies the script code of the character category to add it to. Because you specify a script code, it's ensured that the category will always be valid. —CodeCat 23:55, 16 September 2014 (UTC)

quote-newsgroup is not suitable for non-Usenet groups

I was looking at Twihard and noticed that it has several citations from Google Groups, which (even though Google also archives Usenet newsgroups) are not part of Usenet. However, because the citations are formatted with the quote-newsgroup template, it incorrectly says "Usenet" beside them. What is the best solution? Equinox ◑ 07:52, 2 September 2014 (UTC)

In this case, the best solution is probably to remove them, because non-Usenet Google Groups are not durably archived, and the non-durable citations do not significantly differ from the durable citations in date or in how well they illustrate the use of the word.
But there will be other cases where non-durable citations are worth keeping — words need three durable citations to meet CFI, but once they have three durable citations, there's no prohibition on them also citing non-durable things, e.g. as usexes (if they illustrate the typical usage of the term better than the durable citations), or as support for a statement that the word has been attested since year X (if they predate the durable citations). After all, the online editions of Merriam-Webster and Dictionary.com are cited in many etymologies. I suppose the question is whether we need a new "non-Usenet-group" citation template for the non-durable citations we do keep, or whether {{quote-web}} is enough. - -sche (discuss) 15:45, 2 September 2014 (UTC)

I don't have an issue with Google Group postings being used as citations, but I went ahead and replaced the ones in the Twihard entry with cites from Google Books. -Cloudcuckoolander (talk) 19:23, 5 September 2014 (UTC)

Template:head should take f1tr etc. params

(Notifying CodeCat): {{ar-verb}} passes in a parameter f1tr that's intended to be a translation of an additional verb form (the imperfect), but {{head}} doesn't support that. Presumably it should support it; in the meantime, what's the best way to make this visible? Benwing (talk) 05:45, 3 September 2014 (UTC)

No, it shouldn't. Most foreign script languages don't transliterate inflected forms in the headword, e.g. Russian (e.g. ве́ра (véra), де́лать (délatʹ)). One reason: it makes it cluttered, the other: if the transliteration is irregular, one should always supply it. --Anatoli T. ^{(обсудить}/^вклад) 05:50, 3 September 2014 (UTC)

Whether the transliteration is irregular has nothing to do with whether it should be displayed. As for cluttering, I think that's questionable. There's only one inflected form here and it's not going to clutter things by adding the transliteration. The general practice anyway is to transliterate most words -- why do we bother providing transliterations in inflection tables if someone's just going to say it "clutters" the tables? The intention was clearly to provide such transliterations, that's why the imperfect transliteration is provided. Was there a general decision made at a certain point not to provide transliterations of inflected forms? Benwing (talk) 06:20, 3 September 2014 (UTC)

I think there was but I can't find it at the moment. User:CodeCat might remember, she has also edited {{ar-verb}} but it's probably controlled by {{head}}, sorry, my programming skills are not great. --Anatoli T. ^{(обсудить}/^вклад) 06:34, 3 September 2014 (UTC)

BTW {{ar-noun}} does include transliteration of the inflected form (the plural). It does it by manually inserting the transliteration, although with your changes it looks like it now appears twice (one comes from the use of {{l}}). An example is زرد. We should probably remove the manual insertion. Benwing (talk) 06:36, 3 September 2014 (UTC)

Hmm, I don't know what happened there but it's a bug. Arabic headword templates also need attention, sorry, you are busy as is. --Anatoli T. ^{(обсудить}/^вклад) 06:39, 3 September 2014 (UTC)

There was a discussion about this some months ago. I don't know where it went, but I think there was some opposition to transliterations for every form in the headword line, if I remember? —CodeCat 11:36, 3 September 2014 (UTC)

I think this should be decided on a per-language basis. For some languages the transliteration of the plural does not add much, for others, it is very useful. In other words, the template should support both possibilities. --WikiTiki89 15:21, 3 September 2014 (UTC)

I won't oppose it, if the majority decides so. Would be great if Lua-skilled people addressed Arabic headword modules/templates. --Anatoli T. ^{(обсудить}/^вклад) 01:10, 5 September 2014 (UTC)

I think overall we are overusing Lua. See my new Belarusian and Ukrainian adjective declension templates for examples of what I think is the proper mix of templates and Lua, ending up with the same effect as the fully Lua Russian adjective declension template. Likewise, the Arabic headword templates need only use {{head}}, which they already do, however some more functionality needs to be added to {{head}} such as what we are discussing here. --WikiTiki89 19:43, 5 September 2014 (UTC)

I find complicated template hacking to be nightmarish, much harder than using Lua. But then again, I am a programmer. Certainly, I don't see how I could have possibly implemented the whole set of Arabic conjugations in a reasonable amount of time using templates, as I did with Module:ar-verb. Templates also lead to tons of code duplication, almost necessarily (although some of the Lua modules have lots of duplication, too, e.g. Module:ru-verb). Benwing (talk) 20:24, 5 September 2014 (UTC)

Yes, complicated templates are nightmarish, and that's why I support replacing all the complicated parts with Lua, but that doesn't mean that the whole thing needs to be Lua (look at the examples I linked to above, they are both very simple). --WikiTiki89 21:35, 5 September 2014 (UTC)

Indeed, these are parsable although IMO they're about at the limit of where it makes sense to switch the whole thing to Lua, just because template syntax is so horrible.

BTW in the case of these two templates, I would make it so it automatically infers the stem and ending from the headword. This needs to be done in Lua but it will make it much easier to add conjugations to new adjectives since you just cut and paste the same call to {{be-decl-adj}} or whatever in every adjective lemma. I did this with Old French verb conjugation and with Arabic verb conjugation (in this latter case, inferring the radicals is significantly more complicated than inferring the stem/declension for Ukrainian or Belarusian). Benwing (talk) 07:44, 6 September 2014 (UTC)

Unfortunately, the template needs to know the location of the stress. Otherwise a simple template that requires no arguments would have obviously been better. --WikiTiki89 19:34, 6 September 2014 (UTC)

Ah of course ... I forgot that the stress isn't in the page title. Benwing (talk) 19:40, 6 September 2014 (UTC)

Category:J. R. R. Tolkien

Would somebody be willing to do whatever is necessary to make Category:English terms derived from Tolkien's legendarium into a subcategory of Category:en:J. R. R. Tolkien? I tried doing it myself, but I couldn't get it to work. Thanks! -Cloudcuckoolander (talk) 22:45, 3 September 2014 (UTC)

Done. Subcategories are just categories that are in a category. --WikiTiki89 23:42, 3 September 2014 (UTC)

What is that category for, anyway? I'm not really thrilled about mixing categories like this. —CodeCat 23:54, 3 September 2014 (UTC)

From its use of {{topic cat}}, it seems like Category:en:J. R. R. Tolkien is supposed to house terms which are (semantically) about Tolkien... but then it contains balrog, which is derived from but not about Tolkien. (Side note, balrog’s formatting needs to be cleaned up.) I'm not sure there are enough terms about Tolkien to merit the category. - -sche (discuss) 08:34, 4 September 2014 (UTC)

That's not what I was after, Wikitiki. I know how to manually add a category to a page. I wanted to edit this so that Category:en:J. R. R. Tolkien would be a parent category of Category:English terms derived from Tolkien's legendarium (and Category:fr:J. R. R. Tolkien a parent category of Category:French terms derived from Tolkien's legendarium, and so forth). -Cloudcuckoolander (talk) 21:27, 4 September 2014 (UTC)

If we do that, we would end up with 10 new categories whose only purpose is to hold that one subcategory. I agree with -sche that I'm not sure a category about Tolkien is warranted. —CodeCat 21:40, 4 September 2014 (UTC)

The purpose of this category is to allow Tolkien-related and Tolkien-derived terms to be slotted into relevant categories in the topical categorization system, like Category:British fiction and Category:Fantasy. There just isn't a convenient name used to refer to the Middle-earth mythos as a whole. -Cloudcuckoolander (talk) 21:55, 4 September 2014 (UTC)

I don't know what I'm doing wrong here. I'm ending up with a module error. -Cloudcuckoolander (talk) 22:09, 4 September 2014 (UTC)

Figured it out. Had to edit the module (is that the correct term?) for people, not culture. -Cloudcuckoolander (talk) 22:16, 4 September 2014 (UTC)

Tolkien and Carroll are not British fiction, literature or fantasy. They are authors. —CodeCat 22:23, 4 September 2014 (UTC)

That's splitting hairs. If you think Category:Tolkien legendarium or something similar would be a better category name, you could propose a rename at WT:RFM. But I don't see anything problematic with the current title. It's simple and does its job. -Cloudcuckoolander (talk) 23:05, 4 September 2014 (UTC)

Going to manually add all Tolkien-related and derived terms to Category:en:J. R. R. Tolkien as an alternative to my original proposal. -Cloudcuckoolander (talk) 23:33, 4 September 2014 (UTC)

I do not agree with that change. —CodeCat 00:49, 5 September 2014 (UTC)

I've now nominated Category:Authors for deletion. I kindly ask you not to make any further changes until that discussion has run its course. —CodeCat 00:56, 5 September 2014 (UTC)

Wiktionary is a collaborative project. It isn't your place to dictate where I can and cannot contribute. -Cloudcuckoolander (talk) 01:35, 5 September 2014 (UTC)

I would hope that someone interested in writing a dictionary would understand the difference between "kindly ask" and "dictate". —Aɴɢʀ (talk) 13:56, 5 September 2014 (UTC)

Prefacing a demand with "kindly" doesn't make it polite. Quite the opposite, actually. It's sarcastic and patronizing. -Cloudcuckoolander (talk) 17:43, 5 September 2014 (UTC)

Category:Wiktionary protected edit requests

The category contains some open requests, in particular MediaWiki talk:Gadget-LogoTiles.css. (I hope I followed the correct procedure; I tried several linked from Wiktionary:Request pages but couldn't find any.) --Nemo 09:36, 6 September 2014 (UTC)

Actually, that category has only been created this year. Normally we handle these requests here, at the GP (we have very few of them anyway). I guess we should not really have {{Edit protected}}, for the same reason we have no real {{helpme}}. — Keφr 10:04, 6 September 2014 (UTC)

Thanks for fixing. I've redirected the template here and added this page to Wiktionary:Request pages, I hope it works. --Nemo 05:37, 8 September 2014 (UTC)

Very bad idea. This way, when someone from TOW comes and uses the template out of habit, they will transclude the whole Grease pit page and after saving tell themselves "WTF just happened?". Better to just adapt {{helpme}} a bit. Also, GP is not really a "request page" — it is a general-purpose technical forum. — Keφr 16:15, 8 September 2014 (UTC)

Well that section is called "Other places to congregate". Technical requests go here and that's the page where one can be expected to look for the information. --Nemo 05:10, 9 September 2014 (UTC)

Module:ar-translit -- how can I shoehorn module-specific documentation?

The module Module:ar-translit uses generic documentation for transliteration functions. However, it currently takes two extra parameters, which I'd like to document. Is there a way to stick some such customized documentation in the template call that creates the documentation? If not, perhaps someone (@CodeCat?) could look into fixing this? Thanks very much! Benwing (talk) 09:38, 6 September 2014 (UTC)

Appendix:Arabic Frequency List from Quran

The subpages have been showing up intermittently in Category:Pages with module errors because {{l}} now transliterates, so the {{xlit}} makes 2 transliterations per line and the page tends to run out of script execution time. Could someone who knows what they're doing remove the autotranslit column? I ran into text-direction issues that scrambled things when I converted between formats.

It may actually be possible to consolidate further, since the Arabic text in all three Arabic columns seems to be identical (@Atitarev should be able to confirm). If it is, then it would be best to have the lemma column changed to use {{l}} and the other two Arabic columns removed. Thanks! Chuck Entz (talk) 00:15, 7 September 2014 (UTC)

I did exactly this. Benwing (talk) 11:26, 7 September 2014 (UTC)

Thank you! No more module errors on those pages. Appendix:Arabic Quranic Verbs has similar problems, but I'm not sure it can be fixed the same way. Chuck Entz (talk) 14:34, 7 September 2014 (UTC)

I edited the verb pages to remove the unvocalized column and link the vocalized column but that doesn't eliminate the module errors entirely. Is there no way to mark an individual page as needing more time to run? If not maybe we will end up having to break the 1-1000 page into two (1-500, 501-1000). Benwing (talk) 23:02, 7 September 2014 (UTC)

As far as I know, there isn't. It seems to be close: the parser profile shows it consistently using about 10.3 out of the allowed 10 seconds. The best solution would be to fix it by streamlining your transliteration code, but if that's not be possible, breaking the page up into shorter pages would be a good idea. There's nothing magical about 1000 lines per page, and it's much too big to really navigate through, anyway. We've been having several long and heavily-templated pages showing up with this error every few days, but those clear up with a null edit (I suspect running of processes by system people or heavy usage are temporarily slowing the system down). This one can sometimes be cleared to the point that no module errors show on the page, but not to the point that it disappears from the maintenance category. Chuck Entz (talk) 14:12, 10 September 2014 (UTC)

I'm not sure if it's possible to fix up the transliteration code that much. The problem may have happened when I added code to return nil upon encountering unvocalized text, which requires a bunch of additional pattern subs. But this is good functionality to have; otherwise you end up with incorrect transliterations. So maybe it should just be split in two. Benwing (talk) 19:09, 10 September 2014 (UTC)

Why does returning nil cause "a bunch of additional pattern subs"? --WikiTiki89 02:28, 11 September 2014 (UTC)

Because of the additional checks necessary to determine whether a word is properly vocalized. Benwing (talk) 20:29, 11 September 2014 (UTC)

If you do it right, you would transliterate and check at the same time and it should be pretty fast. Of course Lua makes it difficult to "do it right", due to its lack of native support for Unicode characters. Anyway, I misunderstood you. I thought you meant that returning nil itself causes "a bunch of additional pattern subs" in the calling module. --WikiTiki89 14:10, 12 September 2014 (UTC)

Hmm, that is a possibility. Some of the subs are shared between transliterating and checking for nil, and some aren't. For example, once the exceptional cases are handled, transliteration just maps all the remaining characters to Latin equivalents regardless of the exact sequence of consonants and vowels, but checking for nil needs to check to make sure the ordering is correct. Benwing (talk) 20:07, 12 September 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I split the verb page in two. Hopefully this will eliminate the errors. Benwing (talk) 14:48, 13 September 2014 (UTC)

Workshop: Greek and Latin in an Age of Open Data

This event, at the University of Leipzig in December, may be of interest: Workshop: Greek and Latin in an Age of Open Data. It would be good to have somebody there to represent and speak about Wiktionary and Wikidata. Pigsonthewing (talk) 15:59, 7 September 2014 (UTC)

undocumented template: anchor

Template:anchor

1. has no documentation
2. and seems to have some problems in its implementation

Furthermore, it's had these problems for 5½ years. Can someone(s) competent, as I am not, please take care of these? Thnidu (talk) 16:18, 7 September 2014 (UTC)

@Thnidu There are 64 pages which transcludes the mentioned template, in which 21 pages are in the main namespace or appendix namespace. Moreover, {{jump}} contains more function and is more useful than the mentioned template, and most pages use {{jump}} instead of {{anchor}}. Therefore, I think that this template is not even necessary. --kc_kennylau (talk) 17:20, 8 September 2014 (UTC)

Does {{jump}} work from links from other wikis? The specific page which anchors are needed for is biscuit, which Wikipedia is going to (or already does) link to different sections of like this. - -sche (discuss) 19:23, 8 September 2014 (UTC)

Broken sort

When using {{der3}} I found that Ancient Greek entries wouldn't sort correctly; for example entries starting with β would come before ἀγ would come before δ.

After some digging ({{der3}} calls Module:columns calls table.sort) I've found that Scribunto appears to somehow override the > operator so that it'll interpret á/ä/ą/etc. as "a" (instead of sorting them by Unicode value as usual); however letters with Ancient Greek diacritics (ἀ/ᾳ/ἁ/ᾶ) are treated as an empty string. I don't know how to fix this, or even where the relevant code might be. If anyone could solve this problem, or even point me in the right direction, that would be great. User:ObsequiousNewt/sig 17:38, 7 September 2014 (UTC)

Echo and watchlist

Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; [1] comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done:

1. Merge these two pages into one.
2. To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).

Thoughts on both, please? --Gryllida 02:24, 9 September 2014 (UTC)

This is something you should propose at MediaWiki. Wiktionary has not control over it. --WikiTiki89 02:34, 9 September 2014 (UTC)

We indeed lack control, but I'd like to see whether we'd like to see this change before I go and make it happen. The purpose of this question is to determine peoples' opinions. -Gryllida 22:18, 9 September 2014 (UTC)

Well then you're asking the wrong question in the wrong place. The WT:Beer parlour would be the right place for making decisions. The Grease pit is for technical questions, implying that you have questions about how to do this. --WikiTiki89 13:09, 10 September 2014 (UTC)

New errors on Arabic pages

Please bear with me. I just redid {{ar-verb}} so it automatically infers radicals from the page name and automatically generates the correct verb parts (as much as this is possible). In the process this has flushed out some existing errors of various sorts and I need to fix them one by one. Benwing (talk) 20:40, 10 September 2014 (UTC)

Template:sv-noun

This template does not categorize into Category:Swedish lemmas, but presumably it should. —Aɴɢʀ (talk) 21:46, 12 September 2014 (UTC)

Fixed. —CodeCat 21:59, 12 September 2014 (UTC)

How do you indicate the argument frame of a verb?

The verb باحث in Arabic has the approximate meaning of discuss, but it is a form III verb, and like other such verbs, it takes a person as a direct object (who you're discussing with), and the topic of discussion appears after the preposition فِي (fī) "in". I have tried to indicate that as follows, but I don't really think this is right, and it looks ugly:

1. to discuss with (someone) (a question (deprecated template usage) (with فِي (fī)))

In linguistic terms, what I'm trying to describe is the argument frame of the verb. In my dictionary, it appears as follows:

to discuss (ه with s.o.) (فِي a question)

where the ه (a letter "h") is a standard Arabic dictionary abbreviation for a direct object that's a person. However, I'm not sure if this formatting makes sense for Wiktionary. (Oddly, the standard abbreviation for a direct object that's a thing is ه‍, which is also a letter "h" but in its combining form.) Benwing (talk) 05:55, 13 September 2014 (UTC)

This is a problem in many languages, and has been discussed before: Wiktionary:Beer parlour/2014/February#French Verb Usage With Prepositions

I created {{+preo}} and {{+obj}} to deal with this problem (both are implemented using Module:object usage); see the backlinks for some examples. The templates are somewhat experimental, and I never really thought about applying them to RTL languages. Here is how they would be used like:

1. to discuss Template:+preo

Or something similar. The styling should be definitely changed to something more readable, but I have no real idea how. — Keφr 07:07, 13 September 2014 (UTC)

The way I like to handle this is to add two or three examples after the definition/translation, and also include a Usage notes section for clarification. —Stephen ^(Talk) 07:27, 13 September 2014 (UTC)

Breves in Ancient Greek

According to the A.A.G. page and this conversation, breves and macrons in A.G. should be marked in the pronunciation, headword, and inflection tables, but not in the entry name. When placing macrons in inflection tables, the automatic linking will replace an ᾱ, ῑ, or ῡ with each's non-long form, but this is not the case for breves. As such, an inflection table with breves will link to a page with a breve in the title. Is there a reason breves have not been added into automatic linking, and if not, could an admin add them? User:JohnC5/sig 07:39, 13 September, 2014 (UTC).

For Latin, the assumption is that a vowel lacking a macron is short. I think we should do it the same way for Ancient Greek. —CodeCat 19:54, 13 September 2014 (UTC)

The argument was made that many beginning A.G. dictionaries do not contain macrons and breves, and so a lot of entries with unmarked vowels are ambiguous as to whether they are short or just not added correctly. Regardless of whether we decide to use breves, which I favor, doesn't it still make sense to add breve removal to the automatic linking so as to stop the linking problem in the future? User:JohnC5/sig 08:04, 13 September, 2014 (UTC).

Breves are not currently stripped for Latin, as we don't include them to begin with. The practive for Ancient Greek and Latin should really be the same. So if we should include breves for Ancient Greek but not Latin, I wonder why? —CodeCat 19:29, 15 September 2014 (UTC)

Atelaes makes the case (in his post timestamped: 21:02, 19 June 2007 in the conversation linked to by User:JohnC5 above) rather well for why we should use brachiae in describing Ancient Greek:

• "[Y]es we are indeed using breves in this dictionary…. Here's the reason: most of the Ancient Greek entries do not have any macrons or breves. So, a blank vowel needs to be assumed ambiguous. Thus, a blank vowel cannot be assumed to be short. Thus, breves must be allowed."

That makes sense to me, and I agree with him. Whether to use breves in Latin is another question; I don't necessarily agree with your assertion that "[t]he practi[c]e for Ancient Greek and Latin should really be the same."

I support extending macra-stripping to brachia-stripping for Ancient Greek. — I.S.M.E.T.A. 00:51, 16 September 2014 (UTC)

I don't understand your reasoning. If most Ancient Greek entries don't have macrons, then we should add them where needed. That's not a reason to add breves. —CodeCat 01:12, 16 September 2014 (UTC)

To quote that same post by Atelaes:

• "[W]e have to allow for editors to input entries with ambiguous vowel lengths when they don't have access to that information…, or for the myriad of A. Greek words which we simply don't yet know what the vowel length is." [my emphasis]

 — I.S.M.E.T.A. 01:24, 16 September 2014 (UTC)

Why wouldn't that apply to Latin too? —CodeCat 01:30, 16 September 2014 (UTC)

I suppose it would, but so what? — I.S.M.E.T.A. 01:31, 16 September 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I believe it should, frankly. Then again, the situation for Latin may be different due to markings or corpus availability. In all other respects I support per Atelaes. User:ObsequiousNewt/sig 02:19, 16 September 2014 (UTC)

@ObsequiousNewt: I'm inclined to agree with you and CodeCat, but my point is that this is a discussion about Ancient Greek specifically, and not a discussion about our general policy with regard to all extinct languages with phonemic vowel quantity and orthographic ambiguity with regard to vowel quantity. In the same way that the proposal to strip brachiae from Ancient Greek links has been extended to the stripping of breves from Latin links, it could be extended to the stripping of breves from Old English links (for Latin and Old English are, after all, both "extinct languages with phonemic vowel quantity and orthographic ambiguity with regard to vowel quantity"). Let's not be too hasty. If this change to our practice concerning Ancient Greek is agreeable to everyone, it can then, later be cited as a precedent in the argument in favour of marking short vowels in Latin using breves (and therefore stripping them from Latin links). — I.S.M.E.T.A. 14:21, 16 September 2014 (UTC)

Agreed. User:ObsequiousNewt/sig 14:29, 16 September 2014 (UTC)

I still oppose the use of breves to mark short vowels, in any language. They make words look very messy and hard to read, and in certain fonts and resolutions they even look (almost?) indistinguishable from macrons. Macron-vs-no macron is much easier to distinguish than macron-vs-breve. —CodeCat 15:00, 16 September 2014 (UTC)

@CodeCat: In my experience, macra and breves are easily distinguishable — far more so than, say, tildes and double-acutes ( ˜ · ˝ ) or breves and háčky ( ˘ · ˇ ). But in any case, there's far more trouble with distinguishing some of the Ancient Greek diacritics that are part of its actual orthography, namely the oxia, baria, psile, and dasia ( ´ · ` · ᾿ · ῾ ). Distinguishability, in the case of Ancient Greek, really isn't a problem for macrae and brachiae, because if your font's confusing those two, you haven't got much of a hope distinguishing the obligatory diacritics. — I.S.M.E.T.A. 15:36, 16 September 2014 (UTC)

• As a discussion about what should be done rather than how it should be achieved, this does not belong to Grease Pit. --Dan Polansky (talk) 17:50, 16 September 2014 (UTC)

Fine. Am I right that all that needs to be done is to tweak Module:languages/data3/g, changing this:

m["grc"] = {

⋮

entry_name = {

from = {"ᾱ", "ῑ", "ῡ"},

to this:

m["grc"] = {

⋮

entry_name = {

from = {"ᾰᾱ", "ῐῑ", "ῠῡ"},

– yes? — I.S.M.E.T.A. 18:44, 16 September 2014 (UTC)

Playing audio repeats the first bit on the second play.

I don't know if this is a firefox issue or a windows 8.1 issue. I click play and it repeats the first parts so, for example, kiwi sounds like k-kiwi. If I reload then it will play one time correctly. Could someone tell me what direction to go for a fix? Thanks.

It's not a Windows issue- I get the same thing on my Mac (Firefox 16.0.2), though I have yet to hear it on Safari (5.0.6). It also seems to vary from clip to clip: on the page for kiwi, the Dutch clip never does it, but the Canadian French one does. Chuck Entz (talk) 21:18, 13 September 2014 (UTC)

Thanks Chuck. The Dutch clip is also doing it, but but because there is some dead space at the front it is just repeating the background noise. You can kind of hear a sh sound. Gbleem (talk) 22:54, 13 September 2014 (UTC)

Same issue here, and I use neither OS. I also get the same problem on w:. MediaWiki bug, I guess. — Keφr 05:21, 14 September 2014 (UTC)

WOTD maintainer?

Hi everyone, I got a message from the toolserver list that mentioned my ancient WOTD tool (that was turned off in 2009?) is currently getting the most "404 - Page not found" errors. That is, something like 2403 page hits per day.

Can someone please identify the best redirect to be used there? Thanks in advance. --Connel MacKenzie (talk) 23:15, 13 September 2014 (UTC)

There was a WOTD tool? (Also, hi. Do you mind being de-checkusered?) — Keφr 05:25, 14 September 2014 (UTC)

I’m not sure what you’re asking, Connel, but, as I understand it, the toolserver tools are being migrated to Labs (tools.wmflabs.org). You probably already knew that, but just in case you didn’t. —Stephen ^(Talk) 14:39, 16 September 2014 (UTC)

Template:br-noun

Hi. Can someone please fiddle with Template:br-noun to allow multiple plurals to be shown: for example koad, which has a couple of plurals. I attempted it, but am utterly inept at templates. --Type56op9 (talk) 09:24, 17 September 2014 (UTC)

This and this seem to have fixed that; however, I don't understand how that f2accel= stuff works, so I might've broken something with that... :-S  — I.S.M.E.T.A. 09:48, 17 September 2014 (UTC)

Visual Editor

Is there a reason why Visual Editor is not available as a beta feature here? There are some things for which I have found it very useful. Cheers! bd2412 T 14:57, 17 September 2014 (UTC)

• I oppose introduction of Visual Editor into English Wiktionary in any form other than as an opt-in. Furthermore, I think this is a Beer parlour subject, since it deals with what should be done rather than how. --Dan Polansky (talk) 18:04, 17 September 2014 (UTC)
  • So what you're really saying is that you support its introduction as an opt-in, except that "support" is probably some kind of swear word to you. —CodeCat 18:36, 17 September 2014 (UTC)
    • Nice one. But I guess if there is a proposal, I will oppose it too (even an opt-in), not on bureaucracy grounds, but because 1) it will encourage creation of manually-formatted entries by clueless users (i.e. '''paradise''' (''plural'' '''[[paradises]]''') plus manually added categories), which are error-prone and not malleable to mass conversions like adding lemma categories; and 2) it does not make it any easier to use the preferable method of formatting and categorising entries here, which is through templates. VE is fine (at least in principle; the actual implementation is rather obnoxious) for relatively free-form articles like there are on Wikipedia, but not for rigidly-templated Wiktionary entries. If we want to make a WYSIWYG editor, it should be WT:ELE-aware, and should use and understand templates transparently. — Keφr 19:29, 17 September 2014 (UTC)
    • No, CodeCat. "support" is not a swearword. I support that your bot gets the bot flag removed, I support that you are desysopped, and I support that you are banned from Wiktionary. Other than that, plenty of my "support" votes are found in various Wiktionary votes. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
      • Well, if you put it that way, then sure, you support a lot of things. Mostly that nothing here should change, ever. — Keφr 05:42, 18 September 2014 (UTC)
• I agree that this introduction of new default features is not a GP matter. I strongly oppose any implementation of new default features of any kind without BP discussion. DCDuring TALK 19:04, 17 September 2014 (UTC)
  • I believe BD was merely asking a question, not making a formal proposal. Beta features are not enabled by default anyway, except for users who explicitly enabled that. And VE is still in testing stages. — Keφr 19:29, 17 September 2014 (UTC)
    • Based on past experience, anything less than clearly expressed opposition to undesirable possible actions can be taken as implicit support. Sow the wind, reap the whirlwind. DCDuring TALK 19:57, 17 September 2014 (UTC)
      • To be clear, I would like the option of using Visual Editor here, as an opt-in only tool. I quite frankly loathed it when it was first introduced, but have played around with it a bit and found that it is a very fast way to make WYSIWYG edits, particularly when you are working on long pages and want to be able to tell the red links from the blue links while you work. bd2412 T 03:00, 18 September 2014 (UTC)
    • Merely asking a question? In Wiktionary:Requests_for_moves,_mergers_and_splits#Rhymes_pages_from_using : as_the_separator_to_using_/, an editor merely asked a question: "Why keep the hyphen?" No one responded. Later, the hyphen got removed without any further discussion by CodeCat. I support that CodeCat is banned. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
• I changed my mind; I oppose introduction of Visual Editor in any form or manner, even as an opt-in. I recall how I gave in and allowed the introduction of LiquidThreads in a vote, and am I sorry that I did; the amount of harm the abomination made in multiple talk pages is significant. --Dan Polansky (talk) 05:19, 18 September 2014 (UTC)
  • I am sorry to hear that. Where can I see that harm? Though I fail to see how VisualEditor and LiquidThreads are related, especially that "opt-in" means different things for the two. — Keφr 05:42, 18 September 2014 (UTC)