Hmm, the problem may be more complicated than I've thought.
I had the idea that your system is more or less just a database of word-translation pairs, with links to a containing section (two or three SQL tables). Given the screenshot, I now see that there is probably TeX markup in the entries and that it is rigidly constructed around replacing variables in pre-formatted strings...
That's completely right. It was designed to allow Taronyu to change words easy on the way, later came other people to translate it more or less easily. After all, it's not a lookup or anything, it's a simple LaTeX creating machine. However, Eana Eltuyä vrrtep, the demon running the translation system for the website and the IRC, is parsing this data (it's also generating the SQL you may have already seen, which has exactly two tables, one for Na'vi, one localized).
What I had in mind by "quick lookup" is not a server-side search, which involves sending a request each time and is highly impractical for repeatedly looking up multiple words, for example when you are translating someone's forum post, and even more impractical for mobile users, given mobile connection latency. My usage scenario is: Encounter a Na'vi text - open the dictionary in a new tab - quickly look up all you need, switching between tabs, then keep the dictionary open should you need it more - close the entire browser when you're done. It only involves one HTTP request for all the known words, and using any browser's in-page search is always blazing fast, and it allows you to jump over occurences back and forth (very important for reverse usage, when translating X to Na'vi).
(Don't read this: To create the SQL file, the demon is capable of fetching *all* available words including all translations and stuff. It's a pretty big query, but since it's using UNIX sockets, it doesn't matter. Damn, you read it, didn't you.)
As for IPA, we don't need it if we mark stress by underlining and mention any exceptions to the otherwise pretty unambiguous latin transcription.
And not having a UTF-8 ready font, that's not going to be the case of any non-english dictionary readers and if there is a problem then OK, they will see gibberish in the pronunciation brackets but they can download the PDF if necessary or solve their own font issues, who cares - we're not creating a paid-for service.
As for markup, format and browsers messing up, you'd be absolutely right if we were to reproduce the original document look using HTML and CSS. But again, that is not the goal, the web variant should be minimalistic, with only the most basic markup - headings, lists, bold, italic, tables and that's it!
Well, that would be very well possible - even an index with hyperlinks and all.
Take a look at the web-published Google Docs version of our current dictionary - ignore it's in Czech and just look at the simplistic but functional and accessible formatting:
http://docs.google.com/View?id=dfrz8dmn_1gv7mc2dmI use this in my 3 years old phone and it loads fast and is quickly searchable. A PDF is neither of those. All we in fact need is something like this, a simple and always-up-to-date on-line dictionary, as an
alternative to the otherwise very nice PDF document.
So, without further rambling - is it possible to output a super-simple HTML from your DB or not? The only real problem I see is the stress, which cannot be easily extracted from IPA to underlining. But having UTF-8 IPA for those who can display it would be pretty much enough.
Thanks for commenting on this issue, Tuiq
I may move this discussion to a separate thread later on...
Actually, I just updated navi_dict.pl - if you take a look at it, you can now display the IPA. I'm not a professional, but I'd say it's about to be correct, using only UTF8.
It is possible, more or less, to create this simple HTML. I'll see what I can do and post if I have something to show.
