User talk:Vitalik

Hello, welcome to Wiktionary, and thank you for your contributions so far.

If you are unfamiliar with wiki-editing, take a look at Help:How to edit a page. It is a concise list of technical guidelines to the wiki format we use here: how to, for example, make text boldfaced or create hyperlinks. Feel free to practice in the sandbox. If you would like a slower introduction we have a short tutorial.

These links may help you familiarize yourself with Wiktionary:

• Entry layout (EL) is a detailed policy on Wiktionary's page formatting; all entries must conform to it. The easiest way to start off is to copy the contents of an existing same-language entry, and then adapt it to fit the entry you are creating.
• Check out Language considerations to find out more about how to edit for a particular language.
• Our Criteria for Inclusion (CFI) defines exactly which words can be added to Wiktionary; the most important part is that Wiktionary only accepts words that have been in somewhat widespread use over the course of at least a year, and citations that demonstrate usage can be asked for when there is doubt.
• If you already have some experience with editing our sister project Wikipedia, then you may find our guide for Wikipedia users useful.
• If you have any questions, bring them to Wiktionary:Information desk or ask me on my talk page.
• You are encouraged to add a BabelBox to your userpage to indicate your self-assessed knowledge of languages.

Enjoy your stay at Wiktionary! --Cinemantique (talk) 17:41, 4 July 2015 (UTC)Reply

Thanks, Cinemantique. I'm glad to see you here! --Vitalik (talk) 20:42, 4 July 2015 (UTC)Reply

Can you tell me what are you trying to accomplish here? — Keφr 15:11, 7 July 2015 (UTC)Reply

Hi Keφr, yes, of cause. Thanks for interesting that!

As for now we have a lot of different instruments for building inflection tables in the Wiktionary (either a huge amount of special templates, or language-individual complex modules, or even both of them).

• Templates (i.e. for russian)

They are easy to create and easy to use.

But it can be difficult to change them all together or add something "intellectual" there. Also it can be a little problem to choose a proper one from the large amount templates.

• Modules (i.e. for russian)

They are easier to use. We don't need to know about huge amount templates (their names, different arguments, etc.). Also we can implement more complex logic there (i.e. determine class and stem endings automatically).

But they are hard to create (only programmers can do that) and it also hard to change/understand another's module even if you are programmer.

So we propose to create only one super-module (not so complex) and special data-modules with inflection rules for each language. And this approach combines advantages of both old approaches (without their disadvantages).

Any user can create or change such data-module. You don't need to be a programmer for that. And also we can provide any complex logic in such data-modules.

I'll certainly write documentation and instructions for that. But if you have any questions please ask me. Vitalik (talk) 16:07, 7 July 2015 (UTC)Reply

…while creating other disadvantages. "Any user can create or change such data-module. You don't need to be a programmer for that. And also we can provide any complex logic in such data-modules." -- these are mutually incompatible. If your "super-module" supports arbitrarily complex logic, you are effectively creating a programming language. And programming language or not, this data module language will be something that has to be learned. Also, adding yet another layer of code means adding yet another layer of code which can fail.

I have never encountered a module on this project whose code I could not follow, except for some imports from w:. Now notice that I had to ask you what your code does. Sure, you can write INTERCAL in any language, but problems of comprehensibility are generally addressed by appropriate conventions. People like Anatoli or Vahag, who know little Lua, create practical transliteration modules on a semi-regular basis; admittedly by naïve copy-paste and reasoning by analogy, but you cannot say they have no understanding at all of what they do. So I think you really overstate this "programming languages are too hard" thing. Even if this is a problem, creating another language to be learned is not the right solution.

I think inflection modules and tables should be handled by per-language modules using simple and direct Lua constructs, so that all you have to do to understand them is laid out right there on a single page. I doubt you can create a single centralised module to satisfy all languages' requirements and manage to end up with anything sane.

(Also, интересоваться does not translate as to interest. But I nitpick.) — Keφr 17:46, 7 July 2015 (UTC)Reply

Thanks for your opinion and explanations. Let me add my thoughts on your words.

• I believe that it's really possible to build solution that will allow us to describe enough complex logic with quite easy description rules in data-modules. And I believe it will be possible to write sufficiently simple central module for that. Let's just check is it possible indeed or not.
• That's correct that we are adding something like "new layer of code" (which can fail), but if central module is sufficiently tested then it will be less likely failed with new data-modules.
• I didn't mean that "programming languages are too hard", I've just meant that it can be hard to investigate another's modules sometimes. And if we have individual modules per each language (and those modules are written by different users) we'll have to gain an understanding of each module individually again and again.
  It would be ideally if all individual inflection modules would be written in common and simply understandable way but I think it almost impossible because anyway each user will bring his own (individual) way of coding.

A few words about "syntax" of suggested data-modules:

• We have three sections there: "affixes" (where we describe some string constants), "conditions" (where we describe some checks and rules) and "classes" (where we describe how to generate resulting word forms) and we can use existing templates with declension/conjugation tables (just to display resulting word forms in usual way).
• Each condition in section "conditions" can contain some checks (i.e. "last" to check last symbols of base word, "arg" to check value of template argument) and some actions (i.e. "set" to set value for affix/variable, "add_class" to apply some class from "classes" section, "replace" to change value with using regexp).

It will be quite simple and understandable syntax. It will be much easier to understand and use it than to investigate and fix individual modules written on Lua. I'll write documentation for it when it will be enough tested and ready to be proposed to wiki-community.

And thanks for pointing on my English mistakes, my English isn't really excellent yet :) --Vitalik (talk) 18:58, 9 July 2015 (UTC)Reply

1. One missing function is to match the number of forms (13 forms of "печь") against expected 13.

See User:Vitalik/inflection/units/ru-noun/testcases/other

2. main page could be prettier:

• Module:es-conj/data/-ar - we can display refults from subpages at one page
• Module:User:Vitalik/inflection/units/ru-noun/testcases

I have no clue how to implement it with LUA yet. d1g (talk) 08:01, 17 April 2017 (UTC)Reply