Example when explaining regular expressions for "Place search" #67
Comments
|
I think at the time I wrote that example, at least some places did. I don't think any do anymore. The example might be too complex for casual users anyways, but I thought it was neat to demonstrate what it could be used for ;) feel free to do some simplification here. Maybe this doesn't have to be so detailed, and we can link here for power users that want to do more than normal text search. |
|
By the way: The code that sorts the place names alphabetically uses that exact RegEx to this day so that the Arabic definite articles don't affect the sorting, both for the visualization and the reports. This is also why this, and the initial apostrophe, are aligned differently in the location list. |
|
I could think of something simple like
Linking to the external documentation is good, too. Btw, why is searching |
I like it!
Because "Bagdad" appears in the |
👍
But these |
|
I'm not sure if there's a misunderstanding, but I cannot see any section or something similar entitled transcription. |
|
|
|
In other words, there is a match when searching because the term matches the simplified transcription of an alternative name? At any rate, I will discuss this with @rpbarczok. I'm not sure how much of this behavior must be made transparent to the visitor who has no access to the db itself, but can only see the tooltip or the URI page which does not provide the simplified transcription either. |
Yes. See https://github.tik.uni-stuttgart.de/frankemx/damast/issues/64 |
|
Ok. As @rpbarczok told me, (It would be preferable, of course, if the |
|
I forgot to mention that we also add an english simplified transcription in the simplified table (e.g. gh, kh, j, sh etc.). Usually we use the simplified english transcription as the main name, but in the case that there is more than one Arabic variant. E.g. in the case of al-Ahsa. For the name variant هجر, we give the transcript Haǧar, and the simplified forms Hagar and Hajar. |
@rpbarczok, you mean "but only in the case that"...? What is more, I'm not sure what to tell the user regarding what you stated. |
|
Just my 2 cents: We included this originally to make the search a bit more powerful and also forgiving. So, we wouldn't have to type names exactly (with the ǧ etc.), but could use a Latin g. Since this is quite hard to do only in software (there are a lot of letters with diacritics, hard not to miss some, ...) we decided it would be good to save the typical "latinified" names in the database. In my opinion, this is an implementation detail users do not need to know about at all. The only thing to communicate here would be that the search box is a bit more forgiving regarding exact spelling (or accepts variant spellings of places). |
|
I am sorry, the sentence was mutilated when editing it. What I mean is: For Arabic and other forms, we usually have one transcribed form in the transcription system of the DMG. Additional, we save the basic form of the letters in the simplified forms. We later decided also to include the simplified english trancription. So basically you can inform that the user usually should find a place also by entering the basic forms of the letters and by looking for a simplified English transcription, e.g. Hajar. |
I might not be the average user in that case, but I would want to know how the search works exactly and how I can reproduce results. But I will certainly find an explanation (which you will correct, if necessary) for the current behavior. This is already pretty good:
|
In the current example in the info text for the search of places, one reads:
If I understand correctly from the list of places, we do not use the DMG notation for Arabic articles (cf. https://de.wikipedia.org/wiki/DIN_31635). That example makes little sense, then. Any better suggestions. @rpbarczok, you probably no the data itself better than @mfranke93?
The text was updated successfully, but these errors were encountered: