Both column headings for the basic mobile layouts should have the same formatting (bold etc.)

[aarppe]

Following up on the implementation of the new mobile basic layouts in #191, for the sake of clarity, both column headings for the four types of verbs should be formatted similarly (bold-faced, etc.), not just 'ni-/ki- word' and 'ê-/kâ- word' as in below ...

... but also 'Actor' and 'Actor -> Goal'

This applies only to the mobile basic layouts for the four verb types, not the nouns.

[eddieantonio]

This is tricky to implement with the current format of the layouts.

Consider the VAI layout file:

	"Something is happening now"
"Actor"	: "ni-/ki- word"
"I"	Ind+Prs+1Sg
"you (one)"	Ind+Prs+2Sg
"s/he"	Ind+Prs+3Sg

or the VTA layout file:

	"Something is happening now"
"Actor → Goal"	: "ni-/ki- word"
"I → you (one)"	Ind+Prs+1Sg+2SgO
"I → him/her"	Ind+Prs+1Sg+3SgO

To denote that something is a title, we surround the column in "" double quotes. To denote that something is a column heading, we surround the column text in "" double quotes. To denote that something is a row label, we surround the column text in "" double quotes.

This ambiguity means we need to make the layout parser attempt to guess our intention. Right now, there are already some heuristics of when it decides that "" is a title, however, it seems like more need to be written. I believe it determines that an alignment mark (a.k.a., a colon ":") indicates a column heading.

I'm worried that with more heuristics trying to interpret ambiguous data, we'll make a very brittle layout parser that doesn't always do what we want. We already have this situation on our hands!

Before I add more heuristics to the layout parser, I want to see if we can make a format where

• titles: "Something is happening now"
• column headings: "Actor"/"Actor → Goal"/"ni-/ki- word"
• row labels: "I → you (one)"/"I → him/her", etc.

are all explicitly labelled.

Antti: do you have any thoughts about such a format?

[eddieantonio]

@aarppe: update, I've come up with a TSV format that might work for us:

https://docs.google.com/spreadsheets/d/1opkulWHTWOzQRRBpkVVc24nY7v508VCcIZgN-z06ryQ/edit?usp=sharing

This is what it looks like as a text file:

	* Something is happening now
_ Actor	_ ni-/ki- word
> I → you (one)	. Ind+Prs+1Sg+2SgO
> I → him/her	. Ind+Prs+1Sg+3SgO
	
	
# Explanation	
# Each cell starts with a character and a space	
# Each character defines what kind of cell it is	
# Cell types:	
# * is a title cell: this is a big title that labels the entire next paragraph	
# _ is a column heading: this gives a label to the rest of the column	
# > is a row label: this labels the data to the right of it in the row	
# # is a comment. Comments are ignored until the end of the line	

# Empty lines denote a separation between panes
# multiple empty lines are treated as one empty line

[eddieantonio]

Bumping. @aarppe, please have a look at my proposal. I'd like to hear your opinion on this. El vie., 13 de dic. de 2019 02:41, aarppe <notifications@github.com> escribió:

…

Following up on the implementation of the new mobile basic layouts in #191 <#191>, for the sake of clarity, both column headings for the four types of verbs should be formatted similarly (bold-faced, etc.), not just *'ni-/ki- word'* and *'ê-/kâ- word'* as in below ... [image: image] <https://user-images.githubusercontent.com/15003407/70790208-47ce6100-1d9d-11ea-8c5a-7e756ed89dfa.png> [image: image] <https://user-images.githubusercontent.com/15003407/70789974-bc54d000-1d9c-11ea-8376-7d3a0b67022b.png> ... but also *'Actor'* and *'Actor -> Goal'* This applies only to the mobile basic layouts for the four verb types, not the nouns. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#193>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARQE7PFN772PGSGMM6UNPDQYNKD5ANCNFSM4J2KNC2A> .

[aarppe]

Yes, looks good, and I think this achieves what we need for the current layouts, as well as has the information that would be needed for the more complex, multipane ones.

A few observations/questions/comments, which need not necessarily hold back development right now:

0. This is micromanagement and/or perfectionism, but I suppose the column labels could be identified by a carot ^, nicely complementing the row-label marker > (doesn't really matter).

1. If there is no cell/label type marker, then that is considered a refer to an inflected form (instead of that being identified based on the lack of quotes)? Not having quotes (to identify the entire label) around labels is probably good, as they can become a source of consternation.

2. It is implicit now, but to be explicit, the multiple words to the right of the type-marker are together considered all part of a label?

3. Could one still specify label justification, if needed, as in the old layouts (e.g. with colons)?

4. I imagine this could be used to create multiple column layouts, by simply specifying more than one column labels (and corresponding cells with references to word forms feature tag combinations)? But ...

5. ... Is the idea that multiple column layouts could be done by dynamically combining panes based on that they share the title and either the set of row or column labels? In the case of multiple columns, one need not then present the row labels again for the 2nd (and 3rd) columns? (One could think that the label could consist of hierarchical levels, e.g. Something is happening now > ni-/ki- word, etc., even though that could also be seen as a combination of the title and column labels.)

6. Where would the translations be defined/incorporated? That is,Something is happening now <-> Present tense <-> ê-ispayik anohc/mâna/mêkwac? I suppose this could be incorporated in the layout files as now, but these could be defined and managed centrally in that spreadsheet we drafted earlier in the fall?

[eddieantonio]

0. This is micromanagement and/or perfectionism, but I suppose the column labels could be identified by a carot ^, nicely complementing the row-label marker > (doesn't really matter).

I like this suggestion! Let's incorporate it!

	* Something is happening now
^ Actor	^ ni-/ki- word
> I → you (one)	. Ind+Prs+1Sg+2SgO
> I → him/her	. Ind+Prs+1Sg+3SgO

2. If there is no cell/label type marker, then that is considered a refer to an inflected form (instead of that being identified based on the lack of quotes)? Not having quotes (to identify the entire label) around labels is probably good, as they can become a source of consternation.

No. Every cell must have a marker as its first character. This is mostly to make my life as a programmer easier, and to make EVERYTHING explicit.

3. It is implicit now, but to be explicit, the multiple words to the right of the type-marker are together considered all part of a label?

Everything up to the tab character is part of the label. The intention is to edit it in a spreadsheet program, so naturally, everything in the cell in the spreadsheet will be part of the cell! No need to quote or anything!

4. Could one still specify label justification, if needed, as in the old layouts (e.g. with colons)?

I haven't decided on how to implement that. I also think it's not a good idea, as "justification" is a presentational concern, whereas I want to keep the layout format "semantic"; The label's role in the layout (e.g., whether it is a column label, row label, or panel heading) should determine its presentation, in my opinion.

5. I imagine this could be used to create multiple column layouts, by simply specifying more than one column labels (and corresponding cells with references to word forms feature tag combinations)? But ...
6. ... Is the idea that multiple column layouts could be done by dynamically combining panes based on that they share the title and either the set of row or column labels? In the case of multiple columns, one need not then present the row labels again for the 2nd (and 3rd) columns? (One could think that the label could consist of hierarchical levels, e.g. Something is happening now > ni-/ki- word, etc., even though that could also be seen as a combination of the title and column labels.)

We could implement this... but again, I prefer things being explicit. Let's cross the pane bridge later :)

7. Where would the translations be defined/incorporated? That is,Something is happening now <-> Present tense <-> ê-ispayik anohc/mâna/mêkwac? I suppose this could be incorporated in the layout files as now, but these could be defined and managed centrally in that spreadsheet we drafted earlier in the fall?

The latter! I'd prefer those translations be defined and managed elsewhere. That way, we can share translations.

See how the TSV file is rendered here: https://gist.github.com/eddieantonio/9eeba1af89ab683406c38b3945adfe89

[aarppe]

No other comments (i.e. I am in agreement), other than the following clarifications:

Re: 2 - so is the period . then a marker of a definition of feature-tags for which a matching form should be generated?

Re: 5-6 - but, how the layouts would now be defined seems to me very much amenable to how I've thought the panes would work. That is, your proposed specification would work to my mind not just for defining the static layouts, but could just as well be interpreted as consisting of a set of pane-wise definitions, in particular if the layout consists of single column panes sharing the same title label (perhaps with some further detail in the title label to make some things explicit), that the software layout logic could then organize as best fits the screen (in terms of one or more columns).

Re: 7 - yes, I do not want to enumerate all the translations over and over again, so one central specification file (or perhaps per P-O-S to avoid ambiguity) is most desirable.

[eddieantonio]

No other comments (i.e. I am in agreement), other than the following clarifications:

Re: 2 - so is the period . then a marker of a definition of feature-tags for which a matching form should be generated?

Yep! I just forgot to mark it as such in the documentation; I shall amend it.

Re: 5-6 - but, how the layouts would now be defined seems to me very much amenable to how I've thought the panes would work. That is, your proposed specification would work to my mind not just for defining the static layouts, but could just as well be interpreted as consisting of a set of pane-wise definitions, in particular if the layout consists of single column panes sharing the same title label (perhaps with some further detail in the title label to make some things explicit), that the software layout logic could then organize as best fits the screen (in terms of one or more columns).

I agree! I just want to implement one small thing (explicit layouts) first before jumping to the bigger thing (explicit layouts with panes).

Re: 7 - yes, I do not want to enumerate all the translations over and over again, so one central specification file (or perhaps per P-O-S to avoid ambiguity) is most desirable.

👍

[aarppe]

The comments here go beyond the original issue. We need a new issue to define and implement the layout format following the sketch above. This is done in #167.

[aarppe]

I think this issue has been superseded substantially by #581 and #582, even though there is much pertinent discussion here. Nevertheless, I'll closed it to remove issue clutter.