Template talk:ru-conj-table

From Wiktionary, the free dictionary
Jump to navigation Jump to search

imperfective and perfective together[edit]

Thanks again, CodeCat!,

I've made some additions as per the discussion.

I just added blocks with comments.

  1. Label "present tense" if impf, "future tense" if pf. I renamed the parameters, e.g. pres_fut_1sg is both present and future, depends on whether it's impf or pf.
  2. Future tense block should appear only if impf
  3. 3 rows: present participle active, present participle passive, present adverbial participle only appear if impf

Please let me know if it makes sense. Can you make the changes, please? Where would you put the impf/pf parameter? In what form? --Anatoli (обсудить/вклад) 23:31, 9 April 2013 (UTC)[reply]

I am not sure if adding the personal pronouns makes the table any clearer. If anything, it diverts the attention of the user away from the words that really matter. Furthermore, the future tense doesn't have the auxiliary verb in perfective verbs, does it? And also, does it make sense at all to list the present participle under the future tense? —CodeCat 23:42, 9 April 2013 (UTC)[reply]
Can we please leave the personal pronouns? "я" is clearer to many users than "1st person singular". It's also used in the Russian wiki.
The future tense for perfective verbs is the same as present form for imperfective. So the label for perfective should be future tense and present tense for imperfective. I renamed the params to "pres_fut_1sg", etc. to show it can be either.
The future tense block (three rows) with auxiliary verbs (бу́ду, бу́дешь ) should only be shown for impf and skipped for pf.
I've just added a header for imperative and past participles. --Anatoli (обсудить/вклад) 00:09, 10 April 2013 (UTC)[reply]
I've changed the layout a bit so that it matches the Slovene templates more. I think it looks better this way. I'm not sure how to make the past tense forms fit in neatly though. The Slovene templates just leave out the gender and assume that this is known, but Slovene also uses the copula as part of the past tense while Russian has no copula anymore. The Slovene template also just says "future is formed using future forms of biti with l-participle" and doesn't give tables for all the forms. Also, the table doesn't currently show this, but I assume that the past plural forms apply not just to oni, but also to my and vy? —CodeCat 01:12, 10 April 2013 (UTC)[reply]
Oh, and another thing. The "present" of the perfective verbs has future meaning, but what if I formed another "future" from such a verb in the same way that imperfective verbs do, using the future forms of "be"? Would that make any sense at all? —CodeCat 01:17, 10 April 2013 (UTC)[reply]
Added the missing мы and вы. (Hmm, I missed that in other templates as well, will have to fix, since it may take some time for new templates to replace the old).
If it's not too hard, I'd like to display future with auxiliary verbs only for impf. - e.g. я буду делать.
Perfective future forms can't be formed by adding auxiliary verbs, - e.g. я буду сделать is incorrect, the correct future form for perfective: "я сделаю". --Anatoli (обсудить/вклад) 01:28, 10 April 2013 (UTC)[reply]
Ok, I wanted to ask because in Slovene, even perfective verbs have separate present and future forms. I am considering making a third column of forms for the imperfective future, which would be displayed between the present and imperative. Since there are only two imperative forms, it might be a bit wasteful to have a whole column just for them so they could be moved back down (in Slovene it's not so much a waste because there is also a 1st person imperative). That way we can prevent the table from becoming too wide. It wouldn't work that well to put the past forms beside the present/future, because of the gender forms which need different rows and columns. The Slovene template also shows forms for the pluperfect (the past of the past, basically), and the present and past conditional. Do those also exist in Russian and if so, how are they formed? —CodeCat 01:37, 10 April 2013 (UTC)[reply]
Not sure about a whole column for the future forms, since it's only for imperfective and the label "present tense" should change to "future tense" if it's perfective. Perhaps the current layout is best (if it can be changed conditionally)
No, pluperfect doesn't exist. --Anatoli (обсудить/вклад) 01:43, 10 April 2013 (UTC)[reply]
No, my idea was to have two columns for imperfective verbs, present and future. For perfective verbs, either we would leave one column empty, or just merge the two columns into one for just the future. I prefer the first approach a little more, because it makes it immediately clear to anyone who sees the table that the verb has no present tense. Of course, someone who understands Russian perfective verbs will also know this, but it would be a lot more obvious this way. I will change the table to show what I mean. —CodeCat 01:56, 10 April 2013 (UTC)[reply]
Re: imperative. Moving to separate rows is OK with me or leaving where it is. I'll leave it up to you. Imperative for the 1st person singular (unlike sometimes in Polish, Ukrainian) always coincides with "pres_fut_1pl" ((мы) идём - let's go) but normally this form not added to conjugation tables. --Anatoli (обсудить/вклад) 01:58, 10 April 2013 (UTC)[reply]
I'd like "participles" to go to the very bottom, after the "past tense", otherwise the order of rows is good. --Anatoli (обсудить/вклад) 02:05, 10 April 2013 (UTC)[reply]
I put participles at the top because they are "non-finite" forms, just like the infinitive. It made more sense to me to group them together. —CodeCat 02:10, 10 April 2013 (UTC)[reply]
I see. Passive participles will be blank for intransitive verbs and present participles are always absent for perfective verbs, though. There are also certain rare verbs for which forming some participles is awkward. --Anatoli (обсудить/вклад) 02:23, 10 April 2013 (UTC)[reply]
Just an idea but while we're at the basic design stage, perhaps Module:ru-translit could be used for transliterating inflected forms? I know Metaknowledge used these modules in some templates. --Anatoli (обсудить/вклад) 02:27, 10 April 2013 (UTC)[reply]
We could try it, but where would we put the transliterations? I've now added imperfective/perfective distinctions to the table. Here is what it looks like: —CodeCat 02:34, 10 April 2013 (UTC)[reply]

Template:ru-conj-table Template:ru-conj-table

I'd put in brackets: бу́ду де́лать ([MODULE CALL REDACTED]) (not sure about any shortcuts).
The tables look great but present participles for perfective should also be "—". --Anatoli (обсудить/вклад) 02:43, 10 April 2013 (UTC)[reply]
There probably wouldn't be enough room for that. The templates we use for Gothic put the transliteration below instead. But as you can see, it makes the table quite a bit taller. —CodeCat 02:47, 10 April 2013 (UTC)[reply]
Users love translit. Hindi, Japanese, Korean, Persian, Arabic templates also use translit. I could add <br>{{#invoke:ru-translit|tr|глаго́льная фо́рма}} (verb form) myself later (or the shortcut). It's OK to make the table taller, it's collapsible now, thanks to you. We can talk about this at a later stage. --Anatoli (обсудить/вклад) 02:58, 10 April 2013 (UTC)[reply]
The table also still needs language and script support. But I think that it may be more effective and less wasted effort if, now that we have the layout of the table fixed, we migrate it over to Lua. —CodeCat 03:01, 10 April 2013 (UTC)[reply]
I don't know much about Lua. Do you mean adding a call to translit modules? Would this be sufficient: {{Cyrl|{{{pres_adv_part}}}}}<br>({{#invoke:ru-translit|tr|pres_adv_part}}) for each form? I'm adding the script support but don't know if we need language support. Should the forms be wikified? Perhaps it could be done on the calling template to have it in this format: "де́лаю (délaju)" instead of just "де́лаю". --Anatoli (обсудить/вклад) 03:26, 10 April 2013 (UTC)[reply]

#if and params?[edit]

I'd like to add some simple logic. For example we have parameters impf and pf.

I want to display:

  1. if {{ru-conj-table|impf|... imperfective aspect
  2. if {{ru-conj-table|pf|...perfective aspect

--Anatoli (обсудить/вклад) 01:05, 10 April 2013 (UTC)[reply]

Yes, that will eventually be necessary, but I would prefer to get the structure of the table working first, before we start adding logic like that. —CodeCat 01:39, 10 April 2013 (UTC)[reply]

Testing[edit]

Imperfective aspect (делать): Template:ru-conj-table

Perfective aspect (сделать): Template:ru-conj-table

Imperfective aspect, reflexive (делаться): Template:ru-conj-table

Perfective aspect, reflexive (сделаться): Template:ru-conj-table

@CodeCat. Reflexive verbs and any other intransitive verbs don't have passive forms, can you make all passive forms optional, please? --Anatoli (обсудить/вклад) 06:14, 10 April 2013 (UTC)[reply]

I could just pass a blank but the translit will show empty brackets. --Anatoli (обсудить/вклад) 06:16, 10 April 2013 (UTC)[reply]

The optional params are: pres_pasv_part, past_pasv_part. Don't know how to for existence of the second param with #ifeq:. --Anatoli (обсудить/вклад) 06:24, 10 April 2013 (UTC)[reply]

I added a conditional that replaces the cell with an em dash if the respective param is empty.[1] It could also be formulated to omit the entire row, but disappearing rows might confuse an editor or reader. Michael Z. 2013-04-10 06:52 z
Thanks, Michael, agreed, em dash is better, I want to explicitly say that there is no passive form for intransitive verbs. Will this also work for blanks or only when there's no param at all? (Can't see in the preview unfortunately, have to save to see the result)--Anatoli (обсудить/вклад) 06:54, 10 April 2013 (UTC)[reply]
Should work for either, but please test. I am new to these parser functions. Michael Z. 2013-04-10 07:02 z
Will with new templates, thanks again. --Anatoli (обсудить/вклад) 07:18, 10 April 2013 (UTC)[reply]
Why did you make it so wide? It looks really bad on my computer now. —CodeCat 15:56, 10 April 2013 (UTC)[reply]
It wouldn’t use the full width of the column before – the restriction forced the text to wrap and look like a confusing jumble. Now you can control its appearance by resizing your browser window, as you can everything else in Wiktionary. It not only looks better in my usual window, but restore control to the reader. Michael Z. 2013-04-10 17:23 z
(And I suggest upping the text size by one notch – makes all of Wiktionary much more readable.) Michael Z. 2013-04-10 17:25 z
The width should be dependent on the contents of the table, not the width of someone's screen. It's far too wide on my 1080p screen, most of it appears as empty space. —CodeCat 18:02, 10 April 2013 (UTC)[reply]
You are right, and I think I know how to do that. Give me an hour. (Although why does your window width depend on your screen instead of the content of a fluid-width website? I find it impossible to read 300-character lines of text.) Michael Z. 2013-04-10 18:34 z
Nope, my initial solution won’t work because the NavBars script is inflexible. How are you with javascript? MediaWiki:Common.js#NavBars
The solution was to give the table no width, and a bit of extra horizontal padding on the td’s and th’s, so it would find its own correct width according to its content. Then .NavFrame { display:table; }, .NavHead, .NavContent { display:table-row; }, so these divs also shrink to fit the content. And if the viewport gets too narrow, only then will the lines wrap.
Two problems:
  1. NavBars is hard-coded to bail out if there are any other class names on the top-level div. “NOTE: some templates use a class of NavFrame for the style, but for legacy reasons, are not NavFrames.” Why the eff didn’t they just pick a name without “legacy reasons?” Anyway, I could work around this by hard-coding inline styles, although I hate splitting up the styles between the style sheet and the template.
  2. The script works by toggling between hard-coded display:block and display:none;. Do you think you could make it get the div’s starting display value, and then restore it?
Another alternative would be to replace the NavBars script with mw:JQuery.makeCollapsible or something else. Michael Z. 2013-04-10 19:12 z
What is wrong with the fixed width that the template originally had? —CodeCat 00:29, 11 April 2013 (UTC)[reply]
I prefer the fixed width as well. If you wish, I could test with very long verbs.
Reflexive, intransitive, imperfective: {{ru-conj-2a|vi|stem1=интернационализи́рова|stem2=интернационализи́ру|refl=y|aspect=impf}} --Anatoli (обсудить/вклад) 01:10, 11 April 2013 (UTC)[reply]
Setting width: 50em is arbitrary. It is too narrow for long words when the reader has a wider display, and it is too wide when the reader has a narrower display. And it steals control from the reader who is able to resize the viewport. It isn’t terrible, but, the way HTML tables work by default is better, adjusting to both the content size and container size. Unfortunately, our collapsing NavBars script uses divs, which don’t behave that way. but this doesn’t seem like a good reason to override the HTML tables behavior. Michael Z. 2013-04-11 15:00 z
It may be arbitrary, but at least it works. The current setup definitely doesn't, because more than 50% of the table is empty space on my screen. —CodeCat 15:20, 11 April 2013 (UTC)[reply]
Which is why I asked if you are able to fix the JavaScript. If not, I will try to struggle through it. (jQuery.collapsible has other problems.) Michael Z. 2013-04-11 15:32 z
What about using a completely different way to make collapsible tables, one which doesn't rely on div elements as a container? —CodeCat 15:33, 11 April 2013 (UTC)[reply]
Thinking about that too. It would be nice to just set a class on a table. Even better if the table caption served as the label.mon the other hand, there are already two collapsing scripts available, and there would be advantages to improving one instead of adding a third. Michael Z. 2013-04-11 15:46 z
Which is the other one? —CodeCat 16:08, 11 April 2013 (UTC)[reply]
mw:JQuery.makeCollapsible. Here it is on a copy of our table. It’s not terrible either. Preserving the table’s width in the collapsed state would make for a less-jarring transition. The script allows us to choose where the control goes, but doesn’t seem to work in the caption. Given that, it is a flaw that the caption does’t collapse with the table. Michael Z. 2013-04-11 16:31 z

User:Mzajac/temp2

Using nested tables allows for the title block and hides the caption. Michael Z. 2013-04-11 21:08 z

User:Mzajac/temp3

Hi Michael. Thank you for your efforts. Will address your questions as well, if CodeCat hasn't done it before. Just a bit busy with grammar questions. --Anatoli (обсудить/вклад) 23:51, 11 April 2013 (UTC)[reply]
  • I must say that the variable-width expansion functionality (provided by jquery.makeCollapsible if I understood correctly) looks fabulous. This would enable having inflection tables unobtrusively integrated in the inflection line. We could get rid of both "principal parts" in the inflection line and separate ==Conjugation==/==Declension== section. --Ivan Štambuk (talk) 21:19, 29 November 2013 (UTC)[reply]

The Lua version[edit]

I have changed Template:ru-conj-1a to use the Lua version, and I've added it to делать and сделать. Is it any good? —CodeCat 18:35, 11 April 2013 (UTC)[reply]

Looks great and it's correct! Will comment and make suggestions on Module:ru-verb. --Anatoli (обсудить/вклад) 22:23, 11 April 2013 (UTC)[reply]
I haven't thought of a good way to specify intransitive verbs yet. I could add a parameter for it, but since there is already a pf/impf parameter, we could also turn that into a combined parameter with pf-tr, impf-tr, pf-intr, impf-intr? Or, since most verbs are transitive in many languages, we could also just decide that impf and pf alone imply transitive, and you add -intr to make it intransitive. —CodeCat 22:26, 11 April 2013 (UTC)[reply]
Now that the Lua version works right, we don't really need this anymore? —CodeCat 12:45, 14 April 2013 (UTC)[reply]
Can we keep this one until we have a template with all forms as parameters, please? Just in case for any weird verb in the future. This one is better to use than the ones majority of verbs currently use. --Anatoli (обсудить/вклад) 12:56, 14 April 2013 (UTC)[reply]