Модул беседа:Wd

message: Преместено от Потребител беседа:Nk. --17:11, 23 август 2021 (UTC)
Здрасти. Един много стар проблем в Уикидата, който го обсъждах навремето със Стан, но продължава. Виж Бахово - като отвориш обекта в Уикидата  координатите са напълно верни и на картата излиза. Като щракнеш обаче върху координатите от нашата статия излиза некъде доста на юг. Това съм го засичал може би вече стотици пъти - като сложа нови координати се оправя - тоест ако сега заместя съществуващите в обекта на Бахово координати с тези 41°1'25"N 22°0'29"E примерно, ще се оправи. -- Мико (беседа) 15:57, 23 август 2021 (UTC)
replies: text: Работата е доста увъртяна. По някаква причина ботът, който е качвал координатите, им е слагал точности от рода на +/-0,1191..°   (които явно се запазват при последващи ръчни редакции, ако не им обърнеш специално внимание ). Нашият модул, при пренасяне на данните, ги закръглява до тази точност. Ще махна закръгляването засега, дано не се счупи нещо друго. --Спас Колев (беседа) 17:06, 23 август 2021 (UTC)
replies: text: : Само да добавя, че този проблем не би трябвало да е актуален за населените места в България. Всички вече са с координати с максимална прецизност. --Nikola Tulechki (беседа) 08:08, 8 септември 2021 (UTC)
replies: text: :: Не знам доколко е трудно и дали би могъл да коригираш това за останалите села в историческа Македония? В повечето случаи ние сме първата Уикипедия със статия за тях и често само тук им се отделя някакво внимание, та надали някой друг ще тръгне да го оправя. --Спас Колев (беседа) 06:20, 11 септември 2021 (UTC)
thread_title:  Закръгляване на координати 

message: Преместено от Потребител беседа:Nk. --07:26, 14 май 2022 (UTC)
Почнало е да вкарва и г. в препратката на родените и умрелите, което е ужасно тъпо. Не знам къде е да го махна. -- Мико (беседа) 16:14, 12 май 2022 (UTC)
replies: text: Намерих го къде е (т.е. мисля, че мога да го поправя), но според мен винаги си е било така. Ако ще се коригира, само за година ли да е или също за век, хилядолетие и т.н.? --Спас Колев (беседа) 15:29, 13 май 2022 (UTC)
replies: text: : Ами, само цифрите трябва да са в препратката - и за век и за хилядолетие. Това е град София, което си е англицизъм некъв. -- Мико (беседа) 15:54, 13 май 2022 (UTC)
replies: text: :: Не баш - за вековете "век" си е в името на статията (то и за годините има логика, но така е подкарано покрай ен:). Все едно, коригирам го, ако някъде се получи много зле, някой ще се оплаче. --Спас Колев (беседа) 07:25, 14 май 2022 (UTC)
thread_title:  "г." в препратки за година 

message: Вижте втория източник в статията Абий Ахмед. Не само че авторите са трима, а пише името на само единия от тях, но и е сложено описанието на свойството P2093, а именно низ с името на автора, което е много грозно. Carbonaro. (беседа) 15:57, 10 октомври 2023 (UTC)
replies: text: Нормално да се случва така, след като за едно и също нещо има минимум 2 – 3 свойства. Ту се използва едното, ту другото. В случая за автор има поне две свойства, дето се ползват масово: едното е за имена на автори, които са известни (?) (явно имат страници в УД); другото е за автори, които са неизвестни (?) (нямат страници в УД). Странен поход, но не е първи случай. Дори и да минаваше през , няма да се покаже повече от един автор с текущата логика както на модула, така и на шаблона – който се интересува, може да погледне двете, за да установи защо би се получило така. Ще се налага преработка, това е ясно... --Ted Masters (беседа) 20:23, 11 октомври 2023 (UTC)
replies: text: : А да го закоментираме и да забравим за случая?  Carbonaro. (беседа) 20:31, 11 октомври 2023 (UTC)
replies: text: :: Не. --Ted Masters (беседа) 20:50, 11 октомври 2023 (UTC)
replies: text: :::Ted Masters, ти си един от най-отговорните уикипедианци. Проблемът с авторите изобщо не е елементарен – и да се измисли нещо, пак няма гаранция, че ще работи. Дори не знам как ще се получи цитирането по БДС, където форматът е фамилия, име. Понеже предполагам, че пак ти по неволя ще се заемеш с тази сложна задача, а след всичко най-много да стигнеш до прегряване, засега недей да мислиш за модула. Аз ще проуча възможностите, не е спешно. Carbonaro. (беседа) 17:33, 12 октомври 2023 (UTC)
replies: text: :::: Не е елементарно, понеже трябва да се предвидят няколко възможни случая. И е нужно да има междинен вариант при всички. Ти хубаво си толкова стриктен относно цитирането по БДС, но нали не забравяш, че и на други места това не се спазва изрядно. Това не е оправдание, разбира се, но не е и нужно да се хващаш за сламки постоянно. Понякога малко е по-добре от нищо, а що се отнася до източниците, аз съм на мнение, че по-добре да има информация в източника, макар и тя да не следва напълно правилата за форматиране, отколкото да липсва напълно. За прегарянето ми не се притеснявай, не съм чак толкова натоварен. Нервен съм, както може би вече си усетил, но причините не са свързани с работата ми в проекта. Опитвам се да не го показвам, но на моменти си ми личи – има хапливи реплики и леко по-нетактични коментари.  --Ted Masters (беседа) 17:59, 12 октомври 2023 (UTC)
replies: text: ::::: Добре, няма да се притеснявам.  Не съм казал, че задължително трябва да е по БДС, просто така предполжих, че искаш да се направи, като се завъртя разговорът около . Carbonaro. (беседа) 19:22, 12 октомври 2023 (UTC)

text: . Проблемът с авторите е решен. Вече всяко цитиране минава през базовия , за да се следва що-годе един стандарт. --Ted Masters (беседа) 04:52, 13 октомври 2023 (UTC)
replies: text: : Колкото и да ти плащат, няма да е достатъчно. Carbonaro. (беседа) 05:55, 13 октомври 2023 (UTC)
replies: text: ::  Тук не ми се плаща. А там, където ми се плаща, бих казал, че си е задоволително. Нищо де, щом казваш, ще знам да си вдигна акциите по-нататък.

text: :: Тази редакция обаче не ми е много ясна? Цели се избягване на наклонените черти от  ли, ако са само URL и заглавие? Ако да, по-скоро трябва да се оправят проблемните шаблони, а не да се прави излишна гимнастика в модула. Бях тръгнал да го правя, но имах друг ангажимент сутринта и затова го оставих за после. --Ted Masters (беседа) 18:44, 13 октомври 2023 (UTC)
replies: text: ::: Това май беше пример за т. нар. предположителна глаголна форма, обект на доста противоречия напоследък – знам, че не се, защото е доброволчески проект, но ако се заплащаше, нямаше да е достатъчно, сещаш се...

text: ::: Да, това беше идеята. Още по-добре, ако се направи в самите шаблони! Carbonaro. (беседа) 19:02, 13 октомври 2023 (UTC)
replies: text: :::: Ох, ама и ти веднага клъвна, рибке.  Не е нужно да ми се обясняваш, че си направил предположение. Аз го приех и като шега, и като комплимент.

text: :::: За шаблоните: аз имам грижата, не се притеснявай. След това ще махна излишната проверка в модула. --Ted Masters (беседа) 19:12, 13 октомври 2023 (UTC)
replies: text: ::::: Хахахаха. Carbonaro. (беседа) 19:20, 13 октомври 2023 (UTC)
thread_title:  Низ с името на автора 

message: : Преместено от Уикипедия:Разговори --Ted Masters (беседа) 19:30, 29 януари 2024 (UTC)
----
replies: text: Преместено от У:ЗА. — Luchesar • Б/П 18:48, 12 януари 2024 (UTC)
----
Здравейте, Опитах се без успех да коригирам името на кмета на Берлин. В шаблона четем Вили Брандт (вече покойник). Сегашният кмет от 27.04.2023 г. е Кай (Петер) Вегнер. Моля който може, да го поправи. Благодаря!   Glagoli (беседа) 14:45, 12 януари 2024 (UTC)

text: В Уикиданни на пръв поглед изглежда нормално, но може и нещо да пропускам. Иначе може би е проблем в  или .— Luchesar • Б/П 18:49, 12 януари 2024 (UTC)

text: Нужно е да привличаме повече активни редактори, които да бъдат запознати как да обработват шаблони. --PowerBUL (беседа) 20:13, 12 януари 2024 (UTC)
replies: text: : Липсваше етикет с името на български, затова вадеше първата стойност, която има зададен етикет на български, дори и тя да не е с ранг предпочитан. --Ted Masters (беседа) 20:17, 12 януари 2024 (UTC)
replies: text: :: Трябва да има повече пояснителни страници. --PowerBUL (беседа) 20:25, 12 януари 2024 (UTC)

text: :: Благодаря ти, Ted! Хммм, интересно, това дали може и дали има смисъл, ако може, да се промени като логика? Според мен може би е по-добре да показваме фактологично вярна информация на чужд език, отколкото неточна на български. А може би може да възникне като казус и в много други случаи, не само за кметове.— Luchesar • Б/П 20:36, 12 януари 2024 (UTC)
replies: text: ::: Лъчо, трябва да прегледам модула по-обстойно, за да видя доколко това е възможно и дали изобщо ще е решение. Спомням си, че преди година (може би две вече) експериментирах с извеждане на чуждоезични стойности, но бях се натъкнал на следния проблем – дали да се извежда информацията на първия срещнат език, ако основните липсват (под основни да се разбират: 1. bg – като главен за нашата езикова част; 2. en – default fallback), и доколко полезно ще е това за читатели и редактиращи, които така или иначе се затрудняват със структурата и редактирането в Уикиданни – а те май са мнозинството. Самият проект Уикиданни извежда имената на обектите на предпочитания от потребителя език, след това на английски (default fallback за УД, ако предпочитаният липсва), а ако и двете не са възможен вариант, показва номера на обекта (като Qxxxx). Вероятно и това трябва да бъде съобразено и премислено. --Ted Masters (беседа) 21:17, 12 януари 2024 (UTC)
replies: text: :::: Не знам доколко е лесно да се модифицира модула в тази посока, но според мен очакваното поведение би трябвало да е: при наличие на стойност с даден ранг, стойностите с по-нисък изцяло да се игнорират. --Спас Колев (беседа) 08:10, 13 януари 2024 (UTC)
replies: text: ::::: Може да помилсим за бот, който транслитерира и добавя етикети и превежда описания на български. Има такива на украински и на арабски които системно цвъкат  по новите обекти, които създавам. --Nikola Tulechki (беседа) 10:22, 13 януари 2024 (UTC)
replies: text: :::::: Благодаря на всички за усилията!:) - Glagoli (беседа) 11:28, 13 януари 2024 (UTC)

text: :::::Струва ми се, че няма да е толкова лесно за постигане. Имаме различни типове данни на свойствата и квалификаторите. Посоченото поведение би било очаквано най-вече при тип на обекта wikibase-entityid, но би могло да бъде вредно при останалите типове данни. И дори за wikibase-entityid не съм много сигурен, тъй като не знам какво ще бъде поведението, ако имаме посочена приблизителна дата (чрез параметъра |date=), а резултатът с ранг предпочитан се окаже, че няма посочена такава. Ted Masters (беседа) 13:03, 13 януари 2024 (UTC)
replies: text: :::::: Вероятно си прав. А нещо, което да събира такива случаи в категория, за да се обработват допълнително (ръчно или с бот, както предлага Никола)? --Спас Колев (беседа) 07:38, 14 януари 2024 (UTC)
replies: text: :::::::Хм, добър въпрос. Мисля, че би могло да се направи, но ползата от такова категоризиране я виждам предимно за ръчното коригиране. За да може ботът да прави по-нататъшно обработване, ще се наложи първо да прави допълнителни проверки на свойствата в съответния обект, тъй като категорията в най-общия случай ще показва самата страница, т.е. обекта. Ted Masters (беседа) 12:34, 14 януари 2024 (UTC)
replies: text: :::::::: Трябва да може да стане - в груб вариант просто ще добавя (вероятно с ръчно задаване на стойностите) липсващите български етикети на всяко свойство във всеки обект от категорията. Пак ще е много по-добре таргетирано от бот, който блуждае из целите Уикиданни. --Спас Колев (беседа) 15:25, 15 януари 2024 (UTC)
replies: text: :::::::::Е, и аз това имах предвид.  Страницата (обектът) просто се явява някаква отправна точка, но нищо повече. Оттам нататък ботът ще трябва да минава по свойствата (потенциално и квалификаторите) на самия обект и да проверява посочените по тях обекти за липсващи етикети, описания и синоними.

text: :::::::::Иначе проблемът с неактуалните данни за постове – и май като цяло за свойства, които така или иначе са за период от време (т.е. имат начало и край) – може да се реши частично чрез посочване текущата дата (ориентировъчен пример – ако приемем, че липсата на информация би бил по-добрият вариант от варианта с налична, но неразбираема или грешна информация). Казвам частично, защото все пак не трябва да забравяме, че се касае за Уикиданни, където няма гаранция за пълнотата и точността на посочената информация въпреки огромния брой ботове и редактиращи.

text: :::::::::За други или по-заплетени казуси обаче си остава въпросът кое би било най-доброто и ефикасно решение. Ted Masters (беседа) 18:03, 15 януари 2024 (UTC)
 По предложението на Спас винаги да се извличат стойностите с най-висок ранг (с леко допълнение от мен: ако няма посочени някакви специални флагове и ако стойностите не представляват многоезични текстови стойности) съм съгласен. Правя генерално обобщение след тестовете на горепосочените два варианта:
# Извличане на чуждоезични стойности или стойности на английски/името на обекта в Уикиданни (ако няма етикет нито на български, нито на английски): Този вариант би бил удачен при резултат с една стойност (property), но при резултатите с повече стойности (properties) е много вероятно да се наблюдава неконсистенто поведение: микс от текст на всевъзможни езици и/или заглавия на обекти в Уикиданни. Това би било по-скоро объркващо.
# Запазване на сегашното поведение, като при абсолютно празни стойности се добавя проследяваща категория: Тук има едно нещо, което ме притеснява. Добавянето на категория към крайния резултат (де факто празен низ) може да счупи функционалността на доста места: в парсерни функции (особено засегнати могат да бъдат често ползваните #if:, #switch: и #expr:), в шаблони или модули, които разчитат на празни стойности, в хипервръзки от всякакво естество, както и ако това се окаже извиквано някъде в суров JSON/Data код (mapframe?/maplink?). В самите инфокутии и навигационни кутии това би довело до визуализиране на празни редове и колони. Това, разбира се, може да се заобиколи сравнително лесно в част от модулите (напр. Модул:Infobox и Модул:Navbox) и/или шаблоните, но за останалите случаи не мисля, че има единно и лесно решение. Вариант е да се добави параметър в Модул:Wd, който да отменя проследяването при нужда, или да се импортира :en:Module:Suppress categories и да се използва като wrapper на определените за това места. Ако все пак някога решат да въведат опцията да се добавят категории директно от Lua модулите, без да се засяга изходният низ, ще е чудесно, защото това би решило много от проблемите, които съм описал по-горе.
Според мен вече става препоръчително да се добавя и параметърът edit (или edit@end) към , който бива извикван в инфокутии, тъй като това би дало възможност на повечето редактори да видят, че стойността се издърпва от УД, освен че дава и директна връзка към свойството/обекта за по-нататъшно редактиране/коригиране. Ако някой има други, по-ефикасни идеи, нека сподели. Отворен съм за още мнения и предложения. --Ted Masters (беседа) 16:02, 17 януари 2024 (UTC)

text: Модулът е преработен така, че да извлича и връща стойностите с най-висок ранг при липсващи специални флагове. Проследяването чрез категории се въздържам да го въведа на този етап. Струва ми се, че това би отворило твърде много работа на други места, а ползата от категоризирането ми се вижда, че ще е минимална, да не кажа даже никаква – не виждам как бот автоматично би правил транслитерации/транскрипции на етикетите за български (при толкова голямо разнообразие на езиците). Ако по-нататък добавят функцията за добавяне на категории директно през скрипта, ще вмъкна категоризиране. Сега при предварителен преглед поне ще се извежда предупреждение директно от модула в началото на статията със съответните редове. И това не вярвам да донесе някаква полза, но поне не би довело до евентуалното счупване на милион други неща насам-натам.  --Ted Masters (беседа) 19:56, 29 януари 2024 (UTC)
thread_title:  Кмет на Берлин