TUFTS lookup for POLIS has diacritics different and now there's an error

[m-linssen]

Describe the bug
Clicking the Greek polis leads to a Perseus error

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://coptic-dictionary.org/entry.cgi?tla=C10233'
2. Click on 'the real Greek word, the blue hyperlink'
3. See error

Expected behavior
no error LOL

Screenshots
http://www.perseus.tufts.edu/hopper/resolveform?type=exact&lookup=poli/s&lang=greek is the erroneous link

Additional context
Fix: the diacritic is on the O, not the I; the next URL will solve this problem

http://www.perseus.tufts.edu/hopper/resolveform?type=exact&lookup=po/lis&lang=greek

By the way, feel free to close issues that you fix, even if it's just in Dev; I'm not going to verify any of these, I'm just investing time and energy in making this product better. I'm odd that way

[amir-zeldes]

Thanks for reporting - this is an error in the original XML (line 252266).

I could patch these things locally but I'd rather see the XML data fixed (which I can also do and push); except that I assume the XML is generated by scripts from the BBAW/DDGLC database, so I don't want to create synchronization problems. @dwerning - should I just fix this and push the corrected XML to GitHub or is this better fixed at some earlier source upstream?

[m-linssen]

Thanks Amir.What we do in IT (via ITIL and similar processes, methods and procedures) is to distinguish between workaround and solution.No need to read all this, I just needed a distraction. It's good stuff though, comes in handy for really complex products and environmentsLater!1. If there's an Incident, try to reproduce it: if you can, you1a. Accept it, even if it's not on your plateYou can shove it around internally but externally you'll be the problem owner forever - which is a mere formality but it just means that there's always someone out there waiting for a reply from the organisation of which you were the last representative regarding this Incident1b. Reject the Incident if you can't reproduce. Tell the customer, and Close the Ticket / Issue2. Evaluate the Incident: it doesn't matter what your heart or soul or mind says, the only thing that counts is the contractual obligations: is this functionality formally intended to work this way, yes or no?Take that to the extreme; if someone accidentally died because of a bug, but it is not explicitly described that such shouldn't be the case nor can that be derived, then formally this is "works as designed". Don't tell that the customer, that would make for bad headlines and all that jazz, just raise a formal Request For Change internally.I'm not being anal, it is all about being reasonable, plausible, and debatable. If someone wants to be an ass, can he obstruct the process here? Then write the damn RFC, that only takes 5-10 minutes, and it is traceable where this functionality came from. I'm talking about finical nonsense that gets debated in multinational enterprises, I'm sure it is completely irrelevant to you guys, but sometimes it's about liabilities and collective memory and those two never are acquaintances of each other when the going gets toughAnd that is the binary outcome of that process indeed:2a. Works as designed, so the Incident will be the end to it. If anyone wants the functionality to be different, a Request For Change must be raised - and that will be Impacted (time, money, what's the cost) and scheduled, and these days people will "put it on the backlog" so it can get prioritised. But that route never involves Ops in any way2b. Oh my, we have bug! All of 2a applies but instead of the RFC, someone will describe all of this in a document which essentially contains the same as the RFC, but it's just not a Change, it is an Incident.If you want to do it for real, then this is the point that you raise a Problem. The Incident gets moved under the Problem, this RFC like document that we call a Solution does likewise, and whatever comes afterwards. From Ops this goes to Dev, they'll give a date, and if you have multiple Problems then Ops prioritises them, and discusses them with Dev on a regular basis.At some point a Problem gets fixed, Ops monitors the new release, and after a while they mark the Problem as solved. The incident gets Closed, the Ticket gets a nice closing comment, and if the Customer is close enough you let them evaluate whether it is fixed or not, and you can even get them to test it in an earlier stage - that's the classic Office environment, certainly not a Distributed Web one3. There's another world out there and that is real time, and the only first question is: does this bleed hard enough to get fixed right away?If not, then good! If yes, then3a. You implement a workaround, which needs to be undone at some point. Document it under the Problem and indeed, only in the case of 2b can there be a 3a. Implement the fix, and in essence everything is back to normal now: in the back (Dev) the real solution will at some point be implemented, which will be done with the Problem documentation in hand. The Ops workaround will be noticed, it will be disabled, and we have a healthy, fixed product, and all is swellSo! LOL. Yes I needed a distraction, sorryTL;DR: no need for a workaround I think, Amir, not a really burning issue ;-) if you ask me. I'd have @dwerning implement a solution along with the next releaseHave a nice day,Martijn Linssen  -------- Original message --------From: Amir Zeldes ***@***.***> Date: 19/10/2021 20:19 (GMT+01:00) To: KELLIA/dictionary ***@***.***> Cc: Martijn Linssen ***@***.***>, Author ***@***.***> Subject: Re: [KELLIA/dictionary] TUFTS lookup for POLIS has diacritics different and now there's an error (Issue #181) Thanks for reporting - this is an error in the original XML (line 252266). I could patch these things locally but I'd rather see the XML data fixed (which I can also do and push); except that I assume the XML is generated by scripts from the BBAW/DDGLC database, so I don't want to create synchronization problems. @dwerning - should I just fix this and push the corrected XML to GitHub or is this better fixed at some earlier source upstream? —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.