Appendix talk:Naʼvi

Spurious words

I'm removing iveh k’nivi s’dir "baby carrier/sling". It does not fit Na'vi phonotactics, and Na'vi doesn't even have a /d/. Given that, I wonder how reliable the rest of the entries are.

[Another, which I can see in a photo online, is nikt'chey for 'food wrap'. Again, not a possible Na'vi word.]

This list was apparently manually copied from the Avatar: A Confidential Report on the Biological and Social History of Pandora book, which is the only reference work for the language available to this moment. So there are likely more hidden typos in it. Hopefully they'll get weeded out eventually.

Stress is apparently phonologically unpredictable, but how should it be marked? Underscores look a bit ugly and distracting, but the usual method of acute accent mark would interfere with other diacritics on vowels (<ì>, <ä>).

Also, pronunciation in phonemic transcription could be easily generated from the spelling, so that's sth to think about. --Ivan Štambuk 05:40, 21 December 2009 (UTC)

Plltxe 'speak' is also attested as prrtxe, so I added that in parentheses. The language has changed over time, so one of those could be dated rather than a typo. A likely typo is peyfa, which is morphologically pe + fya. 'Course, it could by metathesis or assimilation, but we don't see that elsewhere. (Do we?)

Also, I doubt iveh k’nivi s’dir was a typo. There's no credible way you could get from anything Na'vi-like to that. Maybe a spurious copy from some other language.

I started adding the elements in compound forms, but then decided against it, as there are too many unknowns. Several words appear to be based on roots that we don't have, others include case endings, etc.

As for stress, I say go with the acute accent, including ŕr, ĺl for the syllabic consonants. I've done that sporadically on the Wikipedia article. Besides being ugly, underlining is not copy friendly; I've already corrected one such copy error here. We can come up with workarounds for <ì>, <ä>. The easiest would be to not mark them at all, and note that stress goes on the acute accent, or on the <ì>, <ä> if there is none. Since AFAIK basic words have only a single stress, that would reduce the problem to words like zìzìt which have more than one such vowel (also Änsìt, ätxäle, fpxäkìm, ìlä (which I think goes either way), pänutìng (though this is pänu + tìng), pätsì, rä’ä, za’ärìp.

Graphically, <ì> with an acute accent would be <ǐ>, so we could use that if we have to. ä́ required a combining diacritic, since it's not supported as a single letter in Unicode (the closest thing graphically is ǟ). I thought we might go the Hungarian route of a double acute, but the closest precombined letter in Unicode is ȁ. --kwami 06:19, 21 December 2009 (UTC)

OK, I'll later generate new entries with acute accents (plus <ǐ> and <ä́>), as well as IPA. It's annoying that there are no inflection tables available.. --Ivan Štambuk 20:07, 21 December 2009 (UTC)

You might want to check that <ä́> is supported on IE. Diacritics don't always show up.

I converted to Frommer's preferred orthography with c and g. Shouldn't be a problem w the IPA added as well. kwami 20:25, 21 December 2009 (UTC)

Went ahead and added the stress marks per this site. kwami 10:13, 24 December 2009 (UTC)

need additional eyes to review

The dict. is browsable here. I've found some copy errors, as well as several cases where the copyist overlooked stress. Could use some extra eyes to verify we have a reliable copy. kwami 09:40, 6 January 2010 (UTC)

I began doing some work on that. So far (22:12, 14 January 2010 (UTC)), I've checked ’, A, Ä, E, F, H, I, Ì, K, Kx, L, M, N, Ng, O, P, Px, R, S, T, Tx, Ts, U, V, W, Y, and Z (in other words: everything). I'm using stress from the dictionary (Avatar: A Confidential Report ...) and putting it only in the IPA transcription, as you have done with the other sections. Where there was a stress marking in the IPA but not in the book, I put comments into the article so we can check where this stress came from, also for stress that is not in the book but can either be derived from other words or clearly heard in the movie (also for cases where the pronunciation in the movie doesn't match the dictionary, where I consider the movie to be more canon than the dictionary).

One word that I came across where I don't know the syllables (and therefore the correct IPA transcription) is eyaye (sp. plant; Warbonnet). The word is not in the dictionary, where does it come from? Also, what are the syllables in this word? Are ey and ay diphthongs, or is it e-ya and/or a-ye? Sebastian Goll 17:32, 7 January 2010 (UTC)

Similarly, is it fey-ä or fe-yä (their, pl. of peyä), and is it fi-zay-u or fi-za-yu (ancestors, pl. of pizayu)? Sebastian Goll 18:35, 7 January 2010 (UTC)

Sorry, just dropped a comment on this on your talk page. I think we can assume a basic syllabification of CV.CV.CV in Na'vi, not CVC.VC.V. And indeed, that's what we hear in the movie: when a CVC word has a V suffix, it resyllabifies to CV.CV. Also, as far I can tell, there is no distinction in Na'vi between /ai̯a/ (V.V, with the first vowel being a diphthong) and /aja/ (V.CV, with the C being w or y). So I'm betting that /aj+a/ should resyllabify to /a.ja/ just as /aŋ+a/ resyllabifies to /a.ŋa/. Otherwise we'd have a phonemic distinction which is not mentioned by Frommer and not reflected in the orthography or even in his IPA transcription, since he uses the same /j, w/ notation for his diphthongs as he does for his consonants.

As for eyaye, perhaps it's one of those names that is in the text of the Guide but not in the dictionary appendix. There are others; I added 'push' and 'fruit' from 'push fruit'. However, there are several words there which are clearly spurious (non-Na'vi phonologies), so I think we should mark these words somehow. (Not all are necessarily spurious; the "poison water plant" starts with the syllable for "poison", which has an ejective, and so is likely to be correct even though we don't have "water" or "plant" in the dictionary.) kwami 22:06, 8 January 2010 (UTC)

Okay, I've rechecked T, Tx, Ts, U. I'd gone over it too quickly before, and there were a couple of stresses that I'd missed.

V, W, Y, Z are not available online, so I am unable to verify these. kwami 09:03, 11 January 2010 (UTC)

I'll receive my copy of the Guide in a couple of days. I'll go ahead and check V through Z when I have it. Sebastian Goll 20:49, 11 January 2010 (UTC)

Great! Could you also list all the "Na'vi" words in the main text here on the talk page? There might be a couple dozen, maybe. From browsing online, I've seen some which appear reasonable (the poison-water plant) and some which are ridiculous (the food wrap). kwami 00:42, 12 January 2010 (UTC)

I got my copy of the Guide and checked the remaining entries. I'll compile a list of all other Na’vi or pseudo-Na’vi words as I come across them in the main text and put it up here. This will take a couple of days though. Sebastian…talk 22:12, 14 January 2010 (UTC)

Thanks! I noticed a "Na'vi name" field in the info boxes of some of the articles, and not in the actual text, but who knows. kwami 03:21, 15 January 2010 (UTC)

Okay, got some from the LearnNa'vi dict. (the sourced one, not the "Guide") kwami 06:19, 17 January 2010 (UTC)

Should I still make the list? Sebastian…talk 15:33, 17 January 2010 (UTC)

Gender suffixes

I just came across the masculine and feminine versions of túte "person" in the dictionary. They are tuteán "male person" and tuteé "female person". What bothers me here is the clash of two e's in tutee /tu.tɛ.ˈɛ/; I thought Na’vi does not distinguish vowel length? In the maybe similar situation of the laudative ‹ei›, the i transforms to iy, as in siveiyi which is s‹iv›‹ei›i "make‹SJV›‹LAUD›". Might something like this happen with gender suffixes as well? Maybe tutee is really tuteye /tu.tɛ.ˈjɛ/ or something similar, like tute’e /tu.tɛ.ˈʔɛ/? Sebastian Goll 01:08, 10 January 2010 (UTC)

The published dictionary has a few errors in it, and this may be one of them. Remember, Frommer gave túte "person" and tuté "female person" as a minimum pair for stress. kwami 08:45, 11 January 2010 (UTC)

I didn't know that Frommer gave us tuté, so that settles this. Do you want to add a sentence or two on the subject to the main article, explaining that the feminine suffix -é replaces final e? (Or does this only happen with túte? Do we have other examples?) Similarly, I would expect that -án replaces final a, like in tireán (from tiréa "spirit"). Do we have a reference for this? Sebastian Goll 21:00, 11 January 2010 (UTC)

No, no refs. Just F's insertion of a y tween two i's, and his conflation of two e's. (You might want to review the LangLog posting, and his followup. That's pretty much canon right now.) kwami 00:39, 12 January 2010 (UTC)

You mean his follow-up from December 21 on the LangLog posting? I read that (and the LangLog posting, of course) some time ago; but it seems that I should have another look at it: I'm realizing that my memory is not nearly as good as I would like. (Right now, I'm mainly using the Wikipedia article most of the time when I have to look something up.) Sebastian…talk 01:56, 12 January 2010 (UTC)

Túte has the first syllabe as the stress syllabe. It's pronounced /tu'te/, whereas Tuteé is pronounced /tute'/.201.13.32.118 00:13, 24 January 2010 (UTC)

Plural forms

The list currently includes entries for singular and plural forms of words that undergo lenition. This makes the list longer than it need be, and requires two updates in case of errors. I'd like to remove the entries for plural forms: we already name the irregular (lenited) form in the definition of the singular word; I'd only add the plural's IPA transcription there which would otherwise be lost. Are there any objections why we should keep the extra entries for plural forms? Sebastian…talk 01:48, 19 January 2010 (UTC)

It makes things easier to look up. People might be confused if they forget about short plurals. kwami 21:29, 20 January 2010 (UTC)

Is there another (real-world) language that uses lenition or some other mechanism that modifies the beginning of a word for plural forms? How do they handle plurals in dictionaries? We could add a note at the top giving the lenition table for Na’vi, to remind people of short plurals. Also, searching inside the page itself would still reveal the plural, since we would continue to state them at the definition of the singular.

Don't get me wrong, I recognize the advantages of having separate entries for short plural forms, but at the same time I'm worrying that in this way it becomes very easy to end up having inconsistencies in the dictionary by simply forgetting to update both entries when correcting an error. On a related note, I also worry about stating a lot of words as subentries of nì (adverbializing prefix) and tì (nominalizing prefix) instead of giving them proper entries (or stating the adverb or noun only at the main definition): over time these lists can be expected to become increasingly long. Again, how do real-world languages that have prefixes instead of suffixes for adverbialization or nominalization handle this situation?

Ideally, I'd like to have exactly one entry for each bold word in the dictionary, giving all the derived words such as adverb, noun, dual/trial/plural etc. as necessary. Then it would be much easier to manage the dictionary by correcting each mistake, or adding more information, only at a single location. I also argue that then it would be easier to find each word since there wouldn't be three definitions all over the place but just a single one.

Of course, modifiers that change words must be given prominently: common prefixes, as the ones stated above, must keep their proper location in the dictionary and be marked so that people can be redirected to the main entry of the word they are searching. Irregular forms keep their separate entries of course (such as nulkrr), but regular forms should, in my opinion, not have separate entries.

Again, I have absolutely no experience in how real dictionaries handle these issues. I also have no experience in creating a dictionary, so please forgive me if I am stating absolute nonsense. I just noticed that it becomes increasingly difficult to keep the redundant information coherent, so I was wondering if this redundancy is really worth the effort. Regard my thoughts above as just that: random thoughts on the subject. For now, I'm not going to change the appendix in any of the ways I stated above. I just ask that we think about whether the way we have it now is really the best way to do it. Thanks! Sebastian…talk 22:50, 20 January 2010 (UTC)

Also related to the above issue is the fact that Na’vi uses infixes in verbs. For instance, we currently have two separate entries for kame and kìyevame (where the latter is also a subentry of the first). Obviously, we cannot do this for every single verb and tense/aspect/mood combination. With regard to what I said previously, my suggestion would be to not completely remove kìyevame (since it constitutes a distinct phrase with the additional meaning “good-bye”), but at the same time state it only as subentry of kame (since it is directly derived from it). Again, the user of the dictionary would have to be familiar with how verb derivation by infix works in Na’vi – but he has to know that anyway when looking up essentially any verb in the dictionary. What are your thoughts? Sebastian…talk 23:34, 20 January 2010 (UTC)

Another thought regarding the infix in verbs situation: would it hurt to generally indicate the infix positions for every verb in the dictionary? We wouldn't have to name each of the three explicitly, when they end up in the same place (as happens for monosyllabic words), but would only indicate where additional letters would go; this way helping users to find a match to the word they are looking for, by providing this additional visual aid when they are quickly scanning the dictionary. For instance, kame could be written as k·am·e, making it easier to match it with kìyevame by providing the positions where [arbitrary combinations of infixes] would go. Obviously, this notation would have to be explained in the introduction (it's not hyphenation). Sebastian…talk 23:34, 20 January 2010 (UTC)

I just noticed that adding dots (or some other marker) in verbs would make searching for them within the document harder, if not impossible; but I'm guessing we could find a way, using some kind of HTML, CSS, or JavaScript trick, to still be able to use browsers' search function. At the same time, it might be possible to use a similar method to search for both i/ì or a/ä at the same time (i.e. searching for "ka" would stop both at "ka" and "kä", for instance). This would facilitate the use of the search function for users who cannot easily enter foreign characters on their keyboard. Just an idea, maybe I'll look into that (I do have some experience with HTML et al.). Sebastian…talk 00:02, 21 January 2010 (UTC)

Adding infix position markers would be particularly useful for derived or compound words where the infix positions are not immediately clear from the rules, for instance the compound yomtìng “to feed” which has yomt·ìng, and not *y·omt·ìng. Sebastian…talk 00:17, 21 January 2010 (UTC)

I like the idea of the dots; maybe we could add it as a secondary transcription, the way we only mark stress in the IPA, so as to not interfere with searches.

Take a look at a Swahili dictionary some time. Plurals and other derivations are only listed separately when the editors judge that a reader might not know where to look, but some are listed. Arabic dictionaries are similar, but with even more cross entries. Or consider how irregular verb forms are given their own entries in English dictionaries.

We could leave separate entries for short plurals and lexicalized expressions such as kìyevame, but then say only "See kame." That way there'd be nothing to update unless we get the actual form wrong. I also think we should keep fay-.

Under nì- and tì- we could also direct people to look up the root. kwami 09:33, 21 January 2010 (UTC)

I just created a simple (okay, relatively speaking) template that we could use for all headwords in the dictionary. It can automatically produce the second transcription with dots for infix positions, and it also takes care of adding the IPA transcription (making the explicit use of IPAchar unnecessary). In the future, we might also include the category of each word (i.e. verb, noun, etc.) in the template which would then render it in a nice dictionary-like way, eventually ridding us of having to use explicit articles (a [...]) for marking nouns. Also, we could include additional flags inside the headword template to indicate the source of each word (Guide, game, film, etc.) and how certain its meaning in the dictionary is (getting rid of all the randomly strewn question marks).

This is how the template is used (for now anyway; this might change once we know what we also want to include in it):

{{NaviHW|k|am|e|ipa=ˈka.mɛ}}

→ (produces) →

kame k·am·e /ˈka.mɛ/

Using bars for infix markers is optional, and up to three bars are supported – which takes care of all possible infix positions, though we would probably not use more than two anyway, since 1st and 2nd end up at the same position. — (Though we still might want to include all three positions since that would be their logical place – the template would only render two adjacent markers as a single dot. The reason would be that maybe at some later time we might want to change how the template looks like and maybe include all markers. Also, maybe there are words that do not have 1st and 2nd infix at the same position.) — Also, using the ipa parameter is optional:

{{NaviHW|kame|ipa=ˈka.mɛ}}	→ (produces) →	kame /ˈka.mɛ/
{{NaviHW|k|am|e}}	→ (produces) →	kame k·am·e
{{NaviHW|kame}}	→ (produces) →	kame

Together with yet another template NaviSA ("see also", or simply "see") we would be able to use hyperrefs for the seperate entries for words like kìyevame. The NaviHW could include an (HTML) anchor, in turn using the anchor template, that would automatically be referenced by NaviSA, making the "see kame." a clickable reference. In my opinion, this would greatly enhance the user's experience when using the cross-references within the dictionary. Sebastian…talk 19:25, 21 January 2010 (UTC)

Wow, that's a lot of work. Let's hope that s.o. dn come by and decide this appendix is inappropriate!

Hm, I tried "l||u", and got:

l /'lu/

with no dots. I'd expect l··u, to emphasize that all affixes go there.

yomt /X/

Eh, yomtìng dn work yet either. Maybe s.t. to do w conflating the two dots? kwami 01:49, 22 January 2010 (UTC)

I'm sorry! I just mentioned that we could put multiple markers in there but I didn't actually implement it. But I'll do that right away! Sebastian…talk 02:14, 22 January 2010 (UTC)

It should work now. Does it look right this way? Or should I use only a single dot instead of two or three when they are at the same position? As I said we might want to explicitly give all three infix positions in the wiki code for every verb on the list, but for now have the template render only a single dot when two or more collide. Technically, wouldn't lu be lu l···u since all three infixes go before the u? Or should we always use only a single position for 1st and 2nd infix combined? Would it theoretically be possible to have an exotic word where 1st and 2nd infix go at different positions? Sebastian…talk 02:49, 22 January 2010 (UTC)

{{NaviHW|l||u|ipa='lu}}	→ (now produces) →	lu l··u /'lu/
{{NaviHW|yomt||ìng|ipa=X}}	→ (now produces) →	yomtìng yomt··ìng /X/

Another idea: instead of using a single dot for two consecutive dots, we could also use e.g. a colon, symbolizing the fact that two affixes go at that position. lu would then not be rendered as l··u but l:u. Again the template would take care of all that formatting, so it would still be l||u or l|||u in the NaviHW instantiation. Sebastian…talk 02:59, 22 January 2010 (UTC)

Templates

I added a demo of the templates NaviHW (for headwords) and NaviSA (for see also) to the dictionary. Have a look at the entries for kame and kìyevame; this is how using those two templates might look like. I wrote the NaviSA template in a way that it can be used with more than a single argument, in case this might be necessary for some words:

{{NaviSA|kame}}	→ (produces) →	See kame.
{{NaviSA|kame|kìyevame}}	→ (produces) →	See kame and kìyevame.
{{NaviSA|kame|kìyevame|krr}}	→ (produces) →	See kame, kìyevame and krr.
{{NaviSA|kame|kìyevame|krr|kll}}	→ (produces) →	See kame, kìyevame, krr and kll.

As stated above in the Plural forms discussion, I am open to any suggestions as to what else we could or should include in either of the two templates. I am also considering adding yet another template for subentries (such as the kìyevame entry inside kame) which behave like the NaviHW template but do not include the anchor. Oh, also, in my example, I might have mixed up how headword and subentry relate: should the headword kìyevame point to the subentry at kame, or should the subentry kìyevame rather point to the headword (which would then include the definition)? I guess the latter would make more sense. Sebastian…talk 22:47, 21 January 2010 (UTC)

I wouldn't have the subentry point to anything, but just have the definition. The fact that kìyevame is a subentry of kame should make things perfectly clear. It's secondary main entries that I'd have repoint. Or is that what you meant? If so, yeah, I agree that all the defs should be listed under the one primary heading, and that the derivations scattered around the rest of the alphabet should all point back to it. kwami 01:40, 22 January 2010 (UTC)

Right, the headword kìyevame should point to the subentry at kame. I guess I was just confusing myself when I wrote what I did above. What about prefixes such as le (adj.), nì (adv.), tì (noun)? Here we would do it the other way round, right? I.e. just state that these are prefixes (without lenition) and have the user look up the word without the prefix? Maybe add a couple of prominent examples. For ay, fì, fra, tsa however I'd suggest keeping the derived words/ lexicalized expressions (e.g. ayfo, fìtseng, frapo, tsakrr) as subentries with proper definitions, just as with kìyevame, adding additional headwords pointing back to that definition when necessary.

Forget what I just wrote, the rules are so much simpler: whenever a derived lexicalized expression appears, we keep the definition as a subentry. Whenever something is just an example, we state it as such or maybe even remove that subentry (e.g. fìskxawng, nìwin, tìtxur); the definition of that word would then be given under a separate headword. Does this make sense? Sebastian…talk 02:31, 22 January 2010 (UTC)

What else would we want the NaviHW template to do? Right now, we have the additional infix transcription for verbs, the IPA transcription, and the placement of the anchor for NaviSA references. I'd like to also add markers such as [n.], [v.], [adj.], [adv.], [pn.] etc. to each headword so that we can know immediately the function of each entry. Also, the infix notation should only be activated for verbs. Nouns could instead use positional template parameters for singular and plural forms, e.g. {{NaviHW|n|nari|aynari|menari|ipa=ˈna.ɾi}} would be the shortcut for producing “nari /ˈna.ɾi/, pl. menari (2) or aynari”. What else? Sebastian…talk 03:10, 22 January 2010 (UTC)

I added some examples and a short reference to Template:NaviHW. Does this look reasonable? Should I continue to work on the template? Would we even want to use it? Sebastian…talk 02:17, 23 January 2010 (UTC)

As to whether it's worth converting to templates, that's hard to judge. How much time are we going to spend maintaining this if we don't?

Maintaining the dictionary if we don't convert to templates? That's hard to tell. I can imagine that once more words pop up this is going to be a very long list; I wouldn't want to make any layout changes then. Using templates however that would be trivial: just change the template. As to converting the current state to use templates: that shouldn't be too hard using some clever regular expressions – in fact, I already did this to test some things (but only preview, without saving the changes). Sebastian…talk 04:51, 24 January 2010 (UTC)

Is it possible to autoconvert to IPA? I mean, if we used Na'vi orthography but added apostrophes for stress and periods for syllable breaks, could the rest be done by the template? (I don't understand the template syntax at all. For example, you seem to be calling the IPA template with the ipa= parameter, but the template isn't actually called.)

No, autoconversion would very likely not be possible. Templates in MediaWiki are really dumb, you cannot do any elaborated text processing. There is this thing called parser functions which can basically do anything, but only very few such as #if or #switch are activated for the Wiktionary (and Wikipedia). Oh, and the real IPA-template (i.e. {{IPAchar}}) is called inside {{NaviHW/ipa}} which in turn is called by {{NaviHW/main}} which in turn is called by either {{NaviHW}} or {{NaviSE}}. I tried to make everything as modular as possible: the (optional) IPA inclusion is called for every single word category and may appear at a different position for each, so I cannot easily include it in the main template; therefore this nested template structure. Sebastian…talk 04:56, 24 January 2010 (UTC)

• NaviHW: Why should only adj get an adv cell? Adverbs are made from verbs and pronouns too. The special -ly connection that exists between adj & adv is a feature of English, not of Na'vi. What I'd rather see are the attributive forms; that could perhaps be done automatically.

If we're gonna have sep. DU & TRI entries for nouns, I'd have sep. long & short plural forms as well. I think there's only a need for the short forms; the rest can be generated automatically if we ever decide we need them (with override du= & tri= parameters for those few nouns that would get a double e).

Caution: duals are not plurals. In Na'vi, a plural is at minimum 4. We shouldn't list the duals and trials as "pl."

• NaviSE: Do we want these entries in italics? I was thinking it would be nice to keep them in bold, so that they're easy to see them on the page, and to use italics for illustrative phrases. So, under lu we might have oeru lu "I have", which is an easier way of explaining it that just defining lu as "to be, [w dative] to have".

IMO we should also have the option of saying 'Short plural of kore,' not just 'See kore,' also 'lenited form of tsat,' not just 'See tsat.'

kwami 04:13, 24 January 2010 (UTC)

Lots of the things you are mentioning I included primarily in order to evaluate what we really need, so yes, having the adverbs attribute only on adjectives doesn't make that much sense. Do we want to keep the attributive forms in the dictionary? Their derivation is as straightforward as dual & trial forms for nouns which we could also get rid of. The latter I included mainly for entries where we want to indicate that it makes sense to use dual or trial: I'm not sure but maybe using dual for the noun "tree" would only be used for a special pair of trees (not just any two trees) whereas with "eye" it would be perfectly natural to have it in dual; similarly for trial. So we would give dual form for nari but not for utral. (Or does (regular) plural always indicate "at least 4"?) But I'm also fine with dropping dual and trial altogether. The "pl" attribute we would then use exclusively for short plurals (since they may look surprisingly different); we need not include long plurals since the user would find an appropriate note regarding those at the ay prefix.

Italics, no, maybe not. I was just thinking that bold words should be proper headwords (including anchor) and should appear only once in the dictionary. So, for instance, kame would be bold, but kìyevame below the kame definition would not since there is another kìyevame entry later in the dictionary (which essentially is just the reference back to kame). On the other hand, we would place karyu only below kar and not anywhere else since it's directly derived; here karyu would be bold since their is no separate entry elsewhere (due to lexicographic order: there is no other word between kar and karyu). Am I thinking too complicated?

Illustrative phrases wouldn't need any complicated markup, right? I'd even suggest they should not contain an IPA transcription since they should rely only on words that have already been defined elsewhere (as in the oeru lu example you gave). So, we wouldn't need a separate template for those.

Elaborating on {{NaviSA}} to make it more verbose is a good idea (and helps the reader a lot); I will work on that. Sebastian…talk 04:46, 24 January 2010 (UTC)

I was thinking of attributives because the a is so easily missed, unlike plural -ay etc., and this would help in a search. It would also help familiarize people with the diff. tween attrib & pred. adj, which unlike the plural d not occur in English. But maybe you're right.

I started a NaviIPA conversion subtemplate, but don't know how to get it to accept an arbitrary input and covert per the rules I have in there. So right now it only works if you input a single phoneme.

Yes, in Na'vi, plural means at least 4, of anything. I do think duals might be useful for things that come in pairs, like body parts or lovers, as well as words which lose an e.

kwami 04:58, 24 January 2010 (UTC)

The reason why I'm worrying about attributives is that they really are straightforward (no lenition or anything), and the dictionary probably isn't the right place to teach people grammar (that's what the Wikipedia language article is for): we assume that whoever comes here already knows what attributives are and expect them to look up the right adjectives without the a particles. (In fact, I'm thinking of the a particle being not attached to the adjective at all; Na'vi is a spoken language only, so it seems only our (or Paul's) convention that the a attaches to the adjective; it could equally well remain a separate particle between noun and adjective, just like when it's used for subordination; there would be no audible difference. — I just noticed you have a footnote on that in the Wikipedia article; so I guess you agree.)

Regarding IPA autoconversion: I think it's not possible to have a template process an entire string of data, in other words a word. So, the #switch statement in your {{NaviIPA}} is only able to look at the entire first template argument, not at the beginning or only at the first letter or something. One way would be to have each phoneme be a single template argument but then we would easily have 20 arguments; also it's not editor friendly at all (think of k|ì|y|e|v|a|m|e). Maybe I'm mistaken and there is some cool parser function activated here at the Wiktionary that does exactly this kind of textprocessing, but if that's not the case, we can't do it.

Plurals: I'll think about that – esp. I'll fix listing dual/trial after "pl.", I'll probably use "du. X, tri. Y, pl. Z" instead. In any case, we should give any of the plural forms (dual, trial, plural) only when they are "special" in some sense, right? I.e., plural only for short plurals with lenition, dual or trial only for words that come naturally in pairs or groups of three, respectively. Sebastian…talk 05:19, 24 January 2010 (UTC)

Yes; also meveng, pxeveng etc. kwami 06:59, 24 January 2010 (UTC)

plural demonstatives?

Are these attested? Are the plurals of fì'u, tsa'u = fayu, tsayu or ayfí'u, sa'u? Sorry, it might have been me that added the plurals under the heading tsa, I don't recall! kwami 01:42, 22 January 2010 (UTC)

The Guide only gives us the singular forms fì’u and tsa’u, no plurals. I think you added them in revision 8161339 but marked them with question marks. During that time, you made a lot of other changes adding the lenited, short plural forms for all kinds of words to the list. In revision 8235281 I put the question marks in brackets when I added the IPA transcriptions and checked the words on the list with the Guide. Your revision 8235869 then removed the question marks completely when you added monosyllabic stress. I'm guessing that we never had these forms attested but that the question marks got removed accidentally. Sebastian…talk 02:12, 22 January 2010 (UTC)

I'll take them out, then. We don't know if these inflect like non-demonstratives.

Also, should we have IPA /ɑ/ for "a"? I can autoconvert if we should. kwami 11:11, 22 January 2010 (UTC)

I don't know, did you ask Paul? The LL post is partly contradictory or maybe misleading: he explicitly has [a] in the IPA transcription, but in the chart he lists the letter “a” in one column with “u” and “o”, suggesting [ɑ] instead. As long as we don't know for sure which one fits best, let's stick to /a/ since that is easier to type. ;) Sebastian…talk 04:16, 23 January 2010 (UTC)

Yes, one of my earlier questions.

He transcribed Na'vi with /I, E, ay/ etc. originally, then converted. He might simply be using /a/ because it's more easily typable. kwami 11:18, 23 January 2010 (UTC)

Since I don't know what you'll be doing w the templates, I changed /a/ to /ɑ/; easier to change it back than to change it to ɑ later. (I can autochange a to ɑ within templates that have IPA in them, but that won't be easy to do once they have other stuff as well.) kwami 06:56, 24 January 2010 (UTC)

to add?

Anurai - clan name [game]
Li'ona - clan name [game]
Lompo - m.n. [game]
Nok - m.n. [game]
Omati - m.n. [game]
Rai'uk - name [game]
Tasun - name [game]
Tawkami - clan name [game]
Tipnai - clan name [game]

fwa < fi`'u+a ?
rel image, picture ?
reltseo art ?

Where do the latter three come from? (Oh, and what's "[g]", the Guide? Wasn't that "[sg]" for Survival Guide?) Sebastian…talk 12:55, 28 January 2010 (UTC)

No, just the Game. Got tired of typing it.

The others were in an email to Skxawng, hopefully to be posted soon. kwami 19:25, 29 January 2010 (UTC)

Transitivity

Would it be useful to indicate for every verb in the dictionary whether it's transitive or intransitive? Verbs may have a different meaning and be used both as intransitive and transitive, e.g. pay "wait" (intr.), "await" (trans.); for those we would indicate both meanings. Should I include this in the {{NaviHW}} template? Sebastian…talk 12:51, 28 January 2010 (UTC)

Apostrophe

Currently, we use the typographic apostrophe ’ as the marker for glottal stops, such as in Na’vi. However, this often interferes with text searches in the dictionary, or might at least produce unexpected results for some users, since the typographic apostrophe is hard to distinguish from the vertical typewriter apostrophe ' from ASCII in some fonts.

The Wikipedia Manual of Style recommends the exclusive use of straight or typewriter apostrophes and quotation marks:

The exclusive use of straight quotes and apostrophes (see preceding section) is recommended. They are easier to type in reliably, and to edit. Mixed use interferes with some searches, such as those using the browser's search facility (a search for Alzheimer's disease could fail to find Alzheimer’s disease and vice versa). [...]

I propose to change the typographic apostrophe to the typewriter one for the same reason of being able to more easily search the dictionary. Any comments? Sebastian…talk 13:12, 28 January 2010 (UTC)

Yes, good for making it searchable. However, it looks a little odd, because it's not in boldface when at the beginning of a word. We might need to use < b> in such cases. kwami 12:24, 2 February 2010 (UTC)

You're right! This'll be fixed when we move to the {{NaviHW}} template which I'm planning to do some time this week. Sebastian…talk 16:43, 2 February 2010 (UTC)

Reliability

Might we want to add a switch for reliability? Say bold entries if confirmed by Frommer, roman if found in the SG appendix, and italic if in the SG text or the game? kwami 11:16, 4 February 2010 (UTC)

Sure! We could base the formatting you describe on the new src argument that I added a few days ago. See {{NaviHW}} for details. Sebastian…talk 15:08, 4 February 2010 (UTC)

For reliability, I'm (for now) using the src argument exclusively. When in doubt, I'm putting the least reliable source there, so lots of entries will end up as "SG" for Survival Guide, though many have been confirmed by Frommer now. So, please, if you know for sure that a given word has been confirmed by Frommer (or was used in the film, if we want to consider that more reliable than the Guide), change src to "FE" or "FM" or "AF". Sebastian…talk 02:21, 6 February 2010 (UTC)

We should have a sep. code for the text of the SG. The appendix is pretty reliable, but the main text is garbage. kwami 01:23, 7 February 2010 (UTC)

Suggestions? "GA" (or "GD") and "GT" (or "GM") for Guide Appendix (or Guide Dictionary) and Guide Text (or Guide Main Text)? I'd like to stick to two letter abbreviations. Sebastian…talk 01:40, 7 February 2010 (UTC)

Those start getting a little difficult to keep track of, and there are only a few such words, so IMO s.t. longer like "SG" vs. "SG text" shouldn't be a problem. kwami 09:37, 9 February 2010 (UTC)

Let's use "SG" and "SG text". I added a note to the introduction. Sebastian…talk 17:00, 9 February 2010 (UTC)

What about backformations, such as pay 'water' or utu 'push'? kwami 22:57, 9 February 2010 (UTC)

I'd suggest not marking them at all, as there really is no source for them: they're the product of our own guessing, for now (OR, if you want). Alternatively, we could use another marker; "derived", or even "OR", maybe? In either case, we should leave the comments in the source code, so that we still know which other word we derived them from originally (in case we shuffle around subentries). Sebastian…talk 00:49, 10 February 2010 (UTC)

new C section

I think we have an entry for Rr, rrta "Earth". Should be confirmed in writing soon. kwami 07:12, 16 February 2010 (UTC)

Ah, no, glottal stop. kwami 20:19, 21 February 2010 (UTC)

IO verbs

we should have, alongside vt and vi, a code for verbs which take a core dative, like srung si 'to help'. And there are a couple ditransitives like tìng. Don't know which abbrev. would be good; vd is traditional for ditransitive. kwami 20:20, 21 February 2010 (UTC)

Sounds reasonable. If we use "vd" (rendered as "v.d.") for ditransitives, what would we use for core datives? I'm not familiar with the traditional abbreviations, so I'm afraid I don't have any suggestions – other than "v.c." or "v.cd." which look rather artificial. Sebastian…talk 22:22, 21 February 2010 (UTC)

Hey, no fair! I was asking you cuz I haven't a clue. They're intransitive, though, so maybe s.t. based on that - except that 'v.i.d.' might be confusing. We could also have v.d. for dative vs. v.di. for ditransitive. Or v.dat. vs. v.di. kwami 22:35, 21 February 2010 (UTC)

Since you're saying that "v.d." is traditional for ditransitives, we should probably not use this abbreviation for something else. So, yeah, maybe we can stick to "v.dat." and "v.di."? Also, what would be the template codes for that ("vt", "vi", etc.)? Remember, we can change how these abbreviations appear in the final document (that's one of the reasons why we're using templates in the first place). Sebastian…talk 22:51, 21 February 2010 (UTC)

I think the traditional form for verbs with dative objects is v.b., as B stands for a core dative ("b" for "beneficiary"). So we could just go with v.b. and v.d., except that it would seem arbitrary to our readers. Is it worth having an apparently arbitrary abbrev. to save a couple letters?

Oh, could you add plural support to pronouns? I'll take a crack at it if you're busy, since you've done all the actual work :) kwami 03:06, 22 February 2010 (UTC)

We could stick to "vd" (ditransitive) and "vb" (dative; beneficiary) in the wikicode for the template arguments, using the traditional abbreviations, but have them appear as "v.di." and "v.dat.", respectively, in the dictionary. This way, we can be brief in the templates (since we know what we're dealing with; also, it would be documented at {{NaviHW}}), but aid our readers by providing to them the more verbose abbreviations.

Pronouns now behave as nouns, i.e., both "n" and "pron" accept plural, dual, and trial forms now. I'm guessing I should have "num" behave as "adj" too, once I have adjectives implemented? Sebastian…talk 12:22, 22 February 2010 (UTC)

Sounds good, thanks, and IMO yes. kwami 00:47, 23 February 2010 (UTC)

Just added "vd" and "vb" to the template (also to the reference at {{NaviHW}}). Still haven't finished work on the adjectives, I'll do that tomorrow. Sebastian…talk 01:28, 23 February 2010 (UTC)

Looks good. Maybe change PRON to PN? "PRON" makes me think "pronounced", and PN is a standard abbrev. kwami 09:40, 24 February 2010 (UTC)

Right. I added "pn" for now, to ease transition. Once all occurrences of "pron" have been replaced, we can remove the special handling of "pron" from the template. Sebastian…talk 10:32, 24 February 2010 (UTC)

Done. I changed all "pron" to "pn" in the dictionary and removed "pron" from the template. Sebastian…talk 10:40, 24 February 2010 (UTC)

Oh, and ADP and PREP should be added to the affix field. Adp. like mì cause lenition. kwami 11:09, 24 February 2010 (UTC)

Done! :) Sebastian…talk 13:33, 24 February 2010 (UTC)

POS should be more or less done, except for subtyping verbs. Any particular reason not to add "noun" to the short plurals? kwami 02:29, 26 February 2010 (UTC)

Thanks for all your work on the POS! :)

I was thinking maybe we could use "n.pl" (→ n.pl.) for the short plurals, as you did with tei "plains"? Sebastian…talk 14:09, 26 February 2010 (UTC)

That would work. I also wonder if changing v.i. and v.t to v.in. and v.tr. would be helpful or not. kwami 19:07, 26 February 2010 (UTC)

I changed POS to n.pl. for short plurals.

Switching from v.i. to v.in. and from v.t. to v.tr. is easy: we'd just have to change the {{NaviHW/headword}} template. In any case, what we should probably do is add a short list of all POS abbreviations that we use to the dictionary. Sebastian…talk 21:20, 26 February 2010 (UTC)

I didn't want to make any changes in case s.t. else depends on them elsewhere. Yeah, a glossary would be good.

Could you expand "sa"? We have several irregular genitives & aspect. Maybe it'd just take what we fill in? kwami 21:57, 26 February 2010 (UTC)

Okay, I changed v.i. to v.in. and v.t. to v.tr.

What exactly do you mean by expanding "sa"? I'm not sure I understand. Sebastian…talk 23:30, 26 February 2010 (UTC)

AFAIK, we can only indicate the inflection for short plurals. Every other use of the sa parameter just results in "See X". That's a good default, but I'd also like to be able to say "genitive of X" etc. Not that all of those need to be coded; perhaps we could just enter "this=genitive" or s.t. kwami 08:07, 27 February 2010 (UTC)

I see. Yeah, enhancing the abilities of "this=" would be nice. In fact, I just made the template so that it accepts arbitrary values: whenever "this=" doesn't match one of the predefined templates as documented at {{NaviSA}} (for now, we have "lenited", "shpl", and "gen"), the value is used directly. This can be used in "this=Genitive of" (equivalent to "this=gen") or "this=Dative of" or even "this=Similar words:" So, for now, you can use whatever comes to your mind directly; once in a while, when we notice that a specific "this=" is used very often, we would add it to the list of templates and use an abbreviation for it; this way, we can ensure consistency throughout the dictionary and still have the ability to use custom text where necessary. Sebastian…talk 14:17, 27 February 2010 (UTC)

Perfect! kwami 20:10, 27 February 2010 (UTC)

For short plurals, we probably want a one-word gloss, esp. for the print version. It's really annoying to look up a word only to be told to look up another word! We can do it now manually; do you have any problem with the period that would break the sg. form from the def, or isn't that worth bothering about? kwami 02:33, 1 March 2010 (UTC)

deleted

Deleting

fruit ?

Template:NaviSE banana-fruit tree

as apparently spurious. Not likely to be "push-fruit tree" as all morph. is lacking, and it doesn't match "push". kwami 11:02, 24 February 2010 (UTC)

moved

I'm moving my efforts to the dict. at Wikibooks, which is now in better shape than this version. kwami 05:49, 16 March 2010 (UTC)

Sorry, I was out of town the last couple days. I'll keep working on the template problem, either here or on Wikibooks. Sebastian…talk 17:09, 18 March 2010 (UTC)

Should we redirect to WB, rather than keeping a dated page here, or attempting to keep both up to date? kwami 14:15, 30 March 2010 (UTC)

Keeping both up to date sounds like a lot of work; I'd prefer having only a single dictionary, probably the one on Wikibooks: I don't know whether Wiktionary is the right place for keeping conlang dictionaries in the first place. Sebastian…talk 22:14, 31 March 2010 (UTC)

Okay, I'll just place a notice. Feel free to revert me if you think that's going too far. kwami 16:27, 4 April 2010 (UTC)