I just wanted to make sure you saw this. I'd welcome your input about any of it, but what I especially want your input on is categorization, since that's a topic that you seem (from the other discussions) to have an opinion about. In this approach, should the subtemplates like {{label/~medicine}} be categorized? Or . . . ?

I know the normal tosts in Ukraine are budmo or naz da rovya but I've always heard my family use soemthing that sounds like dai borzha and one time I heard that in a (English language) song. Is this a Canadian usage? I've been lead to believe it means "give them shit" but I don't know how I figured that out. Can't find anything about it online. Kevlar67 (talk) 23:12, 3 August 2012 (UTC)

I'm sorry for butting in, however, Michael, you don't speak Ukrainian well and some of your translations and assumptions are incorrect. It must be said that there is no standard or set way to say "cheers" or something in East Slavic languages and different families or groups may have their own way but "за ваше/твоє здоров'я" would be the most acceptable and most common - "to your health". Although "на здоров'я" is also used occasionally as a toast, especially with foreigners, it's normally a reply to "дякую". The phrase "будьмо" is quite common, so is "пий до дна" ("bottoms up"), "дай боже" should not be used as a toast, it means "(if) God is willing" or "God help us", "давай" simply means "come on", "go for it". --Anatoli(обсудить) 01:19, 13 August 2012 (UTC)

Thanks for the welcome clarifications, Anatoli. На здоров’я and дай Боже are the common toasts among Ukrainian-Canadians, and even familiar to some non-Ukrainians and non-Ukrainophones in the Prairie Provinces. A longer version of the former is пиймо на наше здоров’я – pyjmo na naše zdorovja, “Let's drink to our health”. Будьмо is not very common here. Of course, this is mainly the vernacular of Halychany who emigrated here in three different waves in the 1890s–1950s, and their descendants. I haven't spent much time with more recent immigrants or visitors from Ukraine, and of course I wouldn't attempt to describe the language as it is used in Ukraine today. —MichaelZ.2012-08-13 16:46 z

Yeah, I'm not a Ukrainophone, but I've drank with them many times! and I more often hear дай Боже. In fact during the 2005 Brier (Men's Curling Championships) in Edmononton, the tournament's theme song, otherwise in English, ended with that line. Thanks for clarifying how it is spelled. Kevlar67 (talk) 19:22, 22 August 2012 (UTC)

Please stop changing others' signed posts without indicating after their signature, or at the start of the post, that the post was later edited by another. It's bad netiquette in general and AFAICT not done on enwikt in particular. I've just reverted one such of your edits, but I'll leave the rest to you.​—msh210℠ (talk) 04:37, 17 February 2013 (UTC)

I haven’t changed the content of anyone’s post. I am bypassing redirected templates so that their posts would remain the same, if these obsolete templates were to be removed. —MichaelZ.2013-02-17 11:47 z

Changing {{SAMPA|foo}} to {{X-SAMPA|foo}} is changing content, albeit, as you note, not the displayed version of that content (unless the template is <nowiki>ed out or {{temp}}ed; I assume you haven't changed any of those?). Still, I think you should leave a note indicating the change. Should I open this question to a wider audience in the BP?​—msh210℠ (talk) 16:36, 17 February 2013 (UTC)

Look, {{SAMPA}} has redirected to {{X-SAMPA}} since April 2012,[1] so the output of the page is completely unaffected by my change. I left a brief explanatory note (“bypass template redirect”) with my edit, for anyone who is interested in the whys. I’ve been cleaning up the last few uses of some obsolete templates appropriately, and not messing with links to or mentions of them. “SAMPA” is wrong, for anyone who actually cares, because technically we now use “X-SAMPA.” Now that everything is normalized, and everyone has a chance to comment on any evident problems with my changes, and we can collectively delete or redirect the old SAMPA template. —MichaelZ.2013-02-17 19:05 z

What is common.css? I put styles in there and nothing happened. It’s not mentioned in the linked help page. I assumed you’d made a mistake.

Vector is the default skin, and the others are mentioned on the linked help page. Also, it works. —MichaelZ.2013-03-03 01:46 z

common.css is like vector.css, except that it also works if you're using a different skin. I don't know why it didn't seem to work for you; maybe your vector.css superseded it? —RuakhTALK 02:22, 3 March 2013 (UTC)

Sorry – what I tried in my common.css had no effect because of the cascade, yadda, yadda. Regards. —MichaelZ.2013-03-03 16:22 z

You created a new format for headword lines using the strong tag, but the script templates still contain the old code. Do you think you can update them? It might also be a good idea to make a list of all the script templates that use a non-standard format ({{Xsux}} comes to mind). Those non-standard templates will be a problem when we try to move everything over to CSS. —CodeCat 15:13, 25 March 2013 (UTC)

I can update all of these, given some time. Considering the best way to go about this. I think the documentation should be in style sheet rules and comments – it would inevitably get out of sync with reality, unless it were the reality.~~

Ideally, we would eliminate the selection of different tags depending on the face= parameter. Currently, {{Latn}} selects "i" as the element for italic, "b" for bold and headwords, and "span" by default. {{Cyrl}} on the other hand doesn't select italic text separately, so things like {{term}} don't show up in italics (by design). What I think would be nice is if we just applied the same tags irrespective of the script, and let the CSS handle the differences. For example, we could put a rule in CSS that says: "i" with and/or within class "Cyrl" displays normal, non-italic text. I think to avoid too many problems, we could try that approach for Latn, Cyrl, Grek and polytonic and see how it works out? —CodeCat 19:15, 25 March 2013 (UTC)

Do you know if there are other possible values? Do you know if there are any docs for face? —MichaelZ.2013-03-25 20:43 z

Currently, no. But you could always find out by temporarily putting a category into the template, that is added only if the face= parameter isn't one of those five values. Something like: {{#switch:{{{face|}}}|ital|head|bold|term|span=|#default=[[Category:something]]}}. —CodeCat 20:51, 25 March 2013 (UTC)

I have finally updated {{Cyrs}} and {{Grek}} to match Latn and Cyrl. Adding strong.headword { color: green; } to my common.css is a good debugging aid. Will continue to tackle more script templates if no problems occur. —MichaelZ.2013-05-28 19:38 z

I am sorry. The watchlist text is too dense, and I hit a rollback link on my touch screen with my fat finger. I reloaded the page’s history thrice, and couldn’t find the rollback, so I was sure that I had hit the browser’s stop button in time. It’s not the first time, and I’m not sure how to avoid this. —MichaelZ.2013-03-30 18:41 z

Okay, I have added a script to User:Mzajac/common.js which throws up a confirmation dialogue for rollbacks. Won’t happen again. —MichaelZ.2013-03-30 19:09 z

No hard feelings. I should have thought it was just an error. --Dan Polansky (talk) 21:23, 31 March 2013 (UTC)

You seem to be very aware of HTMl standards, so could you have a look at the code in this table and see if it's all ok? —CodeCat 23:06, 9 April 2013 (UTC)

I'd like to keep the layout, though, if possible :) To match other Russian inflection tables. --Anatoli(обсудить/вклад) 00:19, 10 April 2013 (UTC)

The cellpadding and rules attributes on a table are “non-conforming features” which “must not be used by authors.”[2] They can’t be replaced with inline elements, unless we add a style attribute to every cell. Otherwise, it is fine, but I will see about making a style sheet to pare down the inline code. —MichaelZ.2013-04-10 00:27 z

It's a shame that CSS doesn't support anything like "scoped" declarations, which only apply to one element and all of its children. —CodeCat 02:17, 10 April 2013 (UTC)

Not sure what you mean. This is easy to do with selectors in a style sheet. Inline CSS is no good because it is inherently restricted in scope, among other reasons. —MichaelZ.2013-04-10 03:08 z

What mean is, you're not able to say: "here is a style sheet, apply it to this element and its children, but leave the rest of the page alone". Instead, you have to edit the global stylesheet, which is more cumbersome especially on a Wiki where user rights are restricted. —CodeCat 16:04, 10 April 2013 (UTC)

Ah. HTML5 has added exactly that, with the scope attribute for style elements. But MediaWiki doesn’t allow style sheets in the text. The implementation of scope is such that it breaks in every old browser (currently, every release browser), so I don’t expect to ever see this in MW.

Anyway, style sheets are much more powerful, and I think we have enough problems with editors using Wikitext like MS Word, plopping presentational <b> elements everywhere and being fooled by the CMS into thinking they have made some webs. And don’t get me started on discussion threading with “:::::” There are good reasons to separate structure and presentation. —MichaelZ.2013-04-10 17:14 z

I have done sample generic and ru-verb tables at User:Mzajac/temp. The CSS is in MediaWiki:Common.css, starting after the comment “Inflection tables.” You may have to shift-reload or whatever makes your browser update the style sheet.

This page is appearing in some of the term cleanup categories, because it uses {{term}} without a language. It looks like the page is left over from something older, so can it be safely deleted? —CodeCat 19:03, 3 May 2013 (UTC)

I think I cleaned it up. Still going to sit on that idea. Thanks. —MichaelZ.2013-05-06 15:35 z

You do realize that those citations aren't published by Jell-O or Yoplait, and as such aren't the advertising copy you claim them to be? You do realize that berry blue/Berry Blue is offered by a whole buncha companies, not just those two, and as such is a flavor just like rocky road? And you do realize that at this point, you're essentially on a disruptive one-man crusade to get this article deleted? Purplebackpack89(Notes Taken)(Locker) 18:16, 5 June 2013 (UTC)

You ought to realize that badgering people on their talk pages is a waste of time. —MichaelZ.2013-06-05 19:05 z

So is badgering at RfV, which you've been doing disruptively. You've got to realize that you're the only person who sees it that way Purplebackpack89(Notes Taken)(Locker) 02:22, 6 June 2013 (UTC)

Are you able to make this template look better without changing the order and functionality, please: Template:be-decl-adj? The spacing is bad, see геаграфічны or новы. The template is not used directly but by calling templates: Template:be-adj1, etc. later I'll start Ukrainian adj. templates by copy-editing these. will have to find out more about all declension types for adjectives first. --Anatoli(обсудить/вклад) 06:11, 20 June 2013 (UTC)

Got it. {{be-adj1}} had a lot of line breaks in the parameters, which were treated as wikitext, and converted to <p> (paragraph) tags.[4] I presume {{be-adj2}} etc. need the same treatment. I’m out of time today, but let me know if you would like me to go through them (how many are there?). Also {{be-decl-adj}} had a couple of extra <br> tags.[5]—MichaelZ.2013-06-20 23:49 z

Thank you. So you have removed the <br> tags? Maybe the transliteration should then be in brackets - see цёмны? лёгкі, which uses another template probably looks better with <br>.

There won't be many Ukrainian adjective declension types (if pronouns are not included - мій, чий), I reckon 6 as a max - 1 hard (твердий), two soft (синій, безкраїй), and each can possibly be root-stressed and ending stressed (нови́й - ending stressed will need a different template). --Anatoli(обсудить/вклад) 00:16, 21 June 2013 (UTC)

Yes, I removed the extra breaks.

Oops, yes round brackets for the transliteration would be better. I find that having them on the same line makes it easier to understand the table by grouping each translit with its original, and each group to its table header on the same line. It also looks neater and less gap-toothed in a very wide window, while wrapping as expected in a very narrow window.

I will try to go through these templates tomorrow. Go ahead and remind me in case I forget. —MichaelZ.2013-06-21 00:26 z

I have created {{script helper}}, which essentially acts as a single "universal" script template. I have added it to a few of the existing script templates like {{Latn}}, {{Cyrl}} and it seems to work. My goal at this point is to find ways to do this for every script template, so that when it's done the templates won't be needed at all anymore because they all share the same code. The changes I make also involve making modifications to MediaWiki:Common.css so that any functionality that is lost from the script template by the "merger" is compensated by changes in the CSS. For example, {{Cyrl}} originally did not apply the "mention" class for face=term, but {{script helper}} does, so the styling for ".Cyrl.mention" had to be overridden in the CSS so that it did not apply the default italic styling. Similar things probably need to be done for headword lines as well (I know for {{Goth}} it does). I'm letting you know all this in case you would like to help out. —CodeCat 15:38, 7 July 2013 (UTC)

Wow, that is the way it should work. Thank you. —MichaelZ.2013-07-07 17:16 z

I have been converting script templates to use {{script helper}} and all of them are now done, except for this one. I added a category to it, to categorise if the second parameter is given. And it turns out no pages actually use that feature, so all of them really just use the default and this might as well be turned into a regular script code template using {{script helper}}. Do you know if it would be desirable to keep the different varieties that are implemented by this template, in one form or another? Maybe we could make language-specific versions like "akk-Xsux" (stage 4), "sux-Xsux" (stage 6) if we really want to. —CodeCat 17:47, 23 July 2013 (UTC)

I did a bit of reading on the subject, but input from a subject expert would be helpful.

The 1-through-7 parameter is meant to allow comprehensive support for writing style. I think it might be similar to providing support for Fraktur font in English (en-Latn and en-Latf). It would be nice for accurately reproducing original quotations, but is not needed for defining dictionary terms.

I think in practice we really only need standard language support, which I have tried to summarize in Template_talk:Xsux#lang. —MichaelZ.2013-07-28 18:14 z

I thought that putting !important in a CSS class would force it to apply that style above any others. But it doesn't seem to work in all cases. For example, if you type <span class="Jpan"><i>text</i></span> then it comes out as text. That's not correct, the !important directive on the font-style: normal should override the italics. Why does it still display in italics? Is there no way to say "nothing inside this element should be italic, ever"? —CodeCat 21:23, 8 August 2013 (UTC)

The deprecated i is messing up here, either <i class="Jpan">text</i> or (preferably) <span class="Jpan" style="font-style: italic;">text</span> should be used. (give text and text respectively) --Z 21:31, 8 August 2013 (UTC)

But it would be nice if we could make something like {{lang|ja|text ''italic'' '''bold'''}} behave nicely too. —CodeCat 21:33, 8 August 2013 (UTC)

That's true. I was just hoping we could keep all the styling grouped per script. —CodeCat 22:48, 8 August 2013 (UTC)

Oh. No I don't think there is. But grouping like this is a bit better: .Jpan, .Jpan i { font-style: normal; !important (...) }.Deva, .Deva i { font-style: normal; !important (...) } ? For disabling boldface we have to do this, but for italics in example sentences we can use a class in {{usex}}/Module:usex instead of i, this way no other styling needs to be changed and the "font-style: normal; !important" parts will work. --Z 23:31, 8 August 2013 (UTC)

The !important keyword makes the declaration trump any other declaration for the selected HTML element. So it will override any other styles for .Jpan. But as far as I can tell, it doesn’t trump the style specificity of nested elements.

So in this case, you would need to select something like .Jpan, .Jpan i, .Jpan em { font-style: normal; }. I don’t think the !important is necessary, because .Jpan i {} is more specific than the basic selector i {}.

(Also, avoid using !important whenever possible. It makes normal specificity stop working, and may have unintended effects. It forces users to use !important in their own style sheets, which may reduce accessibility.)

This exposes some problems with our whole class-based selector system for styling language scripts. What if the Japanese text quotes some English text? Then italics in the English-language quotation would be incorrectly neutered.

The CSS :lang() selector works fundamentally differently. In our example, .Jpan only selects the outer span, and we hope that its styles cascade to the span’s children, like the nested i. In contrast, HTML language is inherited by child elements, unless overridden by another lang attribute, so :lang(ja) actually selects both the span and the nested i element so just the simple :lang(ja) { font-style: normal; } would work.

Unfortunately, the lang selector only respects the first fragment of a language code, so you can’t select :lang(ja-Japn) vs. :lang(ja-Latn).

The script-based class system was created to work around MSIE 6’s text-display bugs which made international text unreadable. We should stop relying on this for cosmetic purposes and in HTML5 web browsers. We should stop creating hundreds of exceptions in browser rendering. We should stop relying on locally-installed fonts, and only use web fonts that we can serve up, and only when necessary for basic readability. (Of course these are unachievable ideals, but we should work to stop our code from growing more unmanageably convoluted.) —MichaelZ.2013-08-12 17:01 z

Is this function of Module:IPA able to generate X-SAMPA from IPA 100% safely? --Z 10:13, 26 August 2013 (UTC)

The testing is minimal: just what you see on the docs page. And the function has been updated since I wrote it – it looks okay at a glance, although currently I think the 4 to 6-character long symbols won’t be transliterated (the ones at the bottom of Module:IPA/data). Double-check with User:ZxxZxxZ who has been updating it. —MichaelZ.2013-08-30 17:53 z

Greetings! Since you have recently added new discussions to Wiktionary:Requests for verification, please help to keep the page from becoming overgrown by helping to advance, close, or archive some old discussions. Cheers! bd2412T 11:26, 17 September 2013 (UTC)

I am trying to unravel various problems I'm having. One recent problem (I don't know exactly how recent.) is with the disappearance of the control that allows the display of items in rel listings. It doesn't seem to occur in N0, but does in my user page, qv, from two platforms, laptop and mobile. Could your recent change have any bearing on this? DCDuringTALK 17:48, 19 September 2013 (UTC)

I have elimnated all of my css and js customization and now have lost some of the things I liked to have, but have regained the use of the controls. I've used kephir's latest method of killing webfonts, which was leading to various unwanted fonts overwriting (I could see it happen.) that I liked. My problem sometimes included both the quotation control and the rel-top control, but they didn't always occur on the same page at the same time, so I thought they might well be separate problems. It may indeed be some more general problem, what kephir calls a "race condition". I found that inserting {{l/en| }} on problem pages seemed to work. (Why would that be?) Then I deleted that and it still worked. (???) Things seem to be balanced on a knife edge. The several layers of software in a real-time environment do seem to make for a lot of complexity and unpredictability. Is more self-restraint or professionalism required? Is that practical with volunteers?

Do der-top and rel-top have the same basic code? DCDuringTALK 15:21, 20 September 2013 (UTC)

Sometimes just doing a null edit – saving a page with no changes nor edit summary – makes all of the templates on the page update their content, and might fix a problem (or reveal one). Maybe that’s behind the mysterious {{l/en| }} fix.

As far as I know, it is only the following code that makes all of the collapsible headers work. Unless your CSS affects the display or class of these elements, it shouldn’t interfere with the controls. I am not a Javascript expert, but I think there may be many opportunities for JS to screw them up.

In a while, I will continue with cleaning up the HTML in those templates, but it is not urgent.

A project that has live-edited templates, CSS, Javascript, and Lua, running on a server framework updated by a third party, will always stand a risk of breaking without warning. Only copies of the project from database dumps or print-outs will ever promise 100% reliability. The fix would be to have one Wiktionary for editors and one for readers. —MichaelZ.2013-09-20 15:58 z

I noted your suggestion that it might not be worth fighting ULS, which from a non-techie's perspective seems likely. Some seem to be viewing the matter through a NIH lens. Does ULS require webfonts? Are they separate or separable? DCDuringTALK 16:32, 20 September 2013 (UTC)

From a cursory glance I couldn't even determine how the fonts are configured – as far as I can tell it might require a Bugzilla request to the developers, which would not bode well for us.

I’m sure there is no technical reason to require web fonts. With web fonts we can specify one font that works, rather a whole list that no one has even tested. And overcome the problem of users not being able to install fonts, especially on mobile where it is often impossible. A problem might be the sheer download size where many languages appear on one page. —MichaelZ.2013-09-20 16:53 z

Thanks for taking a run at this and for some answers to my questions. If I could have figured more out myself, maybe I wouldn't have grasped at this straw. There are so many things that are going wrong lately, that I am now hesitant to bring some up, like browser-specific preferences not working so well (eg, fonts under search box). DCDuringTALK 17:06, 20 September 2013 (UTC)

For text entry, I suggest you find something that works in your OS, rather than depending on a gadget attached to a field on a website. On the Mac, I use the built-in Character Viewer palette (enabled in System Preferences > Language & Text > Input Sources), and have made some custom keyboard layouts with Ukelele. I can’t help if you’re on Windows, but there must be something along these lines at SIL or elsewhere.

Glad to try to help. I’m sure we will work it all out by the time this project is completed. —MichaelZ.2013-09-20 20:24 z

Hi there, I notice that ruby is a bit bigger. It's easier to read but now it matches up with the text less than it did before and hangs off the edges of words, and worse yet it sometimes pushes the kanji below apart, so we end up with text with gaps such as here. Is there some way to address this? Thanks --Haplology (talk) 12:30, 18 October 2013 (UTC)

You seem to be good at this. Is there a way to specify different font families for Old Armenian (xcl) and Armenian (hy)? Both use Armn script --Vahag (talk) 17:45, 26 October 2013 (UTC)

The Wiktionary way to do this is to create separate language classes xcl-Armn and hy-Armn. See the .Arab examples in MediaWiki:Common.css, and templates like {{fa-Arab}}. I’m glad to help if you are not confident figuring out the details.

(We should really start using standard language codes to code languages, instead of our private class system – this is a big project on my long list.) —MichaelZ.2013-10-27 15:51 z

Now that I know this is not very straightforward, I don't want to do it. There is no practical advantage to gain, just wanted to use a more archaic-looking font for Old Armenian. Thanks for the response anyway. --Vahag (talk) 16:56, 27 October 2013 (UTC)

Well, if it is the right thing to do, I will help make it happen. But is it?

Cyrillic (Cyrl) and Old Slavonic Cyrillic (Cyrs) use different fonts because they are considered different script systems, with very different orthographic and typographic conventions. The average literate Ukrainian might find it impossible to read a document in the old orthography. In en.Wiktionary, Cyrs is only used for Old Church Slavonic, modern Church Slavonic, and Old East Slavic. Living languages that switched from the old script to the new, like Belarusian, Russian and Ukrainian, are only represented in the modern script (although it might be an open question whether very old citations should be presented in their original orthography).

I believe that Arabic script is differentiated because some languages need to select specialized fonts to write them correctly. Likewise polytonic ancient Greek. In these cases we are dealing with the same writing system and script code, but we need to overcome shortcomings of common fonts for “specialized” forms of language. Don’t know the details. —MichaelZ.2013-10-27 18:27 z

It's not needed for Armenian. I simply wanted to humour me with an older-looking font. --Vahag (talk) 18:36, 27 October 2013 (UTC)

Substituting the correct name of your font for code2000. Let me know how this works (currently, the Universal Language Selector is randomly interfering with some language–font selection). —MichaelZ.2013-10-27 18:51 z

Thanks, it works! I had added myself to WebFonts disabler at MediaWiki:Common.js. By the way, when I increase the font size, it increases non-uniformly for different elements of the page. For example, in Վահագն the headword is not very much bigger, elements in {{term}} and {{l}} are a lot bigger, the text in the quotation is only slightly bigger. Even more weirdly, this edit makes the word in the first {{term}} smaller than in other {{term}}s. --Vahag (talk) 19:59, 27 October 2013 (UTC)

Oops, that was not a good rule. When, e.g., <a href> is inside of <b lang="xcl">, both of the nested elements resolve as :lang(xcl), so the 150% relative size is applied twice. Try overriding Wiktionary’s rule when it applies to Old Armenian, instead:

I don’t care about the particular template. But are you suggesting that we cite references in their native language rather than English? That seems wrong. —MichaelZ.2013-11-16 23:39 z

I am not suggesting anything new. The usual Wiktionary practice is to cite references in their native language, in native script for Cyrillic and Greek and in transliteration for other scripts. Browse Category:Reference templates by language. The English name is sometimes given in parentheses. It is my impression from reading professional linguistic literature, that this is the usual practice in real world as well. Native names are unambiguous. --Vahag (talk) 09:06, 17 November 2013 (UTC)

On Wikipedia citation templates have trans_title= parameter to specify a translation which is then listed in brackets. Perhaps we should simply copy w:Template:citation and its infrastructure and use it in individual reference templates. --Ivan Štambuk (talk) 09:43, 17 November 2013 (UTC)

English-language libraries and academic publications use ALA-LC transliteration for foreign-language citations. This is English Wiktionary for English readers. According to what logic would we cite sources in foreign script for an arbitrary list of several dozen languages plus Greek, but not for all others?

Standardizing citations is a good idea. The romanization could be largely Luacized too. —MichaelZ.2013-11-17 17:00 z

I do not mind using transliterations for all scripts and giving a translation in square brackets. But the transliteration should be done automatically from the original name, as in Template:R:hy:Kend1. --Vahag (talk) 18:04, 17 November 2013 (UTC)

Automatic, preferably yes. But libraries catalogue works under “Ṛuben S. Ghazaryan,” not “Ṙuben S. Łazaryan.”[7][8] If it is not practical now, we should aspire to work toward using ALA-LC romanization for bibliographic information in any language. —MichaelZ.2013-11-17 22:53 z

Привет Зайчик! Would you happen to know who to ask to get fonts added to the Universal Language Selector? I noticed that no fonts there support Glagolitic and I did some research and decided that BukyVede and Dilyana are probably the two best choices (see here for links). We already list these fonts in at MediaWiki:Common.css, but most people wouldn't have them installed. I also noticed that Code2000 seems to be broken for Glagolitic, displaying them in a weird font and missing many characters. See ⰿⰾⱑⰽⱁ ‎(mlěko) for an example of Glagolitic. --WikiTiki89 05:24, 24 November 2013 (UTC)

Hi. The FAQ says to file a bug on Bugzilla. I see there is already this one filed, but could use your input. —MichaelZ.2013-11-24 10:02 z

Unfortunately, Bukyvede is not free. We’d have to track down the licence info for any font to be included. —MichaelZ.2013-11-24 10:04 z

The embedded info says “Copyright (c) 2008 by R. M. Cleminson. All rights reserved.” It appears to be distributed by Prof. Cleminson, but I don’t see any licence or terms. Perhaps you can contact him and suggest that it be released with a Wiki-compatible licence.

There might be other fonts already available. Here’s one good place to start looking. —MichaelZ.2013-11-24 20:05 z

I'll take a look. If only the Unicode consortium could release the fonts they use for their lovely PDFs... --WikiTiki89 20:26, 24 November 2013 (UTC)

I want to try this out for a bit and see if it breaks any other NavFrames. If it’s okay, then we just have to remove div.NavFrame { ... overflow: auto from MediaWiki:Common.css. —MichaelZ.2014-01-26 22:32 z

It's better now. The table expands just enough for horizontal scrolling to disappear. Still, it is too narrow and looks ugly. I don't understand why the tables can't take the whole width of the screen for people who do have additional space. The reasoning for this change in Typography Refresh is that people scan text better if it is narrow. That's true and I have been enjoying Typography Refresh on Wikipedia. But the same can't be true for tables. --Vahag (talk) 22:48, 26 January 2014 (UTC)

If we can unify our inflection tables into a set of classes and styles, then we could design them in more detail. If the data cells, or the spans in them, had white-space: nowrap, then this would be much more readable now.

And perhaps the typography refresh can be refined to be more flexible. It’s good for running text, but Wikimedia is much more than Wikipedia. —MichaelZ.2014-01-26 23:15 z

Russian abbreviations are often respelled and pronounced in a non-standard way, that's why they are usually re-transliterated to show this. The correct and a more common pronunciation of Russian abbreviations may cause problems for native speakers or there are variants. There's little consistency and logic in the pronunciation of abbreviations, letters are often misread, not following their official names. ФБР "фэ-бэ-эр", США "сэ-шэ-а/сша", ОБХСС "о-бэ-хэ-эс(-эс)", ФРГ фэ-эр-гэ, СССР (эс-)эс-эс-эр, РСФСР "э-рэ-сэ-фэ-сэр/эр-эс-эф-эс-э́р" but ГУМ, МХАТ, МГИМО, ГОСТ, ТАСС, ГЭС, МИД are respelled as if they were normal nouns - гум, мхат, мгимо, гост, мид, etc. not "гэ-у-эм", etc. The alternative to manual transliteration is to show their phonetic respelling or IPA, which is never done on translations, or {{qualifier|pronounced: "эс-эн-ха́"}}. --Anatoli(обсудить/вклад) 04:31, 28 January 2014 (UTC)

Also, many dictionaries fail to show how to pronounce those abbreviations, rare exceptions are names of countries or official organisations, where the respelling/pronunciation is "prescribed", like РСФСР "эр-эс-эф-эс-э́р" or СССР "эс-эс-эс-э́р", even though these suggestions are seldom followed. Do you have another suggestions rather than transliterating СНХ like this: СНХm ‎(SNX) instead of СНХm ‎(es-en-xá) ("эс-эн-ха́")? --Anatoli(обсудить/вклад) 04:39, 28 January 2014 (UTC)

Pronunciation is indicated in a “Pronunciation” section. As you know, you can indicate it in scientific notation or even in Cyrillics. Why on Earth is this a discussion? —MichaelZ.2014-01-28 05:24 z

I agree that there's no need to duplicate this everywhere the word appears. If someone wants to know how it's pronounced, they can click on it and check the pronunciation section. And as Michael said, you can use the respellings in the pronunciation section. --WikiTiki89 05:31, 28 January 2014 (UTC)

Sorry, I guess Anatoli meant in translation sections? There’s only so much info that should go there. In these one-liners, identifying the word (e.g., ФБР = FBR) to non-Cyrillic readers is more important than explaining how it is pronounced. —MichaelZ.2014-01-28 05:39 z

I understood that. Translation sections are one place covered by "everywhere the word appears". --WikiTiki89 05:42, 28 January 2014 (UTC)

Anatoli, you are still not getting it. The guideline says “Do not add the pronunciation of the translation or detailed grammatical information: such information should be provided on the page for the translation itself.” —MichaelZ.2014-01-28 05:58 z

I created the entry for СНХ, hopefully that will help anyone wondering how to pronounce it. --WikiTiki89 06:09, 28 January 2014 (UTC)

I too think phonetic respelling should be shown in the pronunciation section of the Russian entry. Anatoli, you put too much information in the translation table, like gender, stress, qualifiers, phonetic respelling... This is not a bilingual English-Russian dictionary. The Russian sections exist for showing such information. --Vahag (talk) 09:46, 28 January 2014 (UTC)

Maybe we should start writing a proposal on a dedicated Wiktionary: page somewhere. That way there is more room to work out proposals and problems, things that would need to be done, how far we got, and so on. —CodeCat 19:51, 2 February 2014 (UTC)

Sounds okay, if there is basic support for the idea. I just wanted to throw it out in the GP in case I was missing some obvious disadvantages or overwhelming opposition. —MichaelZ.2014-02-02 20:08 z

right-aligned image squeezes the paragraph to about 6 letters wide[edit]

Re this edit: Yet another downside of the Typography Refresh? --WikiTiki89 20:31, 5 February 2014 (UTC)

Well, yeah. But I would call it a downside of any editor assuming everyone reads Wiktionary through the same interface (a few of our editors don’t even use the current wiki skin).

Even more fundamentally, a downside of using nested definition list definitions for indentation. Reading on a small display can make the window even narrower than the Typography Refresh/Update does. —MichaelZ.2014-02-05 20:38 z

I agree with your second point, but as for differing skins, Wikipedia has had images aligned on the right for its entire existence, before the vector skin, and before widescreen computers. --WikiTiki89 20:42, 5 February 2014 (UTC)

Yes, and editors have been messing with image positioning in long discussion pages for just as long. What the TR/U has changed is that the discussion page has a different width than its preview. That’s just self-defeating. —MichaelZ.2014-02-05 20:54 z

But that can be fixed. The problem of getting people to want a narrower screen cannot be fixed. --WikiTiki89 20:57, 5 February 2014 (UTC)

Completely unconstrained fluid pages have their own problems. The fixed maximum width could be improved upon with a responsive layout. I hope they are working on it. —MichaelZ.2014-02-05 21:15 z

One way to make it responsive is to unfix the width. --WikiTiki89 21:46, 5 February 2014 (UTC)

Yes, except that it would not be what responsive means in web design. And that it is bad design to let 12-px running text wrap to the width of an HD or 4K display. And it would would look like the late 20th century. —MichaelZ.2014-02-05 22:20 z

It's not a "bad idea". It's all a matter of taste. I happen to like having a wide display with a high screen resolution and reading things in full width. I'm sure many other people do to. --WikiTiki89 02:09, 6 February 2014 (UTC)

You’re right, preference is important.

But you are wrong that it’s all a matter of taste. Column width and other factors measurably affect reading speed. —MichaelZ.2014-02-06 05:35 z

Reading speed is not the only thing that we should be concerned with. The amount of content that can fit on the screen at once is also important, especially if you are jumping from section to section and comparing things. Aesthetics is also important, and it doesn't look very nice when more than half the screen is blank. --WikiTiki89 05:41, 6 February 2014 (UTC)

I would like to talk a bit more about possible ways to improve these, continuing on our discussion in the BP. Firstly, what do you think of the tree as it is now? Is it better? —CodeCat 22:07, 3 July 2014 (UTC)

Do you know if I can control the font of transliterations via my custom.css? I have ordered Chrome to display the Latin script in Arial, which it does except for the transliterations, which are shown in the default browser font. --Vahag (talk) 21:40, 15 July 2014 (UTC)

I struggled to create a usage note about the sensitivity of or controversy over the term, but I can’t find any clear indication in published English sources. I think it is really the subject and its details, that are debated (e.g., 2m or 10m victims, deliberate genocide or economic necessity, a tragedy of the Ukrainian nation or Soviet state?), but the use of this name for the event appears to be accepted in English publishing. I don’t think it’s useful to include a note that essentially says “the English term Holodomor is objectionable to Holodomor deniers and Stalinists.” —MichaelZ.2014-09-08 19:54 z

Thanks, Michael. The article looks good to me. I'm not sure about the usage note myself. --Anatoli T.(обсудить/вклад) 22:45, 8 September 2014 (UTC)

I have created a large number hypernyms sections for taxonomic name entries. They all share one feature: extensive use of "&.nbsp;-", sometimes the use is in templates (See Category:Taxonomic hypernym templates), sometimes not. In any event, whenever a Translingual section has a space followed by a dash, the space should be a nonbreaking space. Can CSS compel this to occur? I envision the application of a style whose scope was limited to the taxonomic portion of a Translingual L2. Any advice, including RTFM with direction to the most appropriate M, would be appreciated. DCDuringTALK 21:35, 5 September 2014 (UTC)

CSS can apply white-space: nowrap; to any element. But if you can use a template or something to put in an appropriate element as a handle for this, then you probably may as well just put in a non-breaking space. This would also survive a text-only copy-paste or other reuse of the text. I don’t know about other OSes, but on my Mac typing alt-space enters a literal non-breaking space, which is easier and less cluttering than a code like &nbsp;.

(Instead of a hyphen, you should be entering an en dash – like the one in this sentence.)

Why not use parentheses or a colon instead, which might better indicate the relation between a hypernym and its explanation? —MichaelZ.2014-09-08 16:19 z

Thanks for the advice. Sadly I would have to hold down my alt key and type '0160' to enter a non-breaking space in Windows. Are you sure an invisible non-breaking space is better than '&.nbsp;' anyway?

As to your question, per WT:ELE the content under the Hypernyms is supposed to preceded by {{sense}} and a 'gloss' or other unique sense identifier. For taxonomic name entries, I have been using the taxon type ('species', 'order', 'clade') for that. An individual content item may be followed by a vernacular name or another attribute enclosed in parentheses. But the content items are also of one or more taxon types (eg, 'family', but also some genera not assigned to any family). It is this last function that is served by an indication such as " - species" after the last item of the species type. This parallels the treatment of items under the Hyponyms header and, occasionally, the Synonyms and Coordinate terms headers for taxonomic names. Some other editors have used {{a}} for indicating the taxon type, but IMO this can cause confusion when there are also attributes associated with individual items under the various semantic relations headers (eg, Hypernyms).DCDuringTALK 17:16, 8 September 2014 (UTC)