Homograph number in Interlinear text analysis

18 views
Skip to first unread message

Aaron Broadwell

unread,
Feb 10, 2012, 4:02:03 AM2/10/12
to FLEx list
I've used the Configure Homograph Number dialogue (under the Tools
menu) to hide the homograph number in the Lexicon. Nevertheless, I
continue to see the numbers in the Lexical Entry line for analysed
text, e.g.


Word Soj me ranga' rihaan cuan' ne̱ .
Morphemes soj me ranga' rihaan cuan' ne̱
Lex. Entries zoj³ me³ [3] ranga'³[1] riaan³²[1] cuan'³ ne²[1]
Lex. Gloss you (pl) be buenos dias to today and
‎Free ‎Spn‎ ‎‎Ustedes que aún están en la alborada,
‎Eng‎ ‎‎To those who rose before the sun

(On my screen, the numbers in [ ] are subscripted, but that doesn't
display correctly in this post.)

The me³ that appears in this sentence is homograph 3 of entries
spelled me³.

I am finding the combination of superscript tone number + subscript
homograph number a bit unsightly, but I cannot find a way to suppress/
hide the homograph number.

I tried editing the style of Homograph Numbers to choose White as the
font color, but that doesn't seem to work either.

Does anyone have suggestions? (I am using 7.2.2)

Susanna

unread,
Feb 14, 2012, 3:55:02 PM2/14/12
to FLEx list
Oh, I hate when I find we've been incomplete! We'll have to do a more
thorough job of that new feature by the sounds of things. I can't
think of a workaround, sorry.
-Susanna

Jon C

unread,
Feb 14, 2012, 4:27:08 PM2/14/12
to FLEx list
Aaron,

I don't know of a *good* workaround either, but I did just test a
tedious one out (in 7.2.2) and it worked.

FLEx allows you to add Homograph Number as a column, filter it (e.g.
for value > 0), and manually enter any numbers you like. If you enter
the number 0 (or just delete/backspace), that effectively removes the
number from that entry. You could conceivably do this for all of your
entries, and then maybe run the Reassign Homographs utility (under
Tools, Utilities) at a later date should you decide you need the
numbers for publishing a dictionary. (But their order would then be
arbitrary.)

Unfortunately, though, this field is not bulk-editable, so the set-
to-0 step in this workaround would be very tedious. It might possibly
be worth it in your case, though, since it sounds like you don't ever
want homograph numbers anyway.

Jon

Aaron Broadwell

unread,
Feb 14, 2012, 11:13:44 PM2/14/12
to FLEx list
Hi Jon and Susana,

Thanks for the reply -- I'm glad to know that I wasn't overlooking
something in the options menus!

If a fix will eventually arrive in FLEx, I think I keep the entries
and homograph numbers in the project the same for now. We're
preparing a text for export to Open Office and publication, so I think
I will experiment with find and replace options for the subscripts in
the exported version. As a last resort, we have a work-study student
in the office who can go through and delete them :-)

Aaron

Jon C

unread,
Feb 15, 2012, 4:06:51 AM2/15/12
to FLEx list
You know, I was thinking that there might be a better way of "bulk-
deleting" all homograph numbers:
- Export the lexicon as a LIFT file.
- Use global find/replace to set all homograph numbers to zero (or
blank?).
- Import the LIFT file. (Since this does a merge for all items with
identical IDs, it's one way to do a home-grown bulk edit.)

However, when I tried it just now, I found that the LIFT file doesn't
contain a specific field for homograph number. Instead, it includes it
in the ID label, which precedes the ID and is separated by an
underscore. Here's the line for the entry mpuu[3]:

<entry dateCreated="2009-11-11T03:07:09Z"
dateModified="2012-02-15T08:49:56Z" id="mpuu3_9f83deb4-79d1-4165-a639-
c1173bb44c9d" guid="9f83deb4-79d1-4165-a639-c1173bb44c9d" order="2">

I used a regular expression in Notepad++ to replace this:
(id="[a-zA-Z]*)[0-9]+_
with this:
\1_

The parens saves what we want into a variable (\1) and we simply
discard the number.

But then when I imported back into FLEx, it ignored these changes to
the labels. So, maybe this strategy simply won't work (alas for work-
study students), or maybe I did something wrong.

Jon

D.Rowe

unread,
Feb 15, 2012, 4:23:33 AM2/15/12
to flex...@googlegroups.com
I did this (setting all homograph numbers to 0) using Craig Farrow's
FlexTools in Flex version 6. I'm not sure when this tool will be
available for Flex version 7.

David Rowe

----- Original Message -----
From: Jon C <jvco...@gmail.com>
To: FLEx list <flex...@googlegroups.com>
Subject: [FLEx] Re: Homograph number in Interlinear text analysis

Beth (work) Bryson

unread,
Feb 15, 2012, 11:44:19 AM2/15/12
to flex...@googlegroups.com
I would think that messing with id numbers would be a Really Bad Idea, at least if you ever plan to do anything with merging databases. This is how FLEx/WeSay/other LIFT tools know which entries are the same as each other. I would think this would be highly unrecommended.

-Beth

> --
> You received this message because you are subscribed to the discussion group "FLEx list". This group is hosted by Google Groups and is open for anyone to browse.
> To post to this group, send email to flex...@googlegroups.com
> To unsubscribe from this group, send email to flex-list+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/flex-list

Jon C

unread,
Feb 15, 2012, 1:23:28 PM2/15/12
to FLEx list
Right. Definitely something to be careful with.

I was only touching the part prior to the underscore, which I'm
referring to as the "label". My understanding is that this is
technically not part of the guid, and that the guid is just the part
*after* the underscore.

In a quick test just now, I changed
id="dunia_0e8c771e-f620-4067-a37a-5f73f162dfa1"
to
id="xyz33_0e8c771e-f620-4067-a37a-5f73f162dfa1"
in the LIFT file, and edited that entry's definition. (I'm not saying
that changing the core label like this is a good idea! Just a test.)

Then, when I imported it into FLEx (choosing the "overwrite" option),
it found the matching record and updated its definition correctly. So
I'm pretty sure it's not relying on the label under normal
circumstances. (Maybe it uses the label when it can't find an exact
guid match? I don't know.)

Jon

On Feb 16, 12:44 am, "Beth (work) Bryson" <Beth-work_Bry...@sil.org>
wrote:
Reply all
Reply to author
Forward
0 new messages