[Wikidata-bugs] [Maniphest] T216601: Allow download of Wikidata query results in GPS-friendly format(s)
mxn added a comment. As noted in that discussion, QLever can export GeoJSON, with the caveat that its replag is measured in days or weeks and the GeoJSON it outputs is slightly oddly formatted. TASK DETAIL https://phabricator.wikimedia.org/T216601 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Tagishsimon, Reedy, Arian_Bozorg, ItamarWMDE, valerio.bozzolan, Jklamo, Gehel, MPhamWMF, Lydia_Pintscher, JeanFred, Nemo_bis, Husky, Peb, Frettie, Geertivp, Salgo60, Pigsonthewing, Aklapper, Danny_Benjafield_WMDE, Isabelladantes1983, Themindcoder, Adamm71, S8321414, Hellket777, LisafBia6531, Astuthiodit_1, AWesterinen, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Dringsim, Hook696, darthmon_wmde, Kent7301, Ferenczy, sarhan.alaa, Samuditha24, IM3847, CucyNoiD, Nandana, Namenlos314, kostajh, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Jayprakash12345, Chicocvenancio, MichaelSchoenitzer_WMDE, Mahir256, QZanden, EBjune, KimKelting, merbst, LawExplorer, Lewizho99, Maathavan, Jogi_don, _jensen, rosalieper, xSavitar, Neuronton, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, jayantanth, Rxy ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T334333: Add rel=me attribute to external identifier links on Wikidata items
mxn added a comment. The sparse FAQ <https://microformats.org/wiki/rel-me-faq> about `rel="me"` made it sound like it’s purely about whether the two pages represent the same entity, but this documentation <https://microformats.org/wiki/identity-consolidation> does emphasize the need to make identity consolidation an opt-in, which the feature requested here definitely would not be. I’d be OK with closing this issue unless there’s some way to make the linking more nuanced. TASK DETAIL https://phabricator.wikimedia.org/T334333 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: AntiCompositeNumber, TheresNoTime, Aklapper, Legoktm, mxn, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T334333: Add rel=me attribute to external identifier links on Wikidata items
mxn updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T334333 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Aklapper, Legoktm, mxn, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T334333: Add rel=me attribute to external identifier links on Wikidata items
mxn created this task. mxn added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **Feature summary**: A Wikidata item should have the `rel="me"` attribute on any link in an external identifier statement. **Use case(s)**: This would enable services to recognize that the Wikidata item represents the same entity as the linked external database record. For example, a notable user on Mastodon could add a verified link from their profile <https://docs.joinmastodon.org/user/profile/#fields> to the Wikidata item about them. It is already possible for the Mastodon user to link to the Wikidata item, but Mastodon will only mark the link as “verified” if the item contains a `rel="me"` link back to the Mastodon profile. Mastodon will recognize the link back to the Mastodon profile in a Mastodon address (P4033) <https://www.wikidata.org/wiki/Property:P4033> statement. **Benefits** (why should this be implemented?): Wikidata’s identifier statements are useful as a hub for all the different records about an entity across the Web. Although Mastodon is a somewhat contrived example, other sites might use XFN’s `rel="me"` microformat to distinguish Wikidata’s authority control coverage from other external links. Unlike T322717 <https://phabricator.wikimedia.org/T322717> and T31968 <https://phabricator.wikimedia.org/T31968>, this feature would be scoped to entities who satisfy Wikidata’s notability criteria <https://www.wikidata.org/wiki/Wikidata:Notability>, not necessarily Wikimedians (although there is some overlap <https://www.wikidata.org/wiki/User:Multichill/Questionable_notability_Wikimedians>). TASK DETAIL https://phabricator.wikimedia.org/T334333 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Aklapper, Legoktm, mxn, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T63958: Use existing $dateFormats to format dates on Wikidata
mxn added a comment. This issue still affects any language that numbers its months instead of naming them. Chinese, Japanese, Korean, and Portuguese have been mentioned above, to which I’d add Vietnamese. These languages have narrow month “names” that are just bare numbers <https://unicode-org.github.io/cldr-staging/charts/41/summary/vi.html#62bca2005afce142> and instead rely on date formats to append a prefix or suffix to the month name. In T63958#3286620 <https://phabricator.wikimedia.org/T63958#3286620>, @thiemowmde wrote: > No matter what the users language is, everybody can distinguish day, month and year in "10 November 2017". But we can not assume everybody understands what the month in "2017-11-10" is. This is actually the 11th of October in certain regions of the world. As things stand, dates formatted by Wikibase aren’t necessarily recognizable as dates, let alone the correct dates. For example, Wikibase formats January 25, 2002, as “25 1 2002 <https://www.wikidata.org/wiki/Q10995651?uselang=vi#P571>”. By contrast, ever since T8910 <https://phabricator.wikimedia.org/T8910>, the rest of MediaWiki has correctly formatted the same date as “ngày 25 tháng 1 năm 2002” based on `$dateFormats['vi normal date']` (source <https://doc.wikimedia.org/mediawiki-core/1.34.4/php/MessagesVi_8php.html#a2fc93ea5327f655d3ed306e221ee33f0>). One might deduce that “25 1 2002” is a date in day-month-year format, but that’s hardly assured for every day of the year. It’s even worse with dates outside this millennium, like “22 11 874 <https://www.wikidata.org/wiki/Q1010530?uselang=vi#P569>”. I wholeheartedly agree with commenters above that ISO 8601 format would’ve been preferable, even at the expense of temporarily regressing localized date formats in some other languages. The root cause seems to be this method <https://github.com/wikimedia/Wikibase/blob/8cd12697b6726cb052aa416765b197bc42188ad6/lib/includes/Formatters/MwTimeIsoFormatter.php#L119-L124>, which makes some language-centric assumptions. It correctly calls `getDateFormatString()` to get the localized date format, but then it scans the format string for a number followed by a period or comma <https://github.com/wikimedia/Wikibase/blob/8cd12697b6726cb052aa416765b197bc42188ad6/lib/includes/Formatters/MwTimeIsoFormatter.php#L138> and a word followed by a period or comma <https://github.com/wikimedia/Wikibase/blob/8cd12697b6726cb052aa416765b197bc42188ad6/lib/includes/Formatters/MwTimeIsoFormatter.php#L153> for the month component. It inserts these “formats” into a hard-coded string format `%s %s Y` then passes it into `sprintf()`. Effectively, it extracts a choice of the “Month” and “Day of the month” formatting codes in this table <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#%23time> but discards any other information from the date format. In T63958#3284229 <https://phabricator.wikimedia.org/T63958#3284229>, @thiemowmde wrote: > @deryckchan, simply because the software must understand itself. The formatted date is what appears in the edit field. We do not want to show the unformated -MM-DD there as this would be even more confusing, so we show it formatted. You want to edit this, and expect the software to accept the format it was outputting before. > > With no parser that is able to understand all formats (and not confuse them!) we can't output all formats. It is possible to solve this problem without mangling date formats. For example, the Comments in local time <https://en.wikipedia.org/wiki/User:Mxn/CommentsInLocalTime#Site_options> gadget accepts a list of date format strings to parse out of talk pages (`parseFormat`). On a wiki whose system date format has changed over the years, it’s no big deal to accept multiple formats <https://vi.wikipedia.org/wiki/Đặc_biệt:Liên_kết_thường_trực/61986137#L-22>. As it happens, MediaWiki’s `$dateFormats['vi normal date']` setting provides these formats in a `sprintf()`-compatible syntax. If the goal is to accept a date in any format, that’s laudable, but it shouldn’t preclude outputting a date in the correct format. `parseDate()` doesn’t **have** to call the same function <https://github.com/wikimedia/Wikibase/blob/8cd12697b6726cb052aa416765b197bc42188ad6/repo/includes/Parsers/DateFormatParser.php#L328> as `getLocalizedDate()`. `getLocalizedDate()` can consult `$dateFormats` while `parseDate()` continues to sniff formatting characters out of a format string. TASK DETAIL https://phabricator.wikimedia.org/T63958 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Lens0021, Jony, Kwj2772, Jarekt, C933103, Capankajsmilyo, jeblad, PokestarFan, revi, Phreelance, KTC, Samat, deryckchan, Nikki, Agabi10, gerritb
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. The approach I was forced to take with Vietnamese (separate lexemes per word per writing system, “translations” from one writing system to another) has some downsides. For one thing, the criteria for a translation between vi and vi-Hani must be stricter than the criteria for a translation between vi and en; otherwise there would be no way to distinguish these transcriptions from translations more generally. In principle, it would follow that every simplified Chinese character should also have a separate lexeme from the corresponding traditional character(s), as on Wiktionary, and we could even take this to the extreme that “colour” is the en-GB “translation” of “color” in en-US. On a practical level, this separate lexeme approach means any Wiktionary template similar to https://en.wiktionary.org/wiki/Template:vi-readings would need to look up translations, while a template generating a table of translations of an English sense would need to know to ignore vi-Hani statements or merge them with vi statements. In a Vietnamese dictionary, it’s also normal to list the other words represented by the same characters. Currently, such a template on Wiktionary requires a series of expensive calls to look up second-order lexemes. (A rejected property proposal <https://www.wikidata.org/wiki/Wikidata:Property_proposal/ch%E1%BB%AF_N%C3%B4m> would streamline that somewhat.) It would be nice to be able to more strongly link representations in the two Vietnamese writing systems, but allowing multiple representations to have the same language code would only be a partial solution anyways. A full solution would be able to limit some statements to certain representations of a form. Otherwise, how would one indicate that one representation is now rare, having been supplanted by the other, independently of any broader linguistic shift, or that two sources disagree about whether that change has even occurred? TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mrephabricator, LucasWerkmeister, C933103, AGutman-WMF, mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani
mxn added a comment. In T180345#7624467 <https://phabricator.wikimedia.org/T180345#7624467>, @mxn wrote: > Wikidata’s Vietnamese-language lexemes are currently using `vi-x-Q8201` as the language code for chữ Nôm, as a workaround for this issue: > > phở <https://www.wikidata.org/wiki/Lexeme:L2297>: 𬖾, 頗 > râu <https://www.wikidata.org/wiki/Lexeme:L310625>: 鬍, 𩅺, 𩭶, 𩯁 In T180345#7916094 <https://phabricator.wikimedia.org/T180345#7916094>, @mxn wrote: > You do have a point that `vi-x-Q875344` would be more correct than `vi-x-Q8201` (and more specific, anyhow). Due to T236593 <https://phabricator.wikimedia.org/T236593>, it became necessary to split out //chữ Nôm// forms as separate lexemes. A lexeme’s language is stored as a QID, so I’ve used chữ Nôm (Q875344) <https://www.wikidata.org/wiki/Q875344> as the lexeme language instead of chữ Hán (Q8201) <https://www.wikidata.org/wiki/Q8201>, which is too general. For consistency, I’ve changed the lemmas and form representations to use `vi-x-Q875344` instead of `vi-x-Q8201`, even though `vi-hani` would be a suitable monolingual language code to replace it with. TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Yellowtailshark, Popolon, Esc3300, Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, mrephabricator, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. In T236593#8026331 <https://phabricator.wikimedia.org/T236593#8026331>, @mxn wrote: > If it is so important that forms not be used for orthographic variants of a non-alphabetic writing system, then the alternative approach would be to store the //quốc ngữ// and //chữ Nôm// representations in separate lexemes, as though they’re different languages. We could link individual //quốc ngữ// and //chữ Nôm// senses together as translations. This would be broadly consistent with the approach taken on every Wiktionary and render this ticket moot for Vietnamese, but it bends the definition of a language quite a bit. I’ve implemented this approach, so this feature request is no longer of great importance to Vietnamese. A side benefit is that it’s now possible to say that a //Nôm// character is a “translation” of some senses of a //quốc ngữ// word but not others (because of semantic distinctions that were only necessary to indicate in //chữ Nôm//). TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: AGutman-WMF, mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. In T236593#8025472 <https://phabricator.wikimedia.org/T236593#8025472>, @AGutman-WMF wrote: > @mxn If these are purely orthographic variants (i.e. the pronunciation is the same) I would list them under a single lexeme. And in that case, the most natural way would be to list them as spelling variants rather than distinct forms. This assumption is only valid in an environment with purely phonetic/alphabetic writing systems. But in Chinese, two characters that are “spelled” distinctly but carry the same semantics and pronunciation would still have distinct lexemes. This also makes it possible to indicate that the two characters are pronounced similarly in one dialect but differently in another. //Chữ Nôm// is a Chinese-based writing system that adds a phonosemantic aspect. If not for its relationship to the //quốc ngữ// alphabet, every character would clearly get its own lexeme, just like in Chinese. Any similarity in pronunciation would be irrelevant, because this writing system makes finer semantic distinctions than any alphabet would. For example, the difference between 𬖾 and 頗 (both interchangeable written forms of //phở//) is that 𬖾 combines 頗 with the component 米 as a disambiguator, clarifying that it has to do with rice (because phở noodles are made of rice), as opposed to whatever 頗 originally meant in Chinese. This is only one of many possible ways in which characters may be used interchangeably but can carry different nuances. Yet all this is secondary to the fact that the two characters are equivalent to //phở//, which makes no such distinctions. To further illustrate the difficulty, if you look at a //quốc ngữ//–to–//chữ Nôm// dictionary and a //chữ Nôm//–to–//quốc ngữ// dictionary by the same author, the entries will not line up, just as there isn’t a one-to-one correspondence between the English-to-German and German-to-English halves of an English–German dictionary. If you look up “bỏ” in this dictionary <http://www.nomfoundation.org/nom-tools/Nom-Lookup-Tool/Nom-Lookup-Tool?uiLang=en>, you’ll get three characters from the source “vhn” corresponding to two different senses of //bỏ//. Any Vietnamese dictionary would have just one entry for these two senses of //bỏ//, because Vietnamese speakers no longer illustrate semantics in writing. If it is so important that forms not be used for orthographic variants of a non-alphabetic writing system, then the alternative approach would be to store the //quốc ngữ// and //chữ Nôm// representations in separate lexemes, as though they’re different languages. We could link individual //quốc ngữ// and //chữ Nôm// senses together as translations. This would be broadly consistent with the approach taken on every Wiktionary and render this ticket moot for Vietnamese, but it bends the definition of a language quite a bit. > To attach statements to specific variants, I believe that you can qualify statements using the "subject form <https://www.wikidata.org/wiki/Property:P5830>" property This is for statements on senses. If we somehow combine all the //Nôm// characters into a single form, then it would make sense to qualify sources and P5425 statements by a “applies to representation” property, but even this would get messy with compounds. > (although, aside, I must admit I don't understand the need for the "Han character in this lexeme" property; what novel information does it bring on top of the orthography itself?) Translingual data about a Han character is stored in an item. There’s a need to connect this translingual data to individual senses via language-specific forms. TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: AGutman-WMF, mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. In T236593#8017255 <https://phabricator.wikimedia.org/T236593#8017255>, @mxn wrote: > In T236593#8015993 <https://phabricator.wikimedia.org/T236593#8015993>, @AGutman-WMF wrote: > >> The ideal solution would be to allow (in the language code validator) arbitrary language codes including a rank identifier. For instance, for Viatnamese one should be able to use codes such as vi-x-Q8201-1, vi-x-Q8201-2 etc. Currently this doesn't pass the validation as one gets the error //Invalid Item ID "Q8201-1"//. > > It sounds like representations need the ability to have qualifiers… To elaborate, each //Nôm// character needs a different set of Han character in this lexeme <https://www.wikidata.org/wiki/Property:P5425> statements (multiple statements for compound words), different sources, probably other things that aren’t coming to mind. It’s not that I don’t want to give the multiple-representation approach a try, but how else would hủy bỏ/huỷ bỏ <https://www.wikidata.org/wiki/Lexeme:L679211> and ký hiệu/kí hiệu <https://www.wikidata.org/wiki/Lexeme:L679212> be modeled but to keep the characters in separate forms? In principle, each character should even get its own lexeme, but since each //Nôm// character is an alternative form of a //quốc ngữ// word, the various spellings of that word would need to be duplicated as lemmas of each such lexeme. It ends up being a lot of redundancy and room for error. I had tried this approach at one point, with very redundant lexemes for phở <https://www.wikidata.org/wiki/Special:PermanentLink/1560865877>, 𬖾 <https://www.wikidata.org/wiki/Special:PermanentLink/1560864869>, and 頗 <https://www.wikidata.org/wiki/Special:PermanentLink/1560865170>, but it seemed like needless complication for both editors and data consumers. TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: AGutman-WMF, mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. In T236593#8015993 <https://phabricator.wikimedia.org/T236593#8015993>, @AGutman-WMF wrote: > The ideal solution would be to allow (in the language code validator) arbitrary language codes including a rank identifier. For instance, for Viatnamese one should be able to use codes such as vi-x-Q8201-1, vi-x-Q8201-2 etc. Currently this doesn't pass the validation as one gets the error //Invalid Item ID "Q8201-1"//. It sounds like representations need the ability to have qualifiers… TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: AGutman-WMF, mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T236593: Cannot enter multiple forms for the same language variant
mxn added a comment. Nearly Vietnamese lexeme would be affected by this issue <https://www.wikidata.org/wiki/Wikidata_talk:Lexicographical_data#Forms_in_Vietnamese>, because one of the two writing systems for the language is phonetic while the other is phonosemantic, resulting in a many-to-many relationship between the two writing systems. In T236593#5610378 <https://phabricator.wikimedia.org/T236593#5610378>, @daniel wrote: > So, the solution that we envisioned when originally discussing this about four years ago was: you make up a code for each of the spellings, in a way that allows the consumer to choose which variant they prefer. If that is done by encoding a region or a rhyme or a tradition or school or whatever will depend on the language. If it's a stylistic choice, name the style. This isn’t always possible. Vietnamese //chữ Nôm// is unstandardized, so a single author may use multiple characters interchangeably for the same word (with the same pronunciation and meaning). There isn’t any “style” to speak of: an author’s choice to use one character for “and” has little if any bearing on their choice of character for “or”. If Wikidata were in existence a century or more ago, we might’ve chosen to create separate a separate lexeme for each //Nôm// character, in which case it might be possible to model //quốc ngữ// spellings as dialectal representations of //Nôm// forms. But in the 21st century, //Nôm// characters must be subordinate to //quốc ngữ// words. TASK DETAIL https://phabricator.wikimedia.org/T236593 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, So9q, Ijon, daniel, Asaf, Mahir256, Danmichaelo, Fnielsen, Lucas_Werkmeister_WMDE, Denny, Lydia_Pintscher, jeblad, jhsoby, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani
mxn added a comment. In T180345#7916710 <https://phabricator.wikimedia.org/T180345#7916710>, @C933103 wrote: > In T180345#7916540 <https://phabricator.wikimedia.org/T180345#7916540>, @GerardM wrote: > >> So what is the font to be >> used? > > Please see this list of fonts: https://en.m.wikipedia.org/wiki/Template:Vi-nom/fonts.css For reference, here are similar font lists used by other WMF wikis: - English Wiktionary <https://en.wiktionary.org/wiki/Special:PermanentLink/64309734#L-566> - Vietnamese Wikipedia <https://vi.wikipedia.org/wiki/Đặc_biệt:Liên_kết_thường_trực/65103167> - Vietnamese Wiktionary <https://vi.wiktionary.org/wiki/Đặc_biệt:Liên_kết_thường_trực/2026406> Some of these fonts are specifically designed for //chữ Nôm//. The //Nôm// character repertoire in Unicode has expanded several times. The early favorite of the Vietnamese wikis, HAN NOM A/B <http://vietunicode.sourceforge.net/fonts/fonts_hannom.html>, contains most //Nôm//-specific characters, but many of them are encoded in the Private Use Area because the font predates CJK Unified Ideographs Extension E in Unicode 10. Aside from coverage, selecting a dedicated //Nôm// font is important because some important characters have distinct forms in each CJKV tradition that nevertheless got unified into a single Unicode codepoint. In T180345#7919332 <https://phabricator.wikimedia.org/T180345#7919332>, @Popolon wrote: >> By 1174, Hán tự/Hanzi had become the official writing script of the Vietnamese courts, mainly used by administration and literati, and continued to serve this role until the mid-19th century. > > As said previously, The Hán tự/Hanzi was still used during French colonization, there as documents of mid 20th century (including on commons) with still both chữ Nôm and lain script vietnamese and some French colony stamps. Some continue to use it today, there are several sites wrote using this script, and we can still see some videos using it as subtitles. This ticket tracks adding a monolingual language code, which would be useful regardless of exactly when //chữ nho// or //chữ Nôm// fell out of the mainstream. After all, we’ve already been resorting to workarounds like `vi-x-Q875344` in Wikidata lexemes for a while now, but no such workaround is possible for a native label <https://www.wikidata.org/wiki/Property:P1705> statement on a family name item or inscription <https://www.wikidata.org/wiki/Property:P1684> statement on a commemorative plaque item, for example. TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Yellowtailshark, Popolon, Esc3300, Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, mrephabricator, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani
mxn added a comment. In T180345#7916018 <https://phabricator.wikimedia.org/T180345#7916018>, @Yellowtailshark wrote: > In other words, "vi-Hani" should refer to Hán tự/Hanzi. A person reading Classical Chinese should be able to discern its meaning and not really notice the source is from Vietnam. According to ISO 639, `vi` is the code for Vietnamese. `vi-Hani` cannot represent //chữ nho// because //chữ nho// is not a written form of the Vietnamese language per se. But `lzh` does represent Classical Chinese, including //chữ nho//. > But even though this is how it should be, one also has to note that "Hani" is only understood as "Hanzi, Kanji, Hanja", not "Hanzi, Kanji, Hanja, chữ Nôm/Hán tự". I'm worried we would be sidestepping the ISO, even if we know what Hán tự is. Is it technically correct to interpret the English name of `Hani` in ISO 15924 so literally? After all, //chữ Nôm// differs from //chữ nho// in terms of language usage and many specific characters, but the CJKV writing systems have been unified <https://en.wikipedia.org/wiki/Han_unification#Examples_of_language-dependent_glyphs> into a single subset of Unicode, including //chữ Nôm//. On the other hand, ISO 15924 does contain codes for typographic variants of scripts like Nastaliq Arabic (`Aran`) and Gaelic Latin (`Latg`). Ken Lunde (2009) <https://books.google.com/books?id=SA92uQqTB-AC&pg=PA570> writes that //chữ Nôm// had a dedicated script code of `Cu` in ISO 15924:2004 (which has since been superseded by ISO 15924:2022). Does anyone have more information about these two-letter codes or why //chữ Nôm// didn’t get a four-letter code corresponding to this two-letter code? TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Yellowtailshark, Popolon, Esc3300, Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T181319: Support external tabular datasets in WDQS
mxn added a comment. In T181319#7788961 <https://phabricator.wikimedia.org/T181319#7788961>, @Manuel wrote: > Note from Wikidata Data Re-use Days: @Mike_Peel Q says some Items are huge (e.g. 4.3MB for Q87483673). This is problematic! @Mahir256 noted that this task might be a solution. Q87483673 is a great example of COVID-19 case data that currently isn’t a good fit for Wikidata statements. By comparison, these nine tables <https://commons.wikimedia.org/wiki/Category:Tabular_data_of_COVID-19_cases_in_the_San_Francisco_Bay_Area> have been updating daily since the start of the pandemic. It’s far easier to update these tables than the corresponding Wikidata items. Wikidata prefers keeping outdated statements, but backdated numbers routinely get revised (months into the past), so handling this kind of data properly requires more than adding a statement every day. Unfortunately, the lack of querying functionality has limited the usefulness of these tables – basically, they’re only used for visualizations on Wikipedia that focus on a single table at a time. The `wikidata:tabular` service mentioned in https://phabricator.wikimedia.org/T181319#3860648 sounds like it would be a great starting point. It was live on Sophox for a while but got disabled in 2018 <https://github.com/Sophox/sophox/issues/15> because of divergence from the main codebase. Both CSV and tabular data JSON would be exciting to have access to in SPARQL queries. TASK DETAIL https://phabricator.wikimedia.org/T181319 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Mike_Peel, Ainali, Manuel, Lectrician1, Inductiveload, Dirac, Theklan, Justin0x2004, johanricher, So9q, Moebeus, CamelCaseNick, Librarian_lena, Gnoeee, John_Cummings, mxn, Base, Ferdinand0101, Mahir256, Bugreporter, Daniel_Mietchen, NavinoEvans, Pasleim, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Astuthiodit_1, bking, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, ET4Eva, Dinadineke, DannyS712, Nandana, Namenlos314, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, JakeTheDeveloper, QZanden, EBjune, merbst, LawExplorer, Avner, StuartPrior, Silverfish, Reasno, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, Volker_E, SBisson, Jheald, mys_721tx, Jane023, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, TheDJ, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani, ko-kore
mxn changed the task status from "Stalled" to "Open". TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Popolon, Esc3300, Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani, ko-kore
mxn added a comment. Wikidata’s Vietnamese-language lexemes are currently using `vi-x-Q8201` as the language code for chữ Nôm, as a workaround for this issue: phở <https://www.wikidata.org/wiki/Lexeme:L2297>: 𬖾, 頗 râu <https://www.wikidata.org/wiki/Lexeme:L310625>: 鬍, 𩅺, 𩭶, 𩯁 TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Popolon, Esc3300, Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani, ko-kore
mxn added a comment. In T180345#6710271 <https://phabricator.wikimedia.org/T180345#6710271>, @Nikki wrote: > I think it would be useful to see some examples of how these would be used/what they would be used for. > > I'm not sure that `ko-kore` (or `ko-hani`) would be the best way to add text containing hanja because wouldn't we want it to be linked to the corresponding hangul? Years ago, I proposed a "hanja" property for Korean (proposal here <https://www.wikidata.org/wiki/Wikidata:Property_proposal/Archive/43#hanja>) . It was rejected at the time but I still think that would be the best way to do it and perhaps it would be a good idea to revisit it. > > I imagine it's a similar situation for `vi-hani`. I also proposed a chữ Nôm property <https://www.wikidata.org/wiki/Wikidata:Property_proposal/chữ_Nôm> for lexemes that was similarly rejected in favor of a semantically distinct property <https://www.wikidata.org/wiki/Property:P5425>. I remain convinced about the need for the property I proposed, but I haven’t had a chance to press that point. For the time being, there isn’t really a path to bring the Vietnamese Wiktionary’s large body of chữ Nôm data to Wikidata in a semantically correct way. Anyhow, that proposal only made sense in the context of a lexeme. A “chữ Nôm name” property on an item would have to be qualified by applies to name of item (P5168) <https://www.wikidata.org/wiki/Property:P5168>, with a constraint that it could only apply to a Vietnamese label, and there would have to be separate properties for “chữ Nôm given name”, “chữ Nôm birth name”, “chữ Nôm inscription”, etc. I think a monolingual language code would be cleaner. Another issue is that the Vietnamese Wikisource currently hosts a number of older Vietnamese works with the Latin and chữ Nôm transcriptions either side by side <https://vi.wikisource.org/wiki/Lục_Vân_Tiên_%28bản_Nôm_1916%29/I> or on separate pages <https://vi.wikisource.org/wiki/Truyện_Kiều_%28bản_chữ_Nôm%29>. I suspect that, in the long term, better supporting this diglossia will require software support for `vi-hani` as a language code somewhere or other. TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Nikki, Mahir256, Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani, ko-kore
mxn updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Nikki, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T180345: Add monolingual language code vi-hani, ko-kore
mxn added a comment. Adding chữ Nôm would be a nice improvement for Vietnamese-language Wikimedia projects as well as for federated projects. For example, an infobox at the Vietnamese Wikipedia could display the historical chữ Nôm name of a place or person. OpenStreetMap currently has a nonnegligible number of chữ Nôm names <https://taginfo.openstreetmap.org/keys/name%3Avi-hani>, even though the project is supposed to focus on current details rather than historical details. It’s likely that the people who contributed these names would be less likely to add them to OSM if they were able to add them to Wikidata, where historical nuances could be better accounted for (like the distinction between Ho Chi Minh City and Saigon). TASK DETAIL https://phabricator.wikimedia.org/T180345 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Mbch331, Amire80, jhsoby, GerardM, mxn, Liuxinyu970226, Aklapper, revi, C933103, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Nikki, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173052: Show OpenStreetMap features associated with Wikidata items
mxn added a comment. In T173052#6161088 <https://phabricator.wikimedia.org/T173052#6161088>, @Pigsonthewing wrote: > In T173052#6154762 <https://phabricator.wikimedia.org/T173052#6154762>, @mxn wrote: > >> In T173052#6154753 <https://phabricator.wikimedia.org/T173052#6154753>, @Pigsonthewing wrote: >> >>> We could significantly reduce the number of API calls by not having the script query overpass for certain classes of item (instances of human, taxon, academic paper, astronomical object, language, genome, chemical compound, etc.) >>> >>> If the map display could also not appear for those classes, so much the better. >> >> I think that would require a WDS query on every page load, which would spare one API by hammering another. > > Would it? I'm no coder, but I would have thought the script can read the content of the page on which it occurs. It can, but for instance, there might only be a statement that the subject is an instance of an artificial language; a SPARQL query would be required to crawl up the subclass hierarchy to determine that it’s indeed a language. One workaround would be to build a flat list of subclasses of language and check for membership in any of those subclasses, but the blacklist would be quite large. In T173052#4857228 <https://phabricator.wikimedia.org/T173052#4857228>, @Jc86035 wrote: > For the majority of items it is no longer necessary to use Overpass, as the same can be accomplished with mapframe, which is now shown on every item with coordinates in P625 <https://phabricator.wikimedia.org/P625>. The purpose of this gadget is to show the item’s relationship to OpenStreetMap specifically, whereas P625 <https://www.wikidata.org/wiki/Property:P625> could be derived from some other map or map database with its own idiosyncrasies. In theory, we could have the gadget only show up when a P625 <https://www.wikidata.org/wiki/Property:P625> statement is present, without using the coordinate in that statement. However, there are plenty of geographical items for which there’s no coordinate in Wikidata but the QID is tagged in OSM. TASK DETAIL https://phabricator.wikimedia.org/T173052 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: The_RedBurn, Yurik, Salgo60, Jc86035, debt, TheDJ, Planemad, Pigsonthewing, Aklapper, mxn, PokestarFan, Alilje, darthmon_wmde, Nabetaro, Nandana, MSantos, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, LawExplorer, Ddproxy, _jensen, rosalieper, JGirault, Scott_WUaS, phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173052: Show OpenStreetMap features associated with Wikidata items
mxn added a comment. I think that would require a WDS query on every page load, which would spare one API by hammering another. 😉 I considered but haven’t gotten around to making the gadget only show the overpass turbo embed on demand. That embed is what performs the query, so showing it only on demand would speed up page load quite a bit on some pages. The map is already usually below the fold, so I figure it wouldn’t be so annoying to have to click to see the map. TASK DETAIL https://phabricator.wikimedia.org/T173052 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: The_RedBurn, Yurik, Salgo60, Jc86035, debt, TheDJ, Planemad, Pigsonthewing, Aklapper, mxn, PokestarFan, Alilje, darthmon_wmde, Nabetaro, Nandana, MSantos, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, LawExplorer, Ddproxy, _jensen, rosalieper, JGirault, Scott_WUaS, phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unassigned] T173052: Show OpenStreetMap features associated with Wikidata items
mxn removed mxn as the assignee of this task. mxn added a comment. While not perfect, the Overpass user script does enable users to see which OpenStreetMap features are linked to the Wikidata item. (This is distinct from P625 <https://www.wikidata.org/wiki/Property:P625>, which is about coordinates rather than OSM features.) The original idea at the hackathon was to have this functionality incorporated into Wikidata as a gadget, so I’ll leave this issue open. TASK DETAIL https://phabricator.wikimedia.org/T173052 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: The_RedBurn, Yurik, Salgo60, Jc86035, debt, TheDJ, Planemad, Pigsonthewing, Aklapper, mxn, PokestarFan, Alilje, darthmon_wmde, Nabetaro, Nandana, MSantos, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, LawExplorer, Ddproxy, _jensen, rosalieper, JGirault, Scott_WUaS, phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173017: [Hackathon doc sprint] Add Wikidata link to more OpenStreetMap Wiki pages
mxn added a comment. This proposal would add Wikidata links to taginfo pages as well, based on the links in the infoboxes on the OSM Wiki.TASK DETAILhttps://phabricator.wikimedia.org/T173017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Pigsonthewing, Aklapper, mxn, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173017: [Hackathon doc sprint] Add Wikidata link to more OpenStreetMap Wiki pages
mxn added a parent task: T145688: [epic] Improve OSM-Wikipedia collaboration. TASK DETAILhttps://phabricator.wikimedia.org/T173017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Pigsonthewing, Aklapper, mxn, PokestarFan, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173017: [Hackathon doc sprint] Add Wikidata link to more OpenStreetMap Wiki pages
mxn added a comment. Revision 1498164 adds a link to the Wikidata Query Service as a fallback: Before: F9021993: Ảnh chụp màn hình 2017-08-10 tại 12.08.57.png After: F9022016: after.png Would be great to get something more automated in here, though.TASK DETAILhttps://phabricator.wikimedia.org/T173017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Pigsonthewing, Aklapper, mxn, PokestarFan, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173017: [Hackathon doc sprint] Add Wikidata link to more OpenStreetMap Wiki pages
mxn added a parent task: T170071: Documentation sprint @ Wikimania hackathon 2017. TASK DETAILhttps://phabricator.wikimedia.org/T173017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Pigsonthewing, Aklapper, mxn, PokestarFan, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T173017: [Hackathon doc sprint] Add Wikidata link to more OpenStreetMap Wiki pages
mxn created this task.mxn added projects: Wikimania-Hackathon-2017, Wikidata.Herald added subscribers: PokestarFan, Aklapper. TASK DESCRIPTIONA tag page at the OpenStreetMap Wiki can link to the corresponding Wikidata item, but it requires manually adding a link, so not many pages have one. It would be great if more OSM Wiki pages would link to Wikidata items, so that users can more easily access supporting information.TASK DETAILhttps://phabricator.wikimedia.org/T173017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Pigsonthewing, Aklapper, mxn, PokestarFan, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147656: Overwriting and suppressing interwiki links also for Wiktionary?
mxn added a comment. In T147656#2728114, @Lydia_Pintscher wrote: In T147656#2727633, @Psychoslave wrote: Will it be all interwiki links, including for Example translations section, or only mostly identical lexemes (or any other identification unit set)? Can you show me an example of a translation section? See the little parenthetical links in the "Translations" section here. These are inline interwiki links, so they should be unaffected, just as you can still insert interwiki links inline at Wikipedia without worrying about Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T147656EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxnCc: Psychoslave, Ricordisamoa, GPHemsley, Darkdadaah, Liuxinyu970226, PeterBowman, mxn, jberkel, tarlocesilion, satdeep_gill, Aklapper, JAnD, StudiesWorld, dg711, Yair_rand, gabriel-wmde, Bmueller, WMDE-leszek, daniel, Addshore, hoo, Thibaut120094, Nikki, Noe, Smalyshev, neilpquinn, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T106094: Add support for wikidata tag to iD (OpenStreetMap)
mxn closed this task as "Resolved". mxn added a comment. iD’s maintainer was generous enough to complete and merge <https://github.com/openstreetmap/iD/pull/2732#issuecomment-221988088> the PR I started. The Wikidata field will appear in the next iD release. Closing. TASK DETAIL https://phabricator.wikimedia.org/T106094 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: StudiesWorld, Qgil, phabyogi, Lydia_Pintscher, Pigsonthewing, mxn, Aklapper, Avner, debt, Gehel, JGirault, D3r1ck01, Lynhg, FloNight, Susannaanas, Izno, lxbarth, Planemad, Wikidata-bugs, Malyacko, aude, Deskana, Yurik, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T987: Phase 0: Centralize interwiki language links for Wiktionary
mxn added a comment. The Vietnamese Wiktionary uses redirects for systematic variations involving diacritics, for example xoá to xóa, whereas the English Wiktionary does not. This probably doesn't show up in interwiki stats because the English Wiktionary has relatively few Vietnamese words and the French and Chinese Wiktionaries have little coverage of these variations (which affect maybe a tenth of the overall corpus). On the flip side, automatically normalizing diacritics would be problematic for the same reasons described in https://phabricator.wikimedia.org/T78485. It wouldn't be the end of the world for the Vietnamese Wiktionary to turn its redirects into soft redirects to preserve these links, but soft redirects are highly inconvenient for very systematic variations. TASK DETAIL https://phabricator.wikimedia.org/T987 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: JanZerebecki, Thibaut120094, hoo, Addshore, daniel, WMDE-leszek, Bmueller, gabriel-wmde, Yair_rand, dg711, DannyH, StudiesWorld, JAnD, Aklapper, RobLa-WMF, Lydia_Pintscher, satdeep_gill, tarlocesilion, jberkel, mxn, PeterBowman, Liuxinyu970226, Darkdadaah, GPHemsley, Ricordisamoa, WebIntegrity, Avner, D3r1ck01, Alkamid, Izno, OrenBochman, Wikidata-bugs, Malyacko, aude, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T117524: Cannot access Wikidata on Meta-Wiki via Scribunto API
mxn added projects: Wikidata, Wikimedia-Site-Requests. mxn set Security to None. Herald added a subscriber: Matanya. TASK DETAIL https://phabricator.wikimedia.org/T117524 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Matanya, mxn, Aklapper, Luke081515, Wikidata-bugs, Snowolf, aude, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T108825: [Task] Enable phase 1 for Meta-Wiki
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T108825 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude, mxn Cc: mxn, gerritbot, Johan, MZMcBride, Ricordisamoa, Glaisher, Nemo_bis, Romaine, Nikki, Aklapper, Luke081515, Wikidata-bugs, aude, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T106094: Add support for wikidata tag to iD (OpenStreetMap)
mxn added a comment. I haven’t completed this task yet; it’s on my backlog but I’ll be getting to it eventually. TASK DETAIL https://phabricator.wikimedia.org/T106094 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Qgil, phabyogi, Lydia_Pintscher, Pigsonthewing, mxn, Aklapper, Lynhg, lxbarth, Wikidata-bugs, Malyacko, aude, Deskana, Yurik, scfc, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T106094: Add support for wikidata tag to iD (OpenStreetMap)
mxn moved this task to Work continues after Mexico City on the Wikimania-Hackathon-2015 workboard. TASK DETAIL https://phabricator.wikimedia.org/T106094 WORKBOARD https://phabricator.wikimedia.org/project/board/1033/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: Qgil, phabyogi, Lydia_Pintscher, Pigsonthewing, mxn, Aklapper, Lynhg, lxbarth, Wikidata-bugs, Malyacko, aude, Deskana, Yurik, scfc, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T86528: [RFC] Unit Localization
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T86528 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Snipre, Ricordisamoa, Lydia_Pintscher, thiemowmde, Tobi_WMDE_SW, JeroenDeDauw, JanZerebecki, adrianheine, aude, Snaterlicious, Aklapper, Stryn, daniel, Smalyshev, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77978: [Story] Support unit conversion
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T77978 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Ricordisamoa, Mbch331, Jc3s5h, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77983: [Story] Use localized unit symbols
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T77983 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T103044: [Bug] Interwiki links for newly created wikis are shown at the bottom of sidebar
mxn added a subscriber: mxn. mxn added a comment. In https://phabricator.wikimedia.org/T103044#1404692, @aude wrote: > the sorting order used to be maintained on meta wiki for pywikibot, so > someone would have needed to add it there in the past and was not something > deployers dealt with. Just now noticing this bug. The Meta sort order pages <https://meta.wikimedia.org/wiki/Interwiki_sorting_order> have a Scribunto module <https://meta.wikimedia.org/wiki/Module:Project_portal> in place to alert Meta sysops when they’re missing languages, but the module was apparently broken <https://meta.wikimedia.org/w/index.php?title=Module:Project_portal&diff=12921630&oldid=11491714> for well over a year. With the module now fixed, we’ll be better about updating the sort order there. TASK DETAIL https://phabricator.wikimedia.org/T103044 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, thiemowmde, Hugo.arg, Glaisher, Krenair, Mjbmr, gerritbot, hoo, aude, Lydia_Pintscher, Aklapper, Wikidata-bugs, TTO, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T986: Use structured data on Wiktionary
mxn added a subscriber: mxn. Herald added a subscriber: Aklapper. TASK DETAIL https://phabricator.wikimedia.org/T986 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Aklapper, Psychoslave, Lydia_Pintscher, jberkel, GPHemsley, Gilles, JanZerebecki, Ricordisamoa, Liuxinyu970226, Wikidata-bugs, aude, Darkdadaah, Krenair, Malyacko ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T987: Phase 0: Centralize interwiki language links for Wiktionary
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T987 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, PeterBowman, Liuxinyu970226, Darkdadaah, GPHemsley, Gilles, Ricordisamoa, Wikidata-bugs, aude, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T46874: Full support for wikibase edits in enhanced changes format ("Group changes by page in recent changes and watchlist" [usenewrc])
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T46874 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn Cc: mxn, Ricordisamoa, Perhelion, Elitre, MisterSynergy, Conny, Reaper35, liangent, Jdforrester-WMF, Abraham, matmarex, Nemo_bis, Schnark, Tobi_WMDE_SW, He7d3r, aude, Liuxinyu970226, Tgr, Lydia_Pintscher, Ltrlg, Raymond, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T70029: allow arbitrary data access on Wikidata (parser function)
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T70029 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . To: mxn Cc: Tobi_WMDE_SW, Ricordisamoa, Wikidata-bugs, mxn, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T75460: Sane Lua label access in non-content languages
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T75460 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . To: mxn Cc: hoo, Lydia_Pintscher, Wikidata-bugs, Multichill, TheDJ, mxn, aude, GWicke ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T54971: Sitelinks to Incubator, OldWikisource and BetaWikiversity
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T54971 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . To: mxn Cc: wikidata-bugs, MF-Warburg, Billinghurst, JohnLewis, Lydia_Pintscher, liangent, Tpt, Vogone, Revi, zhuyifei1999, jayvdb, Micru, Candalua, SPQRobin, Filceolaire, mxn ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T49930: allow accessing data from an item not connected to the current page - arbitrary access (tracking)
mxn added a subscriber: mxn. TASK DETAIL https://phabricator.wikimedia.org/T49930 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . To: mxn Cc: wikidata-bugs, Qgil, Jasper, Ltrlg, Addshore, MF-Warburg, He7d3r, Lydia_Pintscher, hoo, Florian, Ainali, Chmarkine, Stryn, Abraham, Danmichaelo, zhuyifei1999, daniel, Multichill, Ash_Crow, Ricordisamoa, MZMcBride, jayvdb, Micru, Mvolz, Daniel_Mietchen, Kersti, matej_suchanek, Bennylin, aude, Jarekt, Pietrodn, Aubrey, Filceolaire, Hkjacksonhk, mxn ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
