-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add RN support #70
Labels
feature
New functionality to be implemented
frontend-web
Having to do with Reykunyu's web frontend, https://reykunyu.lu
server
Having to do with Reykunyu's server side (the word lookup code and API)
Comments
Willem3141
added
feature
New functionality to be implemented
frontend-web
Having to do with Reykunyu's web frontend, https://reykunyu.lu
server
Having to do with Reykunyu's server side (the word lookup code and API)
labels
Jan 10, 2023
I think the current implementation of RN is enough for now. We aren't showing ù yet, but since we don't have a list of words that has ù any such implementation would show incomplete data. The IPA does have support for words that have ù. |
And now we do have the list! |
Willem3141
added a commit
that referenced
this issue
Mar 24, 2024
Until now, searching used to be done using a single JS object indexed by word:type strings. That means, to search for a noun we'd do two searches into this object: query:n and query:n:pr. And to search for a verb, we'd do many searches (query:v:in, query:v:tr, ...). And worse, to search for anything else, we'd just linear search through the list. This clearly is suboptimal, but was grown this way for historical reasons. This commit is a big refactor to improve this. Now, the word database is simply an array. A word can be indexed in two ways: (1) with their index in the array, and (2) with a word/type pair like before, but now we do a preprocessing step to create an object that maps words (independently of their type) to a list of array indexes. This way we can answer questions like finding a word in essentially O(1) time instead of O(n). A secondary benefit (actually the one because of which I finally decided to get started with this big refactor) is that now that we are not using the "na'vi" field for searching anymore, it becomes possible to put some extra data in the "na'vi" field. Specifically Reykunyu has pronunciation and infix data, but these are separate fields from the "na'vi" field, so it is not (easily) possible to show infix dots or underline the stressed syllable in the lemma itself. This commit allows indicating the syllable boundaries with "/" and the stressed syllable with "[...]"; this is then shown in the lemma display, without affecting searches. Also, we can now put ù in the field so that we can automatically create Reef Na'vi forms, if the user wants to see RN. As such, this commit also adds a (as of yet still non-functional) setting to the UI to switch between dialect modes: FN, RN, or a combined mode. Right now all of this is very experimental. Many features (e.g., the all words page and the editor) don't work. I still have to reconsider how to exactly deal with the FN/RN distinction. For example, in word links what dialect should be used? I don't want to have to write [[to]/rùk:n] for a word link to [toruk:n]. So, should word links just use FN spelling? When this all works, this should address #70, #77, and #105. Eventually, it could also enable addressing #36, #42, and #57.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
feature
New functionality to be implemented
frontend-web
Having to do with Reykunyu's web frontend, https://reykunyu.lu
server
Having to do with Reykunyu's server side (the word lookup code and API)
The text was updated successfully, but these errors were encountered: