jcrippen / tlingit-verb-prefixes Goto Github PK
View Code? Open in Web Editor NEWTlingit verb prefix paradigm charts
Tlingit verb prefix paradigm charts
The w- irrealis prefix is found outside of prospectives in lexically specified (mental state, conative activity, resemblance state, pejorative) and derivationally specified (comparative dimension state, indirect motion, pretend activity, extraordinary state) contexts. Some of these may be u- rather than w- in which case they are already covered. The remaining ones need to be integrated into the document.
One option is to put them in the existing irrealis subsections. They probably don’t occur with the g̱- modal so they would only need to be listed in the irrealis subsections and not in the irrealis+modal subsections. This would require either more rows in the existing tables or new tables.
Another option is to add a separate subsection for them. This would complicate the existing structure of subsections, but it would help clarify their relative difference from the u- irrealis forms.
Some outstanding questions include:
There are several tables that are identical to other tables. Most if not all of these are cases where the irrealis u- does not appear in surface forms, e.g. any combination of u- and one of the subjects {tu- 1PL, i- 2SG, yi- 2PL, du- 4H}. Right now there is no indication that these tables are identical to others apart from mentions in the subsection introductions. We need some sort of sign on each page, perhaps a marginpar note like “(= 149)” that contains a table number with a hyperref link.
Currently the tables are organized by simple combinatoric possibility without regard to meaning. This is useful for phonological analysis but it’s less straightforward for grammatical analysis. We need to figure out how the data can be reorganized to reflect specific grammatical contexts, e.g. the set of all hortatives or the set of all imperatives. This is already in place for the prospective aspect. The perfective aspect tables conflate true perfective (wu- and u-) with ∅-conjugation habituals that have the u- perfective prefix.
Negation (and prohibitive/optative) would be an additional dimension to add to some – but not all, e.g. imperative – of the grammatical context prefix charts. In some cases there is no surface effect – e.g. prospective – so even though negation can happen there would be no difference between affirmative and negative tables. But in others – e.g. perfectives – there is at least i- suppression even if irrealis u- is not discernable. There may also be switching between lexical/derived irrealis w- in affirmatives and syntactic irrealis u- in negatives. So phase II of the grammatical table project could be negation tables.
One early decision is whether these grammatical tables should be in their own document or included as a second part to the existing document. The advantages and disadvantages of both approaches need to be listed and considered.
Currently the prefix colours are sort of arbitrary. Before we get locked in to a particular pattern, it would be useful to figure out some ideal sets of colours to use.
Issues to consider:
The LaTeX source code currently represents each row of a table as a single row of text. This makes it easy to read the source, but it actually complicates some automatic tooling. Even if only a single character is changed in one cell, diff
considers the entire row to be different. Since the rows are very long this makes interpreting diffs – and thus git
output – very hard. It also makes the data harder to parse since a program has to know quite a bit about LaTeX table syntax to pick apart the individual cells in each row.
An alternative format is to put each cell on its own line in the LaTeX source. A line like
cell 0 & cell 1 & cell 2\\
would instead be something like
cell 0
& cell 1
& cell 2\\
So that each cell is on a separate line. A change made to a single cell would be seen in a diff by the change of a single line. Parsing a row would be reading each line up to one ending with \\
and then filtering the LaTeX cruft like &
. Since each cell is on its own line, the count of lines in a block would track the number of cells in a row and thus make indexing simpler.
The current source repeats a lot of labels like the header content and table captions. This repetition is error prone. It would not be very hard to replace constantly repeated things like \multicolumn{8}{c}{Classifier prefixes}
or first person singular subject /{χ-}/
with TeX macros.
The usual problems with macros apply (moving arguments, eating following spaces). There are also some slight differences in formatting, such as Asp.\rlap{ +}
versus Asp.\rlap{+}
in tables where horizontal space is a problem. These would need to be either regularized or special cased with some macro magic.
There are several combinations of prefixes that are probably ungrammatical. One particular issue is the any combination of g̱- modality with i- stative without irrealis u-. All the questioned forms need to be reviewed to verify whether they are grammatically possible or not, and those that are not need to be starred with ‘⁎’.
For comparison, see the tables with fourth person human du- for impossible combinations.
It might be possible for a PDF to include tooltips on arbitrary non-hyperlink text. If this can be done then we could add tooltips to the surface form entries in each cell. The tooltip could contain the complete underlying prefix string that corresponds to the surface form. For example, table 85 “N-conjugation n- with irrealis u- and modal g̱-, first person singular subject x̱-” has a cell containing oonḵwadzi. This corresponds to the prefix string a-u-n-g̱-x̱-d-s-i-, from the horizontal a-u-n-g̱-x̱- and the vertical d-s-i-. If a reader using an app like Acrobat or macOS Preview hovers the mouse over the form they would see a popup tooltip containing the prefix string. Since this information would be encoded in the LaTeX source it would also be programmatically extractable and hence would simplify developing an automated mapping between prefix strings and surface forms.
Right now every table comes in two flavours: orthography and IPA. This literally doubles the size of the document. Language learners are probably less interested in the IPA representations and so could benefit from a document with just orthography tables. Likewise, phonologists may be less interested in the orthography representations and could benefit from a document with just IPA tables.
Explore the various LaTeX tools for conditional compilation. We would want a flag that turns on one or the other or both. Some problems:
{table}
environment to keep them on the same page rather than separate {table}
environments for each table.The ‘Prefixes’ column currently duplicates the information in the ‘Disjunct’ and ‘Conjunct’ = ‘Asp.’ + ’Subj.’ columns. It is useful in that it gives the prefix string as a single concise unit, but it takes up a lot of horizontal space. This isn’t a problem for most tables, but some of them – especially the u- + g̱- + g̱- tables – are near the limit of horizontal space on 8½″ × 11″ paper. Shrinking the font size in these tables would make things significantly harder to read given all the colouring. If the ‘Prefixes’ column is removed then there is a lot of additional horizontal space freed up for loosening the inter-column spacing in these worst-case tables.
If the ‘Prefixes’ column is removed, it could be useful to swap the order of contents in the ‘Disjunct’ column. Currently this is ‹form› followed by ‹description›, e.g. “x̱ʼe- ‘mouth’”. If the order was switched to e.g. “‘mouth’ x̱ʼe-” then this would put the prefix’s form immediately before the prefixes in the ‘Asp.’ column. This would make it easier to read the prefixes as a linear string.
If the ‘Disjunct’ column’s internal content order is swapped then it should probably be switched from left-aligned to right-aligned. The left edge of the tables would look ragged, but the distance between the prefix form and the content of the ‘Asp.’ column would always be the same which would make it easier to read the prefixes as a linear string.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.