User talk:Mzajac

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
2007, 2008, 2009, 2010, 2011

Helsinki slang[edit]

By making it a regional category, it becomes 'Helsinki slang Finnish'... and in some cases even 'Helsinki slang English' apparently. I don't think we want that. —CodeCat 01:11, 11 April 2012 (UTC)

Oops, sorry. But it should be categorized as a regional label. Another reason to categorize these with categories, rather than some byzantine code buried in {{context}}Michael Z. 2012-04-11 01:16 z

Wiktionary:Grease pit#Rewrite {{context}}? — {{User:Ruakh/label}}[edit]

Hi Michael,

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 . . . ?

RuakhTALK 13:47, 20 April 2012 (UTC)

Ukrainian toasts[edit]

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)

Hi. Sorry about the delay -- busy August.
на здоров'я (na zdoróvja) means “to your health.” The short version is здоров (zdoróv). дай Боже (daj Bóže), literally “give God,” means something like “may God grant (our wishes).” будьмо (búd’mo) is less common in my experience; maybe it's a more recent import to Canada from Ukraine. It means “let's be,” and I assume it represents “let's be (healthy, happy, etc.).” One might also sometimes hear давай (daváj), meaning “give ’er!” Michael Z. 2012-08-12 14:59 z
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. Michael Z. 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)

Pages moved to your user pages[edit]

I moved Mzajac/Transliterator:uk-Latn-scholari to User:Mzajac/Transliterator:uk-Latn-scholarl and analogously two similarly named pages. I assume that's where you wanted them. If so, it's a mistake I've made a couple of times. DCDuring TALK 23:00, 31 January 2013 (UTC)

Oops. Thank you. Michael Z. 2013-02-01 18:18 z


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. Michael Z. 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. Michael Z. 2013-02-17 19:05 z

Wiktionary:Cascading Style Sheets[edit]

Not everyone uses Vector. It's probably worth mentioning MediaWiki:Vector.css and so on, but there's little or no benefit to mentioning Special:MyPage/vector.css, and there's certainly no benefit to mentioning it instead of Special:MyPage/common.css. —RuakhTALK 01:16, 3 March 2013 (UTC)

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. Michael Z. 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. Michael Z. 2013-03-03 16:22 z

Gender templates[edit]

I think you made some mistakes. {{m}} opens an "abbr" tag but closes a "span" tag, and then the reverse happens after that. —CodeCat 01:53, 6 March 2013 (UTC)

thanks for the fix. Michael Z. 2013-03-06 14:42 z
Something is affecting User:Ruakh/Tbot.js, namely gender generation, which I rely on. I wonder if it has to do with work you're doing. --Anatoli (обсудить/вклад) 02:28, 6 March 2013 (UTC)
Is it still a problem? I’ll need more info to stand a chance of understanding it. Michael Z. 2013-03-06 14:42 z

Input needed...[edit]

I think your input at WT:Grease pit/2013/March#Bot to add {{head|en}} to Category:English plurals would be valuable. (I can't seem to make the link work) —CodeCat 16:23, 22 March 2013 (UTC)

Just copy what the page index gives you:

Use numeric entities for “{{” in the readable name:

Or better yet, just rename the heading to something that works. I think [[:Template:head]] might be better than {{temp|head}}). Michael Z. 2013-03-22 18:42 z

Ok thank you, but my real point was the discussion, not the link itself. :) —CodeCat

Script templates and headword-lines[edit]

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)
The behaviour in {{Latn}} is the following:
  • ital → <i>
  • head<b>
  • bold<b>
  • term<i class="mention-Latn">
  • span<span>
Do you know if there are other possible values? Do you know if there are any docs for faceMichael Z. 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. Michael Z. 2013-05-28 19:38 z

Romanization and definition line[edit]

You have reverted my post to Beer parlour without an explanation, in diff. I have reposted to Beer parlour, as I see no grounds for your reversal. The section that you have removed from Beer parlour is linked from Wiktionary:Votes/pl-2013-03/Romanization and definition line. --Dan Polansky (talk) 18:04, 30 March 2013 (UTC)

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. Michael Z. 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. Michael Z. 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. Michael Z. 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. Michael Z. 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. Michael Z. 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.

The table structure looks like this:

table.inflection.inflection-verb // generic verb table


table.inflection.inflection-ru.inflection-verb // Russian verb table
   th // regular header on the left
 tr.rowgroup // horizontal header row
 tr.divider // has a dark border-top

The code could be simpler for editors if wikitext didn’t filter out some HTML table elements. Please vote for these bugs:

 Michael Z. 2013-04-10 05:08 z

Saves a bit of repetitive coding.[3] When I have a chance, I’ll look at the other conjugation tables and make sure this code works for all of them. Michael Z. 2013-04-10 05:29 z

Script error on your user page[edit]

There is a script error on User:Mzajac/English inflection-line templates, because {{head}} is missing a parameter. Since the page seems to be intended to test the effect of parameters, I thought that might be important. —CodeCat 13:35, 26 April 2013 (UTC)

Thank you. Michael Z. 2013-04-26 22:08 z


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. Michael Z. 2013-05-06 15:35 z

Could you have a look at this?[edit]

WT:Beer parlour/2013/May#Do we really need horizontal rules between language sections?CodeCat 16:10, 19 May 2013 (UTC)

berry blue[edit]

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. Michael Z. 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)

Belarusian templates[edit]


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] Michael Z. 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>.
The others all belong to the same category: Category:Belarusian_adjective_inflection-table_templates - five altogether, they seems to cover all Belarusian adjectives. Please fix, if you can.
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. Michael Z. 2013-06-21 00:26 z
Hi Michael, thank you for fixing {{be-decl-adj}}. I rolled back your change on {{be-adj1}} (removing <br>), though. User:Vedac13's preference is to have them. The tables look much better now.--Anatoli (обсудить/вклад) 07:57, 22 June 2013 (UTC)
Okay, fine with me. But I thought that was the issue you described as “the spacing is bad.” Glad to help anyway. Cheers. Michael Z. 2013-06-22 14:40 z

Further work on the script templates[edit]

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. Michael Z. 2013-07-07 17:16 z


An example of a problem with the ambiguity between topic and usage context. DCDuring TALK 14:14, 16 July 2013 (UTC)


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#langMichael Z. 2013-07-28 18:14 z
Can {{Xsux}} be replaced with a call to {{script helper}} at this point? —CodeCat 18:26, 28 July 2013 (UTC)

Wiktionary:Beer parlour/2013/July#Can we phase out the script code templates?[edit]

This probably interests you... —CodeCat 01:49, 24 July 2013 (UTC)

More Ukrainian adjective declension types[edit]


I've made three Ukrainian adjective declension templates (Category:Ukrainian adjective inflection-table templates) - 1. for -ий (stem stressed), 2. for -и́й (ending stressed), 3. for -ій (stem stressed). I know there's an adjective ending in -їй (безкра́їй) but I can't think of other examples. Do you know any Ukrainian adjectives ending in stressed -і́й? --Anatoli (обсудить/вклад) 01:27, 1 August 2013 (UTC)

I cannot think of one. But it can’t hurt to keep the option open, so it’s there when someone comes up with one. Michael Z. 2013-08-12 16:13 z

Problems with !important in CSS[edit]

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)
We can use .Jpan i { font-style: normal; !important } and .Jpan b { font-weight: normal; !important } --Z 22:01, 8 August 2013 (UTC)
We'd have to do that for every script though. Is there no easier way? —CodeCat 22:23, 8 August 2013 (UTC)
We can use the grouping feature, e.g. .Jpan i, .Taml i, .Deva i { font-style: normal; !important } --Z 22:28, 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.) Michael Z. 2013-08-12 17:01 z

An IPA-related discussion that you may be interested in[edit]

Wiktionary:Beer_parlour/2013/August#Automated_linking_of_IPA_characters_to_their_corresponding_WP_entry --Z 07:30, 21 August 2013 (UTC)


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. Michael Z. 2013-08-30 17:53 z

Keeping RfV balanced[edit]

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! bd2412 T 11:26, 17 September 2013 (UTC)

I will try to do so. Michael Z. 2013-09-17 15:14 z


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? DCDuring TALK 17:48, 19 September 2013 (UTC)

I reverted my last change to Template:rel-top, just to see.[6] (Was only rel-top affected? There’s also Template:rel-top4, &c.) Let me know if this makes any differences.
I was able to expand every box on User:DCDuring in Safari 6.0.5/Mac. Michael Z. 2013-09-20 14:55 z
Just a stab in the dark: if this doesn’t help, try blanking out your User:DCDuring/common.js to troubleshoot this. Michael Z. 2013-09-20 14:59 z
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? DCDuring TALK 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.
<div class="NavFrame">
  <div class="NavHead">...</div>
  <div class="NavContent">...</div>
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. Michael Z. 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? DCDuring TALK 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. Michael Z. 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). DCDuring TALK 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. Michael Z. 2013-09-20 20:24 z

ruby size[edit]

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)

I will move the conversation to Wiktionary:Beer_parlour/2013/October#Using_furiganaMichael Z. 2013-10-18 16:38 z


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.) Michael Z. 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. Michael Z. 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)
Add the following to your common.css to humour yourself:
*:lang(xcl) { font-family: code2000, sans-serif; }
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). Michael Z. 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:
 .Armn:lang(xcl) {
     font-family: TITUS Cyberbit Basic, sans-serif; 
     font-size: 150%;
 Michael Z. 2013-10-27 22:58 z
It works excellently now, thank you. --Vahag (talk) 08:07, 28 October 2013 (UTC)


Hi. Do you cherish Template:R:Melnychuk 1982 much? Would you mind if I converted all its instances to the identical Template:R:uk:ESUM? The latter's format is more in line with the majority of other reference templates, e.g. the ones in Category:Russian reference templates. --Vahag (talk) 23:35, 16 November 2013 (UTC)

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. Michael Z. 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)
That is a great idea. It will allow us to standardize the format of references. Does w:Template:citation allow complex external linking, as in Template:R:sla:ESSJa? --Vahag (talk) 11:00, 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. Michael Z. 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. Michael Z. 2013-11-17 22:53 z

I have moved Melnychuk and Rudnyc’kyj to Template:R:uk:ESUM and Template:R:uk:EDUL respectively. --Vahag (talk) 15:07, 22 November 2013 (UTC)

Cool, and thanks for updating my links. Michael Z. 2013-11-22 18:31 z

Adding fonts to the Universal Language Selector[edit]

Привет Зайчик! 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. Michael Z. 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. Michael Z. 2013-11-24 10:04 z
What about Dilyana? --WikiTiki89 17:29, 24 November 2013 (UTC)
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. Michael Z. 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)
Is a compatible license? If so, the Glagolica Missal DPG font here is decent, although not the best. --WikiTiki89 21:16, 24 November 2013 (UTC)

Narrow tables[edit]

Hi. You didn't answer. --Vahag (talk) 21:58, 26 January 2014 (UTC)

Oops, forgot about this one. I will try it out in my common.css. If that works, it can go in MediaWiki:Common.css, so it would apply in any theme or skin. Michael Z. 2014-01-26 22:03 z
Put the text div.NavFrame { overflow: visible; } into your Special:MyPage/common.css.
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.cssMichael Z. 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. Michael Z. 2014-01-26 23:15 z

СНХ (эс-эн-ха́)[edit]

[regarding Russian translation in sovnarkhoz. —MZ]

Hi Michael,

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? Michael Z. 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. Michael Z. 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.” Michael Z. 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)

Per-language pages[edit]

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. Michael Z. 2014-02-02 20:08 z
I wrote a basic overview page at Wiktionary:Per-language pages proposal. —CodeCat 21:00, 2 February 2014 (UTC)

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. Michael Z. 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. Michael Z. 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)
In the interest of getting it fixed, I posted a comment at mw:Talk:Typography refresh#Previewing discussion is broken.
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. Michael Z. 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. Michael Z. 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. Michael Z. 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 agree with all of that. Michael Z. 2014-02-06 06:41 z
Maybe there could be a quick JS toggle button to switch between reading mode and viewing mode. --WikiTiki89 06:47, 6 February 2014 (UTC)