Wiktionary:Grease pit/2014/September

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)

Why even have WT:Scribunto here anyway? For the most part, it seems to duplicate content over at mw:Extension:Scribunto/Lua reference manual. — Keφr 06:39, 3 October 2014 (UTC)

Please don't delete it. It has lots of important introductory info not found in the MediaWiki Lua reference manual, and more importantly, it's here on Wiktionary. Someone who goes looking for info on Lua will likely try WT:Lua, which is a link to WT:Scribunto, and they will get a nice intro page on Lua, as expected. It's far less obvious to go look on the MediaWiki pages, even less obvious that you have to look under "Extension:Scribunto". Someone who's interested in Lua scripting will probably have heard something about scripting being in Lua but it's unlikely they'll have heard of Scribunto as such. Certainly, I found the docs in exactly this fashion. If there were a WT:Javascript page, it would be a huge help. Benwing (talk) 07:20, 3 October 2014 (UTC)

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)

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)

(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)

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)

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)

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)

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)

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)

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)

@Kc kennylau (I just saw this.) Thanks, but you haven't addressed the absence of documentation. Wikipedia has a fully functional "anchor" template. I've been a W'pedian for many years, so I looked for "anchor" here. Can you, or some experienced Wiktionary editor, at least add a paragraph of documentation to your anchor saying

If you're looking for the Wikipedia anchor functionality, try ?

--Thnidu (talk) 01:32, 20 October 2014 (UTC)

@Thnidu I trust that you can do this yourself. If you would still like assistance, feel free to ask us again. --kc_kennylau (talk) 14:28, 20 October 2014 (UTC)

@Kc kennylau I don't remember how my previous issue here 3½ years ago worked out, if at all. But now, returning and seeing your recommendation of {{jump}}, I looked there and found

This template is experimental and should be used with extreme caution. It should be used only in entries where the large number of senses under a single POS section makes browsing difficult.
...

Usage notes
{{jump}} is only to be used in long entries. In short entries, it creates links between sections that are very close together, and is redundant to simply scrolling up and down, or worse, the entire entry may appear on a single screen with no scroll bar. In this case, {{jump}} does virtually nothing.

--Thnidu (talk) 16:32, 6 May 2018 (UTC)

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. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 17:38, 7 September 2014 (UTC)

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; 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)

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)

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)

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 (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

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)

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? —JohnC5 ^{(Talk | contribs)} 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? —JohnC5 ^{(Talk | contribs)} 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:

• "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 "he practie 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:

• "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."

 — 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. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 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. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 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 = {

⋮

entry_name = {

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

to this:

m = {

⋮

entry_name = {

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

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

I believe you would need to put them in brackets. Compare the preceding sort-key line. (So it would say from = {"", "", ""},) ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 02:10, 27 October 2014 (UTC)

@Carriearchdale, DelianDiver, Dimboukas, Furius, Guovssahas @Jaxlarus, Jmolina116, Omnipaedista, Paul Pela, Salmoneus.Aiolides @Declan Clam, Espoo, Johanna-Hypatia, Leonariso, Medellia, MGorrone, Nyelvérzék, Oberlinclassicist @Paepaok, PierreAbbat, Stelio, Svlioras, Znex, Λεξικόφιλος, Ο Ελληνόαυστραλός βοηθός As members of Category:User grc-3 and -2, I figured I should ping you all so that you can have your input. — I.S.M.E.T.A. 21:00, 21 September 2014 (UTC)

I'm no expert on the long and the short of α, ι, υ; what I read is prose. But I do know a fairly long minimal pair. Συναλιζόμενος occurs in Acts 1:4. According to an appendix in the AENT, with a long α it means "gathering with" (And gathering with , he told them...), but with a short α it means "eating salt with" (I don't see "eating" and suspect it's "salting with", but have no occurrence in context). PierreAbbat (talk) 05:03, 22 September 2014 (UTC)

It doesn't have to mean "eating salt with". It can also mean "eating with". This example is a bit odd, because no one can agree on the exact meaning: apparently all three interpretations have problems. Yes, there's a third interpretation: as a variant of a verb meaning "to stay with". Still, the question here isn't whether length should be indicated, but whether it should be indicated by macron vs. absence of macron or macron vs. breve. Chuck Entz (talk) 05:31, 22 September 2014 (UTC)

I agree with not marking short vowels with breve. This is only ever done for extreme and deliberate clarification of a vowel length. An unmarked vowel should be assumed to be short, and long vowels should be marked with macra. Any ambiguous vowels, which are rare, should be doubly marked (such as ᾱ̆ – note these may not show up well with some fonts). This is the way I tend to mark vowels myself in both Greek and Latin. It removes the need to mark all vowels and makes the language look cleaner and easier to read, and I believe it is the norm nowadays as well. -Jmolina116 (talk) 13:23, 23 September 2014 (UTC)

I support marking ambiguous vowels with macron plus breve. —CodeCat 17:06, 23 September 2014 (UTC)

I would interpret ᾱ̆ as meaning "this form is attested with both long and short α", not "it is uncertain whether the α in this form is long or short". —Aɴɢʀ (talk) 18:27, 23 September 2014 (UTC)

I think it just means "ambiguous vowel length", i.e. either of those two explanations. I don't really know if there is any real way to distinguish between those two, and to my knowledge no grammars or dictionaries do. In actual texts (both Greek and Latin), neither breve nor macra are included, and one just has to figure out which it is (although it is usually irrelevant). In many dictionaries, such as the Lewis and Short for Latin and the Middle Liddell for Greek, macra and breve are only used to disambiguate vowel qualities that are deemed not to be "obvious", for example the υ in συν- is never marked in any compounds as it's always short. I disagree with this method because it assumes a certain level of knowledge of the user. They also do not mark vowels in closed syllables as these syllables are already heavy and the vowel's length is irrelevant for metrical purposes. I also disagree with this as it assumes that meter is the only reason one would want to know vowel length, and there are plenty of other scholarly reasons for wanting to know the length of the so-called "hidden vowels". I think most of us here agree that we should indicate as much information of the vowel quality as possible and let the user decide what they deem to be relevant and irrelevant information. The reason I mention this is to point out that sources and texts vary in their methods of marking vowel length. Textbooks do as well: the Hansen & Quinn leaves short vowels unmarked and marks long vowels with macra; the Athenaze never marks vowel length with macra or breve. I don't know of any sources who mark both short and long vowels and leave unmarked vowels for the far less frequent ambiguous vowel lengths, but I would like to know if anyone knows a text that does. Even so, my reasoning for not marking it is the convenience of not having to mark every vowel in most words. It might also be worth mentioning that marking vowels with both a length mark and with other diacritics is not easy to do in Unicode and doesn't always show up well, so I would suggest minimizing those cases to as few as possible. Sorry for the lengthy response. –Jmolina116 (talk) 02:57, 24 September 2014 (UTC)

Having said that, I'm still in favor of autoreplacing breve-ed vowels with unmarked vowels, just in case they are ever typed as such. If they all get replaced by unmarked vowels assumed as short, then it won't be an issue, but it's better to make sure we're not linking to blank pages where pages do exist. –Jmolina116 (talk) 00:01, 24 September 2014 (UTC)

I have another question along the lines of automatic linking. Is there anyway to do this for all diacritics. The reason I ask is because right now, if someone types ωδη, it shows up as if there are no results, but clearly the intention was ᾠδή. I understand that this is the only thing that separates Ancient from Modern Greek in some cases, but I feel like making it entirely necessary to type all diacritics when wanting to search a word is problematic. –Jmolina116 (talk) 05:39, 3 October 2014 (UTC)

Search is not generally something that we have control over or that is easy to change. DTLHS (talk) 06:06, 3 October 2014 (UTC)

• I've edited the module so that breves are stripped off in grc. —Aɴɢʀ (talk) 19:18, 27 October 2014 (UTC)

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)

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)

Stephen, I have been offline quite a while - there's a lot I'm not up to date on. --Connel MacKenzie (talk) 22:20, 30 September 2014 (UTC)

There is a WOTD feature - I do still get the daily e-mail that includes Wiktionary's WOTD along with a bunch of other stuff. The process is automated at the wiki level now - I'm not clear on the mechanism. --Connel MacKenzie (talk) 22:20, 30 September 2014 (UTC)

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)

@I'm so meta even this acronym It's explained on the documentation for {{head}}. Basically, each number f1, f2, f3 etc. corresponds to a pair of positional parameters following the part-of-speech category parameter. Like so: {{head|lang|category|1|1|2|2|3|3|4|4|5|5|...}}. That means that if you insert a new pair in the middle, like you did, then you have to increase the numbers of all the f-parameters following it by one. I've done that now. —CodeCat 21:34, 21 September 2014 (UTC)

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'' ''']''') 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)
        • Check the past votes before you post yet another inaccuracy. --Dan Polansky (talk) 05:51, 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)
    • Your edit summary (diff): "spreading FUD as usual". No other comment from me to your post. --Dan Polansky (talk) 05:51, 18 September 2014 (UTC)
      • I will take that as an agreement with that assessment of you. — Keφr 06:12, 18 September 2014 (UTC)
        • Dan, whatever disagreements you have had with CodeCat and others over these procedures have not involved me. Please let me have this tool. Cheers! bd2412 T 13:50, 18 September 2014 (UTC)
          • bd2412, let me state that I hold you in high esteem, and that I am sorry that your proposal got mixed up with inflammatory posts by other editors. --Dan Polansky (talk) 07:44, 20 September 2014 (UTC)
            • Much appreciated. bd2412 T 15:18, 20 September 2014 (UTC)

Vote, then? I wouldn't object to opt-in, but I don't want to see it as a default unless/until it has undergone huge amounts of work to tailor it to Wiktionary's specific needs! Equinox ◑ 13:54, 18 September 2014 (UTC)

• I have no desire whatsoever for VE as a default here (it has been pointed out that at present it is awful for templates); I would like to have it in the toolbox as an opt-in. That's all I ever wanted here. bd2412 T 13:59, 18 September 2014 (UTC)
  • I struck my opposition to an opt-in; changed my mind to neutral. Though I still fail to see the benefit of it and I would not recommend that it be used by newbies. — Keφr 08:04, 19 September 2014 (UTC)

I would only support a very difficult opt-in. Such as a modification to Special:MyPage/common.css or Special:MyPage/common.js. That way, only users who really, really want it can have it. --WikiTiki89 17:42, 18 September 2014 (UTC)

• I support the introduction of VE, at least as opt-in. —Mr. Granger (talk • contribs) 22:33, 18 September 2014 (UTC)

• Comment: I have asked the VE people whether they could enable VE with futher restrictions, for example as an admin-only tool, or as a tool for users whitelisted through a process similar to whitelisting for AWB, and was told that they can not. The most restrictive option they offer is the opt-in for registered users. I think that they could give us more restrictive access to it if they wanted to put in a modicum of effort. Therefore, although I believe that this restriction is enough to prevent misuse, I can live without it, and will not push for it over community objections. bd2412 T 15:18, 20 September 2014 (UTC)

I created a template documentation with a misspelt name just now — Template:RQ:Blwnds_TLdgr/documentation — and I've cleared it out but don't know how to delete it. Would someone please delete it, or tell me how to. Sorry for the blunder. — ReidAA (talk) 01:15, 19 September 2014 (UTC)

 Done. — Ungoliant ^(falai) 01:19, 19 September 2014 (UTC)

{{delete}} is intended for the job of drawing attention to something that (almost) certainly should be deleted without a {{rfd}} vote. DCDuring TALK 01:22, 19 September 2014 (UTC)

Do you mean that if I had just put {{delete}} in the emptied documentation then it would have automatically been notified to someone authoritative? Thanks for the prompt response (and deletion). — ReidAA (talk) 01:51, 19 September 2014 (UTC)

Yes, even if it hadn't been emptied. DCDuring TALK 04:03, 19 September 2014 (UTC)

Hi,

I am surprised to find an article anchor named "Noun5". I see in m:Help:Link#Anchors that anchors names are positional names, which, I guess, implies that adding a new section named "Noun" before the one with anchor name "Noun5" would make the "old Noun5" become "Noun6", and "Noun5" anchor would move to a new content.

It would be a lot more useful to include at least the language name in the anchor name, for example "EnglishNoun". And why not the whole hierarchy, for example "EnglishEtymology2Noun".

At the moment I feel that linking to a wiktionary article subsection is pretty dangerous.

Regards.

This is why we (should) avoid linking to subsections other than languages. —CodeCat 16:09, 19 September 2014 (UTC)

Since our entry structure isn't recognized by the wiki software, as long as the headers are done via wiki syntax, there's no way to guarantee the anchor automatically generated for non-unique headers, and only the language headers are unique. The workaround is to use a template that creates an additional anchor to link to. Aside from {{anchor}}, There's also {{senseid}}, which has more functionality and is better documented. Chuck Entz (talk) 17:21, 19 September 2014 (UTC)

There is something else that might work. We can use Javascript to modify various elements on a page, so that they have the right ids for linking to. —CodeCat 18:18, 19 September 2014 (UTC)

It would be nice to be able to do something hierarchical like pan#English.Etymology 1.Verb. --WikiTiki89 18:26, 19 September 2014 (UTC)

Do all users have access to JS? Are there version problems? Do we have the ability to do it in a way that failed gracefully if a user didn't have JS or the version was wrong or old? DCDuring TALK 18:37, 19 September 2014 (UTC)

JS has been around for decades now, so it's pretty much universal. —CodeCat 19:02, 19 September 2014 (UTC)

Everyone has JS, but a some people very few people disable it for who knows what reasons. JS errors are invisible, but they often interrupt the rest of the JS, causing a chain of lost functionality. --WikiTiki89 19:05, 19 September 2014 (UTC)

And I suppose we only do relatively standard JS. DCDuring TALK 20:05, 19 September 2014 (UTC)

How did Talk:Broken/rhymes\x3aEnglish\x3a-e\xc9\xaa\xca\x83\xc7\x9dn get created from ]? At least it looks like that's what happened, since the edit history includes a move by the conversion script to lowercase with the comment "] moved to ]", and there were no further moves. Chuck Entz (talk) 20:46, 19 September 2014 (UTC)

\x3a == '0x3a' == ':', it's just broken encoding. DTLHS (talk) 20:49, 19 September 2014 (UTC)

I've deleted it now. —Aɴɢʀ (talk) 20:49, 19 September 2014 (UTC)

I figured out that much- but how did that happen in the first place? Chuck Entz (talk) 21:00, 19 September 2014 (UTC)

What also confuses me is why your links above don't work. --WikiTiki89 22:42, 19 September 2014 (UTC)

I'm guessing that the change in syntax for the Talk namespace is involved with both somehow- perhaps the former syntax is left unparsed for some reason, and the mystery page is one that got lost in the transition. You might also look at this prefix search, which brings up a few more. Chuck Entz (talk) 23:13, 19 September 2014 (UTC)

See 一日千秋. I want to have no space in the katakana and a space in the romaji, but this would cause it to be added to a tracking category. --kc_kennylau (talk) 15:29, 20 September 2014 (UTC)

IMHO, User:Visviva/Elsewhere is an excellent page, spotting what we lack that other Wiktionaries have. Since the last time it was created, most red links have been turned blue, which is always a Good Thing. Would anyone be able ro regenerate it? --Type56op9 (talk) 10:33, 21 September 2014 (UTC)

@Type56op9: User:DTLHS/elsewhere DTLHS (talk) 04:46, 23 September 2014 (UTC)

Thanks, by the way. I've gone through some of that list and created some stubs. And linked to that page from Wiktionary:Wanted pages, so perhaps at least one other user will be able to use it. --Type56op9 (talk) 10:06, 1 October 2014 (UTC)

I have multiple Burmese-compatible fonts installed on my computer. I used to be able to see Burmese characters everywhere on Wiktionary without any problem. For the past several weeks, though, all I see is boxes in page titles and in the edit field, though the characters still appear correctly in the main body of entries. Any ideas why this is happening and how I can get the Burmese characters back everywhere I need them. Editing Burmese entries is very frustrating when all I see in the edit field is little boxes. —Aɴɢʀ (talk) 19:06, 21 September 2014 (UTC)

A picture being worth a thousand words, I've added a picture. Forgot to mention I'm using Firefox on Windows 7. —Aɴɢʀ (talk) 19:12, 21 September 2014 (UTC)

Same results on IE, but characters do display correctly on Chrome. —Aɴɢʀ (talk) 19:16, 21 September 2014 (UTC)

@Angr: Headers use serif fonts now, whereas the main-body text still use sans serif fonts; might that have something to do with it? — I.S.M.E.T.A. 20:45, 21 September 2014 (UTC)

Maybe, but playing around with the default serif fonts in my Options doesn't help. Even changing the default serif font to a Burmese font didn't work. —Aɴɢʀ (talk) 21:09, 21 September 2014 (UTC)

Also the link to Burmese Wiktionary under "In other languages" on the lefthand side has boxes rather than characters, and that's a part that normally has sans-serif. —Aɴɢʀ (talk) 21:10, 21 September 2014 (UTC)

Also, even in the main text body characters appear correctly only if they're tagged as Burmese by being inside {{l}}, {{m}}, {{lang}}, etc.  Otherwise, it's boxes. —Aɴɢʀ (talk) 21:13, 21 September 2014 (UTC)

What happens if you replace {{lang|my|...}} with <span lang="my">...</span>? —CodeCat 21:14, 21 September 2014 (UTC)

Then I get boxes, not characters. —Aɴɢʀ (talk) 21:53, 21 September 2014 (UTC)

Then it's the alternative fonts applied through script classes and Lua autodetection that is making the text visible to you. I'm guessing that if you wrap it in <span class="Mymr">...</span> then it will display correctly. —CodeCat 22:13, 21 September 2014 (UTC)

Yep, that works. So how do I fix it? —Aɴɢʀ (talk) 22:41, 21 September 2014 (UTC)

I don't think there is an easy way that would fix this in all cases. It comes down to the fonts used. We can change the fonts used in page title headers, and maybe in edit boxes too. But of course that would be a rather major change, and even then it would be impossible to guarantee that everyone has that font, nor that the font can display every single possible character to begin with. For the edit box, the wiki specifies no font, so the default monospace font in your browser is used. If you change that font, it may fix it, but that's only going to work for your own computer, not the site in general.

The wiki software allows us to override the displayed page title. This is already used in a few cases, like on prefix and suffix categories (just go to the category for a non-Latin script suffix and you may notice it). This means that it's theoretically possible for a template to apply script detection and the appropriate script classes/fonts to the title itself. But to do that, we'd have to include that template on every single mainspace page. So it can be done, but I don't know if it's worth the effort. —CodeCat 22:48, 21 September 2014 (UTC)

The above solution with including a template would only work when the page is viewed of course, not when it's edited. But if we don't want to include a template on every page, an alternative could be to add this functionality into {{head}}. Every page contains this template, so it can do this too. I'm not sure what would happen when there are multiple instances of {{head}} on the page; it's possible the software will protest and show an error if a page attempts to override the page title more than once. —CodeCat 22:53, 21 September 2014 (UTC)

At this point, I'm content to fix it only on my own computer. But going to my browser options and changing the setting for serif font and/or monospaced font to a Burmese-compatible font doesn't even fix the problem. —Aɴɢʀ (talk) 22:54, 21 September 2014 (UTC)

Then I'm not sure what would work. I'm sorry. —CodeCat 22:55, 21 September 2014 (UTC)

Is there any way for his common.js to switch things? Chuck Entz (talk) 03:12, 22 September 2014 (UTC)

The link of the page of the screenshot? Please add it! MihaiVulga3 (talk) 13:02, 9 May 2023 (UTC)

Why? That was over 8 years ago and everything has changed since then. Chuck Entz (talk) 13:15, 9 May 2023 (UTC)

I have similar problems with Burmese characters after moving to Windows 7 on one of my computers. --Anatoli T. ^{(обсудить}/^вклад) 02:30, 22 September 2014 (UTC)

For me, this started happening long after I switched to Windows 7. And the fonts do still display correctly on Chrome, but I usually use Firefox. I guess I'll just switch over to Chrome whenever I want to edit Burmese. —Aɴɢʀ (talk) 18:24, 22 September 2014 (UTC)

Probably related: Oriya script is not showing up. - -sche (discuss) 14:55, 27 September 2014 (UTC)

I don't know Oriya, but in that particular case it looks like diacritics might have been added in the wrong order. —Aɴɢʀ (talk) 15:41, 27 September 2014 (UTC)

{{vi-hantutab}} fails to process character 𢞅 at 𠊛𢞅 and nothing is displayed. Pinging @Wyang. --Anatoli T. ^{(обсудить}/^вклад) 02:29, 22 September 2014 (UTC)

@Wyang I see 𠊛𢞅 {{vi-hantutab}} have been removed. Are etymologies for người and yêu incorrect? If it's chữ Nôm, can the characters be still shown for etymologies, even if they are native Vietnamese, if they are correct? What about the entry 𠊛𢞅? --Anatoli T. ^{(обсудить}/^вклад) 02:53, 22 September 2014 (UTC)

{{vi-etym-sino}} and {{vi-hantutab}} are only for Hán (Sino-Vietnamese) words. The word is not of Sino-Vietnamese origin, which is why I removed the {{vi-etym-sino}} template from người yêu. As far as I know, no multisyllabic Nôm words are included. If they are to be included, special templates have to be created, and citations would be compulsory. Wyang (talk) 23:35, 22 September 2014 (UTC)

Thanks. I agree that we need other templates for native Vietnamese or Nôm characters. Would you say 𠊛𢞅 should be deleted? It doesn't seem citable. --Anatoli T. ^{(обсудить}/^вклад) 23:43, 22 September 2014 (UTC)

I would say delete, since it is uncited. A major problem with including Nôm words is that the currently digitised Nôm texts are most unsearchable. Available digitised historical texts online I know of include

1. Nôm: the Tale of Kiều and two other texts (Chinh Phụ Ngâm Khúc and Lục Vân Tiên) by the Nom foundation,
2. Hán/Nôm: Dự án số hóa kho tàng thư tịch cổ văn hiến Hán-Nôm
3. Hán/Nôm: National Library of Vietnam

Of these, only the first is searchable. I found one citation of người yêu in the 1871 version of the Tale of Kiều: Người yêu ta xấu với người (𠊛腰些醜貝𠊛). Wyang (talk) 00:06, 23 September 2014 (UTC)

Thanks. I have deleted 𠊛𢞅 (before your last post) but it would be a pity if there ARE nôm texts but they are just not searchable. Please check the entry nôm, which has the sense "Sino-Vietnamese", which seems wrong. --Anatoli T. ^{(обсудить}/^вклад) 00:22, 23 September 2014 (UTC)

I have a problem with certain words from the above reference being misread (by the template software?). It usually happens when two vowels are next to each other as in the case of beboer. In this case 'oe' is being read as 'ø', and the word is therefore not being recognised by the dictionary. It can also happen with 'aa', which is read as 'å'. In fact any Bokmål words containing the characters å, æ and ø are converted to 'aa' 'ae' and 'oe' respectively by the template software, but the dictionary usually copes with that. I think the same may happen with Nynorsk. Can a cure be found for this problem? Donnanz (talk) 12:18, 24 September 2014 (UTC)

It looks like the site itself is doing the conversion, prompted by the parameter "&alfabet=o". Is there a reason you include that? Chuck Entz (talk) 12:40, 24 September 2014 (UTC)

Hmm, not necessarily. If I go directly to the dictionary website and type in "beboer" it is read as "beboer" by the dictionary. I think the problem is at this end. Donnanz (talk) 12:47, 24 September 2014 (UTC)

A further test. You get the message "Vi har dessverre ingen informasjon om ordet "bebør" ...", but if you click on the Bokmål button the word comes up. A wee bit weird. Donnanz (talk) 12:57, 24 September 2014 (UTC)

If you look at the URL generated by the template, it has "oe": "http://www.nob-ordbok.uio.no/perl/ordbok.cgi?OPP=beboer&bokmaal=+&ordbok=bokmaal&alfabet=o". If you take out the "&alfabet=o", you get "http://www.nob-ordbok.uio.no/perl/ordbok.cgi?OPP=beboer&bokmaal=+&ordbok=bokmaal", which works. I suspect the "&alfabet=o" is for the purpose of accommodating those who can't easily produce the special characters on their keyboards. Chuck Entz (talk) 13:18, 24 September 2014 (UTC)

I think it's fixed now. The short story of the problem was that the dictionary site used to have a tricky character encoding (that doesn't seem to be the case any longer; though this change would not have had any effect on the template the way it was designed). --Njardarlogar (talk) 14:18, 24 September 2014 (UTC)

Ah, wonderful! Thanks very much! Donnanz (talk) 15:43, 24 September 2014 (UTC)

See this BP comment. As I understand it the user did not see anything that gave him a sufficient hint that there were quotations for the definitions at the entry looked at. I found nothing at all remarkable in the formatting of the entry or its appearance on my screen. I put up some questions in case the user follows up on his posting. If the questions are completely irrelevant or misleading please strike them through. DCDuring TALK 18:20, 25 September 2014 (UTC)

Possibly due to the changes which were made to Template:head/Module:headword a while ago (mentioned e.g. here), which expanded the set of 'probably multi-part' items which the template automatically linked the presumed parts of, terms like mo·s now erroneously link to "mo" and "s" — the mid-dot in fact indicates vowel length in Menominee and several other languages. Terms like al·legoria are also erroneously split. How should this be fixed? I would suggest that the template/module be modified to treat a mid-dot as an indication of a morpheme break only for certain listed languages that use it for that purpose, or vice versa (to not treat it as a morpheme break only for certain listed languages that use mid-dots for other purposes) based on whichever list would be shorter. - -sche (discuss) 04:09, 29 September 2014 (UTC)

I think the first way would be shorter. I don't know of any language other than Old Irish that uses the raised dot at a morpheme break, and even for Old Irish we only use the raised dot as part of the head= display, not in entry titles. And even if Old Irish did use the raised dot for entry titles, and we had entries like do·beir instead of dobeir, I still wouldn't want the headword line to display that as do·beir. —Aɴɢʀ (talk) 14:15, 29 September 2014 (UTC)

OK, I've excluded mid-dots entirely, since even in the one language that uses mid-dots as morpheme breaks they shouldn't cause breaks in the linking. - -sche (discuss) 15:36, 7 October 2014 (UTC)

Hi,

How do you change the lettering? Thanks. — This comment was unsigned.

That depends what you're trying to do. You can make text italic by putting it inside double apostrophes ''like this'' and you can make it bold by putting inside triple apostrophes. —Aɴɢʀ (talk) 14:09, 29 September 2014 (UTC)

And you can change the font, and font size, using CSS. MediaWiki:Common.css sets the default fonts for various things, you can use your Special:MyPage/common.css to set different fonts for yourself. - -sche (discuss) 18:00, 29 September 2014 (UTC)

This was posted on w:WP:VPT#Many_deprecated_JavaScript_methods_will_be_removed_from_MediaWiki_next_week. I just checked and didn't find anything on this site that used any of the functions that are being removed, so it looks like we're in the clear. - -sche (discuss) 18:09, 29 September 2014 (UTC)

Just a heads up to let you know that a bug filed by Conrad Irwin back in 2009, Please add ISO code interwikis for non-standard language codes has now been (at least partially) resolved. This means that the following ISO language code interwikis now function correctly:

• vro:, pointing to fiu-vro: (although there is currently no Wiktionary edition in this language)
• cmn:, pointing to zh:
• lzh:, pointing to zh-classical: (although there is currently no Wiktionary edition in this language)
• yue:, pointing to zh-yue:
• rup:, pointing to roa-rup:
• gsw:, pointing to als: (although there is currently no Wiktionary edition in this language)
• be-tarask:, pointing to be-x-old: (although there is currently no Wiktionary edition in this language)
• sgs:, pointing to bat-smg: (although there is currently no Wiktionary edition in this language)
• egl:, pointing to eml: (although there is currently no Wiktionary edition in this language)

Hopefully this reduces the amount of special casing that is required in places like Module:wikimedia languages/data.

For some yet-to-be-determined reason, a few ISO standard prefixes (such as nb: and nan:) are still not functioning correctly. I'm going to continue to look into this. This, that and the other (talk) 01:47, 30 September 2014 (UTC)

If someone removes these from the modules, remember that the linking is two-way. The data entries for the main languages also need to be edited. —CodeCat 02:00, 30 September 2014 (UTC)

It was agreed in BP that yue: can point to zh:. The Cantonese Wiktionary doesn't exist. If any doubt, I'll search for the discussion (it was the same page where it was suggested to point nn: to no:). --Anatoli T. ^{(обсудить}/^вклад) 02:32, 30 September 2014 (UTC)

Also, I suggest be-tarask: to point to be:. Taraškevica spellings are older or alternative forms of Belarusian, e.g. сьнег (older form, Taraškevica) = снег, etc. And as was said above, be-x-old: doesn't exist. --Anatoli T. ^{(обсудить}/^вклад) 02:37, 30 September 2014 (UTC)