You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I often use Jotoba to supplement glossary information from others, for example to fill in pitch accent or for more detailed PoS data. This usually means making a request based on what I have, then trying to match that to some result in the response. I'm usually conservative in evaluating the quality of a match, because I don't want to accidentally add data from the wrong word just because they match in reading or the like. One obstacle to this is that the /api/search/words endpoint does not return the alt_readings field returned by the api/app/words endpoint. That means that if, for example, I search for よる but also know it can be written in kanji as 因る, it's difficult to match to the entry for 依る, because there is no authoritative source of alternative forms, although there is a field "information": "esp. 因る, 由る" provided under one of the senses; but since that field could (maybe?) contain any useful information, I'm not confident using it for matching.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Include the the same data included in the alt_readings in the /api/app/words API endpoint in the /api/search/words endpoint.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Alternatively, document the /api/app/words endpoint so that it is easier to use that.
Alterantively, I can perform two searches, one with the reading I'm certain of, and one with the kanji that is associated with the word but not as its primary citation form. This works fine, but I try to avoid making too many requests to respect infrastructure.
Additional context
Add any other context or screenshots about the feature request here.
From the /api/app/words endpoint (from the browser network traffic):
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I often use Jotoba to supplement glossary information from others, for example to fill in pitch accent or for more detailed PoS data. This usually means making a request based on what I have, then trying to match that to some result in the response. I'm usually conservative in evaluating the quality of a match, because I don't want to accidentally add data from the wrong word just because they match in reading or the like. One obstacle to this is that the
/api/search/words
endpoint does not return thealt_readings
field returned by theapi/app/words
endpoint. That means that if, for example, I search for よる but also know it can be written in kanji as 因る, it's difficult to match to the entry for 依る, because there is no authoritative source of alternative forms, although there is a field"information": "esp. 因る, 由る"
provided under one of the senses; but since that field could (maybe?) contain any useful information, I'm not confident using it for matching.Describe the solution you'd like
A clear and concise description of what you want to happen.
Include the the same data included in the
alt_readings
in the/api/app/words
API endpoint in the/api/search/words
endpoint.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Alternatively, document the
/api/app/words
endpoint so that it is easier to use that.Alterantively, I can perform two searches, one with the reading I'm certain of, and one with the kanji that is associated with the word but not as its primary citation form. This works fine, but I try to avoid making too many requests to respect infrastructure.
Additional context
Add any other context or screenshots about the feature request here.
From the
/api/app/words
endpoint (from the browser network traffic):From the
/api/search/words
endpoint:The text was updated successfully, but these errors were encountered: