D6194c-1cc

upper respiratory tract infection (Q2622199) и acute viral respiratory tract infection (Q81194549)

Добрый день! Коллега, вы разделили элемент на два, но в результате в первом оказалась "Гостра респіраторна вірусна інфекція", что странно. Можете объяснить отличие в описании к этим элементам и правильно разделить по языкам? Wikisaurus (talk) 16:20, 14 January 2020 (UTC)

• Добрый! Инфекция верхних дыхательных путей не есть то же самое, что и ОРВИ, а соответственно и "Гостра респіраторна вірусна інфекція", поскольку вторая, судя по названию, и есть ОРВИ. Полагаю, что в Украине термин пришёл из русского языка. ОРВИ – термин принятый в русском языке, инфекция верхних дыхательных путей – в английском. ОРВИ же в английском раньше принято было обозначать как "viral ARI" (вирусная ОРИ) (ВОЗ, 1978). ОРВИ может быть только из-за вирусов. Инфекция верхних дыхательных путей – из-за вирусов, бактерий, грибков и простейших. Также ОРВИ включает в себя и нижние дыхательные пути по определению, в частности РСВ-инфекция у маленьких детей может вызывать бронхиолит (воспаление бронхиол, именно вирусный), а грипп по своей сути есть инфекция нижних дыхательных путей. Поэтому ОРВИ не является даже частным случаем инфекции верхних дыхательных путей. В других языковых разделах сюда же присоединили ОРИ, там мне сложнее понять, что к чему, поэтому оставил как есть на откуп тех, кто знаком с языком. В общем случае есть иерархия: ОРЗ <- ОРИ <- ОРВИ <- конкретная инфекция. ОРЗ включает в себя ещё и аллергию, помимо инфекций. Инфекция верхних дыхательных путей и ОРВИ являются частными случаями ОРИ. Врачи обычно ставят в качестве диагноза именно ОРИ, т. к. не могут достоверно узнать этиологию без лабораторных тестов. Для ОРИ, возможно, имеет смысл сделать ещё один элемент викиданных, но возможно, что это то же самое, что и "respiratory tract infection", пока не вникал в особенности этого термина, но популярный дословный аналог ОРИ в английском языке – ARI (Acute respiratory infection). -- D6194c-1cc (talk) 17:48, 14 January 2020 (UTC)
• Только сейчас понял, о чём именно Вы говорили. Я забыл, что помимо присоединённой статьи из Википедии есть ещё описания элементов на всех языках, и что это разные вещи. Думал, что Вы имеете в виду присоединённую страницу из Википедии. Действительно, не доделал. Спасибо, что поправили. Белорусский вариант я там тоже стёр, раз эти страницы перенесли. -- D6194c-1cc (talk) 17:03, 15 January 2020 (UTC)

Human / generic kidney

kidney (Q9377) is about the kidney of all vertebrates, not just of humans like ru:Почка (человека).--Art Kulik (talk) 16:57, 9 May 2022 (UTC)

• Wikidata describes human kidney too (metanephros, mammalian kidney), and most articles connected to it would be about human kidney. It was be easier to create new Wikidata entity. More information could be found in en.wikipedia.org/wiki/Talk:Kidney discussion initiated by me. I'm preparing new article about vertebrate kidney in english. --D6194c-1cc (talk) 17:17, 9 May 2022 (UTC)

Nevertheless I would change the interwiki at Q9377 from Почка (человека) to Почка, since all other languages (besides enwp) describe the vertebrate kidney.--Art Kulik (talk) 17:21, 9 May 2022 (UTC)

No. Why do you think that other languages describe vertebrate kidney? Most Wikipedia languages would describe human kidney as English wikipedia did with the same errors. I check some pages through google translator. The kidney of vertebrates is now kidney (Q111907436). --D6194c-1cc (talk) 17:35, 9 May 2022 (UTC)

Mostly wikis are just satellites of enwp, but German wiki explicitly talks about all vertebrates.--Art Kulik (talk) 17:39, 9 May 2022 (UTC)

"Von hier wird der Harn kontinuierlich über den Harnleiter (Ureter) zur Harnblase geleitet. Aus der Blase wird er gelegentlich über die Harnröhre (Urethra) ausgeschieden." - Birds for example have no urinary bladder, they have cloaca. German article tries to describe vertebrate kidney but makes the same mistakes. --D6194c-1cc (talk) 17:48, 9 May 2022 (UTC)

Oh no. You've merged them? Now it's a huge mess. I have refactored all to the new model: kidney -> metanephros -> human kidney. Now vertebrate kidney became human kidney again. --D6194c-1cc (talk) 17:40, 9 May 2022 (UTC)

I've NOT merged them. User:Infovarius ist currently editing.--Art Kulik (talk) 17:41, 9 May 2022 (UTC)

It would be hard to put things in order. I thought it would be easier. --D6194c-1cc (talk) 17:50, 9 May 2022 (UTC)

Well, it's okay. They were not merged. But instead kidney and human kidney were fully splitted from each other. Other wikipedia languages can make other work by themselves. --D6194c-1cc (talk) 09:39, 10 May 2022 (UTC)

From items to lexemes

First, my apologies if I have appeared a bit stubborn and single-minded.

I'm concerned that our recent exchange at Wikidata talk:Lexicographical data#Listing lexemes the topic (QID) consists of isn't very useful to anyone, so we are probably better off dropping it for the moment. In spite of my objections to your idea, I trust that you do see a real problem that should be solved, and I'm curious to learn what it is, so that I can provide more constructive comments towards a practical solution.

I understand from your explanations that you are working with Wikipedia internals (maybe just Russian Wikipedia, but possibly other languages as well). I have done some minor article edits plus talk page commentary in English and Swedish Wikipedia, but nothing substantial with the internals, which means I'm largely unfamiliar with the constraints your work may be subject to.

Since April of 2020, my focus has been on Wikidata, but I have also experimented a little with Lua code on Swedish Wikipedia to find out what can be achieved. While much of the Q-item namespace is language-neutral, some information is language-specific, and I would like to see the latter migrated to the Lexeme section. This is a process which will take time, in order not to destroy structures that Wikipedia and other language-specific projects still depend on.

However, adding more language-specific content to the Q-item namespace would mean going in the wrong direction, hence my opposition to that idea. As an interim approach, in my first comment to the thread you started, I referred to the linguistic pattern tables that I mentioned in the previous thread (which may have triggered your question). If I get to understand your problem better, I may suggest a solution using a similar table format, or some entirely different idea. Please let me give it a try, and feel free to be as verbose as you like! SM5POR (talk) 10:04, 27 November 2022 (UTC)

Currently I work with cite module that is intended to display information about different information sources in different languages. It's in a stage of writing tests, refactoring and adding side features. You can get more information at these pages in my sandbox (also see the sources): ru:Модуль:Песочница/D6194c-1cc/CiteGost, ru:Участник:D6194c-1cc/Черновик/Шаблон:Источник. The idea of the underlying modules is that they could be used in English Wikipedia and other Wikipedias. D6194c-1cc (talk) 11:59, 27 November 2022 (UTC)

I have created a small test file manually and uploaded it as Commons:Data:Sandbox/SM5POR/cite.tab to try using it from Lua according to mw:Help:Tabular Data. I don't have time to continue working on this tonight, but you may want to take a look and see if it could be useful to you. We'll have to figure out later how to generate larger files with the items you need automatically (I'm not out of ideas, just spare time). I had to create some missing senses and forms for the English and Swedish translations, but for Russian I didn't even find a lexeme "научный" to refer to. Since I don't know Russian myself (I get along with Google Translate), I'll leave the editing of Russian lexemes to you.

Since the GOST standard specifies that bibliographic records should be expressed in the language of the cited publication, which items and fields still need translation (or transliteration between Latin, Cyrillic and other scripts)? Publishing houses, author names, printing locations etc? What if a Swedish academic publisher (say, Uppsala University) publishes a dissertation in English, German or French? English is quite common in Swedish science publications these days, but Stig Strömholm (Q446338) wrote his doctoral thesis (on copyright law) in French.

I have a copy of Современний шрифт (1966) by Виллу Тоотс (found in a Swedish second-hand bookstore; typography and languages are a few of my interests)... SM5POR (talk) 21:17, 27 November 2022 (UTC)

Thanks for the example! It might be useful. I need to learn more about tabular data.
As for what I need to translate, I use abbreviations for some words and I've made proposal for the missing property: Wikidata:Property proposal/abbreviation. Also not all of the words may have abbreviations in certain languages and some words need to be abbreviated in plural form, so for some words I need to determine plural form and for other I need to get plural abbreviation form if such exists. It's a bit complicated task that cannot be solved be just one property in items (but the property is a good workaround).
For example I use abbreviated form of page (Q1069725) for the pages range, in English it needs to be pp. ([1]). If some another language have no such abbreviation than I need to get its plural form for the pages range. Some items have more than one lexeme in some languages, for example editor-in-chief (Q589298) ("Гл. ред.: Иванов А. А., Петров Б. Б."). I doubt that the situation when more than 1 editor-in-chief is possible, but for universal purposes I need to take it into account.
Tabular data on Commons can be edited by anyone so it's a better solution than a map inside Lua module. As I understand currently tabular data lacks user-friendly edit interface. The main idea of Wikidata usage is that items can be edited by anyone from any country (no need to edit modules). D6194c-1cc (talk) 08:01, 28 November 2022 (UTC)

As to the property proposal (I hadn't seen it before), I definitely agree with the advice to apply it to the lexeme domain only (not sure if it should be on senses or forms). Applying it to Q-items is going to be messy, even when the abbreviation may be identical in multiple languages (consider sign language where not even written letters are used). An abbreviation is part of the language, not of the inherent semantics of the item. But isn't there such a property for abbreviations already? I don't have time to find out now. SM5POR (talk) 11:30, 28 November 2022 (UTC)

It solves big mess with short name, acronym, initialism, or abbreviation not unique (Q64699537). This property is a mess of acronyms, abbreviations and short names (and you probably cannot specify both a short name and an abbreviation, because it could break some Wikipedia templates). If I want to show just a short name I have to analyse the string rather that just get the value. Three different properties are a good workaround until lexemes arrival to the items. D6194c-1cc (talk) 12:23, 28 November 2022 (UTC)

If another language-related property (or three) solves an actual, current problem in Q item space, fine, I won't stand in your way, but I'm convinced this is not how Wikidata is either meant to or should evolve in the long run. In particular, I don't want to see "lexemes arrive at the items", at least not in a visual way. I'd rather see the items arrive at the lexemes, but I'll elaborate on that later.

I began writing a piece explaining my concerns, but it has grown kind of long, and should probably be posted somewhere that makes it reach a wider audience. Before I do that, would you be willing to read it through and let me know how I come across, whether I'm making myself understood, if I'm too verbose or whatever? I'll let you know when it's ready and I have it posted among my own pages. SM5POR (talk) 05:32, 29 November 2022 (UTC)

By the way, the table is an interim solution. I don't want to list multiple language expressions for items forever; we need a way to generate those phrases automatically based on the semantics of the items. And users will need a simple interface to add information affecting the expressions; letting them edit the raw and cryptic pattern tables directly is not a good idea. SM5POR (talk) 11:42, 28 November 2022 (UTC)