User talk:Deryck Chan

Jump to navigation Jump to search

About this board

Previous discussion was archived at User talk:Deryck Chan/Archive 1 on 2015-08-24.

2402:1980:28F:43A5:F053:1A02:41A0:40EB (talkcontribs)

Hi Deryck, I invite you to join the discussion of "Label" or "Distributor" at the album release history table, as well as Chinese talk page.

2402:1980:28F:43A5:F053:1A02:41A0:40EB (talkcontribs)

Sorry for the IP has been blocked at English Wikipedia, so I put the message to this talk page.

Deryck Chan (talkcontribs)

Thanks for notifying. I've had a look at the discussion. Sadly I don't have any expertise in this matter, sorry!

Reply to "Discussion about "Label" or "distributor""
Chuankaz (talkcontribs)

Hi Deryck,

I noticed your message in Wikidata project chat, which led me to look up your profile. Thank you for all the great work!

I’m reaching out to you because I’m working on a research project about understanding what motivates editors like you to contribute to Wikidata. We’re also interested in learning about how you feel your contributions are being used outside of Wikidata. Since you are such an active community member, I thought you might also be interested in helping to build the broader community’s knowledge about Wikidata, and why it matters.

If you’re interested, let’s schedule a time to talk over Zoom, or whichever platform you prefer. You could leave a direct message in my user talk page or fill in a questionnaire. The conversation should take about 30 min.

Hope you have a great day,

Charles

Reply to "Interview Invitation"
Gabi S. (talkcontribs)

Thanks for merging the articles I requested. Now I understand how to do it, and will be able to do it myself if I see something similar. Thank you for pointing that out for me.

Deryck Chan (talkcontribs)

Thank you Gabi. To merge items yourself next time, you will need the "merge" tool, which is enabled here: Special:Preferences#mw-prefsection-gadgets

Also, my talk page is a structured discussion board, so there is no need to sign your message in the free text.

Reply to "Thanks"
Liuxinyu970226 (talkcontribs)

目前該屬性翻譯為「頁碼」,但考慮到近期folio(s) (P7416)已有建立,而folio直譯為中文也是「頁碼」,而這兩者會產生衝突,本站基於技術之角度也不允許兩個屬性使用同一名稱(包括翻譯名),所以我想知道閣下對於頁碼一詞之己見,是應予保留P304既有翻譯,P7416另譯為他詞?亦或變更P304翻譯,頁碼改做P7416? (To non-Chinese users: Currently the page(s) (P304) is translated as "页码" in Simplified Chinese, and "頁碼" in Traditional Chinese, but because of the recently created folio(s) (P7416), now there's a problem that, if directly translating "folio", then that should also be "页码/頁碼" which results confliction, and by technically Wikidata will not allow two or more properties to use purely same name (also applying to translations), so I would love to know that how do you consider the original points of "页码/頁碼", should P304 continue to translate as "页码/頁碼" and consider another proper translation of P7416? Or should we alter the P304 translation, and release "页码/頁碼" for P7416 instead?)

Deryck Chan (talkcontribs)

I'm skeptical. @Jura1, Jheald, PKM: Liuxinyu970226 raised a good point. The distinction between folio number and page number may not cross cultures.

Jheald and Jura - you two said there are some cases where a combined "folio" and "page" property won't work because the same work uses folio and page for two distinct meanings. Can you give some examples?

I quote from the English Wikipedia (w:Folio): "folio" is used in terms of page numbering for some books and most manuscripts that are bound but without page numbers as an equivalent of "page" (both sides), "sheet" or "leaf", using "recto" and "verso" to designate the first and second sides, and (unlike the usage in printing) disregarding whether the leaf concerned is actually physically still joined with another leaf. This usually appears abbreviated: "f26r." means the first side of the 26th leaf in a book.

page(s) (P304) has property "string" because the page numbers we follow are not strictly the number of sides counting from the cover, but rather the page numbers as used in the book. Folios work the same way - we count in the established order of counting sheets of paper in a historical manuscript. The two systems are in complementary distribution and page(s) (P304) isn't concerned about whether you count sides or sheets.

I suspect the distinction between "page" and "folio" is a red herring as far as Wikidata is concerned, and causes more problems than it solves because e.g. Chinese does not distinguish between them. Since the property hasn't begun to be used yet, I suggest that we abandon it unless you guys have some good examples of minimal pairs between "page" and "folio".

Jheald (talkcontribs)

I think I've seen scanned manuscripts with both folio and page sequences on them (as distinct from Wikidata:Property_proposal/Generic#file_page, which is something else, and very much needed).

At the moment I can't cite you an example manuscript where this has been done; but here are some UK 1881 census extracts: http://www.healds.org.uk/census/chs1881.html

Census returns for each area were completed in booklets, with page numbers running from 1 to n for each booklet; the booklets were then bound in volumes, the folios of which were numbered as folios for the volume as a whole. Either system is used for referencing in older references, though folio-referencing is dominant now. But possibly this is a special case, that could be dealt with in a special way?

However, when you say Chinese does not distinguish between folios and page numbers, surely Chinese must distinguish between the two, when referencing older European material where this is a relevant distinction?

Deryck Chan (talkcontribs)

I'm not a professional librarian so I looked this all up this week:

A bit of historical linguistics is in order here. The Chinese language(s?) has never had separate words for "folio" (2 sides) and "page" (1 side). The word 頁 (Pinyin: yè, Cantonese Yale: yihp), derived from the root word for "leaf", is used for both. The Chinese Wikipedia article on "page" explains it well: a "yè" historically referred to both sides of a sheet, but now typically refers to one side.

There is a "sheet" (張) vs "side" (面) distinction in Chinese, but these are overwhelmingly used with cardinal numbers (total number of sheets in a manuscript), seldom in ordinal numbers. When counting page / folio numbers, 頁碼 (page number) is used for both.

Library scientists do have a contrived sentence fragment to cope with the double-sided vs single-sided numbering systems: "頁碼(佔二面)", literally "page number (takes two sides)". Another suggestion on that glossary is "葉碼", which uses the modern character for "leaf" rather than "page" (so, "leaf number"). This appears to be a single-sided vs double-sided distinction rather than an Eastern vs Western distinction. If we intend to use page(s) (P304) and folio(s) (P7416) consistently so P304 counts sides and P7416 counts sheets, this can be feasible workaround, albeit somewhat clumsy.

This library guide from CUHK provides another solution: "Sometimes manuscripts are renumbered upon reproduction. In that case, please specify which version of page numbers"!

Reply to "page(s) (P304)"
VIGNERON (talkcontribs)
Deryck Chan (talkcontribs)

Thanks Vigneron. It took me some time to figure out what the constraint violation was (because constraints violation tooltips don't show in either diff mode nor mobile view). So the issue is a class violation... and it seems that we consider Lanterne rouge (Q1315624) a award (Q618779) (taking it very literally) not a position (Q4164871). So I've changed the qualifier to award received (P166) which seems to obey all constraints.

Reply to "Change of qualifiying property"
Jura1 (talkcontribs)
Deryckchan (talkcontribs)

That should be taken care of. TV episodes should be P279 / Q2431196. Can you give me an example where the property should've been migrated but wasn't? (Or the reverse, was migrated but shouldn't have been)

Jura1 (talkcontribs)

Deryck Chan (talkcontribs)
Jura1 (talkcontribs)

Nevermind, I thought you'd be fixing them.

I agree about the first part, but if we know the original language of the episode, we should be using P364 and not delete it. Apparently this wasn't clear to everyone before the closure of the threads.

Deryck Chan (talkcontribs)

To be honest, the only advantage of keeping P364 that I can see, is that many film and TV infoboxes use P364. As I wrote in the PFD, there are only 487 items that have different values for P364 and P407, which suggests that the vast majority of use cases do not generate minimal pairs between P364 and P407 in the intended use of P364 = original language, P407 = translation. This is because the WikiProject Films had already decided that translations should get their own items.

Jura1 (talkcontribs)

From that point of view, it could make sense, but the question is if it the outcome would have been as reliable ..

Personally, I wouldn't do a recommendation about meaning of P407 currently present on other works (except maybe scientific articles).

BTW, it's not translations, its about specific dubbings.

Deryck Chan (talkcontribs)

Yes I did mean "dubbings". Sorry, that word escaped my head when I wrote the previous message.

Reply to "break"
Catherine Laurence (talkcontribs)
Deryckchan (talkcontribs)

谢谢回复。另外提醒您,您的维基字签名有错(维基数据没有 U: 和 UT: 名字空间简写),请改正。

Catherine Laurence (talkcontribs)

了解,谢谢提醒。

Reply to "提醒"
Catherine Laurence (talkcontribs)

謝謝您在權限申請中幫我說明情況。

Reply to "Thanks"
Zazpot (talkcontribs)

Hi Deryck,

I saw your comment on Wikidata:Requests_for_comment/Adopt_a_username_policy and thought it might be helpful if I explained one of the factors that motivated me to open that RfC. A year ago, I noticed the username YULdigitalpreservation being used on enwiki and several other WMF wikis, apparently to represent a small group of people rather than a single person. On enwiki, there is clear guidance about whether that practice is acceptable (it is not) and what another user (e.g. me) should do upon encountering such behaviour. You can see the outcome here, here, and here.

On Wikidata, that user's behaviour is, IMO, equally problematic; but there is no adequate policy or guidance for handling it. What would you suggest, besides adopting a username policy (which you opposed)? Thanks! Zazpot (talk) 12:20, 31 October 2018 (UTC)

Deryck Chan (talkcontribs)

If this role account's edits are unproductive, Wikidata:Blocking policy already takes care of it.

The slightly wider issue is "should we forbid or allow role / shared accounts". The ongoing debate at the RfC on whether the en.wp policy or Commons policy is more appropriate has shown that we don't have consensus over this matter, nor do I see a strong need for regulation at this stage.

If we decide to forbid shared accounts, an amendment (or expansion) to Wikidata:Alternate accounts can be an adequate solution which doesn't require having a local username policy.

Deryck Chan (talkcontribs)

Another example I have in mind is User:ScorumME and User:ScorumMEBot. The name and their edits imply that the operator(s) is the owner of sports statistics site scorum.me . These accounts contributed useful sports statistics for some time, but the external link destination page eventually became a cryptocurrency page, so the bot was blocked and all links to the site removed.

Throughout the case nobody cared whether the account was meant for a single person or multiple people in the same role.

Zazpot (talkcontribs)

Had I known about User:ScorumME and User:ScorumMEBot, I would have cared! Shared-use accounts inevitably and irreversibly muddy provenance and editorial responsibility. As such, edits from people using shared-use accounts are inevitably less productive than those same edits would have been if they had instead been made from individual-use accounts. Is that difference sufficient to warrant a block (and a policy)? In my view, yes; but other editors disagree.

Hence my call for clarity from the community; to replace the status quo of ad-hoc responses and laissez-faire regulation that leaves many new and old editors unsure what is acceptable, what is not, and why.

Anyhow, thanks for explaining your rationale. I am grateful to know it, even though I disagree with it. Zazpot (talk) 16:18, 31 October 2018 (UTC)

Deryck Chan (talkcontribs)

I wonder if we should write a documentation page on accounts, rather than a policy page:

  • Wikidata has several policies that are relevant to the use of accounts: Wikidata:Alternate accounts; Wikidata:Blocking policy
  • User accounts are unified across all Wikimedia projects.
  • Each person should only use one account, except for limited purposes set out in Wikidata:Alternate accounts.
  • Wikidata does not currently have a local username policy. However, as Wikidata is inherently a cross-wiki project, users may run into problems during editing if their username falls foul of the rules of another Wikimedia project:
    • Some other Wikimedia projects, notably the English Wikipedia, forbid usernames which imply shared usage or usage by different people at different times, for example "Communications Department at XYZ Company", "Secretary at ABC Foundation".
    • Many Wikimedia projects have rules that say forbid usernames that are offensive. Sometimes a name that is benign in one language may be misconstrued as offensive in another language. Administrators understand that usernames are unified across projects of many languages and cultural misunderstanding may arise, and editors should be prepared to explain themselves should such situations arise.
  • The Wikimedia Foundation terms of use require any editor who is receiving compensation for their editing, or editing on behalf of an organisation, to declare their employer and affiliation. This is best done by a statement on the user page attached to your account.
  • Accounts that are disruptive to Wikidata may be blocked according to Wikidata:Blocking policy.

...something like that?

Zazpot (talkcontribs)

I appreciate your effort, but this still doesn't say anything about the acceptability or otherwise of (ostensibly) shared-use accounts on Wikidata. As such, it doesn't really address the concerns that I discussed above.

Reply to "Username policy"
117.136.54.99 (talkcontribs)

How do you think about it, this was rejected years ago but now has a lot of users who just make support votes. --117.136.54.99 23:02, 28 May 2018 (UTC)

Deryck Chan (talkcontribs)

Thanks for the heads up.

Reply to "Wikidata:Property proposal/Baidu Baike ID"