Wiktionary:Grease pit/2014/January

There are some transclusions of templates which do not exist in that template. I am not sure what should be done with it. Keφr 17:15, 1 January 2014 (UTC)[reply]

My guess is that those subtemplates instituted some features which the designer never got around to implementing. In any case, it doesn't seem like anything uses the parameters (4-9) which are called there, so there shouldn't be any problems in removing that section, so I have done so. I'll leave a note on Dixtosa's page, and see if they have any further comments. -Atelaes λάλει ἐμοί 07:08, 2 January 2014 (UTC)[reply]

I was wondering if I could possibly get a dump analysis on all uses of the template {{grc-cite}}. Specifically, I'm looking for a list of all parameters used (including numbered ones), as well as all used values for the parameter "form". I am sorry that I haven't yet learned how to do this for myself. Thanks very much. -Atelaes λάλει ἐμοί 05:04, 2 January 2014 (UTC)[reply]

Ok- User:DTLHS/grc-cite (json)- does this format work for you? The format is parameter -> parameter value -> count of parameter value. Let me know if you want more specific information like page titles. DTLHS (talk) 06:12, 2 January 2014 (UTC)[reply]

Wow. I'm really sorry, but I don't know how to access the information you've encoded into that page. In fact, I am at a complete and utter loss how you could have clearly encoded something into that page, without me being able to see it in the editing window. I'm really, really sorry, but the whole thing is just beyond me. Should I be using some sort of URL querying? If so, could I possibly have an example? -Atelaes λάλει ἐμοί 06:42, 2 January 2014 (UTC)[reply]

Yeah, that didn't work... fixed now. DTLHS (talk) 06:50, 2 January 2014 (UTC)[reply]

Ok, that's a little more legible. I'm really sorry, but that has everything I could possibly want to know......except for what I actually need right now. If I'm understanding it right, and it's quite possible that I'm not, it is a list of every value that has been used for any parameter within {{grc-cite}}, and how many times it's been used. But I don't actually need the values, with one exception I only need the keys, so that I can ensure that they're all being passed when I make grc-cite into a soft redirect to {{Q}}, as I've done with {{grc-test}}. Additionally, I also need all the values that have been passed to the key "form". I'm sorry to be such an ingrate. -Atelaes λάλει ἐμοί 06:58, 2 January 2014 (UTC)[reply]

Ok: the unnamed parameters are 1, 2, 3, 4, 5, 6, the named parameters are form, quote, notes, tr, trans, through, year, transauthor, transyear, thru, refdis, and the values for form are inline, work and ref. DTLHS (talk) 07:11, 2 January 2014 (UTC)[reply]

Awesome. That is exactly what I needed. Would it be pushing my luck to ask what entries make use of 6 and refdis? In any case, thank you so much for your help with this. I really appreciate it. -Atelaes λάλει ἐμοί 07:19, 2 January 2014 (UTC)[reply]

κράτος, ὠνέομαι DTLHS (talk) 07:30, 2 January 2014 (UTC)[reply]

Perfect. Thanks again. -Atelaes λάλει ἐμοί 07:48, 2 January 2014 (UTC)[reply]

This category currently contains something like 75% of all Welsh noun entries. All of the ones I've spot checked, however, do not lack gender info at all; they have it labeled quite correctly using {{cy-noun}}. Is there something wrong with {{cy-noun}} making nouns get sorted into this category incorrectly? —Aɴɢʀ (talk) 14:09, 3 January 2014 (UTC)[reply]

I may have fixed it, the template was checking if g= was not specified, but allowed either g= or 1= for the gender, so all the ones using 1= and not g= were in the category. Server will probably need an hour to catch up, then recheck it. Mglovesfun (talk) 14:21, 3 January 2014 (UTC)[reply]

There's also Category:Welsh terms with incomplete gender which is added by generic templates like {{head}} (which {{cy-noun}} uses). —CodeCat 14:30, 3 January 2014 (UTC)[reply]

Yes cy-noun has both categories. Mglovesfun (talk) 14:33, 3 January 2014 (UTC)[reply]

I think it takes longer than that for template-based categories to be fully updated. Are module-based categories more quickly updated? DCDuring TALK 17:07, 3 January 2014 (UTC)[reply]

Not sure, but if you were in a hurry you could get a bot to make null edits on the all pages in the category. DTLHS (talk) 17:11, 3 January 2014 (UTC)[reply]

I think that's overkill for most uses. I'm not bot-literate either.

Also, as I understand it, category updating is a task that is queued. AFAICT, The Queue is not FIFO. Isn't it first-in, random out? If so, then if it does not get to zero from time to time, there is no certainty that any given task will get performed. DCDuring TALK 17:46, 3 January 2014 (UTC)[reply]

@DCDuring it depends how widely used the template is. For some templates it's done in microseconds. Mglovesfun (talk) 19:19, 3 January 2014 (UTC)[reply]

(For the benefit of non-techies: Mglovesfun is exaggerating. Even just saving the template change must take tens or hundreds of milliseconds, let alone updating all the pages that transclude it. —Ruakh_TALK 22:52, 3 January 2014 (UTC))[reply]

To clarify what I am talking about: I am NOT talking about what appears when one downloads a page that directly transcludes the template. I have never experienced a delay that even reached minutes between saving a template with a change and seeing the consequence of that change in a page that transcludes it directly.

NOR am I talking about entries that directly transclude templates that transclude other templates or modules, though I am curious about that.

I AM talking about category listings. If the categorization of an entry depend on the operation of a transcluded template that must evaluate something, I don't think that anything other than edits of the entry will guarantee that the template will perform the evaluation and update the category listing. I think that the category will eventually be updated, but the updating seems to be a queued process and the queue is apparently not FIFO, but FIRO, ie, queued jobs are performed at random. Thus, as long as the queue is not at zero, there is no guarantee that any specific job that has been entered into the queue since the last time the queue was empty will have been performed.

Doing nul edits is just a form of queue jumping, perfectly valid when testing to make sure a change has the correct result, but probably impolite when done by bots, though there may be valid reasons to overlook the impoliteness, or gaps in my simple understanding of how jobs get handled in the queue. Does anyone here know how the queue works in more detail? DCDuring TALK 23:26, 3 January 2014 (UTC)[reply]

I don't think that even the developers know how the queue works. It's just one of those mysteries. But the queue's documentation, does confirm that it is FIRO and that there is currently nothing other than probability preventing entries from sitting in it forever. --WikiTiki89 23:34, 3 January 2014 (UTC)[reply]

I wonder if certain people could be given the right to flush the whole queue out in larger pieces. It would take some time and put a lot of load on the server, but I think that's better than a site that just doesn't work. —CodeCat 02:28, 4 January 2014 (UTC)[reply]

An en-verb entry with missing inflections (e.g. disperple) no longer shows the -ing form as a green link for auto-creation. Instead, it is a normal red link with a mysterious green dotted underline. The -s and -ed forms still work as before. Equinox ◑ 17:10, 3 January 2014 (UTC)[reply]

Fixed. The dotted green underline means an error occurred while trying to accelerate the link, to distinguish it from a regular red link that just isn't accelerated. —CodeCat 18:52, 3 January 2014 (UTC)[reply]

Going back to the ACCEL topic...there's a bug (or maybe not). When ACCEL-creating Asturian nouns using the WT:ACCEL function in Template:ast-noun, the green-link plurals create pages categorized as "Asturian noun forms". I guess it should be changed to "Asturian plurals" instead. How can I change it? --Back on the list (talk) 16:59, 4 January 2014 (UTC)[reply]

• Hmm, assuming we're taking the same approach for Asturian as for Spanish, which is wise, apparently we don't categorise Spanish plurals, after User:CodeCat deleted that category. Which one is preferred, Category:Asturian plurals or Category:Asturian noun forms? --Back on the list (talk) 17:03, 4 January 2014 (UTC)[reply]
  • I prefer "noun forms" because "plurals" is ambiguous. There are different types of plural in Asturian, for nouns and for adjectives. —CodeCat 17:23, 4 January 2014 (UTC)[reply]

With the advent of Lua, isn't it possible now to enhance {{der-top}} and its friends in Category:Column templates so that they would automatically divide the list into columns of equal length? The number of columns can be set by a parameter or the template could automatically determine it based on the length of the words. Currently I have to count the number of words, then divide it by three; or I just heap them into one kilometer-long list as here.

A possible additional feature is automatic alphabetization. --Vahag (talk) 22:41, 4 January 2014 (UTC)[reply]

I wonder whether automatic splitting to columns could today be achieved using CSS. {{ws beginlist}} uses some CSS that works in Firefox ("column-count:3;-moz-column-count:3;-webkit-column-count:3"), but I wonder whether there is now a similar thing working in IE. --Dan Polansky (talk) 22:50, 4 January 2014 (UTC)[reply]

Believing web search, "column-count:3" works in IE10 but not earlier. --Dan Polansky (talk) 22:53, 4 January 2014 (UTC)[reply]

{{ws beginlist}} works nicely. Now someone needs to make it collapsible. --Vahag (talk) 23:28, 4 January 2014 (UTC)[reply]

(after edit conflict) It's possible but there are certain things that could stump it, such as invisible text such as categories or categorizing templates. As for alphabetization, it would only alphabetize the output, while we want the source text to be alphabetized as well. It could however put unalphabetized pages in a cleanup category that a bot could then check. --WikiTiki89 22:52, 4 January 2014 (UTC)[reply]

What categories or categorizing templates? Shouldn't between {{der-top}} and {{der-bottom}} be only terms inside the {{l}} template and nothing else? --Vahag (talk) 23:26, 4 January 2014 (UTC)[reply]

I was thinking more generally. For example, in translation tables there are often cleanup templates inserted by User:KassadBot. --WikiTiki89 23:35, 4 January 2014 (UTC)[reply]

I've created Module:columns. Right now it splits up anything given in the first parameter by newline. You can specify the background color, title, whether or not it is collapsible, class, and whether or not to sort. For example:

{{:User:DTLHS/Template:test|collapse=1|sort=1|title=test|columns=2| [[z]] [[y]] [[x]] [[w]] [[v]] [[u]] [[t]] [[s]] [[r]]}}

It could still use some tweaking (the column widths mainly), and there are some edge cases I wasn't sure about (what's the best way to split 9 items between 4 columns?) DTLHS (talk) 00:49, 5 January 2014 (UTC)[reply]

Nice work, DTLHS, as usual! The column widths are very narrow when there are 3 or more columns. For 9 items between 4 columns I would use 3 + 3 + 3 + 0, so that the user will notice and choose 3 columns instead. Alternatively, 3 + 2 + 2 + 2. --Vahag (talk) 11:48, 5 January 2014 (UTC)[reply]

I'm not really happy with how this is done, but I don't know if there's a better way. Ideally, you'd specify a fixed column width (or derive it from the length of the text), and the browser would decide how many columns can fit on the screen. This isn't something you can really do in a module because different people have different screen widths. On my screen (1920 pixels wide), three columns still leave a lot of empty space between. JavaScript might be a better solution, because it knows how wide the browser window is. Or is there a way to do this in CSS? —CodeCat 14:41, 5 January 2014 (UTC)[reply]

CSS, works in modern browsers. I think this is acceptable for use now, because older browsers will merely display this as a single column and no harm is done.

minimum column width of 10 em:

Five columns. The browser applies logic to keep the columns balanced. In Safari, at least, nine items are restricted to three columns here.

References: MDN, Can I Use. —Michael Z. 2014-01-05 17:40 z

Is it possible to say that there should be a minimum of, say, 4 items per column? —CodeCat 17:54, 5 January 2014 (UTC)[reply]

I don’t think so. —Michael Z. 2014-01-05 21:53 z

CSS currently doesn't work with nested list. It separates the sub-bullets from their parents:

Is there a work-around for this? --WikiTiki89 17:54, 5 January 2014 (UTC)[reply]

It works as expected, because lines normally wrap within and after list items. I don’t know if there is a way to change this.

Where is it likely to be an issue? Can Module:columns create sublists? —Michael Z. 2014-01-05 21:50 z

Module:columns does not create sublists. Sublists are found in, for example, ====Descendants==== sections, and even in ====Translations==== sections. I know it works "as expected". But the "as expected" is not what we want. Currently, with manually columnization, we control where to break the columns and ensure that this doesn't happen. --WikiTiki89 23:48, 5 January 2014 (UTC)[reply]

We've had this conversation before, no? If someone has a CSS solution that will actually work in most browsers feel free to implement it. DTLHS (talk) 19:28, 5 January 2014 (UTC)[reply]

I don’t recall a conversation. This does work in most or all browsers, just not outdated ones. It is also degrades gracefully, meaning it renders the page perfectly acceptably in all browsers. And it is still better than a JavaScript solution that fails unpredictably, or a fixed-column layout that gives no benefit in most browsers because it is too wide on small screens and too narrow on big ones. —Michael Z. 2014-01-05 21:47 z

Try li { column-break-inside: avoid; page-break-inside: avoid; break-inside: avoid; } and the various browser-prefixed variants (-webkit-, -o-, -moz-). Keφr 18:09, 7 January 2014 (UTC)[reply]

I don't understand what's the problem with DTLHS's proposal. Can I create and use a template for listing derived terms utilizing the capabilities of Module:columns? --Vahag (talk) 12:11, 18 January 2014 (UTC)[reply]

Still needs work (I will work on it). Unless someone wants to actually implement a CSS solution. DTLHS (talk) 20:25, 18 January 2014 (UTC)[reply]

Should be more stable now- takes items from the template parameters rather than newlines. Feel free to use it. DTLHS (talk) 01:58, 19 January 2014 (UTC)[reply]

Am I correct that breaking up by columns is not automatic now and I need to insert | where I want a column break? --Vahag (talk) 12:13, 19 January 2014 (UTC)[reply]

No. For example {{:User:DTLHS/Template:test|z|y|x|w|v|u|t|s|q|r|sort=1|collapse=1|columns=3}} DTLHS (talk) 19:26, 19 January 2014 (UTC)[reply]

I am stupid. What code in {{der3}} would call {{columns}} with the following default parameters |sort=1|collapse=1|columns=3|title=Derived terms? --Vahag (talk) 20:24, 19 January 2014 (UTC)[reply]

"{{borrowing|LL.|lang=en}} {{term|lang=la|confluentia}}" gives, as desired, "Borrowing from Late Latin confluentia", whereas "{{borrowing|LL.|lang=en|confluentia}}" gives "Borrowing from Late Latin Script error". This makes sense, no doubt — LL. is not valid in {{term}} either, I guess. But is there a way around it? Some module that maps LL. to la (and likewise for similar cases) for the purposes of {{borrowing}} (and probably other templates)?​—msh210℠ (talk) 06:43, 5 January 2014 (UTC)[reply]

Module:etymology language/data gives each code there a "parent". If it uses the parent for all things except {{etyl}}, then it could be done, I think. —CodeCat 14:38, 5 January 2014 (UTC)[reply]

(A similar case is xno mapping to fro.) Ƿidsiþ 14:40, 5 January 2014 (UTC)[reply]

It's fixed. See confluence. —CodeCat 14:49, 5 January 2014 (UTC)[reply]

Many thanks.​—msh210℠ (talk) 20:49, 5 January 2014 (UTC)[reply]

In many modules (such as Module:columns) there is a lot of hardcoded HTML manipulation- would it be better to have a module to build HTML instead? DTLHS (talk) 21:42, 5 January 2014 (UTC)[reply]

Maybe not a bad idea, if it makes it easier and not harder to understand.

Anyway, styles should just be removed to the style sheet MediaWiki:Common.css, and invoked using classes. That should reduce complexity of the HTML to be generated, reduce the overall page weight, improve accessibility by avoiding inline styles, centralize CSS editing, and actually make use of the cascade for simpler and more powerful CSS. —Michael Z. 2014-01-05 23:02 z

What has prevented removing the styles to the stylesheet MediaWiki:Common.css and invoking the styles using classes? Are votes needed? Is no one willing to do it? DCDuring TALK 23:18, 5 January 2014 (UTC)[reply]

1. Does it have anything to do with the stylesheet being 42K, 32 pages printed?
2. Does it have anything to do with not knowing which of the styles is in active use?

Just asking. DCDuring TALK 23:25, 5 January 2014 (UTC)[reply]

Nothing has prevented it. Just offering advice, and am glad to help. I do this occasionally with other templates. But the rate at which obsolete HTML attributes and inline CSS get produced in many dozens of templates is much greater than that at which I can update and consolidate it. There is much potential for reused code, but little work in that direction.

The inflection tables could all be styled with a few CSS declarations in total, for example. I have the beginnings of a framework out there somewhere.

Yes, the style sheet is largish, but better to load and cache these styles once than have them potentially repeated scores of times in each page. Yes, the lack of documentation is a problem, and perhaps some of those styles are unused. The only way it’s going to work is to have self-documenting CSS with comments in the style sheet, because separate docs will always be out of sync (all comments and unnecessary whitespace get stripped out before the style sheet is served). I wonder if there is any benefit to be gained in modularizing the style sheet by splitting it up. —Michael Z. 2014-01-06 20:16 z

You mean, something like w:Module:HtmlBuilder? It will be built into MediaWiki soon as mw.html (gerrit:101874). Keφr 20:20, 6 January 2014 (UTC)[reply]

About ten minutes ago the quotations simply disappeared, not just on my pages like 永続的 but on others like disappear. I've tried restarting, using another browser, and using my mobile in desktop mode. Each time, the "quotations" link is just gone. Quotations still appear on the mobile view at least. Haplogy (話) 00:34, 6 January 2014 (UTC)[reply]

Translation tables are also broken. DTLHS (talk) 00:35, 6 January 2014 (UTC)[reply]

They're broken on my end too. Haplogy (話) 00:37, 6 January 2014 (UTC)[reply]

Seems that all collapsables are broken. It's probably a JavaScript error, but no one has edited MediaWiki:Common.js recently. It could be a gadget. --WikiTiki89 00:40, 6 January 2014 (UTC)[reply]

It looks like it's the Vector scripts, which means it might well be MediaWiki-wide. I imagine someone important will notice it shortly. -Atelaes λάλει ἐμοί 00:46, 6 January 2014 (UTC)[reply]

Seems to work now. No idea what that was about. --Yair rand (talk) 01:03, 6 January 2014 (UTC)[reply]

I thought these were designed so that they will be open if the Javascript fails to load or run. Did something more complicated happen? We should never depend on Javascript for any text to be readable. —Michael Z. 2014-01-08 02:29 z

The specific error was "Uncaught ReferenceError: sajax_init_object is not defined" (on [1]) DTLHS (talk) 04:53, 8 January 2014 (UTC)[reply]

The JS encountered an error after the content was hidden but before the toggle could be set up. If the JS broke or failed to load before the original hiding, or if it broke after the toggle was created, the content would be accessible. --Yair rand (talk) 06:02, 8 January 2014 (UTC)[reply]

I don’t know if this makes sense, but can the toggle be set up first? Can the table hider check that the toggle exists first? —Michael Z. 2014-01-29 16:40 z

The cleanest solution (but probably the most infeasible) is to reinvent the web, replacing JavaScript with something better. --WikiTiki89 16:43, 29 January 2014 (UTC)[reply]

Can someone try and convert Korean PoS templates, e.g. {{ko-verb}}? --Anatoli ^{(обсудить}/^вклад) 04:23, 7 January 2014 (UTC)[reply]

I've gone head and written a skeleton headword module for Korean at Module:ko-headword, but still needs a lot of work before it will be complete. To everyone, please help out if you can. Haplogy (話) 07:25, 7 January 2014 (UTC)[reply]

What in the world just happened to the Wiktionary layout? The typography suddenly changed and the pages now only take up half of the width of my screen. --WikiTiki89 19:10, 7 January 2014 (UTC)[reply]

This only applies with typography refresh enabled (which I had for a while). The typography suddenly increased in size and text of the pages now takes up a constant width of 700 pixels (which is way too narrow). --WikiTiki89 19:25, 7 January 2014 (UTC)[reply]

Did you accidentally hit CTRL+mouse wheel? TeleComNasSprVen (talk) 20:54, 7 January 2014 (UTC)[reply]

No, it's apparently a new feature of the Typography Refresh Beta (see mw:Talk:Typography refresh#The new constant width pages). It was bad but tolerable, now it's intolerable. It's a bad sign if a feature is confused with a bug. --WikiTiki89 22:24, 7 January 2014 (UTC)[reply]

What was bad about it? —Michael Z. 2014-01-13 16:42 z

The typography. --WikiTiki89 19:24, 13 January 2014 (UTC)[reply]

The translation and declension tables look especially bad with the fixed 715px width, which is too narrow. --Vahag (talk) 14:06, 9 January 2014 (UTC)[reply]

That would be a problem with the tables, since it has always been possible for display to be constrained in that way. Readers may resize their browser window on the desktop, or they may have a narrow display on the desktop or mobile that doesn’t allow a wider window at all. The tables should be designed to work in any browser window, not just yours. —Michael Z. 2014-01-13 16:42 z

That's quite a stretch. People have different expectations on different devices. Someone using a smartphone with a two-inch-wide screen will want a website to be two inches wide, and laid out accordingly. Someone using a laptop will not want that, and will immediately leave any site that's so broken as to look like it's on a smartphone. —Ruakh_TALK 18:03, 13 January 2014 (UTC)[reply]

I am not suggesting tables should be fixed to either a 320px screen or a 4K display. And also, not everyone is using the Typography Refresh, nor even Monobook, nor even wiktionary.org to read our entries. The tables shouldn’t be designed so they look good on a particular display size at the expense of others.

Of course this depends on exactly what looks bad about them on Vahag’s display. I would be happy to try to improve the situation. —Michael Z. 2014-01-17 21:10 z

I have disabled tabbed languages to free up space on the left. Still, the conjugation table for օգտագործել (ōgtagorcel) is so narrow that a horizontal scroll bar appears. I like the narrow style for reading paragraphs of text, but not for tables. --Vahag (talk) 21:29, 17 January 2014 (UTC)[reply]

Okay, that is clearly bad, since a reader can’t even scan over a table. Better to scroll the browser window horizontally on small screens, than scroll a div on every screen. A possible fix is .NavFrame { overflow-x: visible; }. —Michael Z. 2014-01-19 17:44 z

Where should that code be inserted? --Vahag (talk) 20:00, 19 January 2014 (UTC)[reply]

Ironic because 'broken' is a past participle. Please fix. TeleComNasSprVen (talk) 05:23, 9 January 2014 (UTC)[reply]

You need to give a bit more information than that. —CodeCat 13:04, 9 January 2014 (UTC)[reply]

Maybe https://en.wiktionary.org/wiki/Wiktionary:Grease_pit#Changes_to_WT:ACCEL above? Hard to tell without more information. --AKlapper (WMF) (talk) 13:44, 9 January 2014 (UTC)[reply]

See break the ice and take exception. And I have a feeling it is connected to that thread above. TeleComNasSprVen (talk) 16:23, 9 January 2014 (UTC)[reply]

Ah, I see it has been fixed. TeleComNasSprVen (talk) 16:25, 9 January 2014 (UTC)[reply]

The following German verbs have conjugation tables that use "a" as the fifth parameter of {{de-conj-weak}}. According to the template's documentation this optional parameter takes the value of "t" only. I am in the process of modifying SemperBlottoBot to create the inflected forms of German verbs, and don't know what to do with these. SemperBlotto (talk) 16:24, 11 January 2014 (UTC)[reply]

• ablösen, befassen, bekränzen, benützen, bepflanzen, bepissen, beschützen, bumsen, erfassen, foppen, freisetzen, mehren, siezen and verletzen

It looks like the template is only checking for existence of the parameter without checking what it contains, so "a" is the same as "t", but is easier to find on the keyboard, Chuck Entz (talk) 16:46, 11 January 2014 (UTC)[reply]

OK, thanks. I'll change them all to use "t" anyway. SemperBlotto (talk) 17:46, 11 January 2014 (UTC)[reply]

I think the common practice is to use "1" if all that matters is that it's not empty. —CodeCat 18:31, 11 January 2014 (UTC)[reply]

I apologize if this has already been covered somewhere, but is it possible for a Lua module to read and write data somewhere? So, for example, could Module:Quotations note any works and authors that it doesn't have in its data set, and then collate that info in a centralized location? Thanks. -Atelaes λάλει ἐμοί 23:02, 11 January 2014 (UTC)[reply]

The only thing a Lua module can do is show wikicode. So if it's not possible to get the same result by writing it manually on a page, then I don't think you can do it. The best you can do is add a page to a category, but that means that someone has to monitor that category and you can't create categories randomly (because they are nonexistent pages like any other red link). You can work around it though. It's possible to transclude a page and then not use it in the module. It will count as a transclusion and show up in "what links here" for that page. If you know what name to look for, you can use the transclusions of that page to see how many are using it. —CodeCat 00:05, 12 January 2014 (UTC)[reply]

One halfway work-around would be to have the module provide a link that could be clicked on to enter the text in the appropriate place, perhaps preloading the text so you would only have to click the link and save the resulting edit. Chuck Entz (talk) 00:46, 12 January 2014 (UTC)[reply]

One way to do solve the problem at hand is with categories. Lua can add pages to cleanup categories. For example adding to a hidden category such as Category:Unknown Ancient Greek quotation data. --WikiTiki89 03:10, 12 January 2014 (UTC)[reply]

Can an administrator change the link for the context label "formal" to point to Appendix:Glossary#formal, rather than our entry at formal? I believe it gives more information, and it's quite unintuitive to have the context formal "informal" point to the glossary, and not have the same consistency for "formal". TeleComNasSprVen (talk) 08:26, 12 January 2014 (UTC)[reply]

• Good call,  done. —Ruakh_TALK 08:42, 12 January 2014 (UTC)[reply]

Could someone make a list (as a subpage of WT:Todo) of all pages where the template {{wikipedia}} appears before the first language header? —CodeCat 20:19, 13 January 2014 (UTC)[reply]

• Wiktionary:Todo/Template:wikipedia in section 0 (warning: large!) Keφr 21:03, 13 January 2014 (UTC)[reply]

According to Wikipedia's article on the topic, Serbo-Croatian's isocode sh has been deprecated in favor of hbs so I was wondering if we should follow suit here and replace clear-cut instances where sh marks Serbo-Croatian with hbs. TeleComNasSprVen (talk) 20:34, 13 January 2014 (UTC)[reply]

No, because we are not bound to ISO decisions. -- Liliana • 21:18, 13 January 2014 (UTC)[reply]

Oh I just found out about Wiktionary:Languages and I didn't see the section on language codes at first, and it just happens to mention Serbo-Croatian as an exception to the ISO rules. However, I still don't think it gives clear enough instructions on what we are supposed to do with the current ones, it merely defines how the ISO codes are currently represented on Wiktionary. Since you seem to favor leaving it alone, I think a note expressing that sentiment on the Wiktionary:Languages should be left near the section on Serbo-Croatian. TeleComNasSprVen (talk) 21:57, 13 January 2014 (UTC)[reply]

"it merely defines how the ISO codes are currently represented": Yeah, I wrote much of what you see on that page, and did so more to document Wiktionary's practices than to prescribe (though I was correct in my estimation that documenting the practices would make them easier to follow). - -sche (discuss) 18:15, 14 January 2014 (UTC)[reply]

• Support. —Ruakh_TALK 03:47, 14 January 2014 (UTC)[reply]
• Oppose. No reason to complicate things. --WikiTiki89 03:55, 14 January 2014 (UTC)[reply]

• Are you saying that hbs is more complicated than sh? How can that be? —Ruakh_TALK 05:04, 14 January 2014 (UTC)[reply]

Two reasons: It has three letters instead of two for a major language, and it makes less sense since "sh" stands for "srpskohrvatski" while "hbs" doesn't clearly stand for anything (I suppose it might be "hrvatski, bosanski, srpski", but that is not a name of the language). --WikiTiki89 05:13, 14 January 2014 (UTC)[reply]

• Using ISO codes is preferable to using codes of our own devising, and accordingly we have dropped exceptional codes like "aus-syd" when ISO codes like "xdk" came into existence. But "sh" is not a code of our own devising, it is an ISO code; the ISO has come to deprecate it, but (descriptively) we do use deprecated ISO codes in various circumstances — e.g. when the ISO retires a code for a language to split it into codes for dialects, but we decide to continue to treat the language as a single entity (and that is indeed what happened here). I do not think typing three letters is so much better than typing two letters (...it fact, it seems very slightly worse) that it merits the great bother of updating every Serbo-Croatian entry, translation, etc and relearning what code to use to refer to the language. - -sche (discuss) 18:15, 14 January 2014 (UTC)[reply]
  • Do we have the technical ability to have code "redirects"? That way, if someone does expect our code for Serbo-Croatian to be hbs and creates an entry whose headword line says {{head|hbs|noun}}, it will be treated exactly the same as if it said {{head|sh|noun}} until a bot comes along to clean it up. Back when we used templates for codes it would have been easy enough, but I don't know how easy it is in Lua. —Aɴɢʀ (talk) 20:24, 14 January 2014 (UTC)[reply]
    • Our templates never actually supported redirects, and that was always a problem because people thought they did. I remember at one point we ended up with some topical categories prefixed with eng: for English because of that. After that, we decided that every language should have one unique code, to avoid problems with our templates. Our modules still make this assumption, but I think it would actually be possible to add redirects to Module:languages. With some changes we could make it so if you do getLanguageByCode("sh"), then that function could perform the "redirect" and actually give you the language information for "hbs". And that would work perfectly as long as all of our code uses lang:getCode() to retrieve the code of the given language, and never uses the provided code directly, anywhere. But this would only work for modules... we still have many templates and they wouldn't be able to use those codes. Topical categories would still be a problem. —CodeCat 21:05, 14 January 2014 (UTC)[reply]

      My personal preference is for sh over hbs, as hbs is designated as a macrolanguage, and we treat Serbo-Croatian as a language, as well as the fact that it'd just be a huge pain in the ass (and would almost certainly become a clusterfuck; those who have been on this project for a while will remember the nightmare that our original decision was). However, whatever we decide, I support CodeCat's suggestion of making as many code tweaks as possible such that modules accept the alternate code and treat it as the primary code. -Atelaes λάλει ἐμοί 08:26, 15 January 2014 (UTC)[reply]

We should use standard codes whenever possible. I’d rather give up backwards-compatibility with 3.6M entries created over 12 years, in favour of compatibility with the next thousand years of Wiktionary development and the rest of the Internet.

Of course, with the understanding that someone smarter and harder-working than I has the coding chops and bots to implement the change. —Michael Z. 2014-01-17 21:02 z

I've been reading about this some more, and there are some interesting points. One archived email discussion at the IETF (the body that regulates HTML language codes) seemed to conclude that "sh", deprecated or not, was the only valid code that could be used for Serbo-Croatian in HTML. The language code rules for HTML state that the shortest code should always be used; 3 letter codes that have a 2-letter equivalent should not be used. ISO has explicitly defined "hbs" as equivalent to "sh", so language tags can't use "hbs" as it has a 2-letter equivalent. It was also noted that deprecated codes will always remain valid, their use is only discouraged, not forbidden and will never be forbidden. Once valid, always valid, I think someone said. Search this page for "Serbo-Croatian" for the discussion. —CodeCat 21:33, 17 January 2014 (UTC)[reply]

Confirming this, the language subtag registry lists only "sh" and not "hbs", and for our own purposes that list should be definitive, and not the ISO lists. So ISO can say what they like but we have to follow the subtag registry, which tells us to use "sh". —CodeCat 21:36, 17 January 2014 (UTC)[reply]

A couple things: 1) That's fine but what if someone wants to put in 'hbs' as the language code, as noted above? We'd need to have some way to redirect it to 'sh' in our coding and HTML. 2) What if IANA decides to change up the language subtag registry? Not that they'd be likely to, of course. TeleComNasSprVen (talk) 21:54, 17 January 2014 (UTC)[reply]

1) We don't have to do anything; we just treat it as invalid, like we already do with any code we don't recognise. —CodeCat 22:01, 17 January 2014 (UTC)[reply]

Genau. (=Exactly. / I agree.) - -sche (discuss) 22:02, 17 January 2014 (UTC)[reply]

I didn’t realize it was ISO and not IETF that changed the code. Do you think it’s likely that they will continue to differ?

For HTML, a valid language attribute does mean according to BCP 47. But we are currently using invalid language tags. So how about we convert those to private-use tags? —Michael Z. 2014-01-18 00:48 z

We did discuss that a while ago... can you find the discussion? —CodeCat 01:06, 18 January 2014 (UTC)[reply]

There was Wiktionary:Beer_parlour/2013/February#Changing "exceptional" language codes to comply with the HTML specification. I have also harped on it every chance I get. —Michael Z. 2014-01-18 01:59 z

I think it would be good to start a new discussion about this, as it's going somewhat off topic and we can expect this to attract a lot of reactions in itself. —CodeCat 02:26, 18 January 2014 (UTC)[reply]

I registered wikt.org a long time ago with the intent of using it for hosting some Wiktionary tools on my home server, and possibly as a shortcut URL for Wiktionary. My home server went to the great server room in the sky a while ago and my registration for this domain expires in the middle of February 2014. If anyone can use the domain for the above purposes, I can transfer it to you. You'll probably want to change registrars, as I use register.com which is quite expensive for a hobby domain. Send me an email via Wiki if you are interested. --Versageek 22:11, 13 January 2014 (UTC)[reply]

Template:grc-decl-2nd-pax and presumably other Ancient Greek inflection templates seem to link to the diacritical forms of words; γενεαλόγος, for example, links to γενεᾱλόγοι and not γενεαλόγοι. In other words, the templates don't use the diacritic-removal that Module:languages affords them the option of. (and/or) For some reason, γενεᾱλόγοι (geneālógoi) links to γενεᾱλόγοι, despite diff. I'm not sure whether both of these are issues or only one of them. - -sche (discuss) 02:25, 14 January 2014 (UTC)[reply]

That template uses {{grc-cell}}, and that just "makes" its own link. So it's never given to Lua. Your diff changed how sort keys are generated, but for diacritic removal in entry names, you want the entry_name property instead. —CodeCat 02:38, 14 January 2014 (UTC)[reply]

Re first part: so should it be changed to 'pass through' Lua? Re second part: aha, thanks! - -sche (discuss) 02:51, 14 January 2014 (UTC)[reply]

Ok, done. —CodeCat 03:15, 14 January 2014 (UTC)[reply]

When I typed "sales" into the search box and hit "enter" or press "Go" I did not get [[sales]], I got [[salés]]. I don't know how general a problem this is, but I am sure that it will put us even farther behind other dictionary sites for English monolingual users if widespread and not corrected. DCDuring TALK 14:05, 14 January 2014 (UTC)[reply]

It works right for me. —Aɴɢʀ (talk) 14:34, 14 January 2014 (UTC)[reply]

That has been happening to me for a long time now. Must be one of the Beta Features. --Vahag (talk) 14:38, 14 January 2014 (UTC)[reply]

Thanks, Vahag. It is indeed the Beta search. Disabling it solves the problem and I added my complaint to the discussion thread for the Beta search. Others might also want to weigh in there, but Kephir and Wikitiki had previously done so. DCDuring TALK 15:33, 14 January 2014 (UTC)[reply]

Already noticed: mw:Thread:Talk:Search/"WTF" search results, bugzilla:59841. Keφr 16:02, 14 January 2014 (UTC)[reply]

A couple of years ago, someone generated a cleanup page to find all entries which had erroneous Level-3 headings. Could that be regenerated, to track down any pages like [[бзэджай]], which shows "Ajdective". --Back on the list (talk) 12:36, 15 January 2014 (UTC)[reply]

See Category:Entries with non-standard headers. DCDuring TALK 23:18, 15 January 2014 (UTC)[reply]

...although not all entries with bad headers are in that category (e.g., the entry BOTL links to is not in that category). - -sche (discuss) 00:41, 16 January 2014 (UTC)[reply]

At least items are being added. I suspect that many items slipped through when AF or its successors was not working. I don't think they just review old entries. DCDuring TALK 02:59, 16 January 2014 (UTC)[reply]

• Thanks all --Back on the list (talk) 11:34, 16 January 2014 (UTC)[reply]

Apparently links that in N0 would show up as orange (due to missing section link [or missing L2 category ?]) do not show up if the link is from, say, a user subpage (User:DCDuring/orangetest), using Vector or Monobook, Win7, FF 26. Should that not be available from such pages? If it needs to be an extra gadget, can someone add same? Or what CSS or JS would enable me to achieve this for myself? DCDuring TALK 18:00, 15 January 2014 (UTC)[reply]

I don't think the page that the link is on should matter for whether it works or not. Then again, should it appear on every page, even discussion pages like this one? —CodeCat 18:09, 15 January 2014 (UTC)[reply]

It does appear on discussion pages like this one: test, and it should. The problem is that when the "section link" links to something like an RFD/RFV template or to a {{senseid}}, it turns orange even if the RFD/RFV template or {{senseid}} is there. --WikiTiki89 18:18, 15 January 2014 (UTC)[reply]

If you click on the test page User:DCDuring/orangetest, do you see orange in every link? DCDuring TALK 18:49, 15 January 2014 (UTC)[reply]

To be clear, I have no problems with seeing orange on this page. I've gotten used to seeing it in senseid-type linked headers. DCDuring TALK 19:05, 15 January 2014 (UTC)[reply]

I don't see any orange at all at User:DCDuring/orangetest. I do see orange on this page. --WikiTiki89 19:31, 15 January 2014 (UTC)[reply]

I've added User: to the list of namespaces it runs on. --Yair rand (talk) 19:59, 15 January 2014 (UTC)[reply]

Do you think you can fix the other bug I pointed out? Or is it not worth it? An example is: fin. --WikiTiki89 20:02, 15 January 2014 (UTC)[reply]

Thanks a lot, Yair. I've become dependent on it. It's very useful. A very good use of color. DCDuring TALK 22:14, 15 January 2014 (UTC)[reply]

Suddenly, this morning, I can't see conjugation tables (contents hidden) and I can't even see any hide/unhide buttons. Wiktionary:Per-browser preferences also shows up as having no content - just the Warning text and the "Save settings to refresh view." button. Who has done what? SemperBlotto (talk) 08:01, 16 January 2014 (UTC)[reply]

• And now everything is back to normal. Strange. SemperBlotto (talk) 08:21, 16 January 2014 (UTC)[reply]

Would it be possible to update Template:rft-sense so that the "+" button takes you to the window for adding a thread to the current month subpage, rather than to the window for adding a thread to the now-disused main Tea Room page? Please check if Template:rft needs to be updated too or not. Thanks, - -sche (discuss) 03:16, 17 January 2014 (UTC)[reply]

It's easy to do, but it doesn't really do what we may want it to do. The problem is that once a thread has been created, if we move on to the next month, anyone who clicks the link will be taken to the current month, not to the existing thread. —CodeCat 03:30, 17 January 2014 (UTC)[reply]

Why? "Discuss" can be a different link than "+", like so:

Discuss(+)

TeleComNasSprVen (talk) 03:48, 17 January 2014 (UTC)[reply]

From what I gathered at WT:ID, we don't actually need these codes to distinguish simplified and traditional characters. Our templates add Hans, Hant and Hani depending on what set of characters is being used, but if Hani already supports all the characters by default, we don't really need Hans and Hant anymore. We can just use the code Hani for all Chinese characters, and not worry about it. Would it be feasible to do this? —CodeCat 03:28, 17 January 2014 (UTC)[reply]

I think there were people who objected merging them, probably Liliana-60 (talk • contribs)? The reality is, most templates just use {{Hani}}, even there are really minor differences, IMO, in the way characters may look. I'd risk saying "it would make our life much easier" if we use {{Hani}}. There are also negative visual effects when identical traditional and simplified look different, they may appear slightly different in size or not aligned properly. I can't find good examples at the moment. --Anatoli ^{(обсудить}/^вклад) 03:46, 17 January 2014 (UTC)[reply]

There are typographical differences, eg. 黄 (Hans and Hant): 黄, 黄. Wyang (talk) 04:00, 17 January 2014 (UTC)[reply]

I see no difference there at all. —CodeCat 04:02, 17 January 2014 (UTC)[reply]

Hans has 由 but Hant has 田 in the middle. Wyang (talk) 04:06, 17 January 2014 (UTC)[reply]

(after EC) @Wyang Yes, that's right, they are not aligned properly. In this case, they are also different characters 黃／黄 (huáng) (trad.) and 黄 (huáng) (simpl.) (huáng) with a small difference, similar to 沒／没 and 没 (méi). using the same template, they are similar but different characters. --Anatoli ^{(обсудить}/^вклад) 04:07, 17 January 2014 (UTC)[reply]

I don't see any difference between the first two big characters that Wyang showed, but between the second two I do, and between the ones Anatoli gave. —CodeCat 04:09, 17 January 2014 (UTC)[reply]

Wyang used simplified character 黄, which was changed visually by {{Hant}}. The difference is a small connecting stroke between top and bottom, which is missing in the traditional character. --Anatoli ^{(обсудить}/^вклад) 04:12, 17 January 2014 (UTC)[reply]

That difference doesn't appear to me in 黄. It appears between 由 and 田 though. —CodeCat 04:15, 17 January 2014 (UTC)[reply]

Those are traditional-simplified characters. The example of 黃 (just the traditional one) or 黄 (just the simplified one, above) shows how the same character is rendered differently by different fonts. For both characters, some fonts show 由 while others show 田 in the middle. Both Taiwan and Hong Kong use traditional characters and use the same character, but the version with 田 (黃) is considered correct in Taiwan, whereas the version with 由 (黃) is considered correct in Hong Kong. Wyang (talk) 04:18, 17 January 2014 (UTC)[reply]

(after EC) @CodeCat Maybe your computer doesn't allow you to see the difference? Because, in fact, he used the same character but different templates. How about 黄, 黃, if I use different characters, simplified, then traditional? --Anatoli ^{(обсудить}/^вклад) 04:22, 17 January 2014 (UTC)[reply]

I do see the difference there. But... I'm not sure how all this relates to my original question? —CodeCat 04:23, 17 January 2014 (UTC)[reply]

@Wyang. Both Hong Kong and Taiwan have a bit of confusion regarding standardisations and which simplified characters, they are willing to accept. Like in the case of 台灣 and 臺灣. --Anatoli ^{(обсудить}/^вклад) 04:29, 17 January 2014 (UTC)[reply]

@CodeCat. Wyang has demonstrated that using fonts one can change the displayed characters, which probably didn't work on your system. Here's this potential risk of merging. It's a matter of deciding how critical this difference is. Some other characters do look differently, even if they use the same code. Let me try: 平, 平 ([removed {{big}}]).--Anatoli ^{(обсудить}/^вклад) 04:29, 17 January 2014 (UTC)[reply]

It didn't work on my system this time. I've seen traditional 平 has the side strokes turned the reverse way. --Anatoli ^{(обсудить}/^вклад) 04:31, 17 January 2014 (UTC)[reply]

Can you please stop putting these huge characters everywhere? It's making the rest of the text unreadable because it overlaps all the other text. —CodeCat 04:40, 17 January 2014 (UTC)[reply]

OK. It's not easy to show very small differences, like between 黄 and 黃. It's common to show them big when discussing their looks. --Anatoli ^{(обсудить}/^вклад) 04:44, 17 January 2014 (UTC)[reply]

Maybe typographic variants could be indicated under ==Variants== ? Speaking of which, how come we do not have an entry or variant for the English letter a in handwritten form? That one is like ɑ, written in one or two strokes with a round center and a vertical stroke on the right hand side. TeleComNasSprVen (talk) 04:56, 17 January 2014 (UTC)[reply]

Single and double-storeyed a aren’t different letters in English. The distinction is stylistic, not lexical, and so doesn’t warrant a separate dictionary entry any more than italic a, or a set in Helvetica bold.

That said, entries for letters could well have images that demonstrate their typical appearance in manuscript and type, and common variations in their glyph design, and native variations like roman, italic, and blackletter for Latins, orthotic, cursive, and chancery for Greeks.

The Unicode character ɑ (U+0251, Latin small letter alpha) is a special symbol for IPA, and not exactly equivalent to the English letter a. —Michael Z. 2014-01-17 20:21 z

Chinese characters belong to simplified/traditional (or both), also Category:CJKV characters simplified differently in Japan and China, Japanese specific, like 畑, also some specific to Korean and Vietnamese. --Anatoli ^{(обсудить}/^вклад) 05:41, 17 January 2014 (UTC)[reply]

My favorite example for demonstrating this is 次, which looks totally different simplified and traditional. Observe: 次, 次. (See the picture on the right if the characters don't display.) This is why we can't merge the two templates. -- Liliana • 16:16, 17 January 2014 (UTC)[reply]

I see them both the same. And if I see them both the same, there are others that see them both the same too. That means that we can't rely on that distinction. —CodeCat 16:22, 17 January 2014 (UTC)[reply]

That means you need to install fonts. I mean, Gothic characters display as squares for most people, is that a reason for banning Gothic? -- Liliana • 16:27, 17 January 2014 (UTC)[reply]

You're really saying that we should make a distinction in our content that can only be expressed by using two different fonts to show the same Unicode character. I think that's bad practice. —CodeCat 16:35, 17 January 2014 (UTC)[reply]

In the case of Han ideographs, it is inevitable, by virtue of the Han unification that Unicode caused. Our alternative would be reverting to the old pre-Unicode character sets (gb2312, big5) - but that is neither feasible nor possible with how MediaWiki is currently set up. -- Liliana • 16:38, 17 January 2014 (UTC)[reply]

Our current situation is also not feasible. Script detection doesn't work here, so we'd have to put sc= everywhere, and that's just not possible. I think the only workable solution is to concede that the graphical difference between two different fonts does not merit all the extra complexity of having three script codes for three mostly overlapping sets of characters. The presence of fonts should only matter in whether characters are displayed, not in how, and definitely not as the only way to make a graphical distinction that has no semantic distinction in Unicode. —CodeCat 16:42, 17 January 2014 (UTC)[reply]

Why is it not possible? We've been doing it all the time before script detection even existed. In fact, these templates are most commonly used in custom inflection templates which embed them automatically anyway, and Chinese has a special version of {{t}} I think which takes care of that problem as well. So only in very rare cases would you actually need to specify sc= directly. -- Liliana • 16:50, 17 January 2014 (UTC)[reply]

I'm still not convinced that we need to use three different fonts to display simplified, traditional and shared characters. This makes things look messy and inconsistent. Both simplified and traditional text can be formatted in both ways; either as Hans/Hant or as Hani. If we're going to keep the font usage consistent (which I assume is part of the point of having different fonts in the first place), we would have to eliminate the Hani code instead and use only Hans and Hant. Or we can use only Hani. Mixing them up looks bad. —CodeCat 17:01, 17 January 2014 (UTC)[reply]

Well, there's no such thing as "neutral Han", it's either traditional or simplified (or shinjitai in some cases). But if we don't have {{Hani}}, what would we use in Han ideograph entries for the translingual entry? -- Liliana • 17:05, 17 January 2014 (UTC)[reply]

If there is really an important graphical distinction between simplified and traditional like you say, then there should be two things (entries, headword lines, or something else) on those pages: one to show the traditional, one to show the simplified graphical variety of the character. —CodeCat 17:08, 17 January 2014 (UTC)[reply]

Ok, so I believe there's a consensus not to merge these fonts, which was the question for this thread, even though the situation as it is currently displays an inelegant solution to the problem of variants. Is this correct, what I'm reading this? TeleComNasSprVen (talk) 16:42, 17 January 2014 (UTC)[reply]

The discussion is still going and you call it a consensus? That's premature. —CodeCat 16:45, 17 January 2014 (UTC)[reply]

Indeed, I have highlighted some minor risks but in my opinion, we should merge but only when language is Chinese, unknown or translingual. --Anatoli ^{(обсудить}/^вклад) 21:48, 17 January 2014 (UTC)[reply]

This is just another example of Unicode being an oppressive monopoly. --WikiTiki89 17:50, 17 January 2014 (UTC)[reply]

You mean “universal standard”? —Michael Z. 2014-01-17 20:49 z

I support using Hani in most cases, where there is ambiguity or with any Chinese variety, translingual, simplified, traditional, shared. Japanese, Korean have their own fonts. When the language can't be detected, use Hani. --Anatoli ^{(обсудить}/^вклад) 21:42, 17 January 2014 (UTC)[reply]

There always (should) be a language code available when showing text, so our modules and templates would always know when they are dealing with Chinese (and which dialect), Japanese or Korean text. Japanese and Korean should never use Hani, Hans or Hant, because they already have their own Jpan and Kore codes. On the other hand, they have no way of knowing when they are dealing with simplified or traditional Chinese, so templates have to resort to Hani unless we tell them that something is Hans or Hant. If we remove Hani, then that would mean that either: 1) our templates have to choose Hans or Hant by default (which is not an improvement over defaulting to Hani), or 2) sc= becomes mandatory for all Chinese languages, which isn't really a workable solution at all and would require updating thousands and thousands of entries. Option 2) would also mean that we stop recognising "shared" characters; Chinese would have to be either Hans or Hant, because there's no Hani anymore for shared cases. That would then mean we would have to duplicate things, to show them as both Hans and Hant. All in all, this doesn't seem very enticing. I think if we have to choose between having 1, 2 or 3 script codes, 1 is definitely best, 2 is worst, 3 (current situation) isn't great either. —CodeCat 21:52, 17 January 2014 (UTC)[reply]

Well, that's what I said too but we have Translingual sections, which are basically Chinese (all dialects) definitions of characters and as I said, if a script detection is used anywhere in Wiktionary on Chinese characters (which may also be Japanese, Korean or Vietnamese - CJKV) and no language is specified, then it should default to Hani. That's what I meant if it wasn't clear.

I saw Wyang's post on my iPad and 黄 looked identically, despite different templates used (Hans and Hant) but 黄 and 黃 always look different because they are. Liliana's example is interesting but it's too common to use the same encoding on both simplified and traditional Chinese and Unicode doesn't know which one is which. Translations and AFAIK Mandarin (and other Chinese) entries already use just Hani, so let's stick with it. --Anatoli ^{(обсудить}/^вклад) 00:38, 20 January 2014 (UTC)[reply]

Hi, I'm trying to fix some problems in various arabic "root" articles. There is a problem with the {{l}} template.

The first two rows works correctly. The first one correctly show the arabic word with diacritics but links to the article without them. The second generate an arabic type-I verb with diacritics. But if I try to combine both It doesn't work. The display is fine, but it should link to جمع but it links to جَمَعَ& with a extra & in the name.

I really don't understand this behavior. --Haitike (talk) 11:53, 17 January 2014 (UTC)[reply]

The string returned by Template:ar-verb-fa3ala contains HTML entities, which would cause problems when passed to Module:links. We should use mw.text.decode somewhere in our modules. --Z 12:16, 17 January 2014 (UTC)[reply]

The problem is that it affects the verb links in all the Category:Arabic_roots articles. Should I fix it replacing the "l" template with simple brackets (for example: [[{{ar-verb-fa3ala|ج|م|ع|a}}|{{ar-verb-fa3ala|ج|م|ع|a|shakl=yes}}]] )? Or there are a more elegant solution? --Haitike (talk) 13:21, 17 January 2014 (UTC)[reply]

Z, do you know why this causes problems? I'm not seeing it... —CodeCat 13:27, 17 January 2014 (UTC)[reply]

HTML entities in plain links in wikitext of pages are decoded by the software, but in modules, when the input (the second parameter of Template:l) contains an HTML character reference, like abcd{, the string before # (i.e., abcd&) will be treated as the title of target page and everything after # (i.e., 123;) will be considered as title of a section. --Z 14:11, 17 January 2014 (UTC)[reply]

I see... then I think we should decode the HTML entities before we do any processing on the string. But where would that be in Module:links? I'm thinking it should be in language_link, but full_link does script detection which is also a kind of string processing. Script detection on a HTML entity might accidentally decide that it's Latn text because HTML entities can contain letters. —CodeCat 14:24, 17 January 2014 (UTC)[reply]

I tried to do some tests, now I see part of what I said above about decoding HTML character references in modules is wrong. Anyway, problems like this must be solved if we decode text in Module:links#language_link, Module:utilities#detect_script, and also Module:script_utilities#transliterate. But note that this change itself may cause problems in cases that we have intentionally used HTML entities, for example, for * in *nix. --Z 14:40, 17 January 2014 (UTC)[reply]

I'm not able to access the "Ladino" tab. When I click it, it goes to "Ladin" instead. All the other tabs work. —CodeCat 21:38, 19 January 2014 (UTC)[reply]

I don't know if it makes any difference, but they were in the wrong order, with "Ladino" before "Ladin". Chuck Entz (talk) 23:25, 19 January 2014 (UTC)[reply]

Yes, that fixed it. I wonder why that causes a problem though. It shouldn't be too hard for the script to account for out-of-order sections. —CodeCat 23:27, 19 January 2014 (UTC)[reply]

Something like this would be highly desirable. It would be feasible in principle because as far as I know, each character always transliterates the same way, there are no exceptions. The problem of course is the sheer number of characters. But if we already have large data modules to handle languages and such, then I don't think there's a problem with writing a data module to store pairs of Chinese characters with their transliterations. Then again, it's quite possible that I'm underestimating how many characters there are, and maybe this is doomed from the outset, but I think there is a lot we can gain by trying, at least. —CodeCat 02:32, 20 January 2014 (UTC)[reply]

It already exists at Module:zh. Incidentally, there are characters that have multiple readings, so this is impossible to do without some manual transliterations. —Μετάknowledge^{discuss/deeds} 02:37, 20 January 2014 (UTC)[reply]

There ARE exceptions but not as common as say, in Japanese, it's about 2-5% of total characters, not sure about the number. Notably 行 (xíng, háng, héng), 樂／乐/乐 (yuè, lè)

Neutral tone characters have also original tones. Suffix 子 (zǐ) in 孩子 (háizi) (háizi) has a value "zi"

兒／儿/儿 (ér) as an erhua suffix is simply "-r" (no syllable). Wyang (talk • contribs) has a few templates automatically generating transliteration in pinyin but a manual fix is often require on such characters. --Anatoli ^{(обсудить}/^вклад) 02:50, 20 January 2014 (UTC)[reply]

Note, these suffixes are very productive, so are the characters, which are 多音字 (duōyīnzì) (characters with two or more readings), like 行 or 樂／乐/乐. All neutral tone characters have other tones as well. --Anatoli ^{(обсудить}/^вклад) 02:52, 20 January 2014 (UTC)[reply]

A related discussion with various lists on my favourite Chinese-forums.com - [2] --Anatoli ^{(обсудить}/^вклад) 03:02, 20 January 2014 (UTC)[reply]

Module:zh is pretty messy right now, mixing functions for Mandarin with functions for all Chinese characters. I'm a bit disappointed though because I thought this would be easier to do. But if there are exceptions, then it kind of defeats the purpose. —CodeCat 03:09, 20 January 2014 (UTC)[reply]

{{cmn-new}} through Module:zh does a very good job of finding the pinyin readings, IPA and simplified/traditional pairs but it needs manual interventions for all of these - pinyin readings, IPA and simplified/traditional pairs. Programs with automatic transliteration of Mandarin Chinese are quite common and it's much easier to transliterate Mandarin than Arabic, Hebrew or Persian but they are only 95%+ right, if they don't check words semantically, which is easier for humans (but humans struggle to learn all these characters). --Anatoli ^{(обсудить}/^вклад) 03:58, 20 January 2014 (UTC)[reply]

Ok, but imagine what would happen if we switched the transliteration "on". Then all entries with {{head}}, {{l}}, {{term}} and such that don't already have a transliteration will now have one generated for them by default, even if the default is wrong. I'm not sure how to prevent that from happening. We were able to do it with Russian because the difference was only minor then (e instead of ɛ isn't a huge issue), but for Mandarin it will be very different. And how is it for other Chinese-script languages like Cantonese, Korean, Japanese or Vietnamese? —CodeCat 04:29, 20 January 2014 (UTC)[reply]

It could be turned on if editors keep an eye on it and mark exceptions the way Russian exceptions are in Category:Russian terms with irregular pronunciations and Japanese are in Category:Japanese words with nonphonetic spellings (theoretically speaking, it would take some efforts). Note that by convention, traditional/simplified translations we only transliterate simplified, e.g. in university#Translations: 大學／大学 (zh) (dàxué), 大学 (zh) (dàxué). So, the traditional may get a wrong transliteration if turned on on translations. Ideally, Mandarin words should be categorised by characters, like Japanese currently is (e.g. Category:Japanese terms spelled with 台), then it would be easier to mark potential problems like characters containing 行, 乐, 子, etc. The potential damage should be assessed properly and number of possible exceptions counted. All terms containing "多音字" should be grouped together, then it would be easier to address the problem. All depends WHAT needs to be transliterated. The Japanese automatic transliteration is used selectively on hiragana and katakana and works very well. It doesn't need to be transliterated by kanji, if hiragana is present see {{ja-usex}}.

Japanese is only OK to be transliterated with hiragana/katakana, not kanji (Chinese characters), which is mostly unpredictable. As I said, there is Category:Japanese words with nonphonetic spellings. Korean should be transliterated by hangeul, not hanja (Chinese characters). There is a module that does it, again Wyang (talk • contribs) and Haplology (talk • contribs). See Module:ko-translit, which is 95% done but is already used. Vietnamese Hán tự should not be transliterated either. The situation with Cantonese, Min Nan, etc. is similar to Mandarin but worse, since we have no modules that handle them but reading are given in character entries. --Anatoli ^{(обсудить}/^вклад) 04:50, 20 January 2014 (UTC)[reply]

All of the members of Category:Japanese words with nonphonetic spellings are in there because it contains は or へ which was originally a separate particle but merged into a single word. (That is except を, but I don't think it belongs there.) For example konnichi wa is a shortened form of a typical greeting like konnichi wa ii tenki desu ne ("Fine weather today, isn't it?"). That's why it's romanized as konnichi wa on 今日は. If you indicate that the character は or へ is a particle, then automatic transliteration works correctly. So in fact all of those terms can be automatically transliterated. You also need to know where morpheme boundaries fall in a small proportion of cases. As long as the editor marks up the kana to provide that information, automatic transliteration of kana works every time. Haplogy (話) 05:08, 20 January 2014 (UTC)[reply]

Yes, thanks. The automatic transliteration didn't work quite well on つうじょう, could you have a look? Anyway, I was just explaining to CodeCat that we should transliterate kana (i.e. hiragana and katakana), not kanji (Chinese characters) for Japanese, which are almost unpredictable from the technical point of view. "Marking" particles は or へ as particles is just putting a space in front of them, which achieves two purposes - particles are separated by space in rōmaji and they are transliterated as "wa" and "e", instead of "ha" and "he" (all spaces are removed in the display, as Japanese doesn't use word spaces). If the automatic transliteration can handle variants of "おう" (ō vs ou) then it's working almost perfectly. --05:18, 20 January 2014 (UTC)

つうじょう fixed. Wrong PoS was used - for verbs final う is by default not combinable with transliteration of previous letter. Wyang (talk) 07:22, 20 January 2014 (UTC)[reply]

Thanks, I must have been blind:) . What do you think of categorising Chinese entries by Hanzi? The way the Japanese entries are done, possibly adding categories for characters with multiple readings? If {{zh-hanzi}} and {{Hani-forms}} worked similar to {{ja-kanjitab}}, it would be possible. Only the number of categories would be large but it would easier to find Mandarin (specifically, by language) words using a specific character. --Anatoli ^{(обсудить}/^вклад) 11:59, 20 January 2014 (UTC)[reply]

There is a massive discrepancy in the translations offered/available at all for different words with identical meanings. It is proposed that in order to make the burden of translation easier (and hence good, consistent translations more available), a new feature should be built and implemented permitting specific meanings of different words to be linked together as "full synonyms", where there is no difference in how those words would be applied in relation to effecting that meaning. This would allow translations to be automatically linked and shared across multiple Wiktionary pages (perhaps even definitions could be shared). Here are some examples:

1. Alternative spellings. The most obvious examples of where this feature would be useful is where words have alternative accepted spellings. For example where British & Irish spellings differ from American, as with: yoghurt/yogurt, colour/color. Or where archaic spellings differ from modern: warriour/warrior. Or other instances where a word has two spellings: ay/aye, spelt/spelled, dreamt/dreamed (in this last of cases, even the pronunciation is different). In all these cases the benefit of a common set of translations is unequivocal.

2. Words with exactly the same meaning. For example: thus, therefore, ergo. Again, the case here is fairly unequivocal: however a usage policy/guideline should be put in place instructing people not to mark as fully synonymous words with the same literal meaning but different connotations or vastly different registers or normal usage contexts where it is possible those differences might give rise to different translations - for example: "thou", "ye", "you" (limiting our focus to the singular, indicative sense of those words); or informal and formal second person pronouns in some languages: "tú"(es) should be translated to "du"(de), but "usted"(es) shouldn't be translated to "du"(de), even though both "tú" and "usted" are exclusively singular second-person pronouns and hence have identical literal meaning in all cases, because the first is informal/familiar (as is "du"), but the latter is formal (which "du" is not).

Further technical/connotational issues may arise in the case of equating formal second-person pronouns between French, German and Spanish due to the different methods they use for distancing/depersonalising the person/people being formally addressed: in French one addresses them in the plural (vous), in Spanish one addresses them in the third-person (usted/ustedes), in German one addresses them in the plural AND the third-person (Sie) - so there may be a different "flavour" to those words, even though their actual usage may be exactly the same: something that must be taken into consideration especially when designating words (or specific senses of words) of different languages as "full synonyms".

3. Die/dice. The words "die" and "dice" have become confused to the point that it is now acceptable to use either word as singular or plural. However in other languages the singular and plural will be separated. So we need to make sure that the singular sense of both words is linked to one set of translations, and the plural sense to another. Alternatively, both words could be linked to a set of two sets of translations. Whether in cases where two words have exactly the same set of distinctly different meanings, the words as a whole should be designated as full synonyms or just the meanings individually would need to be decided.

4. Words with multiple meanings, where only a specific meaning of each word is fully synonymous. For example: "gazunder/chamber pot", where only the noun meaning of "gazunder" should be marked as synonymous with "chamber pot", and not the quite separate verb meaning; or more subtly, "hence/ergo", where the propositional relative pronoun sense of "hence" should be marked synonymous, but not the spatial relative pronoun sense.

Conclusion: I think this feature, in conjunction with a sensible and cautious usage policy, could go some way towards making comprehensive and consistent translations more available on Wiktionary.

P.S.

Perhaps this policy could go further: perhaps there could be a cross-lingual implementation so that for example if two English words were marked as fully synonymous on the English Wiktionary, and those same two words had entries in the French Wiktionary, then the entries on the French Wiktionary would automatically be marked as fully synonymous and would share translations. Or the same English word could share a common set of translations across its entries in multiple different language Wiktionaries: although cross-lingual features would be much harder to implement owing to the fact that different language wikis are run by distinct communities.

Please understand that operationally we do not use a definition of synonym that means "exact". As to points one and two: We have a template {{trans-see}} that is intended to direct users and translators to terms that are most commonly used rather than less common alternative forms and rare, obsolete, or archaic synonyms. Your fourth point suggests that it might be useful for your purposes to mark certain senses of words with multiple definitions ('polysemic') with {{senseid}}. It would be particularly useful to focus such efforts on members of the class of English terms that are both polysemic and used as synonyms. This would be a list that could be derived from the latest XML dump.

As to point 3, you might try testing your thoughts on that pair of entries. DCDuring TALK 14:44, 20 January 2014 (UTC)[reply]

I'm getting an error in Module:am-translit, which I modelled on other modules that worked OK: "Lua error: bad argument #1 to 'gsub' (string expected, got table)". Please have a look. --Anatoli ^{(обсудить}/^вклад) 04:50, 21 January 2014 (UTC)[reply]

I think I fixed it. Try it. --WikiTiki89 04:55, 21 January 2014 (UTC)[reply]

Thank you for trying (I'm sure your fix is also important) but the problem was with single quotes instead of double. Fixed now, see test on Module talk:am-translit. -- Anatoli ^{(обсудить}/^вклад) 04:58, 21 January 2014 (UTC)[reply]

The module is now moved to Module:Ethi-translit as it works for a few languages using Ethiopic script. It's a syllabary script, it might use a different allignment but it's working! --Anatoli ^{(обсудить}/^вклад) 05:04, 21 January 2014 (UTC)[reply]

I haven't checked, but please make sure it covers all the characters used in every Ethi language (they can all be found, with respective transliterations, at WT:Ethiopic transliteration). —Μετάknowledge^{discuss/deeds} 05:13, 21 January 2014 (UTC)[reply]

Actually, it was my change that fixed it. You can verify this clicking edit on the old versions and previewing. The single-quotes and double-quotes don't make a difference in this particular case. --WikiTiki89 05:24, 21 January 2014 (UTC)[reply]

I used the same table from Wikipedia (it has the same shape). I think the module covers all symbols in WT:Ethiopic transliteration.

@Wiki, thanks. I saw your edit but the talk page was still producing the same error after your edit. I didn't have problem compiling. Can you test in the preview? --Anatoli ^{(обсудить}/^вклад) 05:28, 21 January 2014 (UTC)[reply]

There's a preview button for testing modules and templates at the bottom where it says "Preview page with this template". And the error was probably still there because you didn't null edit the talk page. --WikiTiki89 05:38, 21 January 2014 (UTC)[reply]

I wonder how Module:Geor-translit works, it uses the same export function but the characters have " ", not ' '. --Anatoli ^{(обсудить}/^вклад) 05:51, 21 January 2014 (UTC)[reply]

The quotes are the same thing in this case. Module:Geor-translit works because it is not invoked directly. If it is, it produces an error: {{#invoke:Geor-translit|tr|ქართული ენა}}, because of the same bug. --WikiTiki89 05:58, 21 January 2014 (UTC)[reply]

Okey, I admit my mistake. Does that mean one of these modules and other modules need to change to work both with templates and directly? --Anatoli ^{(обсудить}/^вклад) 10:27, 21 January 2014 (UTC)[reply]

Actually, now with the {{xlit}} template, this fix is unnecessary. If you use {{xlit|ka|ქართული ენა}} rather than calling the module directly, there will be no error. --WikiTiki89 16:00, 21 January 2014 (UTC)[reply]

Would anyone like to have a go at one or two PoS templates, for Amharic or Tigrinya, to actually make use of the module, apart from {{l}}, {{t}} and {{term}}? --Anatoli ^{(обсудить}/^вклад) 21:52, 21 January 2014 (UTC)[reply]

The ordinary {{head}} template already makes use of the translit module. Creating designated headword modules should only be done by someone who is going to work with the language and knows what should be included in it. --WikiTiki89 22:25, 21 January 2014 (UTC)[reply]

• {{am-noun}} and {{ti-noun}} already exist and should be converted to use the module. —Μετάknowledge^{discuss/deeds} 05:27, 22 January 2014 (UTC)[reply]

  Problem: Amharic has gemination which is not indicated in the orthography. Therefore the translit module won't be able to transliterate gemination the way we currently do. This does not seem to be a problem with Tigrinya, since I looked at a dozens of entries and none had any gemination in the transliteration. --WikiTiki89 07:25, 22 January 2014 (UTC)[reply]

Languages with exceptions are always a problem. That's why perhaps, Amharic transliteration shouldn't be mandatory and should allow exception like Russian and Japanese. In Japanese the exceptions are few and consistent with PoS, so the problem is solved by separating particles は and へ with spaces and verbs ending in o-row + う, were transliterated with "ou", all other instances as "ō". With Russian it's only possible for consistent adjective endings - -его/-ого. --Anatoli ^{(обсудить}/^вклад) 12:53, 22 January 2014 (UTC)[reply]

It's not so much an exception as it is a rule. The majority of the random set of words I looked at had gemination. I think we should entirely disable the translit for Amharic. --WikiTiki89 17:46, 22 January 2014 (UTC)[reply]

I mean it's a common exception. Far from majority of words geminate and not showing gemination is also quite common in Amharic dictionaries. For the lack of native contributors it is a good temporary solution to provide transliteration of characters written (graphically), like we do with Cyrillic Mongolian, which is not 100% phonetic either but we don't have a reliable resource to accommodate exceptions. I'm not suggesting to remove existing transliteration for now if its standardised doesn't match automatic. I have added handling to remove word-final (inherent) "ə". See also Category:Amharic terms with geminations I have created today with a single example so far ቀዝቃዛ (ḳäzəḳazza). (The templates do handle automatic transliteration but but in this case I have given it a manual transliteration, as a possible example for more such entries). --Anatoli ^{(обсудить}/^вклад) 23:04, 22 January 2014 (UTC)[reply]

Language coverage: Amharic, Blin, Ge'ez, Oromo, Tigre and Tigrinya -am, byn, gez, om, tig and ti. I haven't added Oromo (om) anywhere, Blin (byn) needs script detection, as it also uses Latin. --Anatoli ^{(обсудить}/^вклад) 05:35, 21 January 2014 (UTC)[reply]

At -idae, for example, I cannot get the category loaded when I hit the arrowhead icon. It does load when I click on the category name. I can get the template to work properly at -ism.

Do others have the same problems with Translingual suffixes? DCDuring TALK 18:38, 21 January 2014 (UTC)[reply]

Never mind. I should have RTFMed. DCDuring TALK 18:40, 21 January 2014 (UTC)[reply]

User Marcel coenders has made over 100 000 (!!) Dutch word pronunciation files. Thanks to him, all Dutch words at nl.wiktionary now have an audio pronunciation file. You can find all files at Commons, here: commons:Category:Dutch pronunciation.

Request: Maybe a bot could go through all Dutch entries at en.wiktionary, and check if there's a pronunciation file for it at Commons. If so, the bot could add a link to the audio file; maybe like this: [3], [4], but I'm not too sure about the formatting details.

Thanks in advance! -- Curious (talk) 21:29, 21 January 2014 (UTC)[reply]

You might try contacting User:Derbeth. User:DerbethBot is a bot specifically tasked with adding audio pronunciation files. It hasn't run since October, but Derbeth might be persuaded to crank it up again if you ask nicely. Chuck Entz (talk) 04:03, 22 January 2014 (UTC)[reply]

I will try to find some time to make a short test run of the bot until the end of the week, let you check if results are correct and then I will run it for all entries. --Derbeth ^talk 07:45, 23 January 2014 (UTC)[reply]

Would it be possible for your bot to add a request tag of some sort to the entry if there is no IPA on it yet? —CodeCat 01:54, 24 January 2014 (UTC)[reply]

I'm not sure if this is a good idea. This would mean editing a majority of entries only to put an "IPA missing" template. Plus this is something completely new and I would prefer not to put a lot of time and effort for maintaining the bot code. --Derbeth ^talk 07:59, 25 January 2014 (UTC)[reply]

Please take a look at the latest bot edits. BTW, there is help needed in User:DerbethBot#Reports. --Derbeth ^talk 10:30, 26 January 2014 (UTC)[reply]

This module Module:PinyinBopo-convert needs to convert numbers in numbered pinyin to tone marks, so that e.g. "ni3 hao3" is converted to "ㄋㄧˇ ㄏㄠˇ". How do I force the conversion? The final purpose is to add Bopomofo transliteration to each Mandarin Chinese entry for the benefit of Taiwanese people or whoever prefers Zhuyin fuhao (注音符號) or just wants to learn another phonetic system to transcribe Chinese, if there is no performance problem. --Anatoli ^{(обсудить}/^вклад) 09:53, 23 January 2014 (UTC)[reply]

Would a conversion of '3' -> 'ˇ' do the job, if I understand you correctly? Wyang (talk) 11:25, 23 January 2014 (UTC)[reply]

Thank you. I have no idea, I haven't found anything appropriate in the reference. I will try your suggestion. --Anatoli ^{(обсудить}/^вклад) 20:07, 23 January 2014 (UTC)[reply]

It didn't work. Still need assistance. Please post if you think it's a bad idea to add bopomofo to Mandarin entries. Not sure if Bopomofo entries need to have their own entries. Note, I'm not suggesting we should, then they wouldn't be linked as in the examples below.

{{look}}

Example look and feel for 你好 (nǐ hǎo):

你好 (traditional and simplified, Pinyin nǐhǎo, Zhuyin ㄋㄧˇ ㄏㄠˇ)

Example look and feel for 再见 (zàijiàn):

再见 (traditional and simplified, Pinyin zàijiàn, traditional 再見／再见 (zàijiàn), simplified 再见, Zhuyin ㄗㄞˋ ㄐㄧㄢˋ)

Feedback on the idea in general would be appreciated.

--Anatoli ^{(обсудить}/^вклад) 01:25, 24 January 2014 (UTC)[reply]

I believe I've fixed it for you. You need to search for strings maximally instead of just using the any ('.') character. I couldn't get the tone numbers to work initially because in the 'tt' array, they were declared as strings (e.g., ["1"]), so I created another array for tone numbers only and declared them as ints (e.g., [1]). Then you just have to use two chained gsubs to get the desired effect. Seem to work now. I will introduce my test cases just to be sure. Jamesjiao → ^{T ◊ C} 02:50, 24 January 2014 (UTC)[reply]

Thank you, James! Something's gone wrong with Module:PinyinBopo-convert/testcases. See also Module:Bopo-convert, which should do the reverse conversion but it's not 100% working. Maybe it should be done by full syllables to make it easier? I think it's important to have this one working as well, so that people who don't know Zhuyin are able to see it converted back to Pinyin. --Anatoli ^{(обсудить}/^вклад) 03:14, 24 January 2014 (UTC)[reply]

Looks like WYang has done a much better job of it. Jamesjiao → ^{T ◊ C} 10:16, 24 January 2014 (UTC)[reply]

Thanks everyone for helping! Related discussions: Module talk:PinyinBopo-convert, Module talk:PinyinBopo-convert/testcases. Can someone please advice what erhua should like in Zhuyin. As erhua is avoided in Taiwan, it's harder to find examples. On Pleco wánr and dàir are ㄨㄢˊㄦ˙ and ㄉㄞˋㄦ˙ When testing is complete. {{cmn-pinyin}} should be edited to add Zhuyin, probably like this, see Zhōngguó:

Zhōngguó Zhuyin ㄓㄨㄥ ㄍㄨㄛˊ.

Is everyone OK with this? Then Mandarin headword templates could include a call Module:PinyinBopo-convert, one issue is also with the English word "or", which is separated multiple Pinyin, it should not be converted. --Anatoli ^{(обсудить}/^вклад) 11:58, 26 January 2014 (UTC)[reply]

How close is this? I've just arrived for a month in Taiwan and am very interested in exactly this. Can I already see it in action? Can I help? — hippietrail (talk) 08:40, 27 January 2014 (UTC)[reply]

It's almost ready. A few people have joined and helped already. Note that one won't need to add Zhuyin manually if the module and templates are working.

Outstanding things:

1. Sort out the correct conversion for erhua and any other issues in Module:PinyinBopo-convert/testcases
2. Templates to call Module:PinyinBopo-convert to convert delinked toned Pinyin to Zhuyin. I've made Template:Zhuyin but it's a bit raw.
3. Next step - make Template:cmn-pinyin display (Zhuyin + Zhuyin). It will affect all Category:Mandarin pinyin entries.
4. Add Zhuyin to Mandarin headwords.

Issue with erhua: Since erhua is very unpopular in Taiwan, we still need to convert them correctly but they may be back conversion problems. ㄦ is equivalent to a full syllable "ēr" (first tone without a tone mark. To convert Pinyin like wánr and dàir probably need to do ㄨㄢˊㄦ˙ and ㄉㄞˋㄦ˙. Converting them backward would give wáner (wán+er) and dàier (dài+er). I can't find a definite explanation of how to transliterate erhua using Zhuying but Pleco uses ㄦ˙ (with a neutral tone marker) to render the "-r" suffix. --Anatoli ^{(обсудить}/^вклад) 12:06, 27 January 2014 (UTC)[reply]

• I fully support adding on zhuyin. Though I don't use it myself, there's no reason why we shouldn't include it. Take a look at how the 國語辭典 handles erhuayin - [5]. ---> Tooironic (talk) 02:38, 28 January 2014 (UTC)[reply]

Good example - 一股腦兒／一股脑儿 (yìgǔnǎor), shows how erhua is displayed)! (but you can't copy it, just view)--Anatoli ^{(обсудить}/^вклад) 02:45, 28 January 2014 (UTC)[reply]

It's always a bit frustrating when acceleration doesn't work because there's already an entry there. If we have a script that can tell if a link has a section for the given language (and turns them orange), would it also be possible for WT:ACCEL to insert the new content into the existing page? —CodeCat 21:35, 23 January 2014 (UTC)[reply]

This would indeed be a great feature to have. - -sche (discuss) 20:38, 26 January 2014 (UTC)[reply]

There probably is a way, and it's probably not too difficult. I'm not very good with JavaScript, however. Also, while we're at it, we might as well make an "add language" button on each page that would make it easier to insert a new language section without editing the whole page. This may or may not be possible, but if it is, it would share a lot of functionality with WT:ACCEL working on orange links. --WikiTiki89 20:50, 26 January 2014 (UTC)[reply]

The last update to {{ko-categoryTOC}} was four and a half years ago, and in that time maybe the MW software learned how to sort hangeul. I know that at one time it could not and now it can, but I don't know when that feature was introduced. In any case, the first half of the characters, the jamo initials, do not work. The MW software does sort by those jamo, but clicking on those links does not bring you there. The second half does work, but brings you to jamo, so the link does not match where it brings you. For example, clicking ㅁ fails, but 마 brings you to Korean hanja from ㅁ. Haplogy (話) 00:57, 25 January 2014 (UTC)[reply]

This template for any single kanji allows you to give the old form (kyūjitai) of the kanji if it is a new form (shinjitai) kanji, and similarly the other way around, but the hyperlinks for those alternate forms don't work and state that the articles don't exist even though they clearly do. Is there a way for this to be fixed please? Thank you. Examples: http://en.wiktionary.org/wiki/%E9%9D%88#Kanji http://en.wiktionary.org/wiki/%E6%81%86#Kanji — This unsigned comment was added by 78.147.186.129 (talk).

Should be fixed now. Sorry about that. Haplogy (話) 12:23, 26 January 2014 (UTC)[reply]

I'm bringing this up again because it seems it has been forgotten: months ago the community reached consensus to orphan Template:m by replacing it with {{g}} in all entries, but this is not implemented yet and we're still using {{term}}. Would someone do this by bot? --Z 20:29, 26 January 2014 (UTC)[reply]

I will do it once I'm finished with Template:nl-noun. —CodeCat 20:37, 26 January 2014 (UTC)[reply]

I request to embark on this project. Confirmation: shall I replace all instance of {{m}} to {{g|m}}? --kc_kennylau (talk) 17:33, 28 January 2014 (UTC)[reply]

Have you finished "zhx-mid" yet? (I can see چت still using it (as an example))

I would like to do this myself. It's more than just bot-replacing entries because there are also many templates that use it. Those templates will need to be rewritten and adjusted to current "standards", and many of them will be edit protected. —CodeCat 18:38, 28 January 2014 (UTC)[reply]

Per WT:RFM#Template:ltc and WT:BP#Middle_Chinese, could someone replace all instances of the language code zhx-mid (an exceptional code for "Middle Chinese") with ltc (an ISO code for Late Middle Chinese which we have decided to use for all "Middle Chinese")? - -sche (discuss) 22:38, 26 January 2014 (UTC)[reply]

I could potentially do that, if you do not mind me being a new-comer. However, I am still working out how to use pywikipediabot package, as when I run login.py, it gives me a syntax error at line 172 of query.py because of its inability to process except ValueError, error:. I suspect that it is due to the compiler not being able to read two "except"s separated by commas. I found that removing ValueError, can solve the problem, but I do not want to do so, since it would not be able to detect "ValueError". As I am new to python, I would like to know if there has been any changes with the code of multiple "except"s. I would be grateful if you could teach me how to run a bot. --kc_kennylau (talk) 08:19, 27 January 2014 (UTC)[reply]

I could also do so with the help of AWB. --kc_kennylau (talk) 08:24, 27 January 2014 (UTC)[reply]

Started replacing using AWB. --kc_kennylau (talk) 08:37, 27 January 2014 (UTC)[reply]

Figured out how to do this with a bot, posted a request in WT:BP. --kc_kennylau (talk) 12:35, 27 January 2014 (UTC)[reply]

@-sche, SemperBlotto I reckon that I have finished doing it. --kc_kennylau (talk) 02:43, 29 January 2014 (UTC)[reply]

Excellent! Thank you for doing it! :) - -sche (discuss) 02:45, 29 January 2014 (UTC)[reply]

Thank you for giving me a new experience too! --kc_kennylau (talk) 03:00, 29 January 2014 (UTC)[reply]

As a final update : zhx-mid has been orphaned (thanks again, kc_kennylau) and I have now deleted it from Module:languages. - -sche (discuss) 01:40, 18 February 2014 (UTC)[reply]

@-sche You're welcome. --kc_kennylau (talk) 11:20, 18 February 2014 (UTC)[reply]

I am working on the Kapampangan Language Wiktionary(pam),I am a native in understanding of Kapampangan and Tagalog (Filipino) language.However I have limited knowledge on the tools here like some templates don't work.Interested helping , Let me know. I new here in Wikimedia, need collaborators as well. Here are the link. https://incubator.wikimedia.org/wiki/Wt/pam/Pun_Bulung https://incubator.wikimedia.org/wiki/Wt/

Thanks in advance.--Kixzer (talk) 22:48, 27 January 2014 (UTC)[reply]

What is it exactly that you need help on? --kc_kennylau (talk) 22:58, 27 January 2014 (UTC)[reply]

Quotations, translations, inflection tables, etc. are broken again, at least for me on Firefox. Haplogy (話) 08:09, 28 January 2014 (UTC)[reply]

Sorry for posting this on multiple pages but suddenly the hidden tables (translations, conjugations and such) have become impossible to see. I can't even see the link. I'm not sure what this is about but I've checked from multiple computers and it's the same. 79.112.21.187 08:12, 28 January 2014 (UTC)[reply]

The problem was due to someone's edit to common.js; it was fixed in diff. - -sche (discuss) 09:11, 28 January 2014 (UTC)[reply]

Still, those tables should always be visible by default, in case javascript fails or is disabled (and the tables are closed by javascript when it loads). We should consider using mw-collapsible for all hidden content. Dakdada (talk) 10:45, 29 January 2014 (UTC)[reply]

The tables are visible if JS is disabled, as the style hiding them depends on the presence of .client-js. --Yair rand (talk) 12:16, 29 January 2014 (UTC)[reply]

Ah. How come the tables became invisible then? Is there no way to test this before saving a javascript page (especially for important pages like common.js)? Dakdada (talk) 13:13, 29 January 2014 (UTC)[reply]

re "How come the tables became invisible then?": Because someone made a change to the part of the .js that adds the "show"/"expand" toggle, such that that toggle stopped working, while the .js to collapse the boxes still worked. And re Michael's comment below, this would not have been prevented by isolating the toggle-adding .js. - -sche (discuss) 01:32, 30 January 2014 (UTC)[reply]

Is there a way to include other script files? Maybe the code that’s critical for text display can be quarantined in a file that won’t be edited all the time. —Michael Z. 2014-01-29 16:33 z

This is happening again. --Vahag (talk) 10:15, 7 February 2014 (UTC)[reply]

Where ? It works OK for me. Dakdada (talk) 13:46, 7 February 2014 (UTC)[reply]

OK, never mind. I reset Chrome and the problem went away. --Vahag (talk) 20:16, 7 February 2014 (UTC)[reply]

Wyang (talk • contribs) needs some help.

Module:PinyinBopo-convert needs to convert Pinyin containing apostrophes, such as dì'èr shǒu, which are quite common, they are used to separate syllables, when the next syllables starts with a vowel.

Apostrophes should be dropped, then the next syllable "èr" (ㄦˋ) will be recognised.

Current result: "ㄉㄧˋ 'ㄜˋㄦ ㄕㄡˇ" Expected result: "ㄉㄧˋ ㄦˋ ㄕㄡˇ"

Note that 'ㄜˋㄦ should be ㄦˋ, the apostrophe creates a bit of a mess.

I have just created dìèrshǒu, without an apostrophe, that works as expected. --Anatoli ^{(обсудить}/^вклад) 23:39, 28 January 2014 (UTC)[reply]

There are two bugs here:

1. Module:PinyinBopo-convert/testcases, where "dì'èr shǒu" is converted to "ㄉㄧˋ ㄦˋ ㄕㄡˇ" but the testing page is showing error.

2. At dì'èr shǒu, the code {{#invoke:PinyinBopo-convert|convert|dì'èr shǒu}} works well but the code {{#invoke:PinyinBopo-convert|convert|{{PAGENAME}}}} fails to work as expected (specifically, apostrophe fails to be recognised).

It would be great if anyone could kindly point out what might have gone wrong in either of these cases. Thanks, Wyang (talk) 00:14, 29 January 2014 (UTC)[reply]

There is a problem with PAGENAME and apostrophes. I'm not exactly sure why it happens or what it does, but somehow it gets converted to something else. I think if you analyse the characters of the string you can see what it is being changed into. We've had this problem with templates too in the past, it was rather annoying to work around. I don't know if the built-in Scribunto version of PAGENAME has the same behaviour; if not, then you can use that instead. —CodeCat 22:19, 29 January 2014 (UTC)[reply]

The answer:

       0          0  003109   E3 84 89       BOPOMOFO LETTER D
       1          3  003127   E3 84 A7       BOPOMOFO LETTER I
       2          6  0002CB   CB 8B          MODIFIER LETTER GRAVE ACCENT
       3          8  000020   20             SPACE
       4          9  003126   E3 84 A6       BOPOMOFO LETTER ER
       5         12  0002CB   CB 8B          MODIFIER LETTER GRAVE ACCENT
       6         14  000020   20             SPACE
       7         15  000020   20             SPACE
       8         16  003115   E3 84 95       BOPOMOFO LETTER SH
       9         19  003121   E3 84 A1       BOPOMOFO LETTER OU
      10         22  0002C7   CB 87          CARON
      11         24  00000A   0A             LINE FEED (LF)

       1          3  003127   E3 84 A7       BOPOMOFO LETTER I
       2          6  0002CB   CB 8B          MODIFIER LETTER GRAVE ACCENT
       3          8  000020   20             SPACE
       4          9  003126   E3 84 A6       BOPOMOFO LETTER ER
       5         12  0002CB   CB 8B          MODIFIER LETTER GRAVE ACCENT
       6         14  000020   20             SPACE
       7         15  003115   E3 84 95       BOPOMOFO LETTER SH
       8         18  003121   E3 84 A1       BOPOMOFO LETTER OU
       9         21  0002C7   CB 87          CARON
      10         23  00000A   0A             LINE FEED (LF)

In short: a double space. My recommendation: rewrite this abomination from scratch. It is already impossible to follow what it does.

As for {{PAGENAME}}, apostrophes are converted to ' by the parser function. You have to use mw.text.decode, {{#titleparts:{{PAGENAME}}}} in the invocation, or pull the page name directly from the module, using mw.title.getCurrentTitle(). Keφr 22:27, 29 January 2014 (UTC)[reply]

It would probably be better to do the conversion in two steps. First, split the string into syllables, then process each syllable separately. That way you can narrow problems down to one step or the other, and fix each separately. —CodeCat 22:47, 29 January 2014 (UTC)[reply]

Fixed. Thanks. Wyang (talk) 22:50, 29 January 2014 (UTC)[reply]

Thanks for help, guys, although I don't agree with "abomination". Wyang has done a great job and put some efforts and time into it. Skills, experiences and interests may differ. I agree that readability is important and comments would be appreciated but people's styles and habits also differ. Again, help you very much. --Anatoli ^{(обсудить}/^вклад) 22:56, 29 January 2014 (UTC)[reply]

I have been sporadically adding Quechua entries to the Wiktionary, with my primary resource being runasimi.de. It seems to be the most comprehensive online collection of Quechua words with entries in standardized Southern Quechua orthography, listings of regional variants, and full translations for English, Spanish, German, and Italian. Since the sparsely-populated Quechua-language Wikipedia has set the Southern Quechua orthography as its standard, I think it would be very helpful for editors to have a Wiktionary that corresponds with it. However, there are few articles at the moment, and there are sometimes standardization issues with those that exist. Another problem is how to balance the need for a variety of articles (i.e. barebones word/definitions) and comprehensive articles (i.e. those that include examples, etymology, morphology, etc.), and I am looking for community advice on how to approach this. Finally, is there a way to automate some of the work? Runasimi.de makes their database available as txt and excel files, but I have been copying a template into a new page and manually entering information. For the record, I have no experience with bots or programming. Thanks for any comments or help in advance. -Sumiaz (talk) 20:51, 29 January 2014 (UTC)[reply]

Yes, anything can be automated as long as there are no licensing or copyright issues. DTLHS (talk) 21:46, 29 January 2014 (UTC)[reply]

Okay, good to know. Does this seem like the sort of project that can be automated?, and if so, how might I go about it (or at least learn how to go about it)? -Sumiaz (talk) 02:51, 30 January 2014 (UTC)[reply]

Discussion moved to Wiktionary:Beer parlour/2014/January#Proposal to change how translation checks and requests are formatted.

Just a thought — since the language templates are (all-but-) deprecated, we could make {{pre}} into a shortcut for {{prefix|pre}}, i.e. make it so {{pre|load|lang=en}} was the same as {{prefix|pre|load|lang=en}}. That would reduce the number of keystrokes required to enter one relatively common etymology.
Alternatively, following {{post}}, we could make {{pre}} a redirect to {{ante}}. - -sche (discuss) 09:35, 30 January 2014 (UTC)[reply]

We could also redirect {{pre}} to {{prefix}} itself. —CodeCat 14:04, 30 January 2014 (UTC)[reply]

I would prefer pfx, since it's more clear and obvious. Chuck Entz (talk) 14:24, 30 January 2014 (UTC)[reply]

[6]. —Aɴɢʀ (talk) 15:01, 30 January 2014 (UTC)[reply]

Because having more template names to remember increases the mental load for learning how to edit Wiktionary. If each person can use their own personal preferred names for templates, that's good for them, but it's horrible for all the other editors who have to make sense of which names are redirects to which. Having just one clear name for each template makes it much easier for editors as a whole. —CodeCat 15:21, 30 January 2014 (UTC)[reply]

Why should other editors have to remember all the redirects? If you use the main name and Chuck uses one redirect and I use another redirect, what difference does that make to any of us? —Aɴɢʀ (talk) 16:14, 30 January 2014 (UTC)[reply]

If I see {{pre}} in a page, I would probably want to know what it does. —CodeCat 16:32, 30 January 2014 (UTC)[reply]

If it's not apparent from the context (something like {{pre|load}} in the etymology section of preload seems transparent to me), and from comparing the displayed page to the page code, you can go to the template to see what it does. But there is still the danger that people will not only not know what something does, but think it does something it doesn't. To me it seems intuitive to use {{pre}} for {{prefix|pre|load}} for preload, and unintuitive to use it for just any random prefix, e.g. it would seem odd to me to see {{pre|post|modern}} on postmodern. But if the latter is more intuitive to you than the former, then there is the possibility that one of us is going to get confused by whichever of those things {{pre}} ends up doing. - -sche (discuss) 17:21, 30 January 2014 (UTC)[reply]

I didn't put this at RFDO because it's just a maintenance deletion, the module redirects to another name now. The module is orphaned, but I want to make sure that no scripts use it before it's deleted. Can anyone who maintains scripts check to make sure? If there are no further complictions I will delete it in two weeks. —CodeCat 14:55, 30 January 2014 (UTC)[reply]

Maybe this could be kept somewhere, for historic purposes? Dakdada (talk) 16:46, 30 January 2014 (UTC)[reply]

What would be the advantage in that? —CodeCat 16:57, 30 January 2014 (UTC)[reply]

Remembering how things worked previously? Or, simply, to preserve the history of the code, even if it was copied elsewhere (where the history is actually lost). Dakdada (talk) 09:54, 31 January 2014 (UTC)[reply]

We can do a history merge. But that would require deleting both modules. Keφr 09:59, 31 January 2014 (UTC)[reply]

In general, history mergers make it confusing to page through the history. The diffs flip back and forth between being from one module and being from the other, making it difficult to find out what was actually changed from one diff of one module to another. (I haven't looked to see whether this module stopped being updated prior to the other module being created, in which case that wouldn't be a problem, but in general history mergers are confusing.) - -sche (discuss) 10:10, 31 January 2014 (UTC)[reply]

This template doesn't seem to work how I would expect (and there's no documentation). See unterm - it should say something like "contraction of unter and dem", but only shows the dem. SemperBlotto (talk) 17:49, 30 January 2014 (UTC)[reply]

Apparently you have to use {{contraction of|[[unter]] [[dem]]}}. — Ungoliant ^(falai) 17:52, 30 January 2014 (UTC)[reply]

We'll have to get CodeCat to drag it screaming and kicking into the 21st century. SemperBlotto (talk) 17:56, 30 January 2014 (UTC)[reply]

Is there something wrong with how it works now? I don't understand. —CodeCat 17:57, 30 January 2014 (UTC)[reply]

It would be more intuitive for it to be {{contraction of|unter|dem|lang=de}} instead, I think. —Aɴɢʀ (talk) 20:01, 30 January 2014 (UTC)[reply]

That would make it work differently from most other form-of templates, where the parameters are like those of {{term}} and {{l}}. I'm not sure if that is more intuitive. —CodeCat 20:30, 30 January 2014 (UTC)[reply]

But contractions are different from most other alternative forms in that they almost always are forms of a string of multiple words that are often SOP. --WikiTiki89 20:35, 30 January 2014 (UTC)[reply]

Contractions can also be contracted from something with parts that are not separated by spaces. What is being proposed here would make the template unusable for such cases, including all Japanese, Chinese, Korean etc contractions. —CodeCat 21:00, 30 January 2014 (UTC)[reply]

That is a good point. I'm ok with the way it is now. --WikiTiki89 21:10, 30 January 2014 (UTC)[reply]

OK. Could someone add documentation please. SemperBlotto (talk) 07:57, 31 January 2014 (UTC)[reply]

It works the exact same way as {{alternative form of}}, which has documentation. --WikiTiki89 08:00, 31 January 2014 (UTC)[reply]

Tamil script is quite straightforward but I don't know how to make those digraphs work and avoid errors if a symbol can't be found in the list. Please take a look at some Module:ta-translit/testcases as well. Any questions, please ask me or DerekWinters (talk • contribs). Thanks in advance. --Anatoli ^{(обсудить}/^вклад) 03:29, 31 January 2014 (UTC)[reply]

Why don't we have the equivalent of w:User:SineBot? --WikiTiki89 04:42, 31 January 2014 (UTC)[reply]

Now this is a whole bunch of things to do: User:Kc kennylau/list of ja-kanjitab usage without all required parameters/more than one kanji. Description at User:Kc kennylau/list of ja-kanjitab usage without all required parameters. I am aware that it is potentially not feasible. I am not sure if it is feasible. --kc_kennylau (talk) 11:03, 31 January 2014 (UTC)[reply]