That would be difficult. Deseret script is phonetic, so you’d have to either look up the pronunciation for each word or eat the imperfection from the ~40% of words that can’t be easily predicted.
Yes you need a phonetic dictionary. eSpeak is a project where people already dealt with the problem of predicting phonetics. You could start with the values that eSpeak produces and allow users to edit them in some sort of Wiki to improve on the eSpeak IPA values.
It would be possible to automatically convert Latin to Deseret (or Shavian) and back, but it wouldn’t be easy, and it probably couldn’t be done quickly enough to have a browser plugin do it.
Local database lookups are very fast I don’t see how speed on a client side browser plugin would be an issue.
Local database lookups are very fast I don’t see how speed on a client side browser plugin would be an issue.
Fast enough that you can do a few hundred of them per page? (Not rhetorical; I don’t know.)
Textspeak substitution wouldn’t actually be a problem; I don’t know why I thought otherwise. And back-conversion to Latin would just require brute-forcing words that don’t show up in the dictionary.
Yes you need a phonetic dictionary. eSpeak is a project where people already dealt with the problem of predicting phonetics. You could start with the values that eSpeak produces and allow users to edit them in some sort of Wiki to improve on the eSpeak IPA values.
Local database lookups are very fast I don’t see how speed on a client side browser plugin would be an issue.
Fast enough that you can do a few hundred of them per page? (Not rhetorical; I don’t know.)
Textspeak substitution wouldn’t actually be a problem; I don’t know why I thought otherwise. And back-conversion to Latin would just require brute-forcing words that don’t show up in the dictionary.
Yes, select queries don’t take much time when you have an index. Thank Moore’s law.