-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mw:12831 #923
Comments
Many of us have had a similar thought.
What new markup should be used? How should the new markup be displayed to the user? One reason this problem doesn't bother me much is that I use list displays (such as that in simple search). In such a display, the 'previous entry' can be seen in the list on the left of display, and can be clicked on to see the previous entry. But of course the user of such displays as advanced search will not have that contextual list, and so will be frustrated. |
How about having another "field" taking the L-number as the search-entry? One could key-in the L-number and get the prev. entry; of course this would 'miserably' fail in case of MW, where many L-numbers [23279 out of 287582, i.e. about 8%] contain decimal numbers, in many variant manners (added mostly in ad-hoc style) that a user cannot "predict"! |
Two more ideas @funderburkjim, to cater to the issue--
As this is a server side activity (that "knows" the entry number sequence of the particular dictionary), these two options have no limitations or drawbacks (as against the idea mentioned in the above post). |
Another idea: revise the markup in mw.txt
This would work in any of the displays. |
date: 07/06/2022 12:30:29
dict: mw
Lnum: 12831
hw: abhisampad
old: id.
new:
comm: In the original ("printed book") it is clear that "id." means content of the previous article, abhisampatti; but here, in the "electronic" form it is absolutely unclear. The means must be found to resolve situation.
The text was updated successfully, but these errors were encountered: