Toggle caps

[davidjamesbeck]

The demo works great. Tweak #1 we need now is to be able to fix the capitalization of abbreviations so that they are consistently small caps as opposed to all caps. Some authors use one, some use the other. I wrote some code for this in formatting.py which can be called while assembling the tags in ijalLine.py. The method is called def correctCapitalization() and essentially checks to see if the abbreviations are given in all caps and, if so, converts them to lowercase (with some exceptions for 4 abbreviations that have to be in caps). The style for in the ijal.css I have (not sure if I pushed it to GitHub or not) specifies font-variant: small-caps; .

[paul-shannon]

I may not yet grasp your approach to correcting grammaticalTerms. So may I ask a few leading questions?

1) are grammaticalTerms (gT hereafter, for brevity) an aspect only of MorphemeGloss objects?

2) why not create a new class, GrammaticalTerms, in grammaticalTerms.py, with accompanying test_GrammaticalTerms.py, which collects together and packages up

• reading them from the user-supplied file, or a list
• applies all known cleanup actions
• formats them appropriately when called upon to do so

3) then MorphemeGloss could be constructed with a gT object, just as it now is created with an optional grammaticalTerms array

4) when I encounter formatting.py in the repo, I don’t know what gets formatted, now why. Can you take the operations you provide there, as well as your “person” operations in ijalLine.py, and make them all part of a ontologically sound & unified GrammaticalTerms class? With tests? This approach isolates a new entity, defines its attributes, the operations it supports, and how it must behave - solving all of those problems in isolation, the plugging the result into the other objects in our system.

Does this appeal to you?

Hoping so,

• Paul

On Mar 11, 2019, at 11:40 AM, David Beck notifications@github.com wrote:

The demo works great. Tweak #1 we need now is to be able to fix the capitalization of abbreviations so that they are consistently small caps as opposed to all caps. Some authors use one, some use the other. I wrote some code for this in formatting.py which can be called while assembling the tags in ijalLine.py. The method is called def correctCapitalization() and essentially checks to see if the abbreviations are given in all caps and, if so, converts them to lowercase (with some exceptions for 4 abbreviations that have to be in caps). The style for in the ijal.css I have (not sure if I pushed it to GitHub or not) specifies font-variant: small-caps; .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[paul-shannon]

I can provide a skeleton GrammaticalTerms class definition, in a new grammaticalTerms.py, if that would be useful. With a minimal test_GrammaticalTerms.py accompanying.

• Paul

On Mar 11, 2019, at 1:25 PM, Paul Shannon notifications@github.com wrote:

I may not yet grasp your approach to correcting grammaticalTerms. So may I ask a few leading questions?

1) are grammaticalTerms (gT hereafter, for brevity) an aspect only of MorphemeGloss objects?

2) why not create a new class, GrammaticalTerms, in grammaticalTerms.py, with accompanying test_GrammaticalTerms.py, which collects together and packages up

• reading them from the user-supplied file, or a list
• applies all known cleanup actions
• formats them appropriately when called upon to do so

3) then MorphemeGloss could be constructed with a gT object, just as it now is created with an optional grammaticalTerms array

4) when I encounter formatting.py in the repo, I don’t know what gets formatted, now why. Can you take the operations you provide there, as well as your “person” operations in ijalLine.py, and make them all part of a ontologically sound & unified GrammaticalTerms class? With tests? This approach isolates a new entity, defines its attributes, the operations it supports, and how it must behave - solving all of those problems in isolation, the plugging the result into the other objects in our system.

Does this appeal to you?

Hoping so,

• Paul

On Mar 11, 2019, at 11:40 AM, David Beck notifications@github.com wrote:

The demo works great. Tweak #1 we need now is to be able to fix the capitalization of abbreviations so that they are consistently small caps as opposed to all caps. Some authors use one, some use the other. I wrote some code for this in formatting.py which can be called while assembling the tags in ijalLine.py. The method is called def correctCapitalization() and essentially checks to see if the abbreviations are given in all caps and, if so, converts them to lowercase (with some exceptions for 4 abbreviations that have to be in caps). The style for in the ijal.css I have (not sure if I pushed it to GitHub or not) specifies font-variant: small-caps; .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Hi, Paul

On Mar 11, 2019, at 2:25 PM, Paul Shannon notifications@github.com wrote:

I may not yet grasp your approach to correcting grammaticalTerms. So may I ask a few leading questions?

1) are grammaticalTerms (gT hereafter, for brevity) an aspect only of MorphemeGloss objects?

Yes, they should only appear there.

2) why not create a new class, GrammaticalTerms, in grammaticalTerms.py, with accompanying test_GrammaticalTerms.py, which collects together and packages up

• reading them from the user-supplied file, or a list
• applies all known cleanup actions
• formats them appropriately when called upon to do so

That is probably a good idea. I have another “issue” that needs to be dealt with in terms of gTs that might be handled this way as well (we need to find a way to deal with things like “1sg”, “2sg”, etc., since authors usually just put “sg” in the abbreviations files but the number is part of the abbreviation).

3) then MorphemeGloss could be constructed with a gT object, just as it now is created with an optional grammaticalTerms array

4) when I encounter formatting.py in the repo, I don’t know what gets formatted, now why.

There are 4 methods in formmatting.py which I designed to be called in ijalLine.py. cleanUpInterlinear() is called in extractMorphemes() and extractMorphemeglosses() to swap out hyphens with n-dashes. I was finding some whitespace in one or two of the lines (not sure why since it looks to me that you had a routine to remove it already), so I added a removeWhiteSpace() method that is called by cleanUpInterlinear(). manageQuotes() is called during getTranslation() and makes sure that the translations have single quotes around them—I was going to add a couple of steps that make sure there is no extra whitespace on either end of the translation as well, but didn’t get around to that.

I’m not sure what the best way to package these sorts of things is, which is why I put the methods in their own .py file. I’ve also found that formatting linguistic data for humans to read often involves lots of little finicky things (like "exceptions = ["A","S","O","P”]" from the correctCapitalization() method), so for me having a place to go to find and adjust formatting has been handy in the past. But you probably know a better way to handle this kind of thing—maybe we need to define classes and subclasses of all line types. Say, have an Interlinear class that shares the formatting (cleanUpInterlinears) and other methods common to the morpheme and morphemeGlosses lines, and then subclassed for the 2 individual line types? And a Translation class that handles quotes, etc., subclassed for Primary and Secondary translations?

Can you take the operations you provide there, as well as your “person” operations in ijalLine.py, and make them all part of a ontologically sound & unified GrammaticalTerms class? With tests? This approach isolates a new entity, defines its attributes, the operations it supports, and how it must behave - solving all of those problems in isolation, the plugging the result into the other objects in our system.

I can try to do that, though it will be a while before I am likely to have a result. This week is turning into a bit of an administrative nightmare … . I might have time to open some more issues on GitHub in the cracks (when the endless meetings get too boring).

David

Does this appeal to you?

Hoping so,

• Paul

On Mar 11, 2019, at 11:40 AM, David Beck notifications@github.com wrote:

The demo works great. Tweak #1 we need now is to be able to fix the capitalization of abbreviations so that they are consistently small caps as opposed to all caps. Some authors use one, some use the other. I wrote some code for this in formatting.py which can be called while assembling the tags in ijalLine.py. The method is called def correctCapitalization() and essentially checks to see if the abbreviations are given in all caps and, if so, converts them to lowercase (with some exceptions for 4 abbreviations that have to be in caps). The style for in the ijal.css I have (not sure if I pushed it to GitHub or not) specifies font-variant: small-caps; .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-471715287, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhngXNDMs1LOaEYhkHCHH5739WbCxks5vVrutgaJpZM4bpTUg.

[paul-shannon]

I'll create a GrammaticalTerms class for you to consider. Good luck with the administrative tasks!

• Paul

On Mar 12, 2019, at 5:08 AM, David Beck notifications@github.com wrote:

Hi, Paul

On Mar 11, 2019, at 2:25 PM, Paul Shannon notifications@github.com wrote:

I may not yet grasp your approach to correcting grammaticalTerms. So may I ask a few leading questions?

1) are grammaticalTerms (gT hereafter, for brevity) an aspect only of MorphemeGloss objects?

Yes, they should only appear there.

2) why not create a new class, GrammaticalTerms, in grammaticalTerms.py, with accompanying test_GrammaticalTerms.py, which collects together and packages up

• reading them from the user-supplied file, or a list
• applies all known cleanup actions
• formats them appropriately when called upon to do so

That is probably a good idea. I have another “issue” that needs to be dealt with in terms of gTs that might be handled this way as well (we need to find a way to deal with things like “1sg”, “2sg”, etc., since authors usually just put “sg” in the abbreviations files but the number is part of the abbreviation).

3) then MorphemeGloss could be constructed with a gT object, just as it now is created with an optional grammaticalTerms array

4) when I encounter formatting.py in the repo, I don’t know what gets formatted, now why.

There are 4 methods in formmatting.py which I designed to be called in ijalLine.py. cleanUpInterlinear() is called in extractMorphemes() and extractMorphemeglosses() to swap out hyphens with n-dashes. I was finding some whitespace in one or two of the lines (not sure why since it looks to me that you had a routine to remove it already), so I added a removeWhiteSpace() method that is called by cleanUpInterlinear(). manageQuotes() is called during getTranslation() and makes sure that the translations have single quotes around them—I was going to add a couple of steps that make sure there is no extra whitespace on either end of the translation as well, but didn’t get around to that.

I’m not sure what the best way to package these sorts of things is, which is why I put the methods in their own .py file. I’ve also found that formatting linguistic data for humans to read often involves lots of little finicky things (like "exceptions = ["A","S","O","P”]" from the correctCapitalization() method), so for me having a place to go to find and adjust formatting has been handy in the past. But you probably know a better way to handle this kind of thing—maybe we need to define classes and subclasses of all line types. Say, have an Interlinear class that shares the formatting (cleanUpInterlinears) and other methods common to the morpheme and morphemeGlosses lines, and then subclassed for the 2 individual line types? And a Translation class that handles quotes, etc., subclassed for Primary and Secondary translations?

Can you take the operations you provide there, as well as your “person” operations in ijalLine.py, and make them all part of a ontologically sound & unified GrammaticalTerms class? With tests? This approach isolates a new entity, defines its attributes, the operations it supports, and how it must behave - solving all of those problems in isolation, the plugging the result into the other objects in our system.

I can try to do that, though it will be a while before I am likely to have a result. This week is turning into a bit of an administrative nightmare … . I might have time to open some more issues on GitHub in the cracks (when the endless meetings get too boring).

David

Does this appeal to you?

Hoping so,

• Paul

On Mar 11, 2019, at 11:40 AM, David Beck notifications@github.com wrote:

The demo works great. Tweak #1 we need now is to be able to fix the capitalization of abbreviations so that they are consistently small caps as opposed to all caps. Some authors use one, some use the other. I wrote some code for this in formatting.py which can be called while assembling the tags in ijalLine.py. The method is called def correctCapitalization() and essentially checks to see if the abbreviations are given in all caps and, if so, converts them to lowercase (with some exceptions for 4 abbreviations that have to be in caps). The style for in the ijal.css I have (not sure if I pushed it to GitHub or not) specifies font-variant: small-caps; .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-471715287, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhngXNDMs1LOaEYhkHCHH5739WbCxks5vVrutgaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

[paul-shannon]

Thanks, David! I’ll take a look this evening.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[paul-shannon]

Hi David,

I like the extra capabilities you have added to the GrammaticalTerms class.

The boundaries between programming abstractions - between classes - can get pretty murky. Maybe we can come up with a concise description of MorphemeGlosss and GrammaticalTerms, clarify that boundary? My naive sense is that they are different, and that we will have a cleaner project if we can arrive at those descriptions.

May I give it a try?

MorphemeGloss: a class to capture, and render into HTML, the morphemes of the spoken text, using standard grammatical terms, and single morpheme translations into the target language. A MorphemeGloss is an interlinear line, thus a collection of terms and translation words.

GrammaticalTerms: a controlled vocabulary - though with author discretion and idiosyncracies permitted- with standard delimiters and html display policies.

In this scheme, MorhphemeGloss has - contains - objects of the GrammaticalTerms class. Along with what I fumblingly call “single morpheme translations”. We probably don’t need, or don’t yet need, a class to represent those single morpheme translation words.

Then we ask: "hat services should the GrammaticalTerms class provide to MorphemeGloss?" I am a bit uncertain here. But maybe it is as simple as:

1) given a raw morpheme gloss line of text, Grammatical Terms can identify GrammaticalTerms, distinguish them from simple words, and return a list of those GrammaticalTerms found in the text passed to it by a MorphemeGloss instance.

2) provides a toHTML method .

If GrammaticalTerms provided these services, then all of our knowledge about, and operations upon them, would be contained in this one class. And testing could be all localized also.

If we did this, then the MorphemeGloss class, already pretty simple, would get simpler still. We could modestly refactor MorpehmeGloss.toHTML to delegate the toHTML operation to GrammaticalTerm.toHTML:

— currently:

67 if(self.grammaticalTerms) and (part in self.grammaticalTerms): 68 with htmlDoc.tag("span", klass="grammatical-term"): 69 htmlDoc.asis(part) 70 else: 71 htmlDoc.text(part)

to something like this (using some pseudocode: “is” is from R; I cannot recall the python equivalent), and assuming we make each “part” item either plain text or a GrammaticalTerm object

          if(is(“GrammaticalTerm”, part)):
             part.toHTML(htmlDoc)
          else:
             htmlDoc.text(part)

What do you think?

• Paul

P.S. You -might- be interested in this story https://www.seattletimes.com/pacific-nw-magazine/ from last Sunday’s Seattle Times Pacific NW magazine. It’s about a project I have been working on for a few years. The connection to Lushootseed may seem tenuous, or even far-fetched, but to me they are linked. Both endeavors get me involved in, teach me about, and perhaps allow me to make a tiny contribution to the survival of structures both old and intricate.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[paul-shannon]

A more durable link to the sword fern story:

https://www.seattletimes.com/pacific-nw-magazine/whats-killing-our-sword-ferns/

On Apr 3, 2019, at 7:26 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I like the extra capabilities you have added to the GrammaticalTerms class.

The boundaries between programming abstractions - between classes - can get pretty murky. Maybe we can come up with a concise description of MorphemeGlosss and GrammaticalTerms, clarify that boundary? My naive sense is that they are different, and that we will have a cleaner project if we can arrive at those descriptions.

May I give it a try?

MorphemeGloss: a class to capture, and render into HTML, the morphemes of the spoken text, using standard grammatical terms, and single morpheme translations into the target language. A MorphemeGloss is an interlinear line, thus a collection of terms and translation words.

GrammaticalTerms: a controlled vocabulary - though with author discretion and idiosyncracies permitted- with standard delimiters and html display policies.

In this scheme, MorhphemeGloss has - contains - objects of the GrammaticalTerms class. Along with what I fumblingly call “single morpheme translations”. We probably don’t need, or don’t yet need, a class to represent those single morpheme translation words.

Then we ask: "hat services should the GrammaticalTerms class provide to MorphemeGloss?" I am a bit uncertain here. But maybe it is as simple as:

1) given a raw morpheme gloss line of text, Grammatical Terms can identify GrammaticalTerms, distinguish them from simple words, and return a list of those GrammaticalTerms found in the text passed to it by a MorphemeGloss instance.

2) provides a toHTML method .

If GrammaticalTerms provided these services, then all of our knowledge about, and operations upon them, would be contained in this one class. And testing could be all localized also.

If we did this, then the MorphemeGloss class, already pretty simple, would get simpler still. We could modestly refactor MorpehmeGloss.toHTML to delegate the toHTML operation to GrammaticalTerm.toHTML:

— currently:

67 if(self.grammaticalTerms) and (part in self.grammaticalTerms): 68 with htmlDoc.tag("span", klass="grammatical-term"): 69 htmlDoc.asis(part) 70 else: 71 htmlDoc.text(part)

to something like this (using some pseudocode: “is” is from R; I cannot recall the python equivalent), and assuming we make each “part” item either plain text or a GrammaticalTerm object

if(is(“GrammaticalTerm”, part)): part.toHTML(htmlDoc) else: htmlDoc.text(part)

What do you think?

• Paul

P.S. You -might- be interested in this story https://www.seattletimes.com/pacific-nw-magazine/ from last Sunday’s Seattle Times Pacific NW magazine. It’s about a project I have been working on for a few years. The connection to Lushootseed may seem tenuous, or even far-fetched, but to me they are linked. Both endeavors get me involved in, teach me about, and perhaps allow me to make a tiny contribution to the survival of structures both old and intricate.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Hi, Paul

That business with the ferns is bizarre and scary. The PNW rainforest has always been my favourite ecosystem, it’s sad to think about it being on verge of collapse.

What you describe below is roughly what I had in mind when I started, but a few things happened in the process. The first thing was that it became clear right away that whatever happened, majorish modifications had to be made to the MorphemeGloss class and I was worried about messing around with it because of the problems with versions and git that I had before. So I cloned it as GrammaticalTerms. Then as I started working on it, I realized that the simplest way to handle the capitalization problem and the number-abbreviation combinations was to modify the list of grammatical terms. That also seemed to need to be in MorphemeGloss at the time. Also, the way some of these formatting processes interlocked made it hard to figure out what needed to be done to the line as a whole, what could be done as part of a GrammaticalTerm class, and what order things had to happen. However, what you say below clarified a couple of doubts I had—and, of course, now that I’ve worked things through the whole business is clearer in my mind.

So, it seems to me that we might be able to proceed like this (I hope this is comprehensible—as you know I’m not very fluent in code-talk)

1) MorphemeGloss is initialized and applies the class methods self.replaceHyphensWithNDashes(), and self.makeAbbreviationsLowerCase() so that we have a line with no hyphens and all the grammatical terms supplied by the author are in lower case (so they render properly as small caps in the HTML);

2) the parse() method extracts parts and then calls the GrammaticalTerms constructor for each part in the parts list, passing the part and self.grammaticalTerms. The "for part in parts" loop also calls get_GrammaticalTerms() from the GrammaticalTerms object to get an updated version of self.grammaticalTerms;

3) the GrammaticalTerms class contains the methods addNumberedAbbreviations() and makePartsLowerCase(), called in that order in the init method of the class;

4) GrammaticalTerms has a toHTML method that wraps the term in a tag and MorphemeGloss calls that method as needed in its own toHTML method

There is one operation that MorphemeGloss performs that needs to apply to the parsing line (the line above the line with all the abbreviations), replaceHyphensWithNDashes(). I’m not sure where that would be done. It could just be added to IjalLine, or we could find a way to use MorphemeGloss without the parse() method. However, there is also a type of validation that might be worth performing: it is essential that there be the same number of parts on the two glossing lines (that is, every parsed morpheme should correspond to a GrammaticalTerm and every GrammaticalTerm should correspond to a parsed morpheme, and the delimiters should match on the two lines as well). I have been wondering if that calls for a GlossingLines class that compiles the two lines and compares them?

Anyway, if you think step 1–4 are on the right track, I can try them out. That would mean moving the tests in text_grammaticalTerms.py into test_MorphemeGloss.py, no?

Cheers,

David

On Apr 3, 2019, at 8:33 AM, Paul Shannon notifications@github.com wrote:

A more durable link to the sword fern story:

https://www.seattletimes.com/pacific-nw-magazine/whats-killing-our-sword-ferns/

On Apr 3, 2019, at 7:26 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I like the extra capabilities you have added to the GrammaticalTerms class.

The boundaries between programming abstractions - between classes - can get pretty murky. Maybe we can come up with a concise description of MorphemeGlosss and GrammaticalTerms, clarify that boundary? My naive sense is that they are different, and that we will have a cleaner project if we can arrive at those descriptions.

May I give it a try?

MorphemeGloss: a class to capture, and render into HTML, the morphemes of the spoken text, using standard grammatical terms, and single morpheme translations into the target language. A MorphemeGloss is an interlinear line, thus a collection of terms and translation words.

GrammaticalTerms: a controlled vocabulary - though with author discretion and idiosyncracies permitted- with standard delimiters and html display policies.

In this scheme, MorhphemeGloss has - contains - objects of the GrammaticalTerms class. Along with what I fumblingly call “single morpheme translations”. We probably don’t need, or don’t yet need, a class to represent those single morpheme translation words.

Then we ask: "hat services should the GrammaticalTerms class provide to MorphemeGloss?" I am a bit uncertain here. But maybe it is as simple as:

1) given a raw morpheme gloss line of text, Grammatical Terms can identify GrammaticalTerms, distinguish them from simple words, and return a list of those GrammaticalTerms found in the text passed to it by a MorphemeGloss instance.

2) provides a toHTML method .

If GrammaticalTerms provided these services, then all of our knowledge about, and operations upon them, would be contained in this one class. And testing could be all localized also.

If we did this, then the MorphemeGloss class, already pretty simple, would get simpler still. We could modestly refactor MorpehmeGloss.toHTML to delegate the toHTML operation to GrammaticalTerm.toHTML:

— currently:

67 if(self.grammaticalTerms) and (part in self.grammaticalTerms): 68 with htmlDoc.tag("span", klass="grammatical-term"): 69 htmlDoc.asis(part) 70 else: 71 htmlDoc.text(part)

to something like this (using some pseudocode: “is” is from R; I cannot recall the python equivalent), and assuming we make each “part” item either plain text or a GrammaticalTerm object

if(is(“GrammaticalTerm”, part)): part.toHTML(htmlDoc) else: htmlDoc.text(part)

What do you think?

• Paul

P.S. You -might- be interested in this story https://www.seattletimes.com/pacific-nw-magazine/ from last Sunday’s Seattle Times Pacific NW magazine. It’s about a project I have been working on for a few years. The connection to Lushootseed may seem tenuous, or even far-fetched, but to me they are linked. Both endeavors get me involved in, teach me about, and perhaps allow me to make a tiny contribution to the survival of structures both old and intricate.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-479515809, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhrTnOqeZbXEgh4-SqpS3qDMRKMIOks5vdLukgaJpZM4bpTUg.

[paul-shannon]

Hi David,

I try to address your questions inline below. With one introductory remark, about “divide and conquer” and “maximum ignorance”. Which may be preaching to the choir!

Software design can easily get really complex and messy. So we try to try to identify the separable parts, solve each in isolation, keeping each solution ignorant of all the other parts, the problems they pose, and the solutions we adopt. Each solution is an independent class.

Can we do this with the morphemes, and their glosses? I think so, despite the correspondences they must have: equal count, each gloss corresponds to one morpheme, they have the same spacing (and thus alignment) when displayed.

Some common operations will be identified as we solve each of these problems. replaceHyphensWithNDashes might be one. So they become utility functions (not methods - see below) available to both (and to other) classes.

The connections between related classes - for instance, of our representations of morphemes and morpheme glosses - are enforced at a higher level, so that morphemes and their glosses don’t know about each other. It is the IjalLine which knows about, and enforces, the relation between morphemes and their glosses.

I am cursed with a small working memory. Or maybe blessed. In terms of the magic number 7 (+/- 2) scheme https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two my variable seems to be a minus 3. Not being able to keep many things in my head at the same time, I look for the atomic parts of a problem, carve up the problem space at the joints between them, try to solve the atomic problem in isolation, test it, then forget it about it, except to use it later to compose a higher level object - which knows nothing about the innards of the previously defined atoms it uses - except the high level operations they provide. Divide, conquer, assemble.

So perhaps the MorphemeGloss class should be our only concern until we have that problem licked?

• Paul

1) MorphemeGloss is initialized and applies the class methods self.replaceHyphensWithNDashes(), and self.makeAbbreviationsLowerCase() so that we have a line with no hyphens and all the grammatical terms supplied by the author are in lower case (so they render properly as small caps in the HTML);

replaceHyphensWithNDashes: this is an operation applied to all tiers, right? So it should not be a member function (a “method”) of any particular class, but instead a utility function called by anyone who needs it.

A nice distinction can be made between methods and functions. Methods are defined with their class. So they typically get the data they operate on from the class object. But functions are less entangled than that. Mathematical functions are good examples: sin, sqrt, log. You call them with an argument, you get the answer. There is no state involved, no object, no class. Everything is transient.

So I propose that replaceHyphensWithNDashes is a function, not a class method. It could live (as a function, not a method) in the IjalLine class. Or in a IjalUtilities.py file which contains no classes, just utility functions.

I am confused about lower case grammatical terms rendering as small caps in HTML. I thought that grammatical terms were always upper case AND rendered in a smaller font into HTML. The examples we have seem to follow this rule. My version of GrammaticalTerms accomplishes this, or so I thought. In GrammaticalTerms.toHTML() every recognized term is wrapped in a span, with a grammatical-term class, and the css later renders them in a smaller font. No case changing.

2) the parse() method extracts parts and then calls the GrammaticalTerms constructor for each part in the parts list, passing the part and self.grammaticalTerms. The "for part in parts" loop also calls get_GrammaticalTerms() from the GrammaticalTerms object to get an updated version of self.grammaticalTerms;

3) the GrammaticalTerms class contains the methods addNumberedAbbreviations() and makePartsLowerCase(), called in that order in the init method of the class;

I’m confused, as I explain above, about the down-casing of the terms.

4) GrammaticalTerms has a toHTML method that wraps the term in a tag and MorphemeGloss calls that method as needed in its own toHTML method

I -think- this already exists in code I wrote. Which may be your point - it is a necessary step, and you are enumerating the steps here.

There is one operation that MorphemeGloss performs that needs to apply to the parsing line (the line above the line with all the abbreviations), replaceHyphensWithNDashes(). I’m not sure where that would be done. It could just be added to IjalLine, or we could find a way to use MorphemeGloss without the parse() method. However, there is also a type of validation that might be worth performing: it is essential that there be the same number of parts on the two glossing lines (that is, every parsed morpheme should correspond to a GrammaticalTerm and every GrammaticalTerm should correspond to a parsed morpheme, and the delimiters should match on the two lines as well). I have been wondering if that calls for a GlossingLines class that compiles the two lines and compares them?

I thought I have already solved this problem. Perhaps? See ijalLine.calculateMorphemeSpacing:

  """
   the spacing is used to create a styleString, specifying grid cell widths which
   accomodate the widest of each morpheme/gloss pair, so that they each member of
   each pair is vertically aligned:
      m1      m2      ----m3-----
      g1   ---g2---       g3
  """
  morphemes = self.getMorphemes()
  glosses = self.getMorphemeGlosses()
  assert(len(morphemes) == len(glosses))

Anyway, if you think step 1–4 are on the right track, I can try them out. That would mean moving the tests in text_grammaticalTerms.py into test_MorphemeGloss.py, no?

Yes!

Cheers,

David

On Apr 3, 2019, at 8:33 AM, Paul Shannon notifications@github.com wrote:

A more durable link to the sword fern story:

https://www.seattletimes.com/pacific-nw-magazine/whats-killing-our-sword-ferns/

On Apr 3, 2019, at 7:26 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I like the extra capabilities you have added to the GrammaticalTerms class.

The boundaries between programming abstractions - between classes - can get pretty murky. Maybe we can come up with a concise description of MorphemeGlosss and GrammaticalTerms, clarify that boundary? My naive sense is that they are different, and that we will have a cleaner project if we can arrive at those descriptions.

May I give it a try?

MorphemeGloss: a class to capture, and render into HTML, the morphemes of the spoken text, using standard grammatical terms, and single morpheme translations into the target language. A MorphemeGloss is an interlinear line, thus a collection of terms and translation words.

GrammaticalTerms: a controlled vocabulary - though with author discretion and idiosyncracies permitted- with standard delimiters and html display policies.

In this scheme, MorhphemeGloss has - contains - objects of the GrammaticalTerms class. Along with what I fumblingly call “single morpheme translations”. We probably don’t need, or don’t yet need, a class to represent those single morpheme translation words.

Then we ask: "hat services should the GrammaticalTerms class provide to MorphemeGloss?" I am a bit uncertain here. But maybe it is as simple as:

1) given a raw morpheme gloss line of text, Grammatical Terms can identify GrammaticalTerms, distinguish them from simple words, and return a list of those GrammaticalTerms found in the text passed to it by a MorphemeGloss instance.

2) provides a toHTML method .

If GrammaticalTerms provided these services, then all of our knowledge about, and operations upon them, would be contained in this one class. And testing could be all localized also.

If we did this, then the MorphemeGloss class, already pretty simple, would get simpler still. We could modestly refactor MorpehmeGloss.toHTML to delegate the toHTML operation to GrammaticalTerm.toHTML:

— currently:

67 if(self.grammaticalTerms) and (part in self.grammaticalTerms): 68 with htmlDoc.tag("span", klass="grammatical-term"): 69 htmlDoc.asis(part) 70 else: 71 htmlDoc.text(part)

to something like this (using some pseudocode: “is” is from R; I cannot recall the python equivalent), and assuming we make each “part” item either plain text or a GrammaticalTerm object

if(is(“GrammaticalTerm”, part)): part.toHTML(htmlDoc) else: htmlDoc.text(part)

What do you think?

• Paul

P.S. You -might- be interested in this story https://www.seattletimes.com/pacific-nw-magazine/ from last Sunday’s Seattle Times Pacific NW magazine. It’s about a project I have been working on for a few years. The connection to Lushootseed may seem tenuous, or even far-fetched, but to me they are linked. Both endeavors get me involved in, teach me about, and perhaps allow me to make a tiny contribution to the survival of structures both old and intricate.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-479515809, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhrTnOqeZbXEgh4-SqpS3qDMRKMIOks5vdLukgaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Hi, Paul

Yes, that all sounds good to me—ijalLine.py can (and may already) enforce one-to-one correspondences between parse and gloss. So we can leave that for later if anything needs to be done,

replaceHyphensWithNDashes can certainly be instantiated somewhere outside the MorphemeGloss class but is has to be called from somewhere when the class first loads the glosses because authors are sloppy about this. Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located. Then we can move it and have the MorphemeGloss class import and call it, or have it applied to the rawText string fed to the constructor (probably better, right?).

The business with upper/lower case and abbreviations is needed for two reasons. One is that some authors submit their abbreviations in all caps and some in lower case, some submit their lists in one and the interlinearizations in another. So enforcing consistency is needed. An additional wrinkle is that there are 4 exceptional abbreviations (A,S,O,P) which should be in caps, not small caps, and these need to be handled properly as well. It also means that just using caps and reducing the font size will erase the distinction, which is why I switched to using CSS small-caps in the stylesheet.

So really most of the innovations in your code are not due to insufficiencies in the code, but my predictions about insufficiencies in the authors.

I will take a stab at separating MorphemeGloss and GrammaticalTerms as soon as I can. We’re having a Ling department 50th anniversary do next weekend, so there’s stuff needs doing and I may be slow at this, but it doesn’t look that tricky at this point, I think we have a plan.

7 - 3? Those were the days ...

David

On Apr 7, 2019, at 8:30 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I try to address your questions inline below. With one introductory remark, about “divide and conquer” and “maximum ignorance”. Which may be preaching to the choir!

Software design can easily get really complex and messy. So we try to try to identify the separable parts, solve each in isolation, keeping each solution ignorant of all the other parts, the problems they pose, and the solutions we adopt. Each solution is an independent class.

Can we do this with the morphemes, and their glosses? I think so, despite the correspondences they must have: equal count, each gloss corresponds to one morpheme, they have the same spacing (and thus alignment) when displayed.

Some common operations will be identified as we solve each of these problems. replaceHyphensWithNDashes might be one. So they become utility functions (not methods - see below) available to both (and to other) classes.

The connections between related classes - for instance, of our representations of morphemes and morpheme glosses - are enforced at a higher level, so that morphemes and their glosses don’t know about each other. It is the IjalLine which knows about, and enforces, the relation between morphemes and their glosses.

I am cursed with a small working memory. Or maybe blessed. In terms of the magic number 7 (+/- 2) scheme https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two my variable seems to be a minus 3. Not being able to keep many things in my head at the same time, I look for the atomic parts of a problem, carve up the problem space at the joints between them, try to solve the atomic problem in isolation, test it, then forget it about it, except to use it later to compose a higher level object - which knows nothing about the innards of the previously defined atoms it uses - except the high level operations they provide. Divide, conquer, assemble.

So perhaps the MorphemeGloss class should be our only concern until we have that problem licked?

• Paul

1) MorphemeGloss is initialized and applies the class methods self.replaceHyphensWithNDashes(), and self.makeAbbreviationsLowerCase() so that we have a line with no hyphens and all the grammatical terms supplied by the author are in lower case (so they render properly as small caps in the HTML);

replaceHyphensWithNDashes: this is an operation applied to all tiers, right? So it should not be a member function (a “method”) of any particular class, but instead a utility function called by anyone who needs it.

A nice distinction can be made between methods and functions. Methods are defined with their class. So they typically get the data they operate on from the class object. But functions are less entangled than that. Mathematical functions are good examples: sin, sqrt, log. You call them with an argument, you get the answer. There is no state involved, no object, no class. Everything is transient.

So I propose that replaceHyphensWithNDashes is a function, not a class method. It could live (as a function, not a method) in the IjalLine class. Or in a IjalUtilities.py file which contains no classes, just utility functions.

I am confused about lower case grammatical terms rendering as small caps in HTML. I thought that grammatical terms were always upper case AND rendered in a smaller font into HTML. The examples we have seem to follow this rule. My version of GrammaticalTerms accomplishes this, or so I thought. In GrammaticalTerms.toHTML() every recognized term is wrapped in a span, with a grammatical-term class, and the css later renders them in a smaller font. No case changing.

2) the parse() method extracts parts and then calls the GrammaticalTerms constructor for each part in the parts list, passing the part and self.grammaticalTerms. The "for part in parts" loop also calls get_GrammaticalTerms() from the GrammaticalTerms object to get an updated version of self.grammaticalTerms;

3) the GrammaticalTerms class contains the methods addNumberedAbbreviations() and makePartsLowerCase(), called in that order in the init method of the class;

I’m confused, as I explain above, about the down-casing of the terms.

4) GrammaticalTerms has a toHTML method that wraps the term in a tag and MorphemeGloss calls that method as needed in its own toHTML method

I -think- this already exists in code I wrote. Which may be your point - it is a necessary step, and you are enumerating the steps here.

There is one operation that MorphemeGloss performs that needs to apply to the parsing line (the line above the line with all the abbreviations), replaceHyphensWithNDashes(). I’m not sure where that would be done. It could just be added to IjalLine, or we could find a way to use MorphemeGloss without the parse() method. However, there is also a type of validation that might be worth performing: it is essential that there be the same number of parts on the two glossing lines (that is, every parsed morpheme should correspond to a GrammaticalTerm and every GrammaticalTerm should correspond to a parsed morpheme, and the delimiters should match on the two lines as well). I have been wondering if that calls for a GlossingLines class that compiles the two lines and compares them?

I thought I have already solved this problem. Perhaps? See ijalLine.calculateMorphemeSpacing:

""" the spacing is used to create a styleString, specifying grid cell widths which accomodate the widest of each morpheme/gloss pair, so that they each member of each pair is vertically aligned: m1 m2 ----m3----- g1 ---g2--- g3 """ morphemes = self.getMorphemes() glosses = self.getMorphemeGlosses() assert(len(morphemes) == len(glosses))

Anyway, if you think step 1–4 are on the right track, I can try them out. That would mean moving the tests in text_grammaticalTerms.py into test_MorphemeGloss.py, no?

Yes!

Cheers,

David

On Apr 3, 2019, at 8:33 AM, Paul Shannon notifications@github.com wrote:

A more durable link to the sword fern story:

https://www.seattletimes.com/pacific-nw-magazine/whats-killing-our-sword-ferns/

On Apr 3, 2019, at 7:26 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I like the extra capabilities you have added to the GrammaticalTerms class.

The boundaries between programming abstractions - between classes - can get pretty murky. Maybe we can come up with a concise description of MorphemeGlosss and GrammaticalTerms, clarify that boundary? My naive sense is that they are different, and that we will have a cleaner project if we can arrive at those descriptions.

May I give it a try?

MorphemeGloss: a class to capture, and render into HTML, the morphemes of the spoken text, using standard grammatical terms, and single morpheme translations into the target language. A MorphemeGloss is an interlinear line, thus a collection of terms and translation words.

GrammaticalTerms: a controlled vocabulary - though with author discretion and idiosyncracies permitted- with standard delimiters and html display policies.

In this scheme, MorhphemeGloss has - contains - objects of the GrammaticalTerms class. Along with what I fumblingly call “single morpheme translations”. We probably don’t need, or don’t yet need, a class to represent those single morpheme translation words.

Then we ask: "hat services should the GrammaticalTerms class provide to MorphemeGloss?" I am a bit uncertain here. But maybe it is as simple as:

1) given a raw morpheme gloss line of text, Grammatical Terms can identify GrammaticalTerms, distinguish them from simple words, and return a list of those GrammaticalTerms found in the text passed to it by a MorphemeGloss instance.

2) provides a toHTML method .

If GrammaticalTerms provided these services, then all of our knowledge about, and operations upon them, would be contained in this one class. And testing could be all localized also.

If we did this, then the MorphemeGloss class, already pretty simple, would get simpler still. We could modestly refactor MorpehmeGloss.toHTML to delegate the toHTML operation to GrammaticalTerm.toHTML:

— currently:

67 if(self.grammaticalTerms) and (part in self.grammaticalTerms): 68 with htmlDoc.tag("span", klass="grammatical-term"): 69 htmlDoc.asis(part) 70 else: 71 htmlDoc.text(part)

to something like this (using some pseudocode: “is” is from R; I cannot recall the python equivalent), and assuming we make each “part” item either plain text or a GrammaticalTerm object

if(is(“GrammaticalTerm”, part)): part.toHTML(htmlDoc) else: htmlDoc.text(part)

What do you think?

• Paul

P.S. You -might- be interested in this story https://www.seattletimes.com/pacific-nw-magazine/ from last Sunday’s Seattle Times Pacific NW magazine. It’s about a project I have been working on for a few years. The connection to Lushootseed may seem tenuous, or even far-fetched, but to me they are linked. Both endeavors get me involved in, teach me about, and perhaps allow me to make a tiny contribution to the survival of structures both old and intricate.

On Apr 2, 2019, at 7:17 AM, David Beck notifications@github.com wrote:

You'll see that I've been tinkering with a GrammaticalTerms class (not because I have time, really, but because I have marking to do and this is procrastination). This class stands in for MorphemeGloss and handles several formatting issues, caps, and several new delimiters. It seems robust and passes all the tests, including a final test to make sure that the HTML output is correct. I know that we were thinking about GrammaticalTerms classes as something fed to MorphemeGloss, but I wasn't quite able to get my head around how to do that efficiently. Maybe you can and can use the methods I worte to create a class with a different structure, or you could simply clean up grammaticalTerms.py and replace the current morphemeGloss.py with it. Whatever seems like best programming practice to you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-479515809, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhrTnOqeZbXEgh4-SqpS3qDMRKMIOks5vdLukgaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480595438, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhrsvD-ZMmjTdzPOhzVYPYhjy4zJlks5vegEdgaJpZM4bpTUg.

[paul-shannon]

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

[davidjamesbeck]

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

[paul-shannon]

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Grr. Try now—I thought I’d pushed but maybe I pulled …

I would say that that next logical steps would be, after you check and clean up my tweaks, would be to resolve the issues on GitHub. Of these, I see

1) EAF file to test for quotes added (should be taken care of in last push) 2) test_lokono failure (ditto) 3) order of operations (outstanding) 4) Toggle caps (should be taken care of in last push) 5) demo8.py (seems to not to have anything unresolved in it, though it does contain a premature express of my having figured out git …) 6) how the tier guide works (seems resolved) 7) disparity between display web age and .html (the main issue is resolved by last push, but it raises a new outstanding task which I’ll open as a new issue, “reducing steps at last stage”) 8) introductory video (remains on to do list, but comes last) 9) eaf xml schema v3.0 (there is only a comment here—if I follow you, we’d not link to www.mpi to maintain an up-to-date schema for ELAN files. This should be okay, though future change to ELAN might mean manual maintenance of slexil down the road) 10) URL not found on server (seems not to have re-occurred, so I’d say it’s resolved) 11) webpage, once created, needs to be self-contained (this seems to be the case now with the possible exception of ijal.css and maybe the ESD referred to in issue #9) 12) rendering flaws and fixes (should be taken care of in last push)

So, it looks to me that 1, 2, 4, 5, 6, 7, 9, 10, and 12 are resolved and/or need no further attention. If you agree, we can close them or whatever you do on GitHub to move them off stage. Issue 11 may be done but if not is almost certainly a trivial fix.

Issues 3 and the new 13 seem like the next things to think about, and they both affect webapp.py. I don’t know if you want to start tinkering with that, or if you want to think about extending ijalLine to handle translation2 and transcription2 first. The latter seems pretty straightforward to me (translation2 is either an instance or a subclass of TranslationLine and we could probably treat transcription2 the way we treat spokenText) and we have some test files already in development (test_text_Chatino_5Line.py and test_text_Chatino_6Line.py) for those. However, you might prefer working on fixes to webapp.py for the canonical 4-line case first.

Any of the subtasks here you can toss back to me.

Cheers,

David

On Apr 13, 2019, at 8:25 PM, Paul Shannon notifications@github.com wrote:

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-482913099, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhtkDCLn1JARHMa61tRcHpAx5A_qaks5vgpF8gaJpZM4bpTUg.

[paul-shannon]

Hi David,

Very cool to see all the tests run and pass!

In response to your list of to-do items, I propose that

• you close all the issues which have been resolved
• I focus exclusively on webapp.py until you judge it ready for outside users
• you develop the translation2 capabilities in a separate branch which we merge after you are satisfied with it, and when webapp.py is ready

I will open a new set of github issues which include the things we have discussed (get rid of the “create web page button”; disable options which, at any point in the flow, do not yet make sense) and some new ones. One of these is to automatically close the content of each stage once it successfully completes - if you like that idea. See screenshots below.

UI webapp flow-of-control programming - getting it right - is almost always frustrating and slow. But leavened for me here by the prospect of getting it done, of then opening up slexil to users, and then I get back to the Harry Moses story.

I re-read some Robert Bringhurst last night. I am keen to pursue things not unlike his claims for similarity and overlap, or at least some formal echoes, between language and biological/ecological intricacies. Dopey though this may sound, I see such overlaps and echoes between the Mink and Raven story and the molecular mechanisms of photosynthesis. Both “peel off” a bit of daylight, put that daylight to some (inefficient) good use, bumbling and error included along the way. Both fuel the formation of downstream structures - all and everything around us. Not sure just how to pursue this yet, but I have the sense that something interesting could be done. I may experiment with a webapp that juxtaposes molecular animations of photosystem II and interlinear presentation of the story. There are a thousand ways to do this which would fall flat. But maybe a couple of ways I might stumble onto in which justice is done to both narratives, each somehow illuminating the other.

But first, let’s get webapp.py right and running.

• Paul

Screenshots suggesting an “assisted flow” through the upload process:

The webapp could automatically close the sub-UI for a step in the process, after a second or two of display:

the body will then automatically close, and then you will see the next step open up, prompting you to your next action:

On Apr 14, 2019, at 8:00 AM, David Beck notifications@github.com wrote:

Grr. Try now—I thought I’d pushed but maybe I pulled …

I would say that that next logical steps would be, after you check and clean up my tweaks, would be to resolve the issues on GitHub. Of these, I see

1) EAF file to test for quotes added (should be taken care of in last push) 2) test_lokono failure (ditto) 3) order of operations (outstanding) 4) Toggle caps (should be taken care of in last push) 5) demo8.py (seems to not to have anything unresolved in it, though it does contain a premature express of my having figured out git …) 6) how the tier guide works (seems resolved) 7) disparity between display web age and .html (the main issue is resolved by last push, but it raises a new outstanding task which I’ll open as a new issue, “reducing steps at last stage”) 8) introductory video (remains on to do list, but comes last) 9) eaf xml schema v3.0 (there is only a comment here—if I follow you, we’d not link to www.mpi to maintain an up-to-date schema for ELAN files. This should be okay, though future change to ELAN might mean manual maintenance of slexil down the road) 10) URL not found on server (seems not to have re-occurred, so I’d say it’s resolved) 11) webpage, once created, needs to be self-contained (this seems to be the case now with the possible exception of ijal.css and maybe the ESD referred to in issue #9) 12) rendering flaws and fixes (should be taken care of in last push)

So, it looks to me that 1, 2, 4, 5, 6, 7, 9, 10, and 12 are resolved and/or need no further attention. If you agree, we can close them or whatever you do on GitHub to move them off stage. Issue 11 may be done but if not is almost certainly a trivial fix.

Issues 3 and the new 13 seem like the next things to think about, and they both affect webapp.py. I don’t know if you want to start tinkering with that, or if you want to think about extending ijalLine to handle translation2 and transcription2 first. The latter seems pretty straightforward to me (translation2 is either an instance or a subclass of TranslationLine and we could probably treat transcription2 the way we treat spokenText) and we have some test files already in development (test_text_Chatino_5Line.py and test_text_Chatino_6Line.py) for those. However, you might prefer working on fixes to webapp.py for the canonical 4-line case first.

Any of the subtasks here you can toss back to me.

Cheers,

David

On Apr 13, 2019, at 8:25 PM, Paul Shannon notifications@github.com wrote:

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-482913099, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhtkDCLn1JARHMa61tRcHpAx5A_qaks5vgpF8gaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Okay, I closed the issues that seem completely resolved. I’ll look into the additional line capabilities on a new branch, hopefully without further git mishaps.

Yes, it seems like we’re close.

I’m curious to see the webapp you describe below.

David

On Apr 14, 2019, at 9:55 AM, Paul Shannon notifications@github.com wrote:

Hi David,

Very cool to see all the tests run and pass!

In response to your list of to-do items, I propose that

• you close all the issues which have been resolved
• I focus exclusively on webapp.py until you judge it ready for outside users
• you develop the translation2 capabilities in a separate branch which we merge after you are satisfied with it, and when webapp.py is ready

I will open a new set of github issues which include the things we have discussed (get rid of the “create web page button”; disable options which, at any point in the flow, do not yet make sense) and some new ones. One of these is to automatically close the content of each stage once it successfully completes - if you like that idea. See screenshots below.

UI webapp flow-of-control programming - getting it right - is almost always frustrating and slow. But leavened for me here by the prospect of getting it done, of then opening up slexil to users, and then I get back to the Harry Moses story.

I re-read some Robert Bringhurst last night. I am keen to pursue things not unlike his claims for similarity and overlap, or at least some formal echoes, between language and biological/ecological intricacies. Dopey though this may sound, I see such overlaps and echoes between the Mink and Raven story and the molecular mechanisms of photosynthesis. Both “peel off” a bit of daylight, put that daylight to some (inefficient) good use, bumbling and error included along the way. Both fuel the formation of downstream structures - all and everything around us. Not sure just how to pursue this yet, but I have the sense that something interesting could be done. I may experiment with a webapp that juxtaposes molecular animations of photosystem II and interlinear presentation of the story. There are a thousand ways to do this which would fall flat. But maybe a couple of ways I might stumble onto in which justice is done to both narratives, each somehow illuminating the other.

But first, let’s get webapp.py right and running.

• Paul

Screenshots suggesting an “assisted flow” through the upload process:

The webapp could automatically close the sub-UI for a step in the process, after a second or two of display:

the body will then automatically close, and then you will see the next step open up, prompting you to your next action:

On Apr 14, 2019, at 8:00 AM, David Beck notifications@github.com wrote:

Grr. Try now—I thought I’d pushed but maybe I pulled …

I would say that that next logical steps would be, after you check and clean up my tweaks, would be to resolve the issues on GitHub. Of these, I see

1) EAF file to test for quotes added (should be taken care of in last push) 2) test_lokono failure (ditto) 3) order of operations (outstanding) 4) Toggle caps (should be taken care of in last push) 5) demo8.py (seems to not to have anything unresolved in it, though it does contain a premature express of my having figured out git …) 6) how the tier guide works (seems resolved) 7) disparity between display web age and .html (the main issue is resolved by last push, but it raises a new outstanding task which I’ll open as a new issue, “reducing steps at last stage”) 8) introductory video (remains on to do list, but comes last) 9) eaf xml schema v3.0 (there is only a comment here—if I follow you, we’d not link to www.mpi to maintain an up-to-date schema for ELAN files. This should be okay, though future change to ELAN might mean manual maintenance of slexil down the road) 10) URL not found on server (seems not to have re-occurred, so I’d say it’s resolved) 11) webpage, once created, needs to be self-contained (this seems to be the case now with the possible exception of ijal.css and maybe the ESD referred to in issue #9) 12) rendering flaws and fixes (should be taken care of in last push)

So, it looks to me that 1, 2, 4, 5, 6, 7, 9, 10, and 12 are resolved and/or need no further attention. If you agree, we can close them or whatever you do on GitHub to move them off stage. Issue 11 may be done but if not is almost certainly a trivial fix.

Issues 3 and the new 13 seem like the next things to think about, and they both affect webapp.py. I don’t know if you want to start tinkering with that, or if you want to think about extending ijalLine to handle translation2 and transcription2 first. The latter seems pretty straightforward to me (translation2 is either an instance or a subclass of TranslationLine and we could probably treat transcription2 the way we treat spokenText) and we have some test files already in development (test_text_Chatino_5Line.py and test_text_Chatino_6Line.py) for those. However, you might prefer working on fixes to webapp.py for the canonical 4-line case first.

Any of the subtasks here you can toss back to me.

Cheers,

David

On Apr 13, 2019, at 8:25 PM, Paul Shannon notifications@github.com wrote:

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-482913099, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhtkDCLn1JARHMa61tRcHpAx5A_qaks5vgpF8gaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-483004702, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhknGdZYOCsK7HSbKgRVXgC6hmpZbks5vg09_gaJpZM4bpTUg.

[davidjamesbeck]

Hi, Paul

I have amended IjalLine to accommodate a second translation and a second transcription on a new branch in the repo. It looks like I succeeded in actually keeping everything I changed on the branch. All the tests pass and the HTML output looks good.

David

On Apr 14, 2019, at 9:55 AM, Paul Shannon notifications@github.com wrote:

Hi David,

Very cool to see all the tests run and pass!

In response to your list of to-do items, I propose that

• you close all the issues which have been resolved
• I focus exclusively on webapp.py until you judge it ready for outside users
• you develop the translation2 capabilities in a separate branch which we merge after you are satisfied with it, and when webapp.py is ready

I will open a new set of github issues which include the things we have discussed (get rid of the “create web page button”; disable options which, at any point in the flow, do not yet make sense) and some new ones. One of these is to automatically close the content of each stage once it successfully completes - if you like that idea. See screenshots below.

UI webapp flow-of-control programming - getting it right - is almost always frustrating and slow. But leavened for me here by the prospect of getting it done, of then opening up slexil to users, and then I get back to the Harry Moses story.

I re-read some Robert Bringhurst last night. I am keen to pursue things not unlike his claims for similarity and overlap, or at least some formal echoes, between language and biological/ecological intricacies. Dopey though this may sound, I see such overlaps and echoes between the Mink and Raven story and the molecular mechanisms of photosynthesis. Both “peel off” a bit of daylight, put that daylight to some (inefficient) good use, bumbling and error included along the way. Both fuel the formation of downstream structures - all and everything around us. Not sure just how to pursue this yet, but I have the sense that something interesting could be done. I may experiment with a webapp that juxtaposes molecular animations of photosystem II and interlinear presentation of the story. There are a thousand ways to do this which would fall flat. But maybe a couple of ways I might stumble onto in which justice is done to both narratives, each somehow illuminating the other.

But first, let’s get webapp.py right and running.

• Paul

Screenshots suggesting an “assisted flow” through the upload process:

The webapp could automatically close the sub-UI for a step in the process, after a second or two of display:

the body will then automatically close, and then you will see the next step open up, prompting you to your next action:

On Apr 14, 2019, at 8:00 AM, David Beck notifications@github.com wrote:

Grr. Try now—I thought I’d pushed but maybe I pulled …

I would say that that next logical steps would be, after you check and clean up my tweaks, would be to resolve the issues on GitHub. Of these, I see

1) EAF file to test for quotes added (should be taken care of in last push) 2) test_lokono failure (ditto) 3) order of operations (outstanding) 4) Toggle caps (should be taken care of in last push) 5) demo8.py (seems to not to have anything unresolved in it, though it does contain a premature express of my having figured out git …) 6) how the tier guide works (seems resolved) 7) disparity between display web age and .html (the main issue is resolved by last push, but it raises a new outstanding task which I’ll open as a new issue, “reducing steps at last stage”) 8) introductory video (remains on to do list, but comes last) 9) eaf xml schema v3.0 (there is only a comment here—if I follow you, we’d not link to www.mpi to maintain an up-to-date schema for ELAN files. This should be okay, though future change to ELAN might mean manual maintenance of slexil down the road) 10) URL not found on server (seems not to have re-occurred, so I’d say it’s resolved) 11) webpage, once created, needs to be self-contained (this seems to be the case now with the possible exception of ijal.css and maybe the ESD referred to in issue #9) 12) rendering flaws and fixes (should be taken care of in last push)

So, it looks to me that 1, 2, 4, 5, 6, 7, 9, 10, and 12 are resolved and/or need no further attention. If you agree, we can close them or whatever you do on GitHub to move them off stage. Issue 11 may be done but if not is almost certainly a trivial fix.

Issues 3 and the new 13 seem like the next things to think about, and they both affect webapp.py. I don’t know if you want to start tinkering with that, or if you want to think about extending ijalLine to handle translation2 and transcription2 first. The latter seems pretty straightforward to me (translation2 is either an instance or a subclass of TranslationLine and we could probably treat transcription2 the way we treat spokenText) and we have some test files already in development (test_text_Chatino_5Line.py and test_text_Chatino_6Line.py) for those. However, you might prefer working on fixes to webapp.py for the canonical 4-line case first.

Any of the subtasks here you can toss back to me.

Cheers,

David

On Apr 13, 2019, at 8:25 PM, Paul Shannon notifications@github.com wrote:

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-482913099, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhtkDCLn1JARHMa61tRcHpAx5A_qaks5vgpF8gaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-483004702, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhknGdZYOCsK7HSbKgRVXgC6hmpZbks5vg09_gaJpZM4bpTUg.

[paul-shannon]

Excellent. Do you want to create a pull request (a “PR” in the lingo) so I can take a look as we merge these changes into the master branch?

I hope to make progress on the UI this weekend.

• Paul

On Apr 17, 2019, at 11:40 AM, David Beck notifications@github.com wrote:

Hi, Paul

I have amended IjalLine to accommodate a second translation and a second transcription on a new branch in the repo. It looks like I succeeded in actually keeping everything I changed on the branch. All the tests pass and the HTML output looks good.

David

On Apr 14, 2019, at 9:55 AM, Paul Shannon notifications@github.com wrote:

Hi David,

Very cool to see all the tests run and pass!

In response to your list of to-do items, I propose that

• you close all the issues which have been resolved
• I focus exclusively on webapp.py until you judge it ready for outside users
• you develop the translation2 capabilities in a separate branch which we merge after you are satisfied with it, and when webapp.py is ready

I will open a new set of github issues which include the things we have discussed (get rid of the “create web page button”; disable options which, at any point in the flow, do not yet make sense) and some new ones. One of these is to automatically close the content of each stage once it successfully completes - if you like that idea. See screenshots below.

UI webapp flow-of-control programming - getting it right - is almost always frustrating and slow. But leavened for me here by the prospect of getting it done, of then opening up slexil to users, and then I get back to the Harry Moses story.

I re-read some Robert Bringhurst last night. I am keen to pursue things not unlike his claims for similarity and overlap, or at least some formal echoes, between language and biological/ecological intricacies. Dopey though this may sound, I see such overlaps and echoes between the Mink and Raven story and the molecular mechanisms of photosynthesis. Both “peel off” a bit of daylight, put that daylight to some (inefficient) good use, bumbling and error included along the way. Both fuel the formation of downstream structures - all and everything around us. Not sure just how to pursue this yet, but I have the sense that something interesting could be done. I may experiment with a webapp that juxtaposes molecular animations of photosystem II and interlinear presentation of the story. There are a thousand ways to do this which would fall flat. But maybe a couple of ways I might stumble onto in which justice is done to both narratives, each somehow illuminating the other.

But first, let’s get webapp.py right and running.

• Paul

Screenshots suggesting an “assisted flow” through the upload process:

The webapp could automatically close the sub-UI for a step in the process, after a second or two of display:

the body will then automatically close, and then you will see the next step open up, prompting you to your next action:

On Apr 14, 2019, at 8:00 AM, David Beck notifications@github.com wrote:

Grr. Try now—I thought I’d pushed but maybe I pulled …

I would say that that next logical steps would be, after you check and clean up my tweaks, would be to resolve the issues on GitHub. Of these, I see

1) EAF file to test for quotes added (should be taken care of in last push) 2) test_lokono failure (ditto) 3) order of operations (outstanding) 4) Toggle caps (should be taken care of in last push) 5) demo8.py (seems to not to have anything unresolved in it, though it does contain a premature express of my having figured out git …) 6) how the tier guide works (seems resolved) 7) disparity between display web age and .html (the main issue is resolved by last push, but it raises a new outstanding task which I’ll open as a new issue, “reducing steps at last stage”) 8) introductory video (remains on to do list, but comes last) 9) eaf xml schema v3.0 (there is only a comment here—if I follow you, we’d not link to www.mpi to maintain an up-to-date schema for ELAN files. This should be okay, though future change to ELAN might mean manual maintenance of slexil down the road) 10) URL not found on server (seems not to have re-occurred, so I’d say it’s resolved) 11) webpage, once created, needs to be self-contained (this seems to be the case now with the possible exception of ijal.css and maybe the ESD referred to in issue #9) 12) rendering flaws and fixes (should be taken care of in last push)

So, it looks to me that 1, 2, 4, 5, 6, 7, 9, 10, and 12 are resolved and/or need no further attention. If you agree, we can close them or whatever you do on GitHub to move them off stage. Issue 11 may be done but if not is almost certainly a trivial fix.

Issues 3 and the new 13 seem like the next things to think about, and they both affect webapp.py. I don’t know if you want to start tinkering with that, or if you want to think about extending ijalLine to handle translation2 and transcription2 first. The latter seems pretty straightforward to me (translation2 is either an instance or a subclass of TranslationLine and we could probably treat transcription2 the way we treat spokenText) and we have some test files already in development (test_text_Chatino_5Line.py and test_text_Chatino_6Line.py) for those. However, you might prefer working on fixes to webapp.py for the canonical 4-line case first.

Any of the subtasks here you can toss back to me.

Cheers,

David

On Apr 13, 2019, at 8:25 PM, Paul Shannon notifications@github.com wrote:

Hi David,

I just tried to catch up to your versions, but “git pull” told me I was up to date. Maybe, if I am not too confused about all this, you need to do a push?

What would you like me to work on next?

• Paul

On Apr 7, 2019, at 6:19 PM, David Beck notifications@github.com wrote:

Hi, Paul

I had some success on one of today’s projects and a major setback on another, which freed up some time to tinker with slexil. I think I’ve written early versions of the new classes for handling glosses and have them working properly together, and I’ve updated IjalLine to work with them and the TranslationLine class I wrote a while back. After adjusting the tests to check for the output we actually want from everything and providing grammaticalTerms files to the test_data folders, all the tests in makefile seem to work. So, unless I’ve miscalculated again, we may be a bit more advanced now than we were this morning.

David

On Apr 7, 2019, at 11:26 AM, Paul Shannon notifications@github.com wrote:

All sounds good, David!

On Apr 7, 2019, at 8:09 AM, David Beck notifications@github.com wrote:

Using n-dashes is particular to IJAL and so contributors usually make the change from hyphens on submission, and typically miss things. Making the change right away avoids any problems that inconsistency might cause. So, for the moment I’ll just leave it where it is until you tell me where the function is best located.

I already have some plain (non-class) functions at the bottom of ijalLine.py:

findChildren buildTable standardizeTable

This could be a good place for replaceHyphensWithNDashes also. It could also be the first function in a new ijalUtils.py. In either place, MorphemeGloss and whoever will be able to find it.

I like your idea of applying it and any similar broad spectrum text fixups early to every tier of every line.

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-480612203, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhkZAFgMGtdRXwPcCmHVRUmzHxTeoks5veipagaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-482913099, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhtkDCLn1JARHMa61tRcHpAx5A_qaks5vgpF8gaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/13#issuecomment-483004702, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhknGdZYOCsK7HSbKgRVXgC6hmpZbks5vg09_gaJpZM4bpTUg.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.